Basic workflow troubleshooting techniques.

Contents
Updating list item errors ......................................................................................................................... 2 How batching works and using the commit pending changes action ................................................ 2 Determining the cause of the actual issue ......................................................................................... 5 Searching SharePoint logs for additional diagnostic information ...................................................... 5 Using the log to history list action to help troubleshoot ........................................................................ 9 How logging values to the history list helps troubleshoot a workflow ............................................ 12 Workflow emails failing to send (send a notification action failing) .................................................... 13 Checking the application event logs for SMTP related Nintex errors ............................................... 14 Common email application event log errors .................................................................................... 15 Troubleshooting the call web service action and using error handling ................................................ 16 Determining internal field names ..................................................................................................... 20 Workflow error handling .................................................................................................................. 21 Web service error (400) Bad Request ............................................................................................. 24 Issues with the delay action .................................................................................................................. 25 Which actions which rely on the SharePoint delay action ............................................................... 25 Safe looping ...................................................................................................................................... 26 Improving the performance of delays in SharePoint ........................................................................ 26

Updating list item errors

When using any of the update actions (set a field update itemetc) you may encounter the generic error as shown below:

The first step is to determine which action is causing the issue. In this example there are 2 updates actions:

How batching works and using the commit pending changes action
From this graphical view it is not clear which action has failed. The reason for this is some actions in SharePoint workflow dont execute their workload immediately - instead they batch their job. For example, the "Update list item" action doesnt actually update an item immediately, it waits until the workflow commits. The workflow commits at a delay action, a task action or the end of the workflow. So when the update list item action runs, it just registers that it needs to update the item, the item actually updates on commit. In this example to force the updates to commit immediately a commit pending changes action is inserted directly after each update.

Now we can rerun the workflow and the action that is failing will be displayed.

In this case we can see that the first update completed successfully, however at the 2nd commit action in the workflow failed. This indicates the Update an item action is failing to complete. Now that we have determined which action is causing the issue the action configuration should be checked to see if it is correct.

Determining the cause of the actual issue

We can see that the value being used is incorrect and there is no matching user for this entry, so the error in this case was that an incorrect value was being used to perform the update. If for example the value seemed correct (as shown) and the update still fails the next place to check are the SharePoint logs for a more detailed error message.

Searching SharePoint logs for additional diagnostic information

In MOSS 2007 (WSS 3) the logs are found at c:\program files\common files\microsoft shared\web server extensions\12\Logs. Following the above example we will want to look for Workflow Infrastructure errors at the time matching when the update action failed, in this case 10/12/2010 11:05 AM.

Browsing to the directory the logs files are listed, find the correct file corresponding to the error time.

Search for workflow infrastructure errors occurring at the same time.

10/12/2010 11:05:27.56 w3wp.exe (0x0928) 0x11B0 Windows SharePoint Services Workflow Infrastructure 72er Medium Microsoft.SharePoint.SPException: Invalid data has been used to update the list item. The field you are trying to update may be read only. ---> System.Runtime.InteropServices.COMException (0x80020005): Invalid data has been used to update the list item. The field you are trying to update may be read only. at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish) at Microsoft.SharePoint.Librar...

The key information from this error is Invalid data has been used to update the list item. This suggests that the value we are using to update a person group field is incorrect. If a variable was being used to update the value then the next step would be to enter the value manually or log this variable to the history list to confirm it contains the correct value (this process is described in the chapter Using the log to history list action to help troubleshoot). However, in this case no variable is being used so the format being used to update the field is incorrect. Checking Nintex Connect for any known issues updating SharePoint person/group fields or example this post can be found: http://connect.nintex.com/forums/thread/1826.aspx. setting the Person or Group field to this value format works: -1;#domain\username

We can now change the value being used in the update list item action to this format using a build dynamic string action to populate the variable used in the update action:

Restarting the workflow, the item is now correctly updated.

Using the log to history list action to help troubleshoot

When using variables in your workflow or generating complex scenarios that rely on certain field values logging these values to the workflow history list or using the history list to log debugging information can be very useful. For example when using a for each action to loop through a collection of values and perform operations/calculations based on these values logging this information to the history list as the loop processes can help diagnose any issues and ensure the loop is running as expected.

Looking at the above example the log to history list action is used to log when the workflow loop began and the current values within the loop.

For each configuration:

Logging information within the loop:

How logging values to the history list helps troubleshoot a workflow

Using this workflow as an example looking at the workflow history each value and execution of the loop can be seen at a glance as well as any calculation results.

Logging values to the history list during a workflow can be used to determine if a process is running as expected and to also troubleshoot where a workflow is failing and where logic is not running as expected. Logging values before any comparisons or calculations is recommended as well as general workflow information. If the workflow becomes very complex this method will make it much easier to diagnose.

Workflow emails failing to send (send a notification action failing)

The send a notification action is used to send emails using Nintex workflow, in some cases the workflows may fail to send and there may be no obvious error in the workflow history. For example a simple workflow containing just a send a notification action, the workflow has completed successfully however no email was actually sent.

When dealing with email related issues the place to look for more detailed error information would be the application event log on the web front end server at the time the workflow action was executed.

Checking the application event logs for SMTP related Nintex errors
Opening the event viewer and looking for any Nintex related error message should show something similar to the following:

Nintex Workflow; Build: 11101 (http://testsupport01/_layouts/NintexWorkflow/preview.aspx?ListId=9f8e7c77-89be-4885b71b-9279ce936f98&ItemId=1&InstanceId=74b5f21e-48cf-432e-bc29-b5a918fa1209) Failed to send email. System.Net.Mail.SmtpException: Failure sending mail. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 68.178.232.99:25 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.InternalConnect(EndPoint remoteEP) at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception) --- End of inner exception stack trace --at System.Net.ServicePoint.GetConnection(PooledStream PooledStream, Object owner, Boolean async, IPAddress& address, Socket& abortSocket, Socket& abortSocket6, Int32 timeout) at System.Net.PooledStream.Activate(Object owningObject, Boolean async, Int32 timeout, GeneralAsyncDelegate asyncCallback) at System.Net.PooledStream.Activate(Object owningObject, GeneralAsyncDelegate asyncCallback) at System.Net.ConnectionPool.GetConnection(Object owningObject, GeneralAsyncDelegate asyncCallback, Int32 creationTimeout) at System.Net.Mail.SmtpConnection.GetConnection(String host, Int32 port) at System.Net.Mail.SmtpTransport.GetConnection(String host, Int32 port) at System.Net.Mail.SmtpClient.GetConnection() at System.Net.Mail.SmtpClient.Send(MailMessage message) --- End of inner exception stack trace ---

at System.Net.Mail.SmtpClient.Send(MailMessage message) at Nintex.Workflow.HumanApproval.Message.SendEmail(String subject, User user, NWContext context, NWContextDataCollection ctxData, MailAddressCollection toAddresses) For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This indicates the SMTP server may be incorrect or the server is unreachable. Checking the global settings for Nintex workflow is the next step. Navigate to Central Administration -> Application management and select Global settings under the Nintex Workflow heading.

Following this example it is clear that the SMTP server was incorrectly configured. Once this value has been updated an IISRESET will also need to be performed on the web front end server and the email settings will be correct.

Common email application event log errors

Other common email related application event log errors include:
Nintex Workflow; Build: 11101 (http://testsupport01/_layouts/NintexWorkflow/preview.aspx?ListId=9f8e7c77-89be-4885b71b-9279ce936f98&ItemId=1&InstanceId=eddc108d-16c6-44e5-bd72-1f6bd3b8827a) Failed to send notification. Microsoft.SharePoint.SPException: Cannot get the full name or e-mail address of user "domain\username".

This error suggests the user domain\username does not have a valid SharePoint or AD account or does not have an email associated to their username. This can be fixed by adding an email address to the users profile or confirming the user is valid. Generally any issues to do with sending emails will be logged to the application event log. If the email is not being sent and there is no error in the event log, the first place to check would be the junk email folder. If the email is not there then we suggest contacting your local email server administrator and tracking the email through your system.

Troubleshooting the call web service action and using error handling
The call web service action can be difficult to trouble shoot as often the workflow will complete and no error messages will be shown. The best method to first try troubleshooting call web service issues is to send the web service result to an email account as plain text to review any error log information. For example a simple call web service action configured to update a list item using the updatelistitems Microsoft web service (http://msdn.microsoft.com/en-us/library/lists.aspx). This action has been configured to update a field named randomfield on the current list item.

Running this workflow it appears to have completed successfully, however the field value is actually not being updated.

Also, there is no error message displayed to indicate the possible cause of this issue. The first step in troubleshooting this is to email the web service result to a defined user as plain text.

Send a notification action configured directly after the call web service:

The reason Plain Text must be set is to ensure any of the xml code used in the web service displays correctly when viewed in your email client.

Once this has been configured you can rerun the workflow and the error diagnostic message will be displayed. Following this example the result was:

The key information from this email is the <ErrorText> parameter. <ErrorText>One or more field types are not installed properly. Go to the list settings page to delete these fields.</ErrorText> This suggests that 1 (or more) of the fields you are trying to update is using the incorrect internal field name.

Determining internal field names

You can determine the internal field name by inserting a reference to the SharePoint field into a build dynamic string action. This will display the internal field name for the field you are trying to update.

Notice in this example the field named randomfield actually has an internal name of text. This can occur when a field is initially created and then the field name is modified. Other notable examples are field names with a space, e.g. Charge Code will have an internal name of Charge_x0020_Code. The internal field name must always be referenced in any web service methods (unless otherwise specifically stated in the web service method definition). So, the correct SOAP for our example would be:

Workflow error handling

The call web service action (as well as certain other workflow actions) can be configured with in built error handling. This can be useful for determining which action caused a workflow to end in an error and also for enabling the workflow to still continue or take an alternate path if these actions ended in an error. Error handling can be configured in the action from the error handling tab.

The capture errors option is used to determine whether or not to attempt to capture an error, store error occurance in uses a yes/no variable to indicate if an error did occur or not and the store error text in allows any error text to be stored into a workflow text variable. Continuing with the previous example from the above call web service action, we can catch the error using a set a condition action and then output the error text using the log to history list action.

For example, running the web service with an invalid URL specified generates the following error:

Web service error (400) Bad Request

Another common error that can occur when using the call web service action is that the values being inserted into the web service must be encoded so they can be correctly used. Error example:

This basically means that any characters such as < must be encoded and represented as &amp;lt;. To do this you can either encode the values before using them in the call web service or configure the web service to encode inserted tokens as shown:

Issues with the delay action

The delay action is a standard SharePoint workflow action provided by Microsoft, which Nintex workflow also uses. The common issues with delays are: 1 - The delay action never continues 2 - The delay action takes much longer than the configured pause to continue (the time may vary from 10mins to X hours) 3 - The delay action takes about 5 - 10 minutes longer than configured.

Which actions which rely on the SharePoint delay action

The following actions also use or rely on the delay action internally. -Delay until

-Task reminder

-Complete workflow task

-Delegate workflow task

-Loop (when Safe Looping is enabled)

-State machine (when Safe looping is enabled)

Safe looping
The state machine and loop actions have an internal hidden delay (5min) to stop potential infinite loops being designed and then taking up all system resources. Safe looping can be disabled via Central Administration -> Application Management -> Global settings under Nintex Workflow heading. Select No for the Enforce Safe Looping option.

For it to take affect you must also perform an IISRESET and republish the workflow.

Improving the performance of delays in SharePoint

The first thing to try: [for ISSUE 1 or 2]

This .NET hotfix was released by Microsoft for delays in workflows: * Ensure Windows 2003 SP 2 is installed * Install hotfix available here http://support.microsoft.com/default.aspx?scid=kb;en-us;932394 Note, if Microsoft .NET 3 Service Pack 1 is installed, the above hotfix will not install. It can be assumed the service pack contains this hotfix.

The second thing to try: [for ISSUE 1]

The SharePoint Infrastructure Updates also address workflow delay action issues (WSS: http://support.microsoft.com/kb/951695 Microsoft Office Server http://support.microsoft.com/kb/951297). Note that the Infrastructure Updates is a significant update for SharePoint, so proceeding with this update should be appropriately assessed. Also note that if you are using a Nintex Workflow build earlier than 10830, see this notice regarding the Infrastructure Updates: http://connect.nintex.com/forums/thread/886.aspx

The third thing to try: [for ISSUES 2 and 3]

Running the following stsadm command can increase the frequency that the workflow timer job runs. stsadm -o setproperty -propertyname "job-workflow" -propertyvalue "every 1 minutes between 0 and 59" -url http://webapplication More information: http://technet.microsoft.com/en-us/library/cc424970.aspx The default value is "every 5 minutes between 0 and 59" PLEASE NOTE: the full impact of increasing the frequency of the workflow timer job is not known.

The fourth thing to try: [for ISSUE 1 and 2]

At this stage Microsoft Support will need to be contacted, as the core issue is with SharePoint. We would appreciate any information that you could pass on to us so we can add to our knowledge base. If you have very recently upgraded, and not restarted the timer service, similar behaviour will be seen. In this case, there will be Workflow Infrastructure messages in the logs to do with "Compile Error".
UPDATE:

We have had questions from various customers and partners asking if SharePoint Service Pack 2 fixes all the above behaviour. Essentially, no it does not. The Timer service still behaves in its idiosyncratic manner, however there is mention in the SP2 release notes that prior to SP2 "The SharePoint timer service may stop working on 64-bit servers" and that SP2 fixes it. Please refer to Service Pack and Cumulative Update documentation for further information.