Integrating external system with Nintex Connectors, business users can do it too..

Nintex Workflow allows integration with external systems in many ways, it could be using Call Web Service action, Execute SQL action, Query BCSNintex connector actions, etc. Nintex Connector actions (e.g. Salesforce or Dynamics CRM actions) when put in a workflow, allows the workflow designer to not have to think about how to talk to the external system.

The Challenges

What do I mean by “not have to think about how to talk to the external system“? Let us take a look at if the Execute SQL action is to be used for the purpose, the workflow designer will need to know how to define connection string and SQL Query in order to use the Execute SQL action. That required the knowledge on Database Server source, Database, Table, Columns, etc. to be queried. As these are low level schemas of the external system, usually one will need to manipulate the data to get the expected result.

Similar to the Web Service request, the workflow designer will need to know the destination web service URL, method(s) to call, etc. or to translate the business process language into low lever programming concept and will need to understand the object models that sit between the two system in order to integrate with external system. The scenario of having the middle-man objects is illustrated in the scenario below where the Business Process designer will need to understand the middle-man “lead/leads” objects are sitting in between the Nintex and external system:

It is indeed challenging for Business Users to model a workflow themselves, as they are not programmer or IT personnel who knows the low level schema or object models of an external system(s). This creates an even challenging situation when more and more business processes will need to integrate with external system which requires more and more “objects” in between the systems.

The Connector Solution

The solution presented in Nintex for integrating with external system via “Connectors” is a more direct and straight forward approach, allows the Workflow designer to integrate with external system without the need to understand the low level schema or the object models of the remote system. It could be as simple as providing the pre-configured connection and “lead/leads” details for creating “lead/leads” in Salesforce system, etc., as illustrated in the scenario below.

Below list the currently supported connectors by Nintex workflow (i.e. both Nintex connectors and connector provided by Nintex vendors:

Nintex Connectors: AWS, Bing, Bitly, Box, DocuSign, Dropbox, Microsoft Dynamics CRM, Facebook, Google, Google Drive, LinkedIn, MailChimp, Office365, Rackspace, Salesforce, StrikeIron, Twitters, WorldPress, Weather UnderGround, Yammer

Partner Connectors: ActiveDocs, Adlib, Biscom, CoSign, dox42, FileTrail, IGC, Innowera (for SAP), muhimbi, Pingar, PSIGen, Qdabra, Qorus, Enterprise Enabler, Vizit, Wand

The number of connectors are growing from time to time, and in most cases, Nintex partners or customers with the Nintex SDK provided by Nintex will be able create connectors that are not available or open for use as generic connectors to customers’ environment.

The UDA solution

Besides connectors, one of the best practices promoted by Nintex is for expert/professional workflow designer to define UDA (A.K.A User Defined Actions). UDA is reusable action or wrapping of actions to work as connector, but without the need to program or coding using Nintex SDK. UDA to be called or used by Business Process designer without the need to understand low level calls to external system. The  diagram below depicts a sample UDA design which calls web service to an external system, the UDA is packaged and to be used by other Business Process design by simple providing required parameters and expecting a retuned results by the UDA.

The following diagram demonstrates how a Business Process Designer model a business process workflow by calling the above “Get Leave Balance” UDA sample, by passing the required parameters that is Employee ID and Leave Type. The UDA (i.e. Get Leave Balance UDA in this example) will return the Leave Balance as expected to be used as leave calculation to be used in this scenario.