Skip to main content

Nintex Workflow | parsing JSON responses from json-only web requests



Update 03/08/16:
Logic Apps has gone GA, and has undergone a major v2 change since this post was written. For the most part, the core actions remain the same but just renamed or work a little differently e.g. http listener (now known as "When an http request is received" + "Received") and conditions (now triggered via the add a condition" button instead of being configured inside the http action.)

It is worth noting that the BizTalk JSON Encoder API app can no longer be found in the marketplace. This is now a native function in Logic Apps. Though, I'll try to refresh this post with the how to do it in the version of Logic Apps that GA'd, I'm not sure when I will have to do it, so if you can't wait, I suggest looking at the xml function can be found here.

Update 07/08/16:
Steps for new Logic App UI that has GA have been added into the solution section below.

The problem


One of the things I have been working on lately in the Nintex Workflow world, is interacting with various software as a service based solutions within a workflow via REST based APIs.

One of the things we will find is that with the growing popularity of JSON, some REST based web services are no longer supporting returning responses of web requests in the XML format.

Workflows in SharePoint, has traditionally been focused around integrating with enterprise level SOAP based web services and Nintex is well catered in this area with it's Query XML Action. Unfortunately (as of the time this blog was written), there is currently no equivalent Query JSON Action within Nintex Workflow for On Premise.

The options


  1. Simple JSON structures: In most cases the JSON responses returned by APIs are simple and flat in structure.

  1. For this scenario, we can leverage (with relative ease) the regular expression capabilities within Nintex Workflow to parse the JSON string. A great example of this can be found from Vadim Tabakman's blog in Nintex Community: Uber price estimate UDA

  1. Complex JSON structures: In some cases JSON responses returned by API's can be nested and/ or contain arrays. Parsing responses of this nature using the regular expression can be more challenging.
    An example of a nested JSON Structure
    An example of a nested structure 



    If only there was a way to easily convert JSON into XML so that we can leverage the Query XML action...

    Well, the relatively recent introduction of the new Logic App and API App platfrom from Microsoft Azure looks to be a great timing. In the next section, we will look at how we can leverage Azure to easily create our own API to convert a JSON string into an XML string so that we can use the capabilities of Nintex's Query List action to retrieve information we need from a web service response.

The solution



Moving parts from Azure:
  1. Logic App: This is the platform that allows us to orchestrate and glues a combination of API Apps together.
  2. When an HTTP request is received: This API app triggers the start of the logic app (pictured above) when it receives a web request. Just add the action (there is no need to configure anything else). 
  3. Response: This API app is used to send back the converted XML string as a response to the application that sent the initial web request (e.g. Nintex Workflow). Ensure you configure the body field with "@xml(triggerBody())" which converts the content from the body of the HTTP request from JSON to XML. 
Using Azure Logic App JSON Encoder in Nintex Workflow
Nintex Workflow - Leveraging Azure to convert a JSON response into XML so that we can parse the information with the Query XML action

Moving parts from Nintex Workflow:


  1. Web Request (JSON Conversion): This action is used to call the API created in Azure Logic Apps (including passing the JSON string we want to convert into the XML)

    URL: Copy the URL that is generated in your "When an HTTP request is received" action.
    Request Type: POST
    Content Type: "application/json" (This is very important as it ensures the JSON string you pass to the Logic App is converted into a JSON object before the logic app tries to convert it into XML. Failure to do use this content type may result in an error).
    Authorization: No longer required

    Nintex Web Request Action
    This configurations shown in this screenshot is a little outdated. Please refer to the notes above for configuration.
  2. Query XML: This action is used to parse through an XML document to retrieve necessary information.
    Nintex Query XML Action

Next Steps

If you would like to try the azure logic apps and API apps out yourself, I would recommend reading the following blogs and articles to get started:
Do you also work with JSON based REST API in Nintex Workflow? Please feel free to share how you address this particular scenario in the comments below.

Popular posts from this blog

SharePoint | Set default value of date field to last day of the month

One of the things, that I needed to do recently is find a way to set the default value of a date field to the last day of the month. Though some content were really helpful in getting me on the way to solving the problem, I thought I'd post the formula required to make it easier for others looking to do the same in the future. What I wanted to do  The steps below describe what I wanted to achieve: User uploads a file into a document library A date column will automatically be populated with the date representing the end of the month (calculated based on the date the file was uploaded) How do we do this? Open your column settings for your date field Under the Additional Column Settings, set the default value option to Calculated Value Enter the the formula below: =(DATE(YEAR(TODAY()),MONTH(TODAY())+1,DAY("1-Apr-2008"))) - (1) Click save and that's all you need to do What does the formula above do? The formula above is quite simple.

Uploading a file from a SharePoint document library into an Azure Blob Storage with Microsoft Flow (or Logic App)

The Problem One of the things that I've been experimenting with lately is Microsoft Flow . The service allows you to build process automation to facilitate transfer of information from one system to another easily. One scenario I wanted to try out is to be able to copy/move a file from SharePoint to an Azure Blob Storage. There are a number of reasons that you may want to do this: Archive files that are no longer needed Upload a copy of a file (usually an image) into a Blob Storage so that images can be hosted in a CDN to optimize page load performance In the past doing something like this would have required some form of custom development e.g. a remote event receiver. However the introduction of Microsoft Flow and Logic Apps has created another alternative that is worth exploring.... Update 30/09/16:  If you are looking to put your assets into a CDN to make it load faster, then it's worth checking out the new Preview Release  Office 365 Public Content Delivery

Only show a control to an employee's manager in PowerApps (using SharePoint as a data source)

The Problem In my previous blog post , I wrote a basic tutorial on configuring PowerApps to conditionally show/hide and make mandatory/optional a control based on the answer provided in a previous control. In this blog post we will expand on that scenario to create a form that only shows a control called approval status to a user if that logged in user is the manager of the user specified in the employee control. This means when the manager is using the application, they can change the status to approved. Meanwhile, a user that is not a manager of the person specified in the employee cannot change the status to approved. The Solution Aside from containing a variety of native functions, PowerApps also allow us to add connections to add functionalities into our app. In this case we will add the Office 365 Users connection so that we can get information on: The user that is logged on The manager of the user specified in the employee control Note: Whilst this soluti