Muhimbi's range of server side PDF Conversion products is very popular amongst InfoPath users as we are the only software vendor with a credible solution for converting InfoPath forms to PDF, including attachments and the ability to specify which views to convert. Yes, this post is about PowerApps, not InfoPath, bear with me for a moment while I get to the point.
Although InfoPath is still popular amongst our customers, it is no longer actively developed by Microsoft. Similar to many other organisations who operate in the Digital Forms field, we have been keeping an eye out for possible replacements. Nintex Forms is a popular choice for organisations who operate in the SharePoint field, but in the past year another player has emerged; Microsoft's own PowerApps solution, part of Office 365.
For details about how to use our software to convert Nintex Forms - including attachments - to PDF, see this blog post. The focus of this post is on how to use PowerApps to capture data and turn that data into a richly formatted PDF. Please note that this article is NOT about converting the layout of the PowerApp screen to PDF. Due to architectural difficulties, that is currently not possible.
In this post we will:
Create a simple PowerApps form to capture user data.
Create a Microsoft Flow to use the captured data, enrich it with HTML, and convert it to PDF.
Invoke the Flow from PowerApps.
Although the Muhimbi Connector can be added to PowerApps directly, at the time of writing PowerApps does not have any built-in facilities for dealing with the generated PDF file. To keeps thing easy to understand, we carry out the actual PDF generation in Flow, from where the file can be emailed, or passed on to a service such as SharePoint, OneDrive, DropBox etc.
Update (2018): It is now possible to directly interact with the Muhimbi Actions from PowerApps, without the need for Flow. Check out this (3rd party) blog post about how to achieve this.
Prerequisites
Before you begin, please make sure the following prerequisites are in place:
An Office 365 subscription with access to PowerApps and Flow.
The appropriate privileges to create PowerApps and Flows.
Working knowledge of both PowerApps and Flow. This is not a generic tutorial for those technologies.
Building the PowerApp & Associated Flow
Let's begin by creating a PowerApp. It doesn't really matter what it looks like, as long as it contains two text fields named TextEmail and TextName as well as a button named ButtonGenerate. A stylised version of the form can be found in the screenshot below. Note that we also added a Pen Input field, which you may need in the Further Enhancements section.
With the form and various fields in place, create a new Flow using the Flows option in the Action ribbon. Click on the Create a new flow option in the right-hand side pane as per the screenshot above.
The Flow editor is opened and the PowerApps trigger is automatically inserted. Let's begin by giving the Flow a sensible name (the default is PowerApps button), instead name it PowerApps PDF Generator.
Click New step and select the Add an action option. Muhimbi's Flow actions are available out-of-the-box, there is nothing to install, just search for Muhimbi and select the Convert HTML to PDF option from the list. This action can convert URLs to PDF, but also has the option to convert HTML fragments, and... anything is possible in HTML.
If this is the first time you are using a Muhimbi action in Flow then you will be asked to specify your Muhimbi account. If you don't have one, click the Try for free button to create a new subscription.
The sky is the limit when it comes to HTML, but let's not go overboard for this simple example. Insert the following HTML in the Source URL or HTML field.
<html><body style="font-family: Arial"> <h1>PowerApp PDF Demo</h1> <p> <b>Name</b>: <br/> <b>Email</b>: <br/> </p> <p>Generated using <a href="http://www.muhimbi-online.com">www.muhimbi-online.com</a></p> </body></html>
Now, this is where things get slightly tricky. We need to generate the parameters for the data we want to pass from the PowerApp to the Flow, in this case the contents of the TextEmail and TextName fields. To do this, position the cursor behind the semi column (:) after the Name label in the HTML fragment. With the cursor positioned, click the Ask in PowerApps option in the Parameters list, which will insert the incredibly undescriptive parameter named ConvertHTMLtoPDF_SourceURLorHTML.
In a similar fashion position the cursor behind the Email label in the HTML fragment, and click the Ask in PowerApps option again, which will insert and create the ConvertHTMLtoPDF_SourceURLorHTML_1 parameter, oh well, we can clean these names up after the Flow has been created and tested.
Depending on your exact use case, and number of variables that need passing between your PowerApp and Flow, you may want to generate the HTML inside the PowerApp, and pass it as a single parameter into the Flow.
Add another step to process the generated PDF file. The file can be written to SharePoint, OneDrive, DropBox or any other Flow service that knows how to deal with files. In this example we will email the file as an attachment, so insert the Send email action of your choice (there are several services that can send email, we picked the one simply named Mail).
Remember how ConvertHTMLtoPDF_SourceURLorHTML_1 contains the email field? Insert that into the To field (or hardcode an address, it is up to you). Enter a descriptive Subject, Email Body and Attachment file name (under advanced options), make sure the file name ends in '.pdf'.
In the Attachment field, insert the Processed file content field from the Convert HTML to PDF action.
That is our Flow done, it is fairly simple as you can see in the screenshot below.
Save the Flow and return to the PowerApps editor.
With the Generate PDF button selected, select the Flow option in the Action ribbon. Select the newly authored Flow from the list. If you named it the same as we did (PowerApps PDF generator) then a method name will automatically be generated and inserted in the button's OnSelect field. Please make sure the parameters for the name and email are passed in in this order.
That is it, save the form and preview the app (F5). Enter your name and email address, and click the button. After a few seconds you will receive an email with the PDF attachment in your inbox.
Troubleshooting
PowerApps, Flow, a third-party PDF Converter, all excellent products but there are quite a few moving parts in this tutorial. It is not unlikely that you will experience a problem during the development.
If you do experience problems then please have a look at the following:
Ask PowerApps: Please make sure that the number of parameters created by clicking Ask PowerApps matches the number of parameters passed to the Flow in the button's OnSelect event.
Flow Name: Make sure the correct flow name is used in the button's OnSelect event. PowerApps will automatically generate the name, don't just copy the name from our example as it may differ slightly.
Muhimbi account: The first time you interact with the Muhimbi Actions from Flow, you will be asked to login or create an account. If you organisation has a subscription, but you don't know the credentials, then please reach out to the appropriate team or create a new test account.
Muhimbi support: If, after double checking all prerequisites and going over all troubleshooting steps in this section, you are stuck, please contact our friendly support desk, we are here to help
Further enhancements
Although this is a nice and easy to follow, tutorial, we can think of a number of refinements and enhancements that will come in handy in the real world:
Rename Ask PowerApps variables: The names of the parameters generated by Flow are undescriptive. You can actually fix this using the full Flow website (not the more limited version integrated in PowerApps). Export the Flow, unzip it on your local system, rename the variables in the included XML files to something more descriptive, zip the files again, upload the Flow and overwrite the existing one. Then refresh the Flow reference under the button. Telegram style instructions, but they worked for us.
Generating HTML: In the real world it is likely that you have quite a few more parameters that your want to merge into the HTML. Passing them as individual parameters into the Flow is a bit painful, so consider creating the HTML fragment inside the PowerApp and pass it as a single parameter to the Flow.
Insert Pen Input: Implementation of this is beyond the scope of this tutorial, but consider it an interesting exercise. It is not possible to easily pass the bitmap associated with the Pen Input to a flow. However, it is possible to create an Excel Data source in PowerApps and pass images to that data source. This should make it possible to query the location of the image using Flow, copy it to a location where it is accessible for anonymous users and include a reference to the image in the HTML. Easy?....NO. Possible?..... Maybe. Use this as a starting point.
Other output: Conversion is not limited to HTML, it is just a format that is easy for tutorials such as this one. The Muhimbi PDF Converter supports most common file formats, including Word XML.
What do you think, is this something that could work for your organisation? Feel free to leave a comment below or contact our support desk if you have any technical or commercial questions.
We have been a little bit in love with Nintex Workflow ever since we integrated it into the Muhimbi PDF Converter for SharePoint all the way back in the SharePoint 2007 era. Although we started simple with just a basic PDF Conversion workflow action, over the years we added Nintex Workflow support for all our Workflow Actions to make it possible to Convert, Merge, Watermark, Secure and OCR documents.
With more and more companies moving to Office 365, and specifically SharePoint online, the industry's focus is moving towards online services, resulting in such products as the Muhimbi PDF Converter for SharePoint Online and Nintex Workflow for Office 365. Although other workflow engines such as Microsoft Flow, Azure Logic Apps, and the built-in SharePoint Online Workflow Manager make it possible for 3rd parties such as Muhimbi to directly integrate their services, this is currently not possible in Nintex Workflow for Office 365.
We don't like 'not possible' and, as many of our shared customers frequently request Muhimbi / Nintex Workflow for Office 365 integration, we decided to see if perhaps we can implement a workaround to make the two products work together. The workaround that our customers have been using for years (Create a SharePoint Designer Workflow using our workflow actions and invoke that from Nintex Workflow for Office 365) works well, but it is just....well...unsatisfactory. In this post, we'll show how to integrate the functionality exposed by the Muhimbi PDF Converter for SharePoint Online directly into a Nintex Workflow by invoking our comprehensive REST API.
Background
When we first released the Muhimbi PDF Converter for SharePoint Online in early 2015, we were very much aware that - due to technical limitations in the SharePoint Online platform - it would not be possible to bring the full power of our existing on-premise (SP2007-SP2016) products to The Cloud. The first release focused on the most important elements (the PDF Conversion user interface and Workflow Actions for SharePoint Designer), but one of the key features of our on-premise products was missing, an API to allow integration with 3rd party solutions and software partners.
Although our customers are very happy with the comprehensive Web Services (SOAP) interface exposed by our on-premise products, it is less suitable for use by online subscription based services. Instead we decided to go for a brand-new, and much-simplified, REST based interface as that is how modern systems, especially Cloud based products, talk to each other.
This new REST based service was launched earlier this year as part of the Muhimbi PDF Converter API and Server Platform product. A separate product that has no dependencies on SharePoint and can be used to integrate with such services as Microsoft Flow, Azure Logic Apps, C#, Java, PHP, JavaScript, Python Ruby and many other services including ... and here it comes .... Nintex Workflow for Office 365.
The appropriate privileges to deploy these Apps, and author workflows.
Working Knowledge of Nintex Workflow for Office 365. This is not a masterclass in Nintex Workflow for Office 365 development.
Please note that this tutorial is for the SharePoint Online version of Nintex Workflow. For details about using our software in combination with the on-premise (2007-2016) versions of SharePoint, see this Knowledge Base article.
Building the workflow
Let's have some fun and build a workflow! It is strongly recommended to follow the tutorial below, but the workflow is available for download as well. Import it in Nintex Workflow for Office 365, SET THE API KEY, publish it and you are ready to go.
Navigate to a site collection and document library of your choice, one that matches the prerequisites listed above, and choose the option to create a new Nintex Workflow. In this example, we use the standard Shared Document library that is available on most site collections.
Create the following workflow variables as we need them later:
JSON (Text): Contains the JSON, JavaScript Object Notation, the command that will be sent to the conversion service.
API_KEY (Text): A unique ID that will be used to look up your Muhimbi subscription details.
ResponseText (Text): The status message returned by the Conversion Service.
ResponseCode (Integer): The status code returned by the Conversion Service.
As a first step (you should always do this) insert a Set Workflow Status action, edit it and set it to Started. This will show us that the workflow has actually triggered (it is always a guess in SharePoint Online), it will also give us something to click on to inspect the current status of the workflow.
Add a Build String action and set the Output to the JSON workflow variable. In the String field enter the following:
JSON Notation: You may be familiar with JSON notation, but please note that we have replaced the curly braces - { } - with square brackets [ ]. This is due to a bug in Nintex Workflow for Office 365. If you have concerns about using square brackets (as they are also used for Array types) feel free to replace them with anything else. In a follow-up step we will fix them.
Copy & Paste: Be careful when copying this bit of JSON from the browser window. Always paste it in Notepad (and copy back) to strip out non-standard characters and formatting.
References: The text displayed in red are Nintex Workflow references. You can't just copy and paste them and expect it to work, after pasting the entire fragment replace each Nintex reference using the Insert Reference facility (Currently on the right-hand side of the action's edit screen, see screenshot above).
Output file name: In this basic example, we just add '.pdf' to the end of the output path and file name. This is not particularly pretty, but in order to keep things simple we are not including the Nintex Workflow actions to strip off the old extension and add the new one. You can use whatever you like here as long as it is a valid output path and file name.
As mentioned above, we have mangled the JSON by using square brackets, we need to replace them with curly braces again. To do so, insert a Replace Substring in String action and configure it as follows:
Search String: Enter the opening square bracket [.
Replace String: Enter the opening curly brace {.
String: Insert a reference to the workflow variable named JSON.
Output: Pick the JSON workflow variable to store the results in.
Click the Save button and copy the workflow action (using the action's ... menu), and paste it as the next action (click the little square on the workflow's timeline). Configure the newly pasted workflow action and replace the opening bracket with the closing bracket ']'. Do the same for the curly brace and replace '{' with '}'. Save the action, we now have valid JSON that we can send to the Conversion Service.
Before we can talk to the Conversion Service, we need to set the API_KEY. Insert a Set Workflow Variable action and configure it to set the API_KEY workflow variable to the API Key you received by email when signing up for the Muhimbi PDF Converter REST-based API for Server Platform. e.g.:
decafbad-baad-baad-baad-decafbaaaaad
Do not try to use this particular key, it will not work. Also, do not try to be clever and put curly braces around the key.
Save the action, we are almost done!
Insert the Web Request action and configure it as follows:
Add header: Click Add header, specify API_KEY as the Header name and insert a reference to the API_KEY workflow variable for the Header value.
Body: Select the Content option, add a reference to the JSON workflow variable in the Data field.
Store response content in: ResponseText.
Store http status code in: ResponseCode.
Click the Save button.
Finally, insert another Set Workflow Status action and configure it with the text Completed. When we run the workflow, we can now easily see when it has completed.
Your workflow should look something like the following:
We are DONE, at least with the initial version. Publish the workflow, give it a sensible name, set the Start Options to a value of your choice.
Once published, open the document library the workflow is associated with, make sure a file of the supported type is present, and manually start the workflow. After a few seconds, the PDF file will show up next to the file the workflow was started on.
Troubleshooting
Although both Nintex Workflow for Office 365 and the Muhimbi PDF Converter are mature services, in workflows like this there are a lot of 'moving parts'. Custom generated JSON, customer specific API keys, paths to document libraries etc. The first time you create a workflow like this, something is bound to go wrong.
Some common issues and troubleshooting tips are provided below:
Check prerequisites: Double check the prerequisites - listed at the beginning of this article - are in place.
Log to History List: If it is not clear what is going wrong, log critical parts such as the JSON workflow variable (after the replace operation) as well as the ResponseText workflow variable (after the web request) using the Log To History List workflow action. You can see the contents of this list by clicking on the Workflow Status column for the List Item the workflow is running on.
Send email: The amount of text that can be logged to the History List is limited (roughly 250 characters I believe), so for larger messages use the Send an Email action action to send an email, with debug content in the body, to yourself.
Copy & Paste: Be very careful when copying the JSON fragment from this article into your workflow. Browsers tend to insert hidden characters that are not filtered out by the Nintex Workflow editor. When copying text from a browser, paste it into Notepad first to clean it. Then copy it from Notepad and paste it into your workflow.
Nintex References: Make sure that the Nintex Workflow references in the JSON provided in this article are replaced by actual Nintex Workflow references. You can double check if the references are active by logging the JSON workflow variable to the History List. You should see the actual paths, not {Current Item:Server Relative URL}.
Muhimbi Support: If, after double checking all prerequisites and going over all troubleshooting steps in this section, you are stuck, please contact our friendly support desk, we are here to help.
Fine tuning
Don't get me wrong, the workflow we created earlier is great, but I wouldn't use it for mission critical processes. There is no error handling whatsoever, and there is a possible recursion problem where the workflow will be triggered for PDF files it has created itself.
A version of the workflow that is more production ready can be found in the screenshot below. Full details are beyond the scope of this post, but you can download the full workflow here. Import it into Nintex Workflow for Office 365, SET THE API KEY, publish it and you are ready to go.
Other operations
This article shows how to invoke the Convert action on Muhimbi's REST interface. In addition to PDF Conversion, we expose additional end-points for Merge, Watermark, Secure, Split, OCR and even Copy Metadata operations. Full examples are beyond the scope of this article, but you can find examples in the SharePoint section of our GitHub repository.
Many of our customers already use the functionality described in this blog post in their mission critical SharePoint Online processes. What do you think, is this something that could work for your organisation? Feel free to leave a comment below or contact our support desk if you have any technical or commercial questions.
We are happy to announce a new version of the Muhimbi PDF Converter API and Server Platform. Although a lot of fixes, workaround and small tweaks have been added, the key change in the 8.3 release is a completely overhauled HTML to PDF Converter, which is more up to date with the latest web based technologies, and more importantly, no longer has a dependency on Internet Explorer.
Brand new Image Converter (For GIF, BMP, PNG and JPG)
Improved resource usage of OCR engine.
Support for PDF Named Destinations.
Original Web page (left), converted to PDF using the Screen Media type (middle) and the Print Media type (right)
A quick introduction for those not familiar with the product: The Muhimbi PDF Converter Services is an ‘on premises’ server based SDK that allows software developers to convert typical Office files to PDF format using a robust, scalable but friendly Web Services interface from Java, .NET, Ruby & PHP based solutions. It supports a large number of file types including MS-Office and ODF file formats as well as HTML, MSG (email), EML, AutoCAD and Image based files and is used by some of the largest organisations in the world for mission critical document conversions. In addition to converting documents the product ships with a sophisticated watermarking engine, PDF Splitting and Merging facilities, an OCR facility and the ability to secure PDF files. Separate SharePoint and Cloud-based Subscription services are available as well.
The Muhimbi PDF Converter for SharePoint On-Premises comes with support for a large number of file formats. MS-Word, Excel, InfoPath, PowerPoint, Visio, AutoCAD, Images, you name it. Although each file format has its own obvious uses, the ability to convert HTML is particularly useful as – in the age of Apps and Web Browsers - more and more information is exposed as either raw HTML or a URL.
We recently overhauled our HTML Converter to bring it in line with the latest standards. As a result it can convert some of the most advanced HTML content including SharePoint Pages, List Items and, the focus of this blog post, Nintex Forms.
As InfoPath is no longer actively developed by Microsoft, a number of alternatives have popped up over the years. As Nintex has a strong foothold in the SharePoint market, mainly because of their Nintex Workflow product (which we fully support), their Forms solution is an obvious choice for many. Quite a few of our customers use Nintex Forms in combination with the Muhimbi PDF Converter for SharePoint On-Premises to convert a form to PDF when it reaches a certain stage, merge it with other documents, watermark it and archive / email it.
In this post we’ll show how to create a simple List, Nintex Form and associated Nintex Workflow to convert the form to PDF once the List Item has reached the Approved stage. The workflow is then enhanced with the ability to convert and merge all attached files.
Please keep in mind that – as per Nintex’ own guidelines – Nintex Forms is a tool for data capture, not for print (and by extension PDF) output. As a result you may need to be creative at times to achieve the desired results. In some cases it may be better to just take the SharePoint columns, filled out using Nintex Forms, and dynamically generate HTML or Word XML before passing that into the Muhimbi PDF Converter.
Prerequisites
Before you begin, please make sure the following prerequisites are in place.
To make sure the Muhimbi Conversion Service has the appropriate privileges to access the list items, make sure the Windows Internet settings - for the account the Conversion Service runs under – is set to Automatic logon (run inetcpl.cpl / Security / Select Zone / Custom Level / User Authentication / Automatic login with current user name and password). For details about troubleshooting authentication issues, see this Knowledge Base article.
Working knowledge of both Nintex Forms and Nintex Workflow.
Please note that this tutorial is for the on-premise version of SharePoint (2007-2016). Although both the Muhimbi PDF Converter and Nintex forms are available for SharePoint Online as well, due to technical reasons it is not possible to use them together at the time of writing. We are working on it though.
Getting started
OK, let’s get started by navigating to your favourite Site Collection, choosing the option to create a new Custom List and naming it Nintex Forms Demo.
Once the list has been created, add a column named Approved, of type Yes/No, with the default set to No. There are many ways to deal with approvals in SharePoint, for the sake of simplicity we use this simple field, but naturally you can easily modify the workflow to deal with your particular situation.
As a next step, modify the List’s Form using the Customise the Item Form option. (In SharePoint 2016 this can be found in the List Ribbon / Customize List section. This results in the following screen:
Obviously you have the option to customise the form to your heart’s content, but for the purpose of this demo the default looks great. Choose the option to publish the form.
With the custom form created, let’s create a workflow to convert the form to PDF once the item has been approved. Before we do, we need to figure out the URL of the form, as we need this information later.
Add a new List item, fill it out and submit it.
After submitting, click the newly created item to open it in Display mode.
Copy the contents of the URL up to, and including, the ‘?ID=1’ section.
Save it somewhere, we need it later in our workflow.
Close the form if it is still open, and from the List ribbon select the option to Create a Workflow in Nintex Workflow.
As a first step, we need to check if the list item has been approved, so insert the Run if workflow action and double click it to configure. Update it to set the Where clause to Approved equals Yes.
Next, drag the Convert URL or HTML to PDF workflow action inside the Run if action. Details about this action can be found here and here, for this example we fill it out as follows:
Destination Path: The path and file name to write the converted form to. Assuming there is a standard Shared Documents library in the current site, enter Shared Documents/Form-ID.pdf, where ID is inserted via Insert Reference / Item Properties / ID. Naturally you can choose your own output path and file name, for details see this blog post.
Source URL: Remember that we earlier saved the URL to the form’s display mode? Paste it here and make sure that behind ?ID=, you enter the Item’s current ID via Insert Reference / Item Properties / ID. The result should look something like http://YOUR_HOST_NAME/sites/Demo/Lists/Nintex%20Forms%20Demo/DispForm.aspx?ID={ItemProperty:ID}
HTML Engine: Although no need to set this in a clean – and unmodified – deployment of the Muhimbi PDF Converter for SharePoint On-Premises, there is a chance that an administrator has changed the default HTML Engine in the config file. To be sure, set this option to WebKit.
Media Type: Similar to the HTML Engine option, the default is set correctly for a clean deployment, but – as it is possible to override this setting in the config file – set it to Print.
Conversion delay: More about this later, but if you end up with an incomplete PDF rendition of the form, set this value to something like 2000 (milliseconds), which is the time to wait between loading the form, resolving all external dependencies, and starting the PDF Conversion process.
Finally, use the Workflow Settings option to start the workflow when items are created and modified.
The final workflow should look as follows, publish it, name it Convert Form to PDF upon approval, and close the editor.
With everything in place, create or update a list item and set the Approved field to Yes. After a few seconds a PDF rendition of the form will be placed in the output folder and look similar to the following.
Fine tuning
As you can see above, the generated PDF looks great and provides a good rendition of the form. However, you may want to tweak things around a bit. As Nintex Forms provides the ability to provide custom CSS as well as JavaScript, the sky is the limit as our HTML Converter supports both.
For example, you may not want to include the Content Type, Created at, and Last modified at labels in the PDF. We can solve this by setting the associated HTML element’s style to display: none. The trick is to figure out the name of the element first.
Click the list item (not the PDF) to open it in Display mode in Google Chrome.
Press CTRL-SHIFT-C to open the Element picker.
Move the mouse near the area you want to hide. You will usually find a container that surrounds the entire area.
Write down the name of the element, in this case table.nf-form-footer, so we can create some CSS to hide it. See screenshot below.
To hide these labels, re-open the Nintex Forms editor, click on Settings and open the Custom CSS section. A number of CSS entries may already be present, so scroll to the bottom and add the following:
We wrap the CSS in a ‘@media print’ section to make sure these changes are only applied during printing (PDF Conversion is considered printing).
Additional CSS has been added to hide buttons as well. There is no need to include these in the PDF.
Save the settings and republish the form to activate the changes. Create / update a list item, make sure it is set to Approved and open the newly generated PDF. The information we are not interested in has now been removed from the PDF.
As mentioned previously, the sky is the limit. Use CSS and JavaScript (JQuery?) to change the form as much as needed. Our PDF Converter will apply your customisations automatically.
TOP TIP: If you wish to run JavaScript only during PDF Conversion, add a value to the URL (e.g. PDF=True) and check for the presence of that value as part of your custom JavaScript.
Advanced fine tuning
In addition to changing the look and feel of the form using CSS and JavaScript, the Muhimbi PDF Converter makes it possible to tweak other settings as well, specifically:
Page Orientation: Change the orientation to suit the layout of your form. This setting can be changed globally in the Conversion Service’s configuration file, or on a request by request basis in the Workflow Action.
Page Margins: By default, a 0.5 inch margin surrounds the content of the page. This setting can be modified in the Conversion Service’s configuration file.
Page Size: The default option for the page size is Letter, this can be changed – e.g. to A4 – in the Conversion Service’s configuration file.
ViewPort Size: This one is tricky, but powerful if you need it. It is possible to simulate the size of the browser window. This can come in useful when converting a form that was designed for Mobile use. E.g. use 375x667 to simulate an iPhone 6. This setting can be controlled via the workflow action as well as the configuration file.
Although Nintex Forms comes with a built-in page breaking facility, this is not recognised by third party browsers such as Google Chrome and Muhimbi’s HTML Converter. We’ll spare you the full details, but it is related to how Nintex Forms positions the various form elements on screen.
We are working with Nintex to see if we can implement a workaround. Until then we recommend to pay extra attention when authoring large forms that span multiple pages. During the design phase, carry out tests using the Muhimbi PDF Converter and make sure all looks well once converted to PDF.
Merging Attachments
Still reading? Wow, you must be really interested in this topic.
Let’s make a useful enhancement to the workflow by converting all the list item’s attachments, and merging everything – including the form itself - into a single PDF. This is where things get fun, and a bit complex as Nintex Workflow does not provide any workflow actions for dealing with attachments.
Please note that this enhancement uses the REST service introduced in SharePoint 2013. For older versions this sample will need to be changed to use the Web Service interface utilised by older SharePoint versions. Have a look at this post in the Nintex Community.
Before we modify the workflow, please make sure that in Nintex’ Central Admin section the Query XML action is enabled.
Edit the workflow we created earlier and add another Run if action INSIDE (not after) the previously created Run if action. Double click it to configure, and set the Where clause to Attachments equals Yes.
As we need a workflow variable to store the list of attachments in, create a workflow variable named Attachments of type Collection.
Next, drag the Query XML workflow action inside the Run if action, and fill it out as follows:
URL to XML file: Insert the URL to the REST end-point for the current item. The URL will be similar to the following, make sure you enter your own host name, site name, list name (if different from our example), and replace the ‘2’ in items(2) with a reference to the current item id. (See screenshot below for an example where we have used Insert Reference to make it all dynamic).
Username / Password: Enter the credentials of a user with the privileges to read the item’s data.
Output 1: Enter the following XPath statement //d:ServerRelativeUrl
Store results in: Select the Attachments workflow variable created earlier.
The end result should look as follows.
We are almost there, we have a PDF rendition of the main form and a list of attachments. All that is needed is to merge it all into one PDF for easy archiving / distribution.
Directly after the Query XML action, insert the Muhimbi Merge files to PDF action. Details about this action can be found here, for this example we’ll fill it out as follows:
Destination Path: In this example we want to overwrite the file that was generated in the first step, so we specify the exact same path and file name as before, Shared Documents/Form-ID.pdf, where ID is inserted via Insert Reference / Item Properties / ID. Amend this to match your specific requirements.
Source Files: As we want to include the PDF rendition of the form created in step 1, on the first line we enter the path and file name, including the reference to the current item:
Shared Documents/form-{ItemProperty:ID}.pdf
On the next line we want to insert the list of attachments. The list retrieved earlier uses a ‘;’ to delimit each individual attachment. The Muhimbi Merge action requires each attachment to be on its own line, so we carry out a Replace operation:
That is it, we can ignore the other fields, the results should look as follows.
The overall workflow is relatively simple, and looks as follows. All the magic happens inside each action.
We are DONE!
Publish the workflow, add or edit a list item, add one or more attachments (making sure the file format is supported), set the list item to Approved and save it. The workflow will complete in a few seconds, once completed you can find a PDF file containing both the Nintex Form and all attachments in the Shared Document library.
Download the workflow here. Once imported, please review the various workflow actions, check that the paths are correct for your particular situation and enter the credentials in the Query XML action.
Further enhancements
When we earlier mentioned that we were done, that was an obvious lie. We are never done, people always want more. The possibilities are endless, some refinement that come to mind:
PDF/A: Convert the end result to PDF/A, a specific subset of the PDF standard for archiving purposes and THE format recommended / demanded by most regulatory bodies. Providing you have a Muhimbi OCR and PDF/A Archiving add-on license, the generated PDF file can be fed back into the Muhimbi Convert Document activity alongside some XML.
Unsupported attachments: Although the Muhimbi PDF Converter supports the most common file types, you may want to filter out attachments for file types that are not supported (e.g. zip).
Troubleshooting
With a workflow this awesome, there are always things that can go wrong. The most common problems are as follows:
Authentication: As mentioned in the Prerequisites section, it is essential that the Muhimbi Conversion Service can authenticate against the list item. For details see this Knowledge Base article.
Incomplete Forms: If the Nintex Form is very complex and depends on external resources (e.g. database requests, external images, or custom JavaScript), then it may take some time for the form to fully finish loading resulting in an incomplete PDF. If this happens, try to gradually increase the Conversion Delay, part of the Convert URL or HTML to PDF workflow action. (The value is specified in milliseconds, try 2000 for a 2 second delay).
Shortly after releasing version 8.2 of the Muhimbi PDF Converter for SharePoint - which added support for SharePoint 2016 as well as Nintex Workflow 2016 - we sat down to identify the main pain-points reported by customers, see what we could do to make life easier for everyone. It soon became clear that the number one pain-point is our HTML Converter, specifically where it comes to converting SharePoint 2013 (and later) pages and related content such as List Items and Nintex Forms.
Although we have supported HTML & URL conversions for years, due to architectural changes in SharePoint, Windows, and Internet Explorer, things just didn’t work as well as they did in the SharePoint 2007 and 2010 eras.
To cut an almost 10 month long story short, today we are releasing version 8.3 of the Muhimbi PDF Converter for SharePoint. The key changes are as follows:
Brand new Image Converter (For GIF, BMP, PNG and JPG)
Improved resource usage of OCR engine.
Support for PDF Named Destinations.
Original SharePoint Web page (left), converted to PDF using the Screen Media type (middle) and the Print Media type (right)
For those not familiar with the product, the PDF Converter for SharePoint is a lightweight solution that allows end-users to merge, split, watermark, secure, OCR and convert common document types - including InfoPath, AutoCAD, MSG (email) MS-Office, HTML and images - to PDF as well as other formats from within SharePoint using a friendly user interface, workflows or a web service call without the need to install any client-side software or Adobe Acrobat. It integrates at a deep level with SharePoint and leverages facilities such as the Audit log, Nintex Workflow, K2 blackpearl, localisation, security and tracing. It runs on SharePoint 2007-2016 & SharePoint Online and is available in English, German, Dutch, French, Traditional Chinese and Japanese. For detailed information check out the product page. This ‘on-premise’ version of the PDF Converter requires software to be installed on the SharePoint server. Please note that if you have no server access, there is always the option to deploy our SharePoint Online App to on-premise versions of SharePoint 2013 and 2016. For details see this blog post.
We have been a little bit in love with Nintex Workflow ever since we integrated it into the 
The 
