Nintex Workflow – Web Request action 101

There are some web services that expose web methods that I can’t use via the Call Web Service action in Nintex Workflow. Usually, it’s those methods that have “out” parameters, but it can also happen for those methods that use non primitive types as parameters.

Below is an example :
http://<server>/<site>/_vti_bin/Lists.asmx?op=AddAttachment

I honestly don’t know the exact reason why there is an issue using that web method, but suffice it to say, YOU CAN’T!

In comes the new Web Request action that Nintex made available in build 11000. It is actually quite handy, and I’m thinking that I will be using this action more often than that Call Web Service in the future.

This is what the configuration of the Web Request action looks like :

In this article, I’m going to take the simplistic approach and just show you how to use this action with SOAP 1.1 packets.

When we look at the SharePoint Lists web service, and specifically the AddAttachment web method, we see it supports a SOAP 1.1, so we select that in our configuration window. The Web Service URL and credentials are the same as if you configuring a Call Web Service action.

You can see that the value of SOAPAction goes into the appropriate edit box in the Web Request configuration, and the SOAP envelope again is a cut’n’paste but all you need to do is fill in the details (place holders).

As a test, I have configured my action to call the AddAttachment web method. What this does, is take the List name, the Item ID where I want to add the attachment to, the name I want to call the new attachment, and the Base 64 encoded value of the data that will go into the file. This would be the best way to add an attachment to a list item if you are building up that data on the fly.

I have set it to pass in my current List, and I want to add an attachment to the item which has a List Item ID of 2. I am building up my filename earlier up in my workflow (which is unimportant in this article). The Base64 encoded data I have in my Nintex Workflow variable is : MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw

When I run the workflow, my item looks like this :

The reason why I have 3 attachments, is that my workflow actually queries the current item the workflow is running on, getting each attachment in a Base64 encoded form and adds it to the next item.

When I click on the one of the attachment that has the above mentioned Base64 encoded data, it looks like this in it’s decoded form:

Output

With what I’m doing in this example, I don’t care about the output I am getting back. But if you look at the information provided from the web service, this method does actually return data. If you were to use an web method like “GetAttachmentCollection”, then you would get more relevant data back, and you would use the Query XML action to parse that data.

For the “AddAttachment”, the output is this :

Querying that with a Query List action would actually be quite straightforward, if you want to get the AddAttachmentResult and store it somewhere for auditting.

Conclusion

There are more things you can do with the Web Request action, such as getting information back, getting it stored in a text variable and then parse it. Or, handle cookies, and keep connections alive. All of which are a little more advanced than this article.

But this should give you some extra options when you are trying to call Web Service methods or HTTP requests.

Leave a Reply

Your email address will not be published. Required fields are marked *