Muhimbi PDF Converter Deployment scenarios
Clavin Fernandes
Muhimbi’s range of server based PDF Conversion products have been developed with performance, scalability and reliability in mind. As a result the software scales from the most humble ‘ everything on the same server’ environments to environments that deal with millions of conversions a day across a farm of servers. In this article I will discuss the most common deployment scenarios.
Whenever this article mentions ‘Server’ it doesn’t matter if this is a physical or virtualised server. Our software does not differentiate between the two and will work fine on either type.
Introduction – Architecture
Both the PDF Converter for SharePoint and the PDF Converter Services ship with the same central conversion engine. This engine, The Muhimbi Conversion Service, is responsible for carrying out all the work including conversion of files, watermarking, merging, splitting and security activities. Although in case of our PDF Converter for SharePoint our front end is quite comprehensive, all it really does is prepare requests for the Conversion Service and receive responses containing new or modified documents.
If you are involved in deploying any of our PDF Conversion products then it is essential to know how our software works from an architectural perspective. The Muhimbi Conversion Service is a standard Windows Service that starts automatically when Windows boots up and requires no user interaction or anyone to be logged in to the server console.
This Windows Service contains a WCF based Web Service that exposes functionality to any Web Services capable environment including Java, C#, VB.NET, Documentum, SAP, PHP etc. Typically when administrators think about web services they assume that they need to host this inside a web server such as IIS or Apache. Although that may be true for many web services, Muhimbi’s PDF Conversion software runs inside a self-hosted WCF service that does not have any external dependencies on third party web servers.
By basing the conversion service on WCF we get a lot of benefits, including:
-
No external dependencies on web servers and other 3rd party products.
-
A mature framework with support for different message and transport types, built in security and advanced features such as MTOM encoding for large attachments.
-
And most importantly, all functionality is exposed via standard HTTP based Web Service requests.
This last point about requests being HTTP based is very important as it allows the Conversion Service to be scaled across multiple servers using standard hardware or software based load balancers, including the free NLBS that ships with Windows. By utilising a load balanced environment you can achieve linear scalability and automatic failover. ( See these performance tests).
Example based on SharePoint Front ends, but Java and .NET deployments work the same.
For details about tuning the various options of the Muhimbi Conversion Service, and installation in general, see the Resources section at the end of this article.
Single Server Farm
The most basic configuration possible is to install everything on a single server. Just follow Chapter 2 in the Administration Guide (including all links to Appendices) and you are ready to go. There is nothing else to configure and, if needed, the Web Service can be accessed on the following URL:
https://localhost:41734/Muhimbi.DocumentConverter.WebService/
Small farms with a single Conversion Service
For slightly larger deployments of 2 or more servers, but with a single conversion server, deployment is very simple as well. Let’s take the following example:
-
Server 1: A new or existing Application Server that will run the Muhimbi Conversion Service.
-
Server 2: A server that will run either a SharePoint WFE or a custom solution.
In this particular case it is a matter of installing the Conversion Service on Server 1 as per the instructions in Chapter 2 of the Administration Guide. No further changes are required, but remember that the web service URL is now:
https:// Server1:41734/Muhimbi.DocumentConverter.WebService/
Naturally you will need to replace ‘Server1’ with the actual host name of the server.
In case of a SharePoint deployment you need to deploy the WSP file to Server 2 and enter the Web Services URL in the PDF Converter’s SharePoint Central Administration screen. If you are not running SharePoint, but your own Java / .NET / etc solution then you will need to pass the above mentioned web service URL using whatever syntax is common for your platform.
Large farms with multiple conversion servers
Now, this is where things get interesting, a farm with multiple front end servers and multiple conversion servers. Let’s take the following example:
-
Server 1: A new or existing Application Server that will run the Muhimbi Conversion Service.
-
Server 2: A new or existing Application Server that will run the Muhimbi Conversion Service.
-
Server 3: A server that will run either a SharePoint WFE or a custom solution.
-
Server 4: A server that will run either a SharePoint WFE or a custom solution.
-
Load Balancer
In this scenario the Conversion Service will need to be installed on Server 1 and Server 2 as per the instructions in Chapter 2 of the Administration Guide. Once installation is complete the web service can be reached on the following 2 URLs:
https:// Server1:41734/Muhimbi.DocumentConverter.WebService/
https:// Server2:41734/Muhimbi.DocumentConverter.WebService/
Although in theory you could build functionality into your software to alternate requests between these two URLs, it is much easier and more robust to use an off-the-shelf HTTP load balancer or Windows NLBS. How this works in detail differs per load balancer, but it usually involves creating a virtual host that listens for requests and configure this virtual hosts to send requests to Server1 and Server2. In this example we assume that this virtual host is named LoadBalancer resulting in the following Web Service URL:
https:// LoadBalancer:41734/Muhimbi.DocumentConverter.WebService/
In case of a SharePoint deployment you need to deploy the WSP file to Server 3 or 4. it doesn’t matter which one, the installer will automatically deploy it to all WFEs.
The LoadBalancer URL needs to be added to the PDF Converter’s SharePoint Central Administration page, or your application’s configuration file. When a request is made to the load balanced URL the load balancer will automatically detect which of the servers are available and only send requests to servers that are up and running. If multiple servers are up and running it will distribute requests between all servers.
If you have multiple SharePoint Web Front End servers it may be tempting to install a copy of the Conversion Service on each WFE. Although this is a supported scenario we recommend deploying the Conversion Service on separate Application Servers to make sure that your WFEs resources are available for running SharePoint, which can be quite resource hungry by itself.
Licensing
Please make sure you are licensed for the correct number of servers. Muhimbi’s software is licensed on a ‘per server’ basis. This means that you need a license for every server that runs our software including all Web Front End servers in your SharePoint farm and all servers running the conversion service.
For more details see this Knowledge Base Article.
Resources
For more details about deployment and configuration see the following resources:
Clavin is a Microsoft Business Applications MVP who supports 1,000+ high-level enterprise customers with challenges related to PDF conversion in combination with SharePoint on-premises Office 365, Azure, Nintex, K2, and Power Platform mostly no-code solutions.
