Being one of the leading Nintex partners in the southeast, as well as its longest tenured partner in the region, we at Abel Solutions have leveraged the “no code/low code” philosophy behind Nintex Workflow, Forms, Mobile and Connectors to cost-effectively build and deliver a wide variety of line-of-business solutions that automate business processes for companies of all sizes. However, on occasion a scenario will arise where it is either impossible or impractical to meet the requirements of a project using the built-in functionality of Nintex Workflow and Forms alone.
In the past, when presented with the need to extend the functionality of a Nintex Workflow or Forms application, I would have responded with my stock answer of using the SharePoint Object Model or Nintex APIs to develop custom functionality that could be deployed to the SharePoint Farm via a SharePoint solution file (WSP). However, I was recently introduced to the idea of using a web service to handle the custom functionality. At first, I didn’t give much credence to the idea and felt that it was unnecessarily complex and inefficient. As one of my former bosses would put it, the juice just wasn’t worth the squeeze. However, after developing several custom WCF Web Services for a client over the past couple of years that are used to add business critical functionality to Nintex Workflows and Forms, I have come to very much appreciate this approach for its ease of use and flexibility.
How Does It Work?
A web service is simply a software application that can be accessed via the Internet or internal network by other applications. A web service consists of two pieces: a SERVICE and a CLIENT. Similarly, the communication between the service and client consists of a REQUEST and a RESPONSE. The client makes the request to the service, typically via a URL, passing in certain parameters specific to the request. The service then performs the necessary operations and generates a response, which it returns to the client typically in XML or JSON format.
Figure 1– The components of web service communication.
How Is It Implemented?
A web service is hosted on a web server and is accessed via a specified URL just like a web site. By nature, web services are technology agnostic. Therefore, the specifics (i.e., programming language, OS, etc.) of how the service is developed are, for the most part, irrelevant. If the web service can accept a request from a client, process the request and return a response, all is good. Likewise, all the client application needs to be able to do is generate a request containing the necessary parameters, pass the request to the web service and process the response that is returned.
To further illustrate how this works, consider a scenario where a Nintex Workflow needs to perform some very complex calculations. Perhaps this logic could be handled within the workflow itself but doing so would result in a very large and convoluted workflow, or series of workflows. If the logic for the complex calculations can be offloaded to a custom web service, the result can be an overall solution that is cleaner, easier to maintain and easier to debug. Nintex Workflow, which acts as the client application in this scenario, has built-in actions that can easily handle generating and sending the client request to the custom web service and accepting the response. The data in the response can then be parsed out and stored in workflow variables so that it is available for use in the other workflow actions such as Flexi-Tasks, Notifications, etc. that are used to complete the process.
Figure 2 – Nintex Workflow can easily be configured to make the client request to a custom web service and process the response.
Another example is a Nintex Form that needs to show or hide different fields based on certain criteria for each user which can’t be easily determined using built-in functionality of the Nintex Forms Designer. Since a Nintex Form is simply a web page, client-side code such as jQuery can be added to the form to handle generating and sending the client request to the custom web service for processing and then manipulating the elements on the form based on the data contained in the response it receives back.
What are the Benefits?
A web service and its resources are decoupled from the SharePoint Farm, and there are several key benefits this provides.
- Change Management – The code for the custom functionality can be updated and deployed without causing any interruption of service in the SharePoint Farm. Typically, deploying updates to a web service involves copying a few files to a mapped drive on the web server instead of having to install/update SharePoint solution files directly on one of the servers in the SharePoint Farm.
- Isolation – Since the custom code runs on the web server and not the SharePoint servers, processing needs of the custom functionality will not consume valuable resources needed by the SharePoint Application Server(s) and Web Front End Server(s) to do their job. This also means that a rogue infinite loop in your code won’t bring down the SharePoint Farm.
- Availability – The custom functionality in the web service can be shared by multiple SharePoint Farms or with other line-of-business applications.
What are the Challenges?
Along with the benefits of this approach come a few challenges that must be considered as well.
- Latency – Sending a request across the wire from one system to another and awaiting a response takes time. Although this is usually a matter of milliseconds, it could be longer if complex operations are involved, and this should be factored into the equation.
- Initial Setup – Getting a web server and web service established successfully can take time and effort. However, once the first web service is up and running successfully, the process is easy to replicate.
- Authentication – Oftentimes, web services are only made available on corporate networks to provide internal access to information that is already available to users in some other format, and authentication is not a huge concern. However, if that is not the case or the web service needs to be accessible from outside a corporate network, then authentication can add a layer of complexity. This is especially true if access needs to be granted on a per user basis.
Sending data from a healthy SharePoint Farm to another application on a separate server, so that it can be processed and sent back, may not always seem to be the shortest path between two points. However, once you have your web service architecture established and running properly, custom web services can provide a viable alternative for extending the built-in functionality of Nintex Workflow, Nintex Forms, and other SharePoint-based applications without having to deal with some of the complications and frustrations that come along with managing SharePoint solution files, which is a significant benefit for everyone involved.
This tip written by Abel Solutions SharePoint Architect, Rob Aycock.