Nintex Reporting - Most Popular Query Report

You'll find this report (or chart) in the Search category of reports. If you go to the Nintex Reporting Report Center it'll look like this :



This is without a doubt, one of my favourite reports that come out-of-the-box. Sounds strange, yes, and you may be asking, why do I care what my users are searching for?

Curse your tongue!

You should always care what your users are doing. Did you not watch 1984? Are you not big brother? What if your users are doing it wrong? What if one person is doing it right, and the rest are wrong? What if everyone is doing it right, but one person?

All that is important information to know so you can improve your organization and make everyone more productive. Because really, when it comes down to it, why are you using an analytics type of product, if you don't want to know this information?

Ok, enough jibber-jabber (Thank you Judge Robert Sanders from Boston Legal for that).

One of the big questions to ask when looking at the Most Popular Query report, is why are my users searching for this particular term? Is there something we can do, that might minimize the need to continually search for it?

Let's use the following screenshot as an example and treat the numbers on the x-axis as 1000's.



In this situation, we see that our users have searched for the word "energy", 2000 times. So I go and run this by a few users, and find out that they are all looking for the link to our internal "Energy conservation" site. Well, each search through our portal might take 5 seconds. 2000 search = 10000 seconds = 166.66 mins = 2.77 man (or woman) hours.

Doesn't sound like a lot, but think about it over all the searches that are performed through SharePoint.

Wouldn't we all benefit, if on our main portal, we just have a link to the Energy Conservation site? All of the sudden, there's 2.77 man (or woman) hours that we have saved.

Now to a similar, but probably more relevant to every company, scenario. What if the term you find your users search for most often is "timesheet", and funnilly enough it happens every Friday. *lightbulb turns on*. Lets add a link to our portal that takes our users straight to the timesheet.

Conclusion

There are going to be reports in Nintex Reporting that different people will find useful in different ways.

You sometimes need to take a look at these reports and think about - What is this telling me about my specific environment or company? Can I use this information to somehow improve things?

Statistics and Charts are great, but it's what you do with them that's really important.

Nintex Workflow - Web Service XML Result - What does it look like ?

Web Services are quite handy, but some of the data that gets returned can look like giberrish. This is especially true when you are dealing with XML that gets returned.

A scenario I came across recently, was getting a list of SharePoint users that are in a SharePoint group. This is possible via the SharePoint UserGroup web service - http://msdn.microsoft.com/en-us/library/ms772647.aspx. Specifically, the GetUserCollectionFromGroup web method.

In order to use the information from this web method, we need to parse the XML returned, and extract the information we need.

What I have found to be the easiest way to start working on this type of issue, is to configure the Call Web Service action to make this call and store the result in a text variable.



Now that we have the resulting XML in a text variable, we want to see what it looks like. You can't log it to the workflow history, because there are just too many characters in it.

Instead, I use a Send a Notification action and configure it to send the initiator of the workflow an email with the XML as a file attachment.



To add an attachment to a Send a Notication action, you simple click on the "Show Attachments" link. Then click on the "Add Attachment" link and it will give you a pop up that will allow you add an attachment to your notification.



You then click on the "New File" radio button, type in a filename you want for your attachment. I usually use something like "xml.txt", as it lets me easilly open the file in notepad.



Click on the Insert Reference button, and you can insert your text variable which contains your XML into the attachment.



Now we can publish the workflow, run it and you should get an email with the attachment. You can then open it, and figure out the best way to use the Query XML action to parse the data that you need.

This is what the email looks like :



As you can see, the attachment is 605 bytes. A lot bigger than what is allowed in a Workflow History message (255 bytes).

As I'm attaching this as a text file, if you open it up, it's not going to be very pretty. But if you save it to your local disk and rename it to XML and open it in something like Internet Explorer, it will look something like this :



Now it's easy to see that we are getting the data we expect, and also what format that data is in, so we know whether to use XSL or XPath in our Query XML action.

What this complicated workflow looks like :



Note : Workflow has been updated to include a few Query List actions to retrieve the Login Name, Email and Name from each User node that we have received from the Web Service call.

Note : this doesn't have to be specific to XML or even responses from Web Services. It can be used in any situation you have some data you want to see in a complete form, but it is not possible via the workflow history.

Useful Downloads

Get Users in a Group Workflow download

Nintex Workflow - Run a Workflow on Delete List Item Event

I'm sure a lot of you have wanted to have a workflow run when someone decides to delete an item out of a List. Ok, maybe not a lot of you, but some. Ok, atleast a couple, because I've seen the questions on Nintex Connect.

So the only way to do this, would be to have a SharePoint Event Handler. I won't go through the process of creating one of those, as you can follow this link : How to: Create an Event Handler Feature

Now kicks in the thinking about what we really want to do, and how efficiently we can do it.

I don't really want to create a new Event Handler for every list where there will be a delete event. I'd also like for there to be nice single location where this can be configured.

The Design

I'm going to add my Delete Event Handler into a SharePoint feature. This can therefore be activated at the Site level. Everytime someone performs a delete action on a SharePoint List Item in site where this is activated, the event handler will be executed.

The Event Handler is going to expect a specific List to exist on the site it is running on. I chose a cryptic name for the list - "Delete Event Handler Workflows". This list will contain (List,Workflow) pairs. When the Event Handler kicks in, it will query this list for any items that match the current list the Event Handler is looking at. If it does, it gets the Workflow name and then starts that workflow on the item that is trying to be deleted.



Once starting the workflow, it will go into a loop and every 10 second, it will check to see if the workflow has finished.

As the Event Handler will wait, and therefore make the deletion wait, you probably want to make the workflows the Event Handler starts, fairly quick.

What does the source look like?

What I've created is a very straightforward piece of code. It can really be enhanced greatly. This is what the main part of the Event Handler source looks like.

            SPWorkflowManager workflowManager = properties.ListItem.Web.Site.WorkflowManager;
            SPWorkflowAssociationCollection waColl = properties.ListItem.ParentList.WorkflowAssociations;

            List workflowNamesToRun = new List();
            string deleteHandlerListName = "Delete Event Handler Workflows";
            string currentListName = properties.ListItem.ParentList.Title;

            try
            {
                SPList deleteHandlerList = properties.ListItem.Web.Lists[deleteHandlerListName];

                SPQuery oQuery = new SPQuery();
                oQuery.Query = "" +
                    "" + currentListName + "";
                SPListItemCollection collListItems = deleteHandlerList.GetItems(oQuery);

                foreach (SPListItem oListItem in collListItems)
                {
                    workflowNamesToRun.Add((string)oListItem["Workflow Name"]);
                }

                if (workflowNamesToRun.Count > 0)
                {
                    List waToStart = new List();

                    foreach (SPWorkflowAssociation wfAssoc in waColl)
                    {
                        if (workflowNamesToRun.Contains(wfAssoc.Name))
                            waToStart.Add(wfAssoc);
                    }
                    foreach (SPWorkflowAssociation wfAssociation in waToStart)
                    {
                        try
                        {
                            properties.ListItem.Web.Site.AllowUnsafeUpdates = true;
                            SPWorkflow workflow = workflowManager.StartWorkflow(properties.ListItem, wfAssociation, wfAssociation.AssociationData);

                            while (workflow.IsCompleted != true)
                            {
                                System.Threading.Thread.Sleep(10000);
                            }

                            Console.WriteLine("Complete...");
                            //properties.Cancel = true;
                            //properties.ErrorMessage = "Deleting items from " + properties.RelativeWebUrl + " is not supported." + Environment.NewLine + names;
                        }
                        catch (Exception ex)
                        {
                            properties.Cancel = true;
                            properties.ErrorMessage = "Deleting items from " + properties.RelativeWebUrl + " is not supported." + Environment.NewLine + ex.ToString();
                        }
                    }
                }
            }
            catch (Exception ex)
            {
                // the Delete Event Handler Workflows list does not exist
            }

One suggestion for enhancing this, would be to somehow have your workflow do something, that tells the Event Handler to cancel the deletion.

Note

This Event Handler currently only works for SharePoint Lists. It is not coded to work with Document Libraries, Tasks etc. So this might be something to think about when you are creating an Event Handler.

Deployment

The SharePoint solution can be installed using the STSADM command line tool :

stsadm -o AddSolution -filename VTNWDeleteEventHandler.wsp
stsadm -o DeploySolution -name VTNWDeleteEventHandler.wsp -immediate -allowgacdeployment
stsadm -o installfeature -filename VTNWDeleteEventHandler\Feature.xml
iisreset

To activate the feature at the SharePoint Site level, you can either go to Site Settings and click on Site Features, and enable the feature there :


Or, you can use the STSADM tool :

stsadm -o activatefeature -filename VTNWDeleteEventHandler\Feature.xml -url 

And to deactivate the feature :

stsadm -o deactivatefeature -filename VTNWDeleteEventHandler\Feature.xml -url 

The SharePoint solution can be removed using the STSADM command line tool :

stsadm -o uninstallfeature -filename VTNWDeleteEventHandler\Feature.xml
stsadm -o RetractSolution -name VTNWDeleteEventHandler.wsp -immediate
stsadm -o DeleteSolution -name VTNWDeleteEventHandler.wsp

Usage

To test this out, I work in a list named "TestDeleteHandler". I created 2 Nintex Workflows that will copy an item to another list named "Archived Items".



First workflow looks like this :



To test this Event Handler, we need to first create an item in the "TestDeleteHandler" list. I create the following item with a title field of "Seven". I do this with a Nintex Workflow (because it's a lot faster than doing it in SharePoint Designer).



Then we delete this item and our Event Handler should kick in, and start off 2 workflows. One will do a direct copy of the item to the "Archived Items" list, and the other with do the same, except with a different Title.



Now that we know it works, we're ready to use this in a more realistic scenario, such a doing backups of items incase the deletion is an accident. I'm ignoring the existence of the Recycle Bin :).

Useful Downloads

VTNWDeleteEventHandler.wsp

Nintex Workflow - Math Inline Functions

The Inline Function functionality has really opened up Nintex Workflow design. You can use any of the out-of-the-box inline functions (look up the Nintex Workflow help - get it at http://connect.nintex.com). But the really exciting thing is that Microsoft provides other static methods that you can add to Nintex Workflow and do even more in the product. I talked about some of this in my article Nintex Workflow - Trigonometry (why?....why not?)

But what if you want something else that you can't find available in any of the Microsoft namespaces/classes?

That's when you start doing some development and create your own Inline function.

What is an inline function?

The simple explanation, is that it is a static method, in a class, in a namespace, in an assembly in the GAC.

So what you need to do, is start a project in Visual Studio. I chose a Class Library. Add a new class to it and then add some static methods to that class that you want to expose to Nintex Workflow designers. Make sure your project is signed, as it will need to go into the GAC (and therefore needs to be strongly named).

Then you add the inline function reference to Nintex Workflow, using NWAdmin tool that is installed with Nintex Workflow. It has an -o AddInlineFunction operation. You just need to provide it with the details of your Inline function.

What has prompted me to look into this?

Recently I found that people would like to do some basic calculations inside the Build Dynamic String action. But it currently isn't built to accommodate this type of functionality out-of-the-box.

Example :
You have a text string "PingPong.txt", and you want extract the "PingPong" part. Yes you could do this with a Regular Expression action, but we want to do it in a Build Dynamic String.

You have the fn-SubString inline function, but that takes a 0-based start index and the number of characters you want to get. But if the text you expect changes length, then you can't hard code that in.

Here's our issue :

fn-SubString(PingPong.txt, 0, 8) = PingPong
fn-SubString(Tennis.txt, 0, 8) = Tennis.t

What we can't do, is something like this :

fn-SubString(PingPing.text, 0, fn-Length(PingPong.txt)-4)

You can't do the (subtract 4) calculation, as the Build Dynamic String action does not support this.

The ugly workaround :
1. Have a Build Dynamic String action that uses the fn-Length inline function and stores the result in a text variable
2. Add a Convert Value action to convert the length into a Number variable
3. Add a Math Operation action that would subtract 4 from that Number variable
4. Add another Build Dynamic String action, that would have this fn-SubString(PingPong.txt, 0, {WorkflowVariable:numLength}) - or something like this

Seems like a lot to do, when a simple calculation would make things so much easier.

Solution

I created a class called VTMath and added 4 static methods to do the most simplest of math operations. Add, Subtract, Multiply and Divide.

public class VTMath
{
    public static double Add(double x, double y)
    {
        return x + y;
    }
    public static double Subtract(double x, double y)
    {
        return x - y;
    }
    public static double Multiply(double x, double y)
    {
        return x * y;
    }
    public static double Divide(double x, double y)
    {
        return x / y;
    }
}

Now that we have the code, I make sure my class library is signed, built into a SharePoint feature (just because) and we are ready to deply.

Deployment of our new Inline Functions

Here are the deployment command lines.

stsadm -o AddSolution -filename VTMathInlineFunctions.wsp
stsadm -o DeploySolution -name VTMathInlineFunctions.wsp -immediate -allowgacdeployment
stsadm -o execadmsvcjobs

Now that the solution is deployed, we need to tell Nintex Workflow of our new Inline Function.

Go to the installation folder of Nintex Workflow, so you can run the NWAdmin.exe tool. Usually located : c:\program files (x86)\Nintex\Nintex Workflow 2007

Run the following in the command line prompt:

NWAdmin.exe -o AddInlineFunction -functionalias fn-VTAdd -assembly "VTMathInlineFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05b6de0f79daedbe" -namespace VTMathInlineFunctions -typename VTMath -method Add

NWAdmin.exe -o AddInlineFunction -functionalias fn-VTSubtract -assembly "VTMathInlineFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05b6de0f79daedbe" -namespace VTMathInlineFunctions -typename VTMath -method Subtract

NWAdmin.exe -o AddInlineFunction -functionalias fn-VTMultiply -assembly "VTMathInlineFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05b6de0f79daedbe" -namespace VTMathInlineFunctions -typename VTMath -method Multiply

NWAdmin.exe -o AddInlineFunction -functionalias fn-VTDivide -assembly "VTMathInlineFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05b6de0f79daedbe" -namespace VTMathInlineFunctions -typename VTMath -method Divide

What this means, is that now instead of all those actions and variables, all you have is one Build Dynamic String action.

fn-SubString(PingPing.text, 0, fn-VTSubtract(fn-Length(PingPong.txt),4))

As an example of what you can do now in the Build Dynamic String action, would be to make a calculation like this :

(((10 + 20) / 5) * 3) - 15

The Build Dynamic String would look like this :

fn-VTSubtract(fn-VTMultiply(fn-VTDivide(fn-VTAdd(10,20),5),3),15)

It may not be the neatest, but it'll cut down your workflow design by a lot if you had to do something like this.

Useful Downloads

Solution File - VTMathInlineFunctions.wsp

Nintex Workflow - Ping the Environmentally Friendly Custom Action

Recently, I saw a Nintex Workflow user comment on a Nintex Connect - How many black balloons ? forum, about how their company has an initiative, that every must turn their computers off at night. Less electricity, means less greenhouse gases, means less bills and better for the environment.

The idea was, that they had some process which pings all the computers and reported the results into a SharePoint list. This list contains a workflow which would run and and perform some sort of calculation, and I assume would then email the appropriate owner of the computer that they forgot to turn it off..etc..etc.

For those that don't know what Ping is : Ping on Wikipedia

Well I think this is a great idea. Most computers are kept for completely unnecessary reasons. I wish I had some statistics to show how many computers are actually kept on around the world, which actually do nothing.

So I thought, rather than separating the process of pinging from the workflow, I want to make my workflow do the pinging as well. We could use the workflow scheduling to schedule it to run every day at a certain time.

One small problem. How do you ping? Nothing came to mind. As in most cases, I had a few options :
1. Create a Nintex Workflow Inline Function - no reason why we couldn't, but it'd be fiddly to configure in a Build Dynamic String action, then convert the Ping time to a number variable.....blah blah blah
2. Create a Web Service - I think that had similar issues as the Inline Function
3. Create a Custom Nintex Workflow Action - I'm a geek, so this was my choice

The Ping Action

The cut and dry of it, is that it sends a 32 byte text string as the ping message, sends the message to the IP Address or Host Name, gets a response and stores it in a Nintex Workflow Number variable. This number is the number of milliseconds it took to respond.

Configuration of the Ping Action

Once installed, the action will reside in the Vadims Actions group in the workflow designer.



For those that don't know why I have a picture of Table Tennis rackets for this action, in other parts of the world Table Tennis is called Ping Pong.

You'll notice I have the other action in Vadims Action. The "VT List Item Get Attachment" action was described here : Nintex Workflow - Get List Item Attachment in Base64 Custom Action (Happy Thanksgiving)

The actual configuration of the action is quite straight forward. You need to first create a Nintex Workflow Number variable to store the Ping Time. Configure the VT Ping action, by providing either a Host Name (eg. vtonms.blogspot.com), an IP Address (eg. 74.125.95.191) or a reference to a Workflow variable or metadata that contains one of those.



Error Handling

Fingers crossed nothing completely bad happens, but just incase, I have added an Error Handling section to the configuration so that you can make your workflow more robust by capturing the error and building some Workflow logic around it.

Return Values

The action will either return the Ping time (greater than or equal to 0), if the computer responds, or a -1 if for whatever reason, we do not get a successful response.

Usage example

I am going to keep my example simple as I think this is a fairly straightforward action.

A simple list with a Title and a Number column named Ping Time. I create a new item and in the Title field, I put in either a Host Name or IP Address.



I then create a workflow that will take the Title field as the input and store the Ping Time in my number variable.



I then use a Set Field Value action to update the "Ping Time" field of my list item, to record how long it look that computer to respond.

The Workflows looks like this :



The resulting list ends up looking like this :



You can see from the results, that the machine "ntx-vadimdesk", which is the server I'm running the workflow on, returns a Ping Time of 0. This is expected, as it should be almost instantaneous as it's all happening on the one server.

I then tried to ping "www.google.com". The result of which is a 99ms response time. Not the best, but not the worst.

My last attempt is for an IP Address I know is not used by any machine. This returns a -1. This is the same as if that was a server name for a machine that isn't on at the moment.

You could potentially, have a list on machine name (or IP Address) the user who owns each machine. In your workflow, if you continuous got a response from that server, but you are sure it should be turned off, then you can email the owner and tell them. If it continute, you can email their manager. The complexity of your workflow to handle this situation is up you.

Download VTPingAction.wsp SharePoint Solution

Installation

To install this solution, run the following command line :
stsadm -o addsolution -filename VTPingAction.wsp

You can then go into SharePoint Central Administration->Operations and click on Solution Management. Here you can deploy the solution.

This deploys into the following folder :
c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\NINTEXWORKFLOW\VadimsActions\VTPingAction

One of the files that gets deployed is the NWA (Nintex Workflow Action) file. You use this to add the action to Nintex Workflow via the NWAdmin.exe utility, located :
c:\Program Files (x86)\Nintex\Nintex Workflow 2007

The command line would be :
NWAdmin -o AddAction -nwaFile VTPingAction.nwa

You will probably need to perform an IISRESET, so that the new assembly gets loaded. Then, in Central Administration->Application Management, in the Nintex Workflow Management section click on Manage Allowed Actions. Here you should scroll down to the VT Ping action and enable it.

The action should now appear in the workflow designer.

In Conclusion

The irony of this, is that this needs to run on a server and use electricity, in order to tell other people that they are running the machines and should turn them off. The upside is, I don't know of any production SharePoint server that is turned off at night, so you might as well utilize it by telling your staff to stop being lazy and turn their machines off before they head home.

Let try to help the environment in our own little way. Every little bit counts.

I had to add this link, as it seems quite related to this issue : Computers and overnight usage

A desktop CPU running idle with Screensaver consumes about 0.082 Kwh
Energy Usage for overnight, 5pm-9am, 16 hours (Given an eight hours work day) = 0.082 x 16 = 1.312 Kwh
Energy Usage over five working day overnights = 1.312 x 5 = 6.56 Kwh
Energy Usage over the weekend = 0.082 x 48 = 3.936 Kwh
One working week Energy Usage = 6.56 + 3.936 Kwh = 10.496 Kwh
Energy usage over one year = 10.497 x 52 = 545.792 Kwh
Average Energy cost per Kwh = 11 cents.
Annual Energy Cost for the Desktop CPU = 545.792 x .11 = $60.04

The above stats are for a specific computer, but we can use them to generalize a few things.

Lets say you had 500 staff, with 500 computers on their desks, all leaving them running every day 24/7.

10.496 Kwh * 500 = 5298 Kwh (wasted electricity)
$60.04 * 500 = $30,020 the company could be saving

Imagine bigger companies like IBM, Microsoft, Oracle etc. They probably have their own energy user reduction schemes, but it's something to think about.

Minor Changes to the Blog

Unfortunately, some of the unpleasant people of the world have been adding comments to my blog entries, trying to pawn off their wares or porn.

So I've had to turn on moderation (I'll need to approve all comments) and require people to enter word verification. I know.. it's a pain, but I'm getting tired of deleting the spam.



On a better note, I've added a Poll to the top right of the blog.



Periodically, I'll change the poll to something interesting, so I can get a feel for what you guys and girls like and dislike. I haven't made up my mind exactly what all the polls will be about. For the time being, they will be about some of things I work with more intimately (Nintex products). Later on, I might poll about other things like Silverlight and WPF. I'm having decision making issues :).

Nintex Workflow - MSDN Hexadecimal use in a Nintex Workflow

There are a number of places on MSDN, where the values you pass to a SharePoint web service are shown in hexadecimal form. This is all good if you are developing in one of the .Net languages as developers would know what that means. But when you are trying to make a call to something like the Permissions web service (AddPermissions web method), then 0x00040000 really means nothing to the Workflow designer.

Remember that these fields really do take a numeric value and not a text value. 0x00040000 needs to be converted to a decimal value (eg. 262144) to be used correctly.

You can do this using the calculator provided with your Operating System.

Open up the calculator and set it to "Programmer" mode. Here you can select "Hex" mode and you can then enter the 0x00040000. Although it'll come up as 40000.



Now that you have entered your Hexadecimal number, you can click on the "Dec" option to change it to a decimal number.



You can now use this number in your web service call.

The other thing to remember, is that if one of these fields can be multiple values, then you need to do some calculation.

For example, if you want to give a user the following permission AddAndCustomizePages and ApplyThemeAndBorder permissions then you do an "add" :
AddAndCustomizePages : 0x00040000 (262144)
ApplyThemeAndBorder : 0x00080000 (524288)
Hex Result : 0x000C0000
Decimal Result : 786432

So you put the 786432 into the field you need.

Is there a way in Nintex Workflow where we can let our workflow do this?

Out of the box, there isn't an easy way to do this. But with a little work we can make it possible in Nintex Workflow.

Our options are to either create a Custom Nintex Workflow action (overkill), or create a Nintex Workflow Inline Function. The advantage of using the Inline functions of Nintex Workflow, is that we can either use something already provided to us by an existing assembly in the GAC, or we could create our own.

For this issue, we'll use something that Microsoft provides.

Convert.ToInt32

This static method can convert hexadecimal strings to integers (numbers). As this will be available on any server that .Net is installed, which is every SharePoint server, we can just add this to our Nintex Workflow database.

What we need to do, is open up SQL Management Studio, expand the Databases option, and then expand the NW2007DB database. This is the Nintex Workflow database, and the StringFunction table is what we are interested. Here we add our new Inline function.



If you want the SQL Insert Script for this :

INSERT INTO [NW2007DB].[dbo].[StringFunction]
           ([FunctionAlias]
           ,[MethodName]
           ,[AssemblyName]
           ,[Namespace]
           ,[TypeName])
     VALUES
           ('fn-ConvertToInt'
           ,'ToInt32'
           ,'mscorlib'
           ,'System'
           ,'Convert')

Another way to add an Inline function, is to use the NWAdmin.exe command line utility that gets installed with Nintex Workflow :

NWAdmin.exe -o AddInlineFunction -functionalias FunctionAlias -assembly Assembly Name -namespace Namespace -typename TypeName -method MethodName

In our case, we would run it this way :
NWAdmin.exe -o AddInlineFunction -functionalias fn-ConvertToInt -assembly mscorlib Name -namespace System -typename Convert -method ToInt32

Now if we want to use this Inline function, we use the Build Dynamic String action.



Here we are calling the fn-ConvertToInt Inline Function, passing in what we see from the MSDN site for SPRights. In this example, we are working with giving the user/group the permission of AddAndCustomizePages, which according to the MSDN site, is actually hex 0x00040000. We are also passing in 16 into our Inline Function, as that it was tells our static method that we are converting a text string which is hexadecimal format, into an Integer.

We can then use the Convert Value action to convert the text we received, back to a Number workflow variable, if we need to do any calculations on it, or we can simply use the text returned, and put it into our Call Web Service action SOAP configuration.

It's as simple as that. A new Inline Function, and we now open up Nintex Workflow with new functionality it didn't have before.