Nintex Forms (on-prem) Web Request Control Internals

I would like to share my experience with Nintex Forms Web Request Control. It's a great Form control that everybody loves to use. However, I tried to do complex tasks based on that control and that is when it’s boundaries were revealed.

In this post, I will explain what my objective was, how this control limited me and how I got around its limitations. Before that some nice things about this control

Advantages

1. This opens up the way to fetch the data from external data sources via HTTP protocol. Not only it provides the comfort of not having to write ajax code but also deals with the CORS issue that every ajax code has to face. How does it overcome CORS? Because it doesn’t request the external web service from the client/browser but rather requests the Nintex REST service (/_vti_bin/NintexFormsServices/NfRestService.svc) that is local to the current domain. Apparently, Nintex REST service does the talking with external web services behalf of the web request control. Amazing! Isn’t it?
2. Icing on the cake now. This control also provides a way to impersonate the current user as the account that was setup on SharePoint server (Secure store target application id). This gives more power in terms of reaching to a remote web service that has been restricted from normal users. Bloody awesome!



3. Of course, you can use XPath to retrieve the data out of the response XML. The impressive thing is that you can dictate what HTML control needs to be used to display that data. If you have one unit of data (eg: first name, last name etc) then you would select either Text control or Label control. If you have multiple values of data then you would go for Drop down list or Check box list etc.

My Requirement

• Call a remote web service that provides product details.

• Get all the product details as the key value pairs.
• Build custom HTML table view based on the key value pair list data and embed the view in the Nintex Form.
• Never store the product data in SharePoint. Always fetch the product details from the remote web service either in the EDIT mode or DISPLAY mode of the form.

Implementation

• Use the Web Request Control to fetch the response from the remote product web service.
• Use XPath to fetch the Xml node and value information.
• Render the control as a Drop Down list.
• Hide the Web Request Control always with the help of Nintex form rules.
• Use the Web Request Control “option” HTML nodes  and their values to build the data object.
• Build the custom HTML table view based on that data object in Edit and Display mode of the Nintex form.

Challenge

According to the implementation plan, everything works well in Edit mode but doesn’t work in Display mode of the form.

Well, there is a very good reason why it behaves in that way. When we configure the Web Request Control to render as a Drop down list, it renders as that only in Edit mode but not in Display mode. It renders as an HTML label control in display mode.

When it renders the Label instead of the Drop Down List, that is where I loose the dataset. Now the dataset is no more a list of key value pairs but a fragmented text value (meaningless!!). By the way, I didn’t connect the Web Request Control to any of the SharePoint List fields.

This is not a fault in the Web Request Control behaviour though! It expects the user to save the selected value to a SharePoint List field. There by, it can display that selected value as a Label in the display mode.

BUT, I want this Web Request Control holding on to key value pair of data (as a DOM node property). I checked the control’s DOM tree in vain.

Work Around

As I am not allowed to save the remote web service response anywhere on SharePoint, I was compelled to dig through the Web Request Control code in search of an alternative. My intention was to leverage the Nintex REST service that was used by this control to fetch the response. And I managed to get hold of it.

The central idea is that you should be able to cheat Nintex REST service by stealing the Web Request Control’s identity. Sorry Nintex!

Here is the code…

formControl = NWF$("div.nf-dataaccess");
var body = {
	TokenResults: formControl.data("TokenResults"),
	Data: formControl.find(".nf-settingsVal").val(),
	ControlType: formControl.attr("data-controltype"),
	DataStamp: (new Date).getTime()
};

NWF.FormFiller.Functions.AjaxPost("/_vti_bin/NintexFormsServices/NfRestService.svc/GetDataForControlAsync", JSON.stringify(body), function(d) {
	console.log(d.Data);
});

Steps

1. Get hold of DIV tag with the CSS class “nf-dataaccess”. Make sure that you catch the right HTML node. If it has returned more than one, narrow down to one by modifying selection criteria.
2. Gather up required parameters that are needed for the HTTP request object.
3. Send the request and Bingo! you got the response.
4. You might have to process the HTTP response data to convert it to list of key value pairs though!

That’s it! you can now do whatever you like by placing this Web Request Control on the form and by stealing its identity.

Happy Nintex coding folks! If you like this post, please like and share. Also, please feel free to comment