Nintex Workflow Experience

Blog change: Now using a Code Sharing Tool

2010-07-20T09:51:00.000+02:00

Since last post I started to use Pastie to share source code. It's a nice free tool which helps to share and embedded code in other sites, a Pastebin Application. Today I updated the last posts also with embedded source codes from Pastie.

I hope you like it!

http://pastie.org/

How to create a Custom Report on Nintex Workflow 2007

2010-07-19T16:42:00.002+02:00

Since last week I was looking forward on how to deal with custom reports on Nintex. And it's very nice, the way they developed it gives the users some great capabilities on querying workflow information. This post shows the necessary steps to create a custom report using the data already available on Nintex Workflows. I also suggest a previous reading on the SDK document, available here:

http://connect.nintex.com/files/folders/sdk/entry122.aspx

Nintex have it own database separated from SharePoint. The developers are capable of creating new tables, stored procedures and what else is necessary to improve the workflow customizing. On the Reporting case, we can create Stored Procedures to handle our custom queries. This How to create a query which looks for how many tasks the users handled. It's quite simple, but is a good way to check how reporting works.

1. First of all, let's create the XML file of our Report. All the information about the elements of the XML can be found on the SDK PDF, which I linked before. Bellow is the full XML. Save it in your hard drive, we will use it later.

2. After creating the XML file, we need to create a new stored procedure to handle it in the Nintex Datababase, on the SQL Server. It's quite simple, with one input parameter - @Username - which is used to filter the query.

3. Now that the Stored Procedure and the XML used as interface are created, when can create a new Report on the SharePoint Central Administration. Go to Application Management > Nintex Workflow Management > Manage Reports. And click on Add New Report.

4. On the new screen, type the name of the new report, an optional description, and the role if you want to restrict the access, and the XML file, which we created before. After filling the information, click Ok.

5. It's necessary to restart the IIS for the server, in order to make the report available in the SharePoint. It's important to notice that this reset is only necessary when a new report is added; if we just change information on an existing Report (including the XML) it's not necessary to restart it.

6. Ok! Now our report is available! Yes, but only for Administration Reports. To check it working, go to SharePoint Central Administration > Application Management > Nintex Workflow Management > Administration Reports. The reports that appear here have the Scope property defined as Farm. You will notice that the filter by user is available and properly working.

7. And how to let the report available on my site collections? It's also simple. You need to give Execute permission on the database Stored procedure to the user of the SharePoint Application Pool. By default, this user is WSS_Content_Application_Pools, but maybe it was changed in your installation. To give the user permission, go to the SQL Management Studio, right click on the Stored Procedure, permissions, search this user and give him Execute permission.

8. Now the report is also available on the sites of the site collections! You can add Nintex Web parts to consume it! Have fun!

How to create links to the Workflow Status and Details on a List

2010-07-16T14:25:00.000+02:00

This post is quite simple, because it uses some common Nintex variables, but it born from a real user needing, and before I realized it was partially available. My first approach to create the links to the Workflow Status and Details pages was to create the URLs manually. And it worked! But then I realized that it is not necessary. Below I explain step by step how to do it!

1. Create a new List, and add two columns to it Workflow Status and Workflow Details, of the type Hyperlink or Picture.

2. Create a new workflow, and add two variables to it, urlStatus and urlDetails , of the type text:

3. As the first step of the workflow, add a String Builder action, in order to format the Workflow Status URL. As I said in the beginning, the URL is already provided by the workflow, what makes it simpler. On the Build String field insert the following text:

{Common:WorkflowStatusUrl}, Status Diagram

And store the result in the variable urlStatus. The format of the URL variable is (url, description) and is used to create the link with a friendly name. I found how to do it here:

http://didierdanse.net/blogs/dev_en/archive/2009/01/11/sharepoint-how-to-set-an-url-column-using-code.aspx

4. The next action is the same as the previous, but now for the other column. Thus, add a String Builder action, and on the Build String field insert the following text:

{Common:WorkflowLogUrl}, Details

And store the result in the variable urlDetails.

5. The last step of the workflow is to update the current list item. Just select the columns and the respective variables and set them up, like the picture below.

6. Now you can Publish the workflow and test it!

7. Maybe it’s a good Idea to create a Snippet to reuse these steps in other workflows. To accomplish it, add an Action Set and move all the actions of the workflow inside it. Then, click in the arrow on the right corner of the action and select Save as Snippet. It will be available in the My Snippets session of the workflow actions menu.

How the delegation works on Nintex Workflow 2007

2010-07-13T10:51:00.005+02:00

After reading a good article on Let's SharePoint blog, I decided to do some tests about delegation on Nintex Workflows 2007, and I found interesting results.

Let's SharePoint post, Nintex Best Practice Task Delegation:

http://aknauer.blogspot.com/2009/10/nintex-best-practice-task-delegation.html

First of all, the way I'm doing the delegation is for all tasks, using the top menu, as I have described in my first HOW TO post on this blog:

http://workflowexperience.blogspot.com/2010/07/how-to-get-delegated-user-of-task.html

About the delegation (on build 11004), it works in a "recursive" way, where I can delegate a task to a user, and this user can delegate his tasks to another user, and it assign the task to the last user of this "queue". But there is "deadlock" prevention mechanism, which avoid the deadlock if, for example, the last user delegate his tasks back to the first user, creating a circle. Bellow there are two examples which describe these scenarios:

I also did more "cascade" tests to see if it really works with more users, and the results are the same. The names in bold represents who the task was assigned, in the end:

- My user > User 2 > User 3 > User 1

- My user > User 2 > User 3 > User 1 > My user

- My user > User 2 > User 3 > User 1 > Other User

- My user > User 2 > User 3 > User 1 > Other User > User 3

After all, we can conclude that this delegation mechanism of Nintex really works, and in my opinion, the way it handles these deadlocks is the best approach.

Nintex Workflow 2010: Just Released

2010-07-12T14:57:00.002+02:00

Hello!

Yes, it was released today! And with a many improvements, comparing to the 2007. Check it by yourself!

http://www.nintex.com/en-US/Products/Pages/NintexWorkflow2010.aspx

I also recomend a look on the two flyers who describes the product, and the comparative table between the 2007 and 2010 versions:

Product Brochure
Edition Comparison Table

In my opinion, the most interesting features available on this new version are:

Fluent ribbon interface (Office 2007-2010 like)
Create “User Defined Actions” using the drag and drop workflow designer (if it allows to export this actions)
Export workflows to Visual Studio 2010 (it’s very useful to customize the workflow, adding new capabilities)
InfoPath form generation/support (no idea how it works yet, there are no info available, but sounds nice)

I hope I can play with it soon! :)

Changes on the Blog design

2010-07-09T21:56:00.003+02:00

Hello friends

I decided to make the blog posts smaller on the start page of the blog. I decided it because my last post/article is really big, and the other posts was really down on the blog.

So, for the future posts I will use the Read More>> link, to make the reading experience of this blog better.

Thanks and good weekend!

How to create a multi-view web-based InfoPath form controlled by a Nintex Workflow

2010-07-09T21:18:00.034+02:00

This post explores the capabilities of the integration between InfoPath 2007 + Nintex Workflow 2007. The idea is to create a form which is handled and modified by the Workflow. In order to do that, some customization on the form is needed to show and allow the users to manipulate the data on the form.

Bellow I will explain the step by step how to create this form and the workflow to manipulate it. It's necessary some coding behind the form, in order to control the default view of the form.

1. The first step is to create a new InfoPath 2007 form, and in the default view, add some elements, as in the screenshot bellow. The information isn't the most important part of this example, so you can add the fields you want. In my case I created a title and added 2 fields: Name and Birthday.

2. In order to simulate different steps, controlled by the workflow, it's necessary to create other Views in the current form. To do it, in the Design Tasks, click in the Views option. Now, we need to create more 2 Views: View 2 and View 3. In order to change between these Views, use the menu: View.

3. Go to the View 2 and add some components on the screen. In my case, I added a Text Field, gave the name comments, and defined in the Display options to be Multiline.

4. When you work with an InfoPath form, the data input of the form is called Data Sources, and it's shared between the Views. In our last View, We will create a Summary, showing the information of the other 2 views. To do it, we need to go to the Design Tasks, and click in the Data Source Option. On this screen, just simple drag and drop the fields to the View 3.

5. Now it's time to do customize the template. The first thing we need to do is to create a new Field on the form. I created the field currentView, type text, and default value 1. This field is responsible by controlling the current view the user will be able to see and handle. We don't need to show it on the form, it's just a logic field.

6. It's publishing time! We need to publish the form on SharePoint, because later we will create some C# code on the form and we can't publish directly (only if we want a web-based form, for regular forms, it works). The publishing is a "Next, Next, Finish" wizard where we need to define the SharePoint site to publish the form, and create a new Form Library for it. I gave the name InfoPath Steps in my example. The most important step of the publishing is the last one, where the columns of the Libraries are defined. When an InfoPath form is published, the fields of the form can became metadata on the SharePoint List/Library. On the screen below, we need to enable the field currentView to be edited externally of SharePoint. In this way, the workflow is able to modify this field, and then control the form.

7. After publishing the form, we can continue modifying it. On the menu, click on Tools> Programming> Microsoft Visual Studio Tools for Application. The idea here is to control the current view of the form. On the Visual Studio, insert the code bellow (I found this approach here: http://support.microsoft.com/kb/826997/en-us)

8. Now we need to enable the fields based on the current view. To do it, go to the View 1, click on the Name textbox with the right button, and select Conditional Formatting. Add a new, and define the condition: currentView is not equal to 1 (currentView ≠ 1). And as formatting, select the option Read-only. Do the same for the other fields in the view 1 and 2.

9. For the View 3, we don't need to change it for every field, we can simple go to the Views Tab, select View 3, click on View Properties and select the option Read-only, for the entire view, because it's a simple summary view, not used to input data. In my form I also removed the borders of the fields.

10. Now the form is ready to use! But because of security issues with the C# code running on the form, we can't just publish it to SharePoint. We need to publish it as a separated template and then upload it to the server, in order to have a trusted template. The publishing process is the same, we only need to check the Web-form option.

11. After saving the file, we need to go to the central administration, and upload the form template. On the Central Administration, go to Application Management> InfoPath Form Services> Manage Form Templates. Simply select the file to upload.

12. After uploading, we need to activate this form in a Site Collection. To do it, click on the form on the forms list, and select the option Activate to a Site Collection. On the next screen, simple select the desired site collection and click in ok. When we finish this step, the form will be available in the Form Templates library of the main site of the selected site collection.

13. Now we need to select this template as the template of the Library. First, go to the Form Templates Library on the Site and copy the shortcut to the Template. In my case the URL is something like: http://mysite/FormServerTemplates/Steps.xsn. Then, go to the InfoPath Steps library, and on the menu, select Settings> Form Library Settings.

14. On the settings, click on Advanced Settings and change the option Allow managed content types to Yes, and also the option Display as a Web page, under Opening browser-enabled documents. Just click in Ok after the changes. With this configuration, the forms will open directly on the browser, and we will be able to manipulate our content type.

15. Now, on the Settings screen, click on the content type Form, to go to list settings. Click on Advanced Settings, and on the document template, paste the Form Template URL and click in Ok. Back on the Settings screen, click on the Current View field, and select it as hidden. This way, the user can't modify this field using the edit forms option, just the workflow will handle it.

16. Finally it's time to create the workflow! On the Library create a new Workflow. The idea is to change the steps after a review of the user, so let's build the workflow this way. The first step is an Update an item, to change the currentView field value to 2.

17. After the Update, let's use a Request Review action (it can be other action as well) to send an email to the user, asking to check the form. The configuration is simple, just select the initiator as a Reviewer.

18. The last step is to change view to the summary. So, simply add an Update an item, to change the currentView field value to 3. After that, let's to Settings> Startup Options and select to Start when items are created. After saving, Publish the workflow.

19. Finally the workflow can be tested. Go to the Library, create a new form and save it. You will see that it's impossible to modify the data in a different view from the current one, and also on the summary view. Have fun!

UPDATE

20. You can hide the Views on the Form Options. Click Tools > Form Options and uncheck the checkbox Views. Publish the form again and that's it, only the code behind changes the form view.

How to easily find the internal names of the columns

2010-07-06T15:25:00.005+02:00

In order to use some Web Services of SharePoint methods, like UpdateListItems, we usually need the columns internal names. How is the best way to find this internal names? There are some ways. I usually used the Web Service Response from the same UpdateListItems method, because it returns the internal names of the columns as attributes on the XML (with an ows_ in the beginning of the attribute).

I also found this nice post on the SharePoint Tricks and Tips Blog:

http://www.sharepoint-tips.com/2007/04/one-of-more-field-types-are-not.html

OK, but is there a simple way to do it? In my opinion, yes, there is. I do it without using an external application, just using Nintex.

How do I do it? Simple. When we export an Nintex Workflow as a file, it's an XML format, used by the Nintex Workflow Engine to Import this workflow in another site or list. All the information about the workflow is available on this file (I will go deeper on this topic in a future post), including the Item Properties variables which we can use directly in the actions.

So, if we simple export a Workflow, and open the *.nwf file in a text editor, like the Notepad for example, we have direct access to all internal names of the current list we are working on.

The important part for us on this XML file is the Fields element. Bellow there is an example of this element on the XML file:

<InternalName>Title</InternalName>

<DisplayName>Title</DisplayName>

</FieldReference>

<InternalName>Person</InternalName>

<DisplayName>Person</DisplayName>

</FieldReference>

...

And here is the Internal Name. I hope it's useful! :)

Twitter: @workflowxp

2010-07-04T15:43:00.001+02:00

I just created a twitter for the blog!

http://twitter.com/workflowxp

How to get the delegated user of a task

2010-07-02T12:48:00.029+02:00

The current build of the nintex workflow 2007 (11004) isn't capable to get the delegated person by itself. Explaining better this scenario, the idea is to know when a User Task (e.g.: Flexi Task or Approval) is sent to a specific user, but this user have delegated all of his tasks using the task delegation from Nintex.

After searching for many days for a solution, I found a way to solve the problem. On this post I will show how is possible to get the user name of a delegated user. But one question before I start: Why do I need that? Well in my case, I needed the user name for 2 reasons:

Update a list collum with the name of the user who handled the task;
Give this user permissions on the List Item;

In my scenario, I was blocking the permissions for specific users, as a requirement of the Workflow. In order to give the delegated users correct permissions to view or modify the List Item, because for the workflow, just the original approver have permission, not the delegated. Just to clarify, I'm not talking about the task itself, the delegated user for who the task is assigned, get the permission to the task automatically from the workflow.

OBS: The approach described here don't works for direct task delegation on the action, it just works if the user delegates all of his tasks. A good example of how to handle a directly delegated task can be found here:
http://connect.nintex.com/files/folders/wflowactions/entry436.aspx

Below the workflow is explained step by step.

1. A new List was created, with the name "Delegation Test" and added a new colunm "Person" of the type "Person or Group".

2. The workflow is quite simple, I only have a FlexiTask which is assigned to the initiator. To make the scenario more real, I removed the permissions of all users and give just permissions to the initiator.

3. Before continuing, It's necessary to setup a variable to use later. It's a variable to store the Initiator User name. I gave the name "initiatorFullUserName". This variable is necessary because Nintex don't allow to use Common lookups in Comparison Actions.

4. The Flexi task must run in parallel with the Action Set used to get the delegated user. It' s necessary because we need to get the delegated user after the task is assigned to him. Approving or reject just send the Initiator a message.

5. Now we really will work with the delegation part. In order to get the delegated user, we will use the Nintex Workflow Web Service, available in every SharePoint site (e.g.: http://mysite/_vti_bin/nintexworkflow/workflow.asmx).
To handle this, we will invoke the "GetRunningWorkflowTasksForListItem" Method. For who are not used to the Nintex and Sharepoint Web Services, I will make a post in the future specifically for this topic, but now, I will only explain this method.

6. In order to configure the action, we need to provide some parameters, "List Name" and "ID" of the Item, all available as lookup data on the workflow, in "Commom" and "Item Properties" respectively. In order to store the results of the Web Service call (we need it to get the delegated user) I created a text variable, called "wsresult". It's also important to select the result format as "Xml", in order to insert a <xml>
tag on the result.

7. Here is a important step: On the XSL Transform textbox, we can create a Xpath query to filter the result. Bellow is the XSLT used for our example. Using it, we get exactly the user name of the person for who the task is assigned. I will not explain how the XSLT works in details because it's not the point here, but I recommend a website for who wants to study it: http://www.w3schools.com/xsl/

8. The last configuration of this action is to Capture the errors. We need to do it, because errors will happen! Yes can sound a little bit strange, but when we run the FlexiTask and the Web Service call in parallel, the webservice always runs first, and the task is not assigned. In order to avoid a workflow error, we capture
the error and keep the task running until there is no user name on the variable wsresult, using a "Loop" action. I have defined the variable wsresult as "string.empty" before the WebService call, to avoid a possible errors using a real empty string.

9. When the Workflow leave this Loop Action, it will have the name of the user for who the task is assigned. Now, we need to check if the username returned by the workflow is the same of the user assigned to the task (in our case, the initiator). If it's a different user name, it means the task is delegated!

10. Now, having the username, it's possible to do anything with the workflow, depending on the requirements. In my case, I will give the delegated user view permissions on the item, and will update the list adding the name of the delegated user to the "Person" field.

11. Bellow I will post the full workflow image, and and here is available the Workflow file. I hope it is useful!

Starting a new Blog

2010-07-01T13:31:00.002+02:00

Hello all!

The idea of this blog is to share my experience with Nintex Workflow development. I started working with it this year and I haven't found many content about this topic outside of the nintex forum.

So, I hope it's useful!

Enjoy.