Search This Blog

SBL-BPR-00176: The workflow engine cannot determine a next step while executing process definition '%1'. The last step that it executed was '%2'.

Applies to:

Error Message Area:Business Processes/Workflow - BPR
Version:Siebel 7.8

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-BPR-00176: The workflow engine cannot determine a next step while executing process definition '%1'. The last step that it executed was '%2'.

Scope

This document is informational and intended for any user.

SBL-BPR-00176: The workflow engine cannot determine a next step while executing process definition '%1'. The last step that it executed was '%2'.

Explanation

The workflow/task engine returns this error when it fails to determine the next step after the last step specified in the message text. To determine the next step, it has to find either an unconditional transition branch or a decision branch that has a satisfied condition.

Corrective Action

Check the outgoing branches from the last step to make sure there is a default branch or at least one decision branch that will satisfy the condition.


Applies to:

Error Message Area:Business Processes/Workflow - BPR
Version:Siebel 7.7

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-BPR-00176: The workflow engine cannot determine a next step while executing process definition '%1'. The last step that it executed was '%2'.

Scope

This document is informational and intended for any user.

SBL-BPR-00176: The workflow engine cannot determine a next step while executing process definition '%1'. The last step that it executed was '%2'.

Explanation

The workflow engine returns this error when it fails to determine the next step after the last step specified in the message text. To determine the next step, it has to find either an unconditional transition branch or a decision branch that has a satisfied condition.

Corrective Action

Check the outgoing branches from the last step to make sure there is a default branch or at least one decision branch that will satisfy the condition.


Applies to:

Product Release: V7 (Enterprise)
Version: 7.7.2 [18325]
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 2.5
Database Server OS: HP 9000 Series HP-UX

This document was previously published as Siebel SR 38-2043024141.

Symptoms

We are going live week after next, we are encountring the floowing problem

We have a to wait for 60 seconds before sending next transaction in a very critacal workflow.
But we are not able to use wait step in intractve workflow mode.
Please find attached a very basic workflow we are trying to implement Wait step, but problem is if we give "MeasureUnit" as a parameter to the wait step we get the following error
"The workflow engine cannot determine a next step while executing process defination 'Wait step'. The last step that it executed was Wait:1-EBOZI.(SBL-BPR-00176) '"

I have attached the sample workflow along the SR.

thanks

Solution

Message 1

This publication is for the benefit of our readers.

"SBL-BPR-00176" error is similar to issues reported on SR 38-1318528021 which is associated to CR # 10473432: Simulating long-running flows should not be allowed.

By design, simulation of 'Long Running' flows is not supported. Currently, there is no check to prevent this, so simulating a long running flow may result in unpredictable behavior (such as a hang if it hits a wait step or any other step that requires a server type configuration).

A suggestion for testing flows with wait steps is to deploy, activate and then test by running as component request/job.

Customer's question:
The only problem we have is all our workflows are Service Mode workflows, and we have to change one of the workflow having WAIT step to interactive mode flow.

We are calling multiple workflows from one master workflow. With this change I have changed my Master Workflow and one child workflow having WAIT step to Interactive flow, but rest of my workflows are Service Flow workflows.

How can this change impact on rest of the exiting linked workflows?

Answer:
New in 7.7 are the Workflow Modes and you need to set this according to the steps used in the workflow process. These are the wf process configuration scenerios for setting workflow mode.

...continued...

Message 2

...2/2...

1. Wf process with a wait step is considered a long-running flow
2. Wf process with user interact step is an interactive flow
3. Wf process with user interact AND wait step is a long-running flow

So any time there is a wait step involved in the configuration its considered long-running flow.

Service Flow is the lowest on the hierarchy, so service flow can only call another service flow. In your case, the main workflow is technically not doing much other than calling other subprocesses, but the subprocesses are various types of flow, so the you need to change the parent workflow to reflect the highest type of the subprocess so if the subprocess has a long-running flow, then the parent process should be long-running mode as well.

You can test this by keeping the parent flow as service and then try to validate this through Tools. This should throw an error that parent service flow can not call subproceses with flow modes other than service flow.

I check the Business Process Designer Administration Guide and didn't find clear statements on setting workflow mode so I logged a Document Enhancement for clarification in current and future documentation.

ER 12-Y7VGWG - Need doc clarification on setting workflow mode.

Thanks,

Siebel Technical Support


Applies to:

Product Release: V7 (Enterprise)
Version: 7.7.0.1 [AN307]
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Server
Database Server OS: IBM AIX 5L 5.1

This document was previously published as Siebel SR 38-1318528021.

Symptoms

I am trying to simulate a workflow process that has only 3 steps: 1) Start, 2) Custom Business Service Method, 3) End

I have created the workflow process in Tools. I right-click the process and choose to validate...everything validates OK. I then try to simulate it. When I click the "Start" button the run-time instance of my Siebel client starts up and connects to the server. The client opens to My Inbox, I drill into "Debug Workflow" record and I get the error attached to this SR.

I do not get any errors when simulating other workflows that run Siebel Operations, only workflows that run Business Services.

Thanks, please respond to Mike Dannenfeldt (mdannenfeldt@envisagesolutions.com)

Regards,
Mike

Solution

Message 1

[1/3]
For the Benefit of other readers, this service request was raised to address some apparent inconsistencies during the simulation of workflows in Siebel Tools.

From Siebel 7.7, the Workflow Development functionality has been moved entirely into Tools.
For this SR a slightly modified version of the Reload Service Region workflow process was used for the simulation.

The following are some of the behaviors encountered and their explanations or solutions:

1. During Workflow Simulation, the following error was encountered:
"The value entered in field <?> of buscomp <?> does not match any value in the bounded picklist."

When the BusObject was removed from the workflow process, the simulation of the workflow completed successfully.

When a Business Object is specified for a Workflow Process, the workflow process always tries to validate the Object Id value is one which comes from the Primary Business Component of the Business Object used in the workflow. If the Object Id value is not from the primary business component, this will produce an error. The typical error we see is that "Row Id does not exist in business component." However, this is not the error we see.

cont'd

Message 2

[2/3]
i) The reason is this::
Now that the Workflow Designer is moved to Tools, Workflow designer uses Tools repository that is readily available and not reading from SRF file. Thus, this allowed user to choose a Business Object for WF Process even though the BO does not have any Primary BusComp assigned to it. This is different than in 7.x / 7.5 where the Designer read from SRF file and user would need to enable the BO for WF first by setting the Primary BC and compiling it into the SRF file.

Thus, the workflow had an Object Id value but not able to check it against any primary business component. This is due to the 'Abs Admin Service Region' business object out of the box does not have any Primary Business Component set.

Note: Using Siebel Tools > Validate was not able to trap the problem.

ii). Why still the error when the Object Id was defined?

This is because the Workflow Engine always checks the Object Id value to see if it's part of the primary BC of that BO Workflow is using. In this case, the Object Id value is valid, but there is no primary BusComp to compare to, so there is a mismatch and thus the error.

In this case, it is required to specify a Primary BusComp for the BO (for testing purposes). As the 'Abs Admin Service Region' BO, out of the box, this does not have any primary BusComp, go to Tools > BO = 'Abs Admin Service Region', set Primary Buscomp = "Service Region"
Compile the SRF file and update SRF file to client and server
cont'd

Message 3

[3/3]
2) When running workflow with wait step via the flow, the following error returned after the wait step:

"The workflow engine cannot determine a next step while executing process definition 'DTV Wait Reload Service Region'. (SBL-BPR-00176)

Note: The last step that it executed was 'Wait'."

This happens when the wait step actually has values for "duration" and "MeasureUnit".

However, if the two input arguments are removed and just set a wait step to do nothing,the simulation runs fine.

This is a known issue and change request ‘CR # 10473432: Simulating long-running flows should not be allowed’ has been raised to address this.

When a user tries to simulate a long running flow, Tools should return an error. Since the engine were not designed for running LR flows in the OM, the behaviour could be undeterministic.

By design, simulation of Long Running flows is not supported. Currently, there is no check to prevent this, so simulating a long running flow may result in unpredictable behavior (such as a hang if it hits a wait step or any other step that requires a server type configuration).

The suggestion to test these flows with wait steps is to deploy the workflow to client, activate it and then run as component request / job.


Applies to:

Siebel Workflow - Version: 8.0.0.7 [20426] to 8.1.1 [21112] - Release: V8 to V8
Information in this document applies to any platform.

Symptoms


Comments
--------
After upgrading to versions 8 or 8.1, customers are encountering errors in workflows either during validation or runtime.

The errors may be at validation:

- Validation failed for the workflow process 'DB LOY Generic Data Map Upsert FMA: 0' for the branch 'Yes1' The 'WF Branch Criteria Value' - field such as LO_.. or HI_.. for the respective data type is null or empty.

... or at runtime:

- SBL-BPR-00176: The workflow engine cannot determine a next step while executing process definition '%1'. The last step that it executed was '%2

- SBL-BPR-00162: error invoking service "" in method "" at step ""

- SBL-BPR-00185: Step '%1' references invalid next step id '%2' in process definition '%3'.

These errors have been reported so far, but other errors may appear as well


Cause

The cause for this behaviors is the upgrade that fails to set the connectors properly. The branches lose their reference to the steps during upgrade and thus there is a gap/failure in the workflow flow.

Errors related to foreign keys and branches can be seen in the upgrade log files, but these may be benign errors.


Solution

Defect 12-1VK09JB(Workflow Validation Problem in Siebel Tools Local 8.1.1.1 patch) has been logged and also fixed in 8.1.1.2 Fix Pack and 8.0.0.9 Fix Pack.

The workaround is to recreate all the branches or the branches that have conditions as mentioned in Document Id (815235.1). However this fix may not be suitable for a large number of workflows.


References

NOTE:815235.1 - Workflow validation failed

No comments:

Post a Comment