Posted at: 8:45 AM on 12 September 2014 by David Radford
We all love filling out forms, especially those in Human Resources- making sure that every employee has the newest iteration of city/district/state withholding forms completed on time makes the day fly by. There are those however, who look at this as a waste of time- most of the information already exists in SharePoint, so why can’t the completion of these forms just be automated in a way that presents them in a format acceptable for submission?
So, what’s the solution..? Why not just use the actual form that needs filling out as a template and then simply watermark the required data into it? List item fields are stored in SharePoint and can be accessed using Muhimbi’s great XML watermarking format, so this is actually quite easy.
To keep this example simple, we’ll start out with a plain SharePoint list that contains a number of custom columns holding basic personal information:
We then place a PDF copy of the form to be filled out, in this case a U.S. W-9, in a library accessible to the workflow.
Our example uses a simple workflow that watermarks this PDF using our XML syntax that can pull in the list item data as the content for the watermark. There are a couple of things to note about this action. It does not run against the list item that started the workflow, but rather the source W-9 PDF that we are watermarking, so that document’s Source List ID and List Item is specified. As well, since we are adding the watermark content from the list item, we have copied that content to workflow variables so it’s referenced properly, no matter what item is being worked on.
The following screenshot shows our software being used in Nintex workflow, but it works equally well in SharePoint Designer workflows and Visual Studio workflows. A basic understanding of workflows is required, if needed you can learn about SharePoint Designer workflows here and Nintex workflows here.
This sample XML places the first and last name of the user (as defined in the First and Last workflow variables) in the correct location:
<watermarks><!—** First Watermark inserts the First Name --><watermarkhPosition="absolute"vPosition="absolute"x="40"
The placement of the watermarks is specified using the specific coordinates of where the data needs to be placed. The coordinates are specified in Points (1/72nd of an inch). After running the workflow on the two items in the list, we get 2 separate PDFs with the custom information watermarked into them.
David Radford W-9.pdf
Bob Denver W-9.pdf
Once this is in place, it is very simple to just modify the watermarking action to move the data to different locations, allowing multiple different forms to be filled out in a single workflow. As well, when forms change slightly, all that needs to be done is change the coordinates of the fields that moved, and everything works again.
Posted at: 10:55 AM on 11 September 2014 by David Radford
Government compliance guidelines and corporate retention policies are always changing- and rarely in a way that makes things easier for the IT staff. Long forgotten documents, saved in obsolete formats can all of a sudden need to be formally archived or made accessible to staff- all with very little notice. Once that happens, the ‘archive’ directory on the old file server in the corner can quickly turn into a nightmare- “Does anyone know where the IBM DisplayWrite install disks went?”
Adding 3rd party converters is a great way to add support for your legacy formats, while still being able to leverage our Converter’s latest and greatest features. The sky is really the limit- you could create a workflow that converts, watermarks, copies meta-data, and merges a brand new InfoPath form to old dBase database tables and then, without any modification, could turn around and do the same for an AutoCad file and DisplayWrite document!
If you’re using the Muhimbi PDF Converter Services, your own code does not require any modification to allow users to use the same process to submit any of the listed file types to it- once integrated with Muhimbi’s Converter, these formats can be manipulated like any other. Who would ever have thought that you’d be able to convert file formats that are 40 years old using a modern web services based API using Java, C#, Ruby and PHP.
As these formats are obsolete and not in high demand, we didn’t hold out much hope of finding a relatively modern Converter for them. Luckily, we were wrong, and a bit of searching led us to Advanced Computer Innovations Inc. and their FileMerlin product. FileMerlin supports conversion of a dizzying array of file formats and some deserve special attention.
The Muhimbi Converter does not support Microsoft Access (or other database formats) conversion as achieving the fidelity we demand from our own conversions would require a considerable effort for something that is not in very high demand. FileMerlin provides good conversion of MS Access, dBase, FoxPro, Microsoft Jet, along with other database formats. Trying to convert the look and feel of a database to file obviously doesn’t work, but for extracting table data, it does quite well.
Word Processor Conversion
By far the largest selection of conversion options is in the word processor arena. This provides conversion for formats like the aforementioned DisplayWrite, as well as WordPerfect, WordStar, Lotus Manuscript, among many others. Again, the conversion fidelity on these is not perfect, but it is good and most importantly, does not require you to find these old applications in order to open and save them into a more accessible format.
Microsoft Office Conversion
FileMerlin supports the conversion of the most common MS Office file formats (Word, Excel, PowerPoint). Since these conversion do not use MS Office in the background like Muhimbi’s Converters, their fidelity is not as good and newer Office formats can cause some problems as well. That being said, in an environment where installing MS Office to support conversions is not an option, this could be a good solution.
So, how do you get this working? The process is pretty much the same as for our other 3rd party converters. Starting with the assumption that the Converter for SharePoint or Converter Services has already been installed, the following steps need to be carried out:
Modify the ‘Muhimbi.DocumentConverter.Service.exe.config’ file as described here and add the following entry to the<MuhimbiDocumentConverters> section. This tells the Converter what file types can be Converted to PDF. If you installed the 3rd party software in a different path then please update the content of the parameter attribute.
If you want to convert other formats as well, you will need to change the supportedExtensions and/or the supportedOutputFormats entries to include the file type extensions you want to convert. As well, you will need to change the sfrm and dfrm fields as well. FileMerlin can support auto detection of file types, however it is much more reliable to specify them manually and simply add the required 3rd party convert entries for each type.
Normally, we’d add some before and after samples of something like a DisplayWrite file conversion, but the boiler for our DisplayWriter terminal is out of coal, so we’ll have to stick with something a bit more current, an MS-Word conversion to PDF. The image on the right is the document as displayed in MS-Word and the one on the left is the PDF converted by FileMerlin as seen in a PDF viewer. You’ll notice that the fidelity is not as good as our native converter, however it should give a good representation of the conversions that can be expected with this tool.