Muhimbi

Posted at: 5:40 PM on 01 December 2009 by Muhimbi

We were recently contacted by a customer who uses our PDF Converter for SharePoint as a workaround for the lack of batch printing support in InfoPath. Their business case was somewhat unusual as they had to print thousands of InfoPath forms that were sitting in a document library and then ship these documents off-site.

Under normal circumstances, e.g. when using MS-Word documents, you can simply select a number of documents using Windows File Explorer, right click and select the Print option from the context menu. InfoPath, however, does not support this Print context menu.

Fortunately PDF files can be printed in batch using the Print context menu, so some clever boffin came up with the idea to use our product to convert an InfoPath form to PDF format as soon as it is posted to the Forms Library. They would then periodically copy the PDF files to a local system and batch print them.

This is very simple to achieve using a SharePoint Designer workflow. We have blogged about this before, but in summary this is how you can make it work.

1. Download and install the PDF Converter for SharePoint.
    
2. If not already installed, download and install the free SharePoint Designer,
    
3. Create a simple SharePoint Designer workflow to automatically convert any new or updated document in a library to PDF format as described in this posting.
    

   

4. Periodically copy a batch of converted PDF files from SharePoint to your local drive using a Library’s Actions / Open with Windows Explorer menu.
    
5. Select the batch of PDF files on your local system, right-click on one of the files and select the Print option.
    

That’s it. A workaround, but a pretty good one if you need it.

.

Labels: Articles, InfoPath, News, PDF Converter, Products, Workflow

Posted at: 5:09 PM on 24 November 2009 by Muhimbi

When we started the development cycle for version 3 of our PDF Converter for SharePoint, we decided to make ‘reliable InfoPath to PDF Conversion’ one of the main deliveries of the new version. There has been a lot of customer demand for it and well…. how difficult can it be…?

… pretty difficult it turned out. InfoPath is a complex product that is much more than a simple forms designer. It allows connectivity with external data sources such as SharePoint Lists and Web Services,  and forms to be hosted and filled out inside SharePoint using Forms Services.

With the release of version 3.0 I believe we have delivered a great product that has already been implemented in Production environments by some of our keenest beta testers. Deployment, however, may require some planning depending on your environment and settings. This article provides an architectural overview of how we deal with InfoPath to PDF conversion and provides some helpful pointers to troubleshoot InfoPath conversion in your environment.

PDF Converter Architecture

The architecture behind the PDF converter is relatively straight forward. There are 2 main components:

1. SharePoint Front End: A SharePoint WSP solution that is deployed to all Web Front End Servers. This contains all SharePoint related logic including end user screens as well as Central Administration screens and Workflow Actions. The Front End doesn’t carry out any conversion, instead it offloads all conversion to the Muhimbi Document Converter Windows Service.
    
2. Muhimbi Document Converter Windows Service (MDCS): A Windows service which can be hosted on the actual Web Front End server or on a completely separate (virtual) machine. This service accepts conversion requests via WCF Web Service calls from the SharePoint server and carries out the actual conversion.
    

Although the following is a simplification, when MDCS receives a request for conversion of an InfoPath form it carries out the following steps:

1. Load the XSN file that is associated with the InfoPath data file.
    
2. Pass the InfoPath data and XSN files to InfoPath for conversion.
    
3. Depending on the complexity of the form, InfoPath may make requests to external data sources such as SharePoint Lists or Web Services.

Step #1 may fail for a number of reasons, most notably:

1. The XSN file is not in the expected location. This may happen when the InfoPath data file is copied from a completely different environment. Many users don’t realise that without the XSN file an InfoPath data file does not know how to visually represent itself.
    
2. The service account that MDCS is running under does not have the privileges to load the XSN file from SharePoint.

Step #2 may fail for different reasons, for example:

1. InfoPath is not installed on the machine that hosts MDCS.
    
2. MDCS is running using an account that does not have local Administration rights.
    
3. InfoPath has never been launched by the MDCS Service account using an interactive session.
    
4. The XSN file and data sources are hosted at locations that are not ‘trusted’.

Troubleshooting steps

The Administration Guide that ships with the product contains a comprehensive troubleshooting section. A separate  Troubleshooting Guide is available as well. The main points are repeated below.

1. Connectivity test: The first test to carry out is to verify connectivity and authentication between SharePoint and the Document Converter Service. Navigate to Central Admin / Application Management / Muhimbi Document Converter Settings, verify the Address of the Web Service and click the Test Button.
   
   
   
    
2. Validate Converters: Once the connectivity and authentication test has completed successfully, select the converters to validate and click the Validate Settings button. The result of the test are displayed underneath the button. If any of the converters failed then the Windows Application Event Log will contain additional details.
    
3. Printer Spooler & Drivers: InfoPath requires the Printer Spooler service to be started as well as a single printer driver to be installed. Although in general it doesn’t matter which driver is installed, some drivers such as VMWare’s Virtual Printer or the OneNote printer will cause problems. Windows Server 2003 R2 and Windows Server 2008 automatically install the XPS driver and the Muhimbi Service installer attempts to start the Spooler Service. Unless you have taken specific actions to disable the Spooler Service and removed all printer drivers, all should work as expected. Note that printers connected via a remote desktop session do not count as they disappear after the session is disconnected.
    
4. Check Trust settings:  When an InfoPath document containing external connections, e.g. a dropdown list with the contents of a SharePoint list, fails to convert then this may be caused by the location of the XSN file not being trusted or the Access data sources across domains setting not being enabled for the trusted site.
   
   Full details about how to check these settings can be found in section 3.5.8 of the Administration Guide.
    
5. Verify access to XSN file: If the log files contain messages listing ‘Access denied’, ‘Unauthorized’ or ‘401’ related errors then MDCS was unable to retrieve the XSN file. Make sure the MDCS Service account can access the XSN file using the following steps:
   
   
   • Open the InfoPath XML data file in notepad and retrieve the address of the XSN file from the  first line.
   • Log-in interactively using the MDCS Service Account. 
   • Try to open the XSN file in a web browser.
   If  these steps don’t make it clear what the problem is behind the Access Denied messages then it is worth checking the following:
    
   • Check the privileges on the XSN file. The MDCS account requires Read Access. You may want to consider applying Web Application wide Read Access for this account using a SharePoint Policy (http://<your_central_admin/_admin/policy.aspx)
   • Are there any proxy settings defined? You probably want MDCS to bypass any proxies. 
   • Are there any hints in the IIS log file about the reason why access to the XSN file is denied?
      
6. Windows Event Log: If all else fails, look in the Windows Application Event log for all messages
   with Event ID 41734.
    
7. MDCS Trace Log: MDCS uses the industry standard log4net framework to write logging and trace data to a log file. Out-of-the-box information is logged to the DocumentConverter.log file stored in the directory MDCS has been installed in. A new file is created for each day and the default logging level is set to ‘INFO’. To increase the log detail, open the config file in the MDCS root directory, search for the <root> element, change the log level to DEBUG and restart MDCS using the following commands:
   
   Net stop "Muhimbi Document Converter Service"
   Net start "Muhimbi Document Converter Service"

 
If none of the guidance provided in this posting or in the Administration Guide has resolved your particular problem then please contact us directly.

.

Labels: Articles, InfoPath, PDF Converter, Products