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 item”etc) 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 don’t execute their workload immediately - instead they batch their job. For

example, the "Update list item" action doesn’t 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-4885-b71b-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-4885-b71b-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 user’s 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.