Skip navigation
All Places > Getting Started > Blog > 2015 > March
2015

Problem:

Wanting the safety of safe looping enabled, but not wanting the five minute delay at every loop or at every statemachine shift.

 

Solution:

Use UDA to implement escalating safe looping

 

Steps:

1)

Disable safe looping at central admin (of course, at your own risk)

 

2)

Create UDA as follows:

     Parameters:

          "Number of iterations before pause" (integer) (input)

          "Number of minutes waittime" (integer) (input)

          "Counter input" (integer) (input)

          "Counter output" (integer) (output)

     Workflow:

          Math operation: Add 1 to "Counter input" and store in "Counter output"

          Run if: "Counter output" > "Number of iterations before pause"

               Pause: Wait for "Number of minutes waittime" minutes

 

 

 

3)

Use the above UDA as first action in every state in every statemachine and as first action in loops.

Add variable "Safe looping Counter" (integer) to workflow.

 

4)

Configure the Safe Looping UDA (screenshot from Danish setup)

 

          "Number of iterations before pause" = (value) (integer)

          "Number of minutes waittime" = (value) (integer)

          "Counter input" = (workflow data) "Safe Looping counter"

          "Counter output" = "Safe Looping counter"

 

In the above example, the workflow will loop 2 times with no delay, and after that it will continue to loop every 30 minutes.

 

Remarks:

Remember to add the UDA to your workflow in the right places, or else it will have no effect.

Remeber to reset the "Safe Looping counter", as shown in the screenshot above, before each use.

 

Benefits:

Quick and responsive workflow, even with many states shifting or looping, with the added security of a "pulling the brake" mechanism if the workflow for some reason starts to loop endlessly.

Products: Nintex Workflow 2010

 

Several requests have come through for locating workflows in an environment where an action is used that could potentially have hard coded credentials present. Typically users are encouraged to use Workflow Constants instead of hard coding credentials into a workflow however, sometimes a few workflows slip by. This can make for a tough time when it comes time to migrate to claims.

 

This migration preparation tool can assist with locating these workflows so that stakeholders can update their workflows to utilize Workflow Constants which are much easier to migrate.

 

Features

  • Quickly and easily locate workflows using actions known to use credentials.
  • Provides meta data for each workflow (if available) so users can go directly to the workflow and update it.
  • Requires no configuration to run.

 

Planned Features

  • A port for SharePoint 2013/Nintex Workflow 2013 if there is any interest.

 

Screen Shots

 

migrationtool.png

Introduction

 

Going on with the series of "Adding functions to Nintex Workflows with XLST transformations", here is the Part 2 showing a sample with some new calculations using XLST.

 

You can see the Part 1 here >>> Adding functions to Nintex Workflows with XLST transformations - Sample 1 (SUM)

 

I 'll write about all xlst formulas that can be used in Nintex Workflow and currently are not available as inline functions.

 

Those different formulas will be updated on a common document with all formulas and samples.

 

More samples

 

Now we'll see the following formulas:

 

  • COUNT
  • FLOOR
  • CEILING
  • ROUND
  • AVG

 

Workflow

So let's start configuring the action named "Query XML"

 

 

 

On the XML I use

 

 

<?xml version='1.0'?>

<root>

  <expenditure>1000</expenditure>

  <expenditure>3000</expenditure>

  <expenditure>2000</expenditure>

</root>

 

On the XSLT I use the following template

 

<?xml version='1.0'?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">

COUNT : <xsl:value-of select='count(//expenditure)'/>

---

FLOOR: <xsl:value-of select='floor(1976.6)'/>

---

CEILING:<xsl:value-of select='ceiling(1976.6)'/>

---

ROUND:<xsl:value-of select='round(1976.6)'/>

---

AVG : <xsl:value-of select=' (sum(//expenditure))  div (count(//expenditure))  '/>

</xsl:template>

</xsl:stylesheet>

 

 

I left the result on the workflow history, where magically we can see the calculated result

 

The minimum permissions to open the Nintex Workflow/Forms Designer:

List: Full control

Site: Read

Site Collection: Read

(Note: The Nintex Workflow/Forms buttons will not be visible without at least full control at the list level.)

 

The minimum permissions to publish a Nintex Form:

List: (See above)

Site: Contribute

 

The minimum permissions to publish a Nintex Workflow:

List: (See above)

Site: Design

 

The minimum permissions to run a workflow:

List: Contribute

Site: Contribute

 

The minimum permissions to Install Nintex Workflow / Nintex forms is 'Site collection administrator'.

 

Please let me know if you find any different results as this may change with the evolution of our product.

 

Cheers,

Andrew Beals

In Making “Work Flow” Matter Part 1, I discussed purpose and the benefits of setting a clear vision for your workflow.  Without a purpose, your workflow can end up being nothing more than a resource constraint on the platform, and no one wants to build that.

 

To honor my commitment to dig deeper with each part of this series, I offer you the below meme for some light humor.  The next part of the series I will simply title “Mr. Action, WWYSYDH? (pronounced Whissidh)”.  Interested?  Keep reading…

Part 2: Mr. Action, what would you say you do here?

When it comes to workflows, do you know what your workflow actions are actually doing?  This goes beyond the purpose, the logic and the idea or the workflow.  What actions are you using, and are they impacting the object and platform in the correct manner?  I touched on this some in part 1 so let’s go deeper.

 

If you have ever built a complex workflow, you would have at some point experienced that workflow failed to run, or an error message while running.  You may have had it complete successfully, but nothing changed as you intended. Sucks right?  Well, you are not alone.  Since actions are the backbone of workflows, when something is not working right, it usually prevents anything else that follows from working. Troubleshooting can also be just as daunting, but here is a tip: use the “log to workflow history” or “custom message” for certain actions so that the workflow can output data to the history area. Don't forget to remove those once everything is working fine.  They can bloat the Nintex database unnecessarily, so keep that in mind.  Another tip is to view the workflow visually to see just what action failed.

Nintex allows you to visually see the workflow, how it ran and what actions completed or did not complete.  This visual indicator is a nice way to see where your logic may need some tweaking. To locate this view, click on the item menu > view workflow history (see above).  Then select your workflow instance.  The goal is to troubleshoot and tweak your workflow until it does exactly what you want it to do.  As promised here are the double E's mentioned in part 1.

 

Workflow Effectiveness: Ensuring that the workflow actions work together following the logic implied to complete a process which produces the intended results.

 

Workflow Efficiency: Ensuring that the workflow accomplishes the intended results with minimal expenditure of time and effort (resources).

 

Everyone wants results, but are you getting the right results?  The scene in the movie Office Space, from which the meme at the beginning is taken, is really funny; however, it provides some good insight into the question of how to make work flow matter.  Being both effective and efficient can help determine the difference between a process someone is willing to work with and a process someone is willing to find a work around.

 

Nintex again helps by providing some great web parts for management and reporting. Two web parts that I would recommend you incorporate into your workflow strategy are:

  • My Workflow Tasks: this is helpful to put on a personal page or maybe even the site home page.  It provides a quick view with link to the workflow tasks that the signed in user may need to perform an action on.  Essentially it helps your users complete their task faster, by being able to find them and complete them from one central view on your site.

  • Workflow Report Viewer: This web parts is useful from an Admin’s perspective.  You can see the workflow reports for Nintex from within a page on the site. This is helpful for tracking your workflows such as the ones that have errors, are overdue, or are in progress.  There are about 10 reports that you can use to help manage workflows within your site collection or site.

The two above web parts can help your users’ do more productively and it gives them visibility into information that they can use to do their jobs.  There is nothing like having good data to support your claim that work flow matters.  Now who wouldn’t want that?

 

In summary, when you build workflows, check on them to ensure they are doing what you intended? If you are archiving data, how much are you archiving and where are you storing it?  If using workflows to break permission inheritance, understand the effects of that on your farm and ensure that the right people have the correct permissions. Use the information from the reports to find ways to do workflows better, decrease running time, or just to show why your workflow is helping.

 

Stay tuned for part 3 where I will discuss a specific use case setting a Training Events Calendar using the steps outlined above.  Part 3 will include an example list and workflows for you to download and use as well.

 

Thanks,

Eric

Products: Nintex Workflow 2010, Nintex Workflow 2013, InfoPath 2010, InfoPath 2013

 

Summary

 

When working with InfoPath and Nintex Workflow, you are using "Assign Flexi Task", or "Request Approval" action and selecting "Task content type" to "... task using InfoPath". 

 

This applies to Nintex 2010 and Nintex 2013 Workflows.

 

 

Then when you try to publish you get this error, however you are still able to save the workflow.

 

The error:

---------------------------

Message from webpage

---------------------------

Server was unable to process request. ---> Sequence contains no matching element

---------------------------

OK  

---------------------------

 

Symptom

 

Only able to save the workflow but, not publish the workflow.

 

Resolution

 

This applies for both 2010 and 2013 versions.

 

1. Open the "Assign Flexi Task", or the "Request Approval" action  > Change the Content Type from Nintex Workflow Task to Nintex Workflow task using InfoPath (wording is slightly different based on version and action type but same process)

2. Click Edit Task Form > Edit with Microsoft InfoPath 2010 (or 2013 depending on version)

3. Save your InfoPath form, then publish it back to the site

4. Go back to the "Assign Flexi Task", or the "Request Approval" action, which should have remained open > Click Save

5. Save your workflow

6. Publish your workflow

There are times that you need to change your Nintex Mobile App to a different site, or use a different account. Especially when you are testing. Look at the document Nintex Mobile Apps Product Guide I found some direction about my account and login that I will copy here.

 

When you sign in to Nintex Mobile apps, your credentials are remembered by the app and will automatically sign you in the next time you launch the app. You can sign in to Nintex Mobile apps on different devices and on different platforms. For instance, you can use the Nintex Mobile app on your Windows 8 laptop as well as on your iPhone at the same time, using the same user account.The Nintex Mobile app supports “roaming” of your data from one device to another one for synced items, i.e. forms which have been submitted to the SharePoint server. Items stored locally to the device, specifically in the Drafts and Outbox folders, are not visible across devices. If you are sharing the mobile device you use for executing Nintex Mobile apps with someone else, or you want Nintex Mobile apps to forget your account credentials, you may want to consider signing out of the app

 

On Sign Out, Nintex Mobile apps will forget your password and sign out of the app. Your username, SharePoint URL and Domain, if available, are retained.

So how do we sign out of Mobile Apps? It was easy to locate for the Phone's Mobile App. I click on the Settings gear at the bottom task bar, then sign out on the settings screen.

nappphonesignout.PNG

But using the Desktop Mobile App took me a few minutes to find so I wanted to post the sign out process here.

 

I have Windows 8.1 using the Windows version of the Nintex Mobile App. To sign out of the App, open the settings pane of the app. You can do this in one of three ways.

  • Move the mouse to the lower right hand corner of the screen to show the Windows Charms, click Settings and the Nintex Mobile App Settings pane will appear
  • Click WindowsKey+C to show the the Windows Charms, click Settings and the Nintex Mobile App Settings pane will appear
  • Click WindowsKey+I to jump straight to the Settings Pane of the App

 

The Windows Charm bar:

NAppCharm.png

 

Nintex Mobile App Settings Pane

nappsignout.png

 

Now click Sign Out. Sign Out will bring up a screen to allow you to simply click Sign Out and your username, SharePoint URL and Domain, if available, are retained. Or click Forget Me to remove that data.

 

When you go back to the app you will be presented with the familiar login screen to pick an account. For details around signing into the app see Signing in Nintex Mobile

 

Nintex It!

 

Products: Nintex Workflow 2010, Nintex Workflow 2013

Summary

 

When installing Nintex Workflow 2010/2013 you may encounter this error even though you already have a valid license and maybe even just doing an update on current version of your workflow.

 

The error:

 

Preparing files.........

Detected SharePoint 2013 is installed

Your license is not valid for version 3.0.8.0 of Nintex Workflow 2013. Please contact admin@nintex.com to obtain a new license.

 

Symptom

 

Not able to install or update Nintex Workflow 2010/2013

 

Resolution

 

Here is a way to get Nintex Workflow installed, however you will still need valid license to actually run the workflow after install.  This guide is to by-pass the license check during install process.

 

  1. Run the Nintex Workflow installer and when you get to "Do you want to add the solution to SharePoint now?" select "No, I wish to export the solution and deploy it manually later."
  2. Save the exported files in a folder of your choice and then open that folder and navigate to the "Workflow" folder.  Here you will see "CheckLicense.ps1", right click on it and uncheck "Read Only".  Now open this file using PowerShell ISE and change "$isValidForUpgrade=$false" to "$isValidForUpgrade=$true" and save the file.
  3. Finally, install Nintex Workflow by running the "install.ps1" file using PowerShell with administrative privileges.

Introduction

 

Some days ago I saw an answer on Nintex Community ( Re: Workflow Number Formatting  )  about how to solve number formatting

One of the replies from Manfred Lauer was about solving it with XSLT using the "Query XML" action.

 

That reply inspired me to start writing about all xlst formulas that can be used in Nintex Workflow and currently are not available as inline functions.

 

I will write some different post with differents formulas and will update a common document with all formulas and samples.

 

First sample

The first sample is for calculating the Sum of some values

 

Workflow

So let's start configuring the action named "Query XML"

 

I left the result on the workflow history, where magically we can see the calculated result

 

You receive one of the following errors upon publishing a workflow/form after anupgrade/install of Nintex

 

 

You also find the following entries in the ULS logs:

Failed to handle workflow upload starting event. Error: Object reference not set to an instance of an object.. Stack trace:    at Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId)     at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.ProcessStartForm(WorkflowUploadStartingEventReceiverContext eventArgs, Boolean& expectedException)     at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.Execute(WorkflowUploadStartingEventReceiverContext eventArgs

Failed to raise event to receiver or the receiver threw an exception. Type: WorkflowUploadStarting. Receiver assembly: Nintex.Forms.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c52d764dcf7ec883. Receiver class: Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting: System.NullReferenceException: Object reference not set to an instance of an object. at Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId) at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.ProcessStartForm(WorkflowUploadStartingEventReceiverContext eventArgs, Boolean& expectedException) at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.Execute(WorkflowUploadStartingEventReceiverContext eventArgs) at Nintex.Workflow.Events.EventReceiverCollection.FireEvents(EventType type, SPWeb web, ReceiverContext eventArgs)

Error saving from workflow export file.: System.Exception: Object reference not set to an instance of an object.      at Nintex.Workflow.Publishing.Publish.AR8=(XomlWorkflow Ah8=, SPList Ax8=, WorkflowRepository BB8=, Boolean BR8=, String& Bh8=)     at Nintex.Workflow.Publishing.Publish.xB4=(XomlWorkflow 1B4=, Boolean 1R4=, Boolean 1h4=, PublishOperationTrackingCollection 1x4=, Boolean 2B4=, WorkflowRepository 2R4=, Boolean 2h4=, Boolean 2x4=)     at Nintex.Workflow.Publishing.Publish.PublishAWorkflow(String wfName, NWActionConfigurations configs, Guid listId, SPWeb web, ImportContext importCtx, Boolean validate, SPContentTypeId contentTypeId, String changeNotes, String& publishWorkflowString)     at Nintex.Workflow.Publishing.Publish.PublishAWorkflow(String wfName, NWActionConfigurations configs, Guid listId, SPWeb web, ImportContext importCtx, Boolean validate, SPContentTypeId contentTypeId, String changeNotes)     at NintexWorkflowWS.PublishWorkflow(String wfName, String activityConfigs, Guid listId, String contentTypeId, String changeNotes)

Resolution

These errors are indicative of either a missing Nintex Forms database or your forms database is not update to date. Nintex Workflow is trying to access a stored procedure in the Nintex Forms database during publish validation which can cause the publishing of your workflow to fail if these stored procedures are not present or up to date.

 

The call "Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId)" is key to this error. This method makes a call to the Nintex Forms database for the stored procedure "MarkFormasDeletedIfExists".

 

Creating the forms database under Nintex Forms Management > Manage Database will resolve this issue if you do not already have one. If your forms database has already been created and you have verified it is indeed connected you may simply need to upgrade the database. You can do this by running the following command: Upgrade-NFservice

 

---Warning---

The the following error "Object reference not set to an instance of an object." is a very common and ambiguous error in .NET and can be found in many other errors in SharePoint. Be certain to confirm the error you are seeing is similar to the ULS log stack trace errors I have provided.

 

- - UPDATE - -

With recent updates to the product you may see the below errors / log messages instead of the above errors. However the resolution remains the same:

 

 

 

Failed to Publish Nintex Form. Error: Procedure or function NLF_GetOnlineFormByItem has too many arguments specified.. Stack trace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at Nintex.Forms.SharePoint.LiveForms.Data.Access.SqlSession.ExecuteReader(SqlCommand command, CommandBehavior behavior, Boolean retryForDeadLock)
at Nintex.Forms.SharePoint.LiveForms.Data.OnlineFormRepository.GetForms(SqlCommand command)
at Nintex.Forms.SharePoint.LiveForms.Data.OnlineFormRepository.GetFromItem(Guid siteId, Nullable`1 listId, String contentTypeId, Nullable`1 workflowBaseId, Nullable`1 taskListId, Nullable`1 taskItemId, String taskTemplate, Nullable`1 taskReference, OnlineFormType type, String workflowVersion)
at Nintex.Forms.SharePoint.LiveForms.LiveFormsMaintenence.RemoveListFormIfExists(SPSite site, Guid listId, String contentTypeId)
at Nintex.Forms.SharePoint.Services.NfWcfService.PublishForm(String contentTypeId, String listId, Form form)

 

 

Failed to raise event to receiver or the receiver threw an exception. Type: WorkflowUploadStarting. Receiver assembly: Nintex.Forms.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c52d764dcf7ec883. Receiver class: Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting: System.Data.SqlClient.SqlException (0x80131904): Procedure or function NLF_GetOnlineFormByItem has too many arguments specified.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at Nintex.Forms.SharePoint.LiveForms.Data.Access.SqlSession.ExecuteReader(SqlCommand command, CommandBehavior behavior, Boolean retryForDeadLock)
at Nintex.Forms.SharePoint.LiveForms.Data.OnlineFormRepository.GetForms(SqlCommand command)
at Nintex.Forms.SharePoint.LiveForms.Data.OnlineFormRepository.GetFromItem(Guid siteId, Nullable`1 listId, String contentTypeId, Nullable`1 workflowBaseId, Nullable`1 taskListId, Nullable`1 taskItemId, String taskTemplate, Nullable`1 taskReference, OnlineFormType type, String workflowVersion)
at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.ProcessStartForm(WorkflowUploadStartingEventReceiverContext eventArgs, Boolean& expectedException)
at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.Execute(WorkflowUploadStartingEventReceiverContext eventArgs)
at Nintex.Workflow.Events.EventReceiverCollection.FireEvents(EventType type, SPWeb web, ReceiverContext eventArgs) ClientConnectionId:8b6d1ffc-abcb-4c69-8529-10a6a6e88122 Error Number:8144,State:2,Class:16 (Build:3160)

Failed to handle workflow upload starting event. Error: Procedure or function NLF_GetOnlineFormByItem has too many arguments specified.. Stack trace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at Nintex.Forms.SharePoint.LiveForms.Data.Access.SqlSession.ExecuteReader(SqlCommand command, CommandBehavior behavior, Boolean retryForDeadLock)
at Nintex.Forms.SharePoint.LiveForms.Data.OnlineFormRepository.GetForms(SqlCommand command)
at Nintex.Forms.SharePoint.LiveForms.Data.OnlineFormRepository.GetFromItem(Guid siteId, Nullable`1 listId, String contentTypeId, Nullable`1 workflowBaseId, Nullable`1 taskListId, Nullable`1 taskItemId, String taskTemplate, Nullable`1 taskReference, OnlineFormType type, String workflowVersion)
at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.ProcessStartForm(WorkflowUploadStartingEventReceiverContext eventArgs, Boolean& expectedException)
at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.Execute(WorkflowUploadStartingEventReceiverContext eventArgs)

Error saving from workflow export file.: System.Exception: Procedure or function NLF_GetOnlineFormByItem has too many arguments specified.
at Nintex.Workflow.Publishing.Publish.3SA=(XomlWorkflow 3iA=, SPList 3yA=, WorkflowRepository 4CA=, Boolean 4SA=, String& 4iA=)
at Nintex.Workflow.Publishing.Publish.pCA=(XomlWorkflow tCA=, Boolean tSA=, Boolean tiA=, PublishOperationTrackingCollection tyA=, Boolean uCA=, WorkflowRepository uSA=, Boolean uiA=, Boolean uyA=)
at Nintex.Workflow.Publishing.Publish.PublishAWorkflow(String wfName, NWActionConfigurations configs, Guid listId, SPWeb web, ImportContext importCtx, Boolean validate, SPContentTypeId contentTypeId, String changeNotes, String& publishWorkflowString)
at NintexWorkflowWS.PublishWorkflow(String wfName, String activityConfigs, Guid listId, String contentTypeId, String changeNotes) (Build:3160)

 

Cheers,

Andrew Beals

Products: Nintex Workflow 2013, Nintex Workflow 2010

 

A request came in for how to dynamically update a content type via Nintex Workflow. The person wanted to update a content type field based on the values of items in a list. Below you will find a PowerShell script that can be used with NTX PowerShell action: NTX PowerShell Action - Initial Beta Release

 

PowerShell Script
  1. Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue
  2. $_web = Get-SPWeb http://contoso.com
  3. $_field = $_web.Fields | where {$_.Title -match 'TitleOfTargetField'}
  4. $_ct = $_web.ContentTypes | where {$_.Name -match 'NameOfTargetContentType'}
  5. $_field.Choices.Clear()
  6. foreach ($item in $_web.Lists['TitleOfSourcelist'].Items){
  7. $_field.Choices.Add($item.Title)
  8. }
  9. $_field.Update()
  10. foreach ($usage in [Microsoft.SharePoint.SPContentTypeUsage]::GetUsages($_ct)){
  11. $list = $web.GetList("$($web.Url)$($usage.Url)")
  12. if($usage.IsUrlToList){
  13. foreach($field in $_web.Fields){
  14. if($list.Fields.ContainsField($field.InternalName)){
  15. $listField = $list.Fields[$field.Id]
  16. if($listField -ne $null){
  17. $listField.SchemaXml = $field.SchemaXml
  18. $listField.Update()
  19. }
  20. }
  21. }
  22. }
  23. }

 

To use the script do the following:

  • Replace http://contoso.com with the URL of the site you wish to execute the script against.
  • Replace TitleofTargetField with the Title of the ListField you are updating.
  • Replace NameOfContentType with the name of the Content Type you are updating.
  • replace TitleOfSourceList with the title of the source list you are pulling values from.

 

Note: By default this script uses the item property 'Title' as the source for updating the content type. This can be changed on line 13.

For those out here that have followed a lot of my posts on this Community or just seen some of my blog posts on my companies blog at Summit 7 Systems, I want to take a moment to say thanks for reading them.

 

I’m encouraged by many of you to keep writing and as I aim to do better and achieve more with the tools I have, I want to share that insight with you as well.  Also a special shout out to David Deschere for being a great reviewer and always providing positive feedback on my posts. Much appreciated .

 

To that end, I know we all are pressed for time, so I’m making this blog short and sweet.  This post will be the first of a series of post aimed at providing some basic but necessary logic and thought processes that is often overlooked or forgotten when it comes to using Nintex forms and workflows in your organization.  I will endeavor to dive deeper with each post to help users from all levels use Nintex more efficiently as we go along.

 

Hope you enjoy this short read and that you learn or remember something from it.

 

 

Part 1: Does your workflow have a purpose?

Just as it is a natural desire to have an impact in your workplace, and to know that what you do matters to your organization; you should approach your workflows with the same consideration.  The image above makes a very profound statement: “Prioritize what matters”.  Yes, that sounds odd when referencing workflows, but why not put some thought into what you are about to architect or create?  How is your logic, the process you are about to automate, and the results going to affect your organization in the end?

 

Priorities help you see what’s important!

 

When creating a workflow, ensure that your workflow was built with a distinct purpose.  Too often I’ve seen people try to automate everything from the making coffee in the morning to turning off the lights at the end of the day.  Some stuff was not meant to be automated by a workflow and that’s okay.  Also, do not try to fix everything in one workflow or solve an entire business process in one big sweep.  Simplify what you are doing, prioritize your logic, and use as few actions as possible to meet your needs. This is not a formula but a mindset and here are some additional thoughts to consider:

  • What are you really wanting your workflow to do?
  • Can you accomplish your desired result in just one workflow or do you need more?
  • Are you using the right workflow scope (Item, Site, and Site Collection)?
  • Are you using the appropriate workflow actions?
  • Do you have unnecessary loops, run-if’s and conditions?
  • Are you overusing the “log to workflow history” for the sake of seeing outputs?

 

Following this process can help you create a workflow that you will be proud of.  You may also be able to show value by making it reusable within your organization,, who knows.  Now that’s “ninticity” for you, and like I promised, I kept this one short.  For more guidance with Nintex and basic workflow management, check out the DUCERIM Process.

 

Feel free to leave comments about this blog or questions you may have about Nintex and your organization.  Stay tuned for Part II: The double "EE’s" of workflows.  and if you can guess what the “E’s” represents, shoot me a comment or tweet @eharris04.

 

Thanks,

Eric

Go to List/Workflow Settings

Go to Remove

 

Select the workflow to remove

Products: Nintex Workflow 2013, Nintex Workflow 2010

 

Occasionally a history list grows to a point where you can no longer utilize NWAdmin to trim the list (Read this article to avoid this: Defensive Workflow Design Part 1 - Workflow History Lists ). In order to get rid of the items and not impact the entire farm, it becomes necessary to utilize paging and indexing to specifically target each item and delete it. Paging helps throttle the traffic to your SQL server down by only deleting x number of items at a time before it rests and starts again. Indexing enables the targeting of items without the performance overhead of enumerating and/or querying a large collection of items.

 

Using this PowerShell script large history lists can be purged utilizing paging and indexing.

 

PowerShell Script
  1.         Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
  2.       
  3.         #Configure target site and list.
  4.       
  5.         $list = $($(Get-SPWeb -Identity 'http://contoso.com').Lists['NintexWorkflowHistory'])
  6.       
  7.         #Index count for list items.
  8.       
  9.         $index = $list.ItemCount
  10.       
  11.         #Index counter for paging.
  12.       
  13.         $page = 0
  14.       
  15.         #Configure how many items to delete per batch.
  16.       
  17.         $pagesize = 1000
  18.       
  19.         #Configure how may seconds to pause between batches.
  20.       
  21.         $sleep = 1
  22.       
  23.         #Turn verbose output on/off
  24.       
  25.         $verbose = $true
  26.       
  27.         While($index -ge 0){
  28.       
  29.         if($verbose){
  30.       
  31.         $("Deleting item at index $($index).")
  32.       
  33.         }
  34.       
  35.         if($page -lt $pagesize){
  36.       
  37.         try{
  38.       
  39.         if($($list.Items[$index])['Modified'] -lt [DateTime]::Parse("01/01/2014")){
  40.       
  41.         $list.Items[$index].Delete()
  42.       
  43.         write-host "Found Item"
  44.       
  45.         }
  46.       
  47.         }
  48.       
  49.         catch [System.Exception]{
  50.       
  51.         if($verbose){
  52.         $("Skipping item at index $($index).")
  53.       
  54.         }
  55.       
  56.         }
  57.       
  58.         $index--
  59.       
  60.         $page++
  61.       
  62.         }
  63.       
  64.         else{
  65.       
  66.         if($verbose){
  67.       
  68.         $("Sleeping for $($sleep) seconds.")
  69.       
  70.         }
  71.       
  72.         [System.Threading.Thread]::Sleep($sleep * 1000)
  73.       
  74.         $page = 0
  75.       
  76.         }
  77.       
  78.         }

To use the script do the following:

  • Replace http://contoso.com with the URL of the site you wish to execute the script against.
  • Replace NintexWorkflowHistory with the title of the history list you wish to target.

 

Note: By default the script will delete 1000 items and then rest for 1 second.

 

Filtering can be added by adding an if statement around the Delete() call as shown below. In this example, the item would be deleted if it was older than 01/01/1999.

 

Filtering
  1. try{
  2. if((($list.Items[$index])[($list.Items[$index].Fields['Created'])] -lt [DateTime]::Parse("01/01/1999")))
  3. {
  4. $list.Items[$index].Delete()
  5. }

 

Version History and other scripts can be found here: http://ALPS.Codeplex.com

Why this article?

Because the Related Item column is not yet available in the Nintex Form in O365.

 

This article is a follow-up to Delegation in O365

In my workflow, I really want to display the link to the document that needs approval in the task.
So, I decide to validate the Delegated action by checking if DelegatedTo is empty of not in the SharePoint Form.


In SharePoint 2013, the EditForm.aspx contains a Javascript validation function called PreSaveItem().
The trick here is to use this name to execute your own code. Note that the PreSaveItem() function of SharePoint will still run.

 

I need to validate only if the Content Type is Workflow Approve. But this field is not displayed if there is only one Content Type.

That is why I am also testing the empty value in the following line
if (strContentType == "Workflow Approve" || strContentType === '')

 

In my case, I have choosed to use the Person or Group column type.
In SharePoint, you cannot test a Person or Group column like a Single text column.
With the help of jQuery, I get an handle to the DelegatedTo field.
I make sure the name is resolved. If this is the case, I get the User object and get the Key property.

var ppDiv = $("[id$='ClientPeoplePicker'][title='" + strControlDelegatedTo + "']");

var spPP = SPClientPeoplePicker.SPClientPeoplePickerDict[ppDiv[0].id];

spPP.AddUnresolvedUserFromEditor(true);

var myUser = '';

if (!spPP.HasInputError) {

   var userKeys = spPP.GetAllUserInfo();

   myUser = userKeys[0];

}

if (myUser != undefined) {

   strDelegatedTo = myUser.Key;

}


If it is not empty, the field can pass the validation, otherwise, I display the validation message and I reset the Task Outcome value to avoid that the message is displayed if the user click Save afterwards.

 

Let's add some Javascript in the SharePoint EditForm.aspx. To accomplish that, open your Workflow Tasks list.

In The List Ribbon, click Form Web Parts - Default Edit Form.
Click Add a Web Part: Media and content - Script Editor and click Add.
Click Edit Snippet and paste this code:

 

<script language="javascript" type="text/javascript"
src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script>
<script language="javascript" type="text/javascript">
$(document).ready(function() {
});
function PreSaveItem() {
    //Only for Workflow Approve Content Type
    var strContentType = $("select[title='Content Type'] option:selected").text();
    if (strContentType == "Workflow Approve" || strContentType === '') {
        var strTaskOutcome = $("select[title='Task Outcome'] option:selected").text();
        if (strTaskOutcome != "Delegated") {
            return true;
        }
        var strDelegatedTo = "";
        var strControlDelegatedTo = "DelegatedTo";
        var ppDiv = $("[id$='ClientPeoplePicker'][title='" + strControlDelegatedTo + "']");
        var spPP = SPClientPeoplePicker.SPClientPeoplePickerDict[ppDiv[0].id];
        spPP.AddUnresolvedUserFromEditor(true);
        var myUser = '';
        if (!spPP.HasInputError) {
            var userKeys = spPP.GetAllUserInfo();
            myUser = userKeys[0];
        }
        if (myUser != undefined) {
            strDelegatedTo = myUser.Key;
        }
        if (strDelegatedTo != "") {
            return true;
        } else {
            alert('Please select the delegated person.');
            $("input[title='DelegatedTo']").focus();
            $("select[title='Task Outcome']").val("");
            return false;
        }
        return false;
    }
    return true;
}
</script>

 

Hope this helps

Christophe Raucq

We often see requests of how to pause a workflow for less than 5 minutes. Until now this has not been possible as the pause action relies on the SharePoint Workflow Timer Job to wake the workflow instance back up (occurs every 5 minutes) after the indicated amount of time.

 

Utilizing PowerShell you can effectively pause a workflow all the way down to 1ms. While a PowerShell script is running it will hold up the progress of the workflow until it completes. To set this up you simply need to set the PowerShell action to execute this command:

 

PowerShell Script
  1. [System.Threading.Thread]::Sleep(20000)

 

Note: 20000 would be a 20 second pause.

 

Here is a screenshot of the action blocking for 20 seconds (Nintex rounds up to the minute for display purposes):

 

2015-03-04 14_35_08-Workflow Progress_ Thread Sleep test - Internet Explorer.png

Note: Avoid pausing the workflow for long periods of time as it may result in the workflow batch timing out.

 

You can obtain the PowerShell action here: NTX PowerShell Action - Initial Beta Release

Products: Nintex Workflow 2013, Nintex Workflow 2010

 

Sometimes it can be helpful to replicate the page load behavior of the Nintex Workflow Support Console for troubleshooting purposes. This PowerShell script emulates the SQL Database queries that can potentially cause the page to timeout on loading.

 

Here is an example error message thrown when loading the Support Console page:

 

"Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding."

 

2015-03-03 13_29_16-Clipboard.png

 

Running this PowerShell script should produce meaningful exceptions if there is an issue with loading the Nintex Workflow Support Console (assuming it is a SQL Client timeout issue).

 

PowerShell Script
  1. Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
  2. [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
  3. [void][System.Reflection.Assembly]::LoadWithPartialName("Nintex.Workflow")
  4. [void][System.Reflection.Assembly]::LoadWithPartialName("Nintex.Workflow.Administration")
  5. function Get-AllNWDatabases(){
  6. $cmd = New-Object -TypeName System.Data.SqlClient.SqlCommand
  7. $cmd.CommandType = [System.Data.CommandType]::StoredProcedure
  8. $cmd.CommandText = 'GetAllDatabases'
  9. $reader = [Nintex.Workflow.Administration.ConfigurationDatabase]::GetConfigurationDatabase().ExecuteReader($cmd)
  10. $data = @()
  11. while($reader.Read())
  12. {
  13.     $row = New-Object System.Object
  14.     $row | Add-Member -MemberType NoteProperty -Name "DatabaseId" -Value $reader['DatabaseId']
  15.     $row | Add-Member -MemberType NoteProperty -Name "DatabaseName" -Value $reader['DatabaseName']
  16.     $row | Add-Member -MemberType NoteProperty -Name "ErrorsCount" -Value $reader['ErrorsCount']
  17. $data += $row
  18. }
  19. $data
  20. }
  21. function Get-WorkflowErrors($DatabaseName){
  22. $cmd = New-Object -TypeName System.Data.SqlClient.SqlCommand
  23. $cmd.CommandType = [System.Data.CommandType]::StoredProcedure
  24. $cmd.CommandText = 'GetWorkflowErrors'
  25. $cmd.Parameters.Add('@DatabaseName', [System.Data.SqlDbType]::NVarChar).Value = $DatabaseName
  26. $cmd.Parameters.Add('@PageNumber', [System.Data.SqlDbType]::Int).Value = 1
  27. $cmd.Parameters.Add('@PageSize', [System.Data.SqlDbType]::Int).Value = 10
  28. $cmd.Parameters.Add('@TotalErrors', [System.Data.SqlDbType]::Int).Value = 0
  29. $reader = [Nintex.Workflow.Administration.ConfigurationDatabase]::GetConfigurationDatabase().ExecuteReader($cmd)
  30. $count = @()
  31. while($reader.Read())
  32. {
  33.         $count += $reader[0]
  34. }
  35. $count.Count
  36. }
  37. function Run-SupportConsoleDiag(){
  38. $data = @()
  39. foreach ($dbref in Get-AllNWDatabases){
  40. $row = New-Object System.Object
  41. $row | Add-Member -MemberType NoteProperty -Name "DatabaseName" -Value $dbref.DatabaseName
  42. $row | Add-Member -MemberType NoteProperty -Name "WorkflowErrorCount" -Value $(Get-WorkflowErrors -DatabaseName $dbref.DatabaseName)
  43. $data += $row
  44. }
  45. $data
  46. }
  47. Run-SupportConsoleDiag

 

 

More Information on this topic can be found here: The specified item was not found.

Planning ahead

 

Speed is typically a business requirement when designing a workflow; however, sometimes the appearance of speed is just as good as the real thing. Adding a 'Pause for...' action as the first action of a workflow will actually have the illusion of being much faster to end users. Additionally, starting workflow designs with a pause has the added benefit of increased durability.

 

Performance

Adding a pause to the start of a workflow will force the workflow instance to immediately dehydrate and persist to the SharePoint Content Database. A workflow executed by a user will show a 'Working on it...' message to the user until completion or dehydration (This has the appearance of sluggishness). The quicker you can dehydrate the workflow, the quicker the workflow will appear to users. Reference: Workflow Scalability and Performance

 

SharePoint has limits set (by default this is 15 workflows) that can make a workflow even slower depending on how often workflows are being started (excluding workflows that are running in the OWSTIMER process on a given SharePoint Content Database (Could be multiple site collections, etc)). Reference: Workflow Limits

 

Durability

When using event receivers (ItemAdded or ItemUpdated) to trigger your list workflows there is a possibility that SharePoint will not have fully instantiated the item and or all of its properties by the time the event receivers fire and start the workflow. The reason for this is that the initial event receivers that trigger: ItemAdding and ItemUpdating are synchronized however, the subsequent ItemAdded and ItemUpdated events are Asynchronous (meaning they complete without actually waiting for the item to be added/updated).

 

In order to be completely sure that the item is ready in SharePoint prior to the workflow executing, we need to add a delay prior to the workflow attempting to reference any properties of the item. Determining whether or not a workflow will run before the properties are ready is a fairly difficult if not impossible task as there are many variables to consider:

  • Size of the farm
  • Resource Utilization of the farm
  • Size/complexity of the item or document being updated/created.

 

Design Considerations

  • Actions that create/update new items/folders/documents may have similar issues to those discussed in the 'Durability' section.
  • The quicker you can dehydrate the workflow instance and persist it to the SharePoint Content database the better (First action of the workflow ideally).

 

Workflow life cycle (for a workflow started manually)

 

  1. The workflow is started in the Web Application Application Pool Process (W3wp.exe).
  2. The user sees a message indicating SharePoint is 'Working on it...' until the workflow does one of the following:
    1. It completes.
    2. it is terminated/error.
    3. It is dehydrated and persisted to the SharePoint Content database.
  3. If the workflow was persisted to the SharePoint Content database it is later re-hydrated by the SharePoint workflow timer job (which occurs every 5 minutes by default).
  4. The SharePoint workflow timer job picks a server in the SharePoint farm that is running the 'Foundation Workflow Infrastructure Timer Service' and that server has a turn at executing workflows that were previously dehydrated and persisted to the SharePoint Content Database (Hence the importance of Defensive Workflow Design Part 2 - SharePoint Topology ).
  5. The workflow will continue to run until it completes or it is time for it to be dehydrated again where steps 3 and 4 happen again.

 

Workflow life cycle (Event Driven)

 

  1. A synchronized event for ItemAdding or ItemUpdating is triggered.
  2. An asynchronous ItemAdded or ItemUpdated event is triggered by an event from step one.
  3. The workflow is started by an event from step two.
  4. The workflow runs until it completes or is dehydrated and persisted to the SharePoint Content database.
  5. If the workflow was persisted to the SharePoint Content database it is later re-hydrated by the SharePoint workflow timer job (which occurs every 5 minutes by default).
  6. The SharePoint workflow timer job picks a server in the SharePoint farm that is running the 'Foundation Workflow Infrastructure Timer Service' and that server has a turn at executing workflows that were previously dehydrated and persisted to the SharePoint Content Database (Hence the importance of Defensive Workflow Design Part 2 - SharePoint Topology ).
  7. The workflow will continue to run until it completes or it is time for it to be dehydrated again where steps 3 and 4 happen again.

 

More Information

 

Defensive Workflow Design Part 1 - Workflow History Lists

Defensive Workflow Design Part 2 - SharePoint Topology

Defensive Workflow Design Part 3 - Separation of Concerns

Defensive Workflow Design Part 5 - Batching

Filter Blog

By date: By tag: