This article is part 4 of a 4 part series, where I’ll cover the steps to import your Azure Function as a new connector using the Nintex Workflow Cloud Xtensions framework. If you haven’t already reviewed the prior posts in this series, here’s what you missed:
- Part 1 – Using Azure Functions to create Xtensions for Nintex Workflow Cloud
- Part 2 – Develop C# code in Visual Studio
- Part 3 – Edit Swagger Definition
My sample project here was to build an Azure Function that wrapped the GSA Per Diem API, making it easy to consume as an Xtension in Nintex Workflow Cloud. The use case for this would be workflow designers creating a solution for Travel Authorization Requests and/or Expense Reports. This custom workflow action could validate that the amount of expenses for Meals and Hotels is within the limit allowed by the GSA.
Now that we’ve created our Azure Function, we’re left with the best part of the solution – importing it into Nintex Workflow Cloud as a new new Xtension / Connector.
Create the Xtension in NWC
After logging into your NWC tenant, click on the Xtensions link on the left side of your Dashboard. The click the orange plus (+) sign on the right side.
This will display the Connector Definition dialog. Simple copy and paste the API Definition URL into the textbox for the OpenAPI specification URL (see bottom of part 2 for how to obtain this URL in Azure Portal). After pasting the URL, NWC will immediately validate the definition and display a green checkmark on the right. Then click Next.
This will display the Security dialog. We can accept the default settings here. These settings indicate that Nintex Xtensions will use an APIKey for security to call our Azure Function (the APIKEY is the token at the end of the API Definition URL) and it will pass the APIKEY value as a parameter named “code” in the URL querystring. The APIKEY shall be entered by the workflow designer when they use the GSA Per Diem action within a workflow. Click Next to continue.
This will display the Publish dialog as shown below. Enter a Name and Description for the Connector.
Then click on one of the available icons or if you prefer you can upload your own icon. Then click the Publish button.
When the Publishing is complete your new Connector will show up in the custom connectors list:
Before using the Connector, we’ll need to create a Connection to it. While you can create the connection after you add the GSA Per Diem action into your workflow. But in this case well create a new connection first. Click on the Connections link from the left side of the Dashboard, then click the Add New button:
From the Add a new connection screen the name of your new Connector from the Connector list. In this case, I’m selecting the GSA Per Diem connector. Then click the Connect button:
Enter values for the Connection name and the API Key that you plan to use name for this specific connection, then click the Connect button:
The new connection shall be displayed in the connection list:
Now, we can actually use our custom Connector in an NWC workflow! So, lets create a new Workflow and when we review the toolbox, we’ll see our new GSA Per Diem connector. If we expand the GSA Per Diem section, we’ll see the specific action that corresponds to our Azure Function. Note that the name displayed for this action is defined in our Swagger definition, as the summary. So if we prefer a different name for the action, we can change that summary value (see part 3 for details).
In this case, I created a workflow using the Nintex Public Web Form as the Start Event, with two start variables: ZipCode and TripDate. I then added my new action GSA Per Diem action onto the workflow design surface. Lets look at the configuration:
For this action there are 6 settings to be provided:
- Connection – Select the name of the connection that was created previously from the drop down list
- The API Key – You may use the same API KEY that was provided in the API Definition URL. Azure Functions also allows you to create and manage additional API KEY for your function app. This can be done from the Settings screen of your Azure Function App.
- Gsa Per Diem Input Zip – assign this to the ZipCode start event variable.
- Gsa Per Diem Input Trip Date – assign this to the TripDate start event variable
- Results Hotel – Define a new variable of type integer called HotelPerDiem. This is an output variable that will be populated by this action.
- Results Meals – Define a new variable of type integer called MealsPerDiem. This is an output variable that will be populated by this action.
So we have no concluded our project to implement a solution using C# & Visual Studio to develop our logic within Azure Functions, and import our API definition as a custom connector for Nintex Workflow Cloud.
The expected scenario with this example, is that we may capture actual Meal and / or Hotel expenses and compare those against the allowed Per Diems. If the actual expenses exceeds the Per Diem the workflow may taken certain actions like automatically reject or route for special approval. But you can hopefully adapt the concepts here for any custom business logic or integration scenarios that you can imagine. Good luck!
If you have questions or comments please contact me on Twitter @TomCastiglia