You are viewing limited content. For full access, please sign in.

Question

Question

Workflow started by Forms - Single instance mode?

Workflow
Updated two days ago
asked on June 9

I have a workflow started by Forms, and if two forms processes are started simultaneously I need to prevent the same workflow from running concurrently - one workflow instance needs to finish before the next can be started.

Will the setting for "Single instance mode" accomplish this, or does that not apply to workflows started by Forms? The documentation only refers to it being applicable to scheduled workflows. Or is there another setting that can accomplish this?

TIA!

0 0

Replies

replied on June 9

Hello,

Single instance mode should apply to all instances of a workflow, not just workflows initiated via schedule rules. For example, if you try to manually initiate a single instance workflow while another instance is active you'll get an error like the following:

I've never used Single Instance Mode with Forms, but it should work the same. However, I'm not sure how Forms would respond to the error from workflow (i.e., it may cause it to suspend, and it probably wouldn't skip the service task automatically).

0 0
View 4 previous replies
replied on June 9

Thank you for the info! I'll turn it on and see what happens. If it suspends the Forms instance that would be ideal so we can retry the step later.

The workflow completes in less than 10 seconds so this should not be a common occurrence, but we had two people submit forms at literally the exact same second today and so both got assigned the same case number by the workflow instances running concurrently.

0 0
replied on June 9 • Show version history

Have you considered using the Simple Synchronization Sequence activity?

You could use the Business Process ID as the synchronization Id, that might work better than single instance mode because it should just wait instead of causing the workflow to fail.

That also lets you narrow the focus to just the activities that can't be concurrent. For example, you could put a db insert activity inside the synchronization but leave the rest out, so other workflows don't have to wait for the entire process, just that one step/activity.

0 0
replied on June 9

I'm still new to Workflow so I didn't know about this activity - I think that's exactly what I need! I'll give it a go. You're awesome, thank you for the help.

0 0
replied on June 9

You're very welcome!

0 0
replied on June 9

Are you using Workflow to generate the case number? Possibly by adding 1 to some stored value? If that's the case, neither one of these will give what you want.

If you set WF to single instance mode and 2 Forms processes try to start it at the same time, the first one will succeed, the second one will get an error (and likely suspend waiting for an admin to retry it). 

If you're using simple synchronization sequence, then you'd need a set of actions and Insert is kind of a waste of a database row. Or, the Forms instance ID is already a unique number, why not use that instead?

If you're looking for sequential numbers for your cases, just use a SQL sequence and call it directly from Forms without WF. SQL Server will handle concurrency and not returning the same value to separate calls.

1 0
replied on June 9

Miruna makes a good point about the Instance Id already being unique.

Typically, I use either Instance Id, which references a specific instance of the Forms business process, or Submission Id, which is unique to a specific submission (e.g., a starting form or a user task).

The added benefit of storing both the Instance Id and the Submission Id is that you can use those to retrieve business process variables later if needed.

 

0 0
replied two days ago • Show version history

The case number is a certain sequence of numbers dictated by the police department - YY-80000, then YY-80001, then YY-80002. Currently the workflow sets the case number by counting the number of case folders already filed for the year + 80000, and then creating a case number string that has the year token built by workflow plus the sequential 80000 number.

So (I think) continuing to build the case number in workflow is my best bet? Especially since it needs to restart over at 26-80000 when the year changes. I like the idea of using a SQL sequence but I'm trying to avoid something that needs to be manually reset each Jan 1.

Below is my workflow. If I put the two highlighted activities in a simple synchronization sequence step using the business process ID as the synchronization ID, then if two forms processes start at the same time (same business process ID) would one wait for the first to finish before firing? So one would get case number 25-80001 and the other 25-80002. 

EDIT: I added a step to create the case number folder in the synchronization activity as well (instead of it being created in the save to repo task later in the Forms process). In initial testing this seems to work for simultaneous submissions! 

0 0
replied two days ago

The case number is a certain sequence of numbers dictated by the police department - YY-80000, then YY-80001, then YY-80002. Currently the workflow sets the case number by counting the number of case folders already filed for the year + 80000, and then creating a case number string that has the year token built by workflow plus the sequential 80000 number.

So (I think) continuing to build the case number in workflow is my best bet? Especially since it needs to restart over at 26-80000 when the year changes. I like the idea of using a SQL sequence but I'm trying to avoid something that needs to be manually reset each Jan 1.

Below is my workflow. If I put the two highlighted activities in a simple synchronization sequence step using the business process ID as the synchronization ID, then if two forms processes start at the same time (same business process ID) would one wait for the first to finish before firing? So one would get case number 25-80001 and the other 25-80002. 

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...