Skip to main content

Nintex Workflow allows integration with external systems in many ways, it could be using Call Web Service action, Execute SQL action, Query BCS, Nintex 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:

 

115908_pastedImage_0.png

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.

115909_pastedImage_1.png

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.

116102_pastedImage_2.png

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.

116103_pastedImage_3.png

Nice Post KK..


Liked the theory--but would appreciate some actual UDAs.

thanks,

Stephan


This is not directly supported for the time being, but I believe the product team has this requirement in the list to support external devices such as bluetooth device directly from the device end.


I have seen quite a number of sharing on UDA from the community, how certain function or reusable workflow packaged into UDA, do a search you should find some. I have planned and will also based on this to share one on my next blog hopefully as soon as possible.


Reply