In classic BPM, you can configure a timer on a join expression, which instructs the runtime to take the join timeout transition when the configured amount of time has elapsed. In Dynamic Business Orchestrator, a gateway simply waits for all inbound sequence flows to arrive, therefore the join timeout concept does not exist in Dynamic Business Orchestrator. The migration utility eliminates the join timeout transition from migrated models, which will "orphan" the steps that were connected to that transition in the classic model. This requires a manual change to the migrated model to achieve the desired execution behavior.

To resolve the orphaned steps that were once connected to the join timeout transition, you can simply remove the steps. Another option is to use a Timer Event Subprocess to achieve an equivalent pattern. The following image is an example of how a Timer Event Subprocess is used to implement the classic join timeout pattern.

In classic BPM you can use Unsatisfied Join, which is a special transition that executes when a Join Expression fails to be satisfied. Dynamic Business Orchestrator does not provide this special transition, because a properly designed model should never result in a gateway that fails to execute. The migration utility eliminates the UnsatisfiedTimeout transition from migrated models, which will "orphan" the steps that were connected to that transition in the classic model. This requires a manual change to the migrated model to achieve the desired execution behavior.

A properly designed model should never look for a failing join to execute correctly, so the recommended approach is to examine the gateways used in the model to ensure they correctly describe the diverging and converging behavior. Once you make sure the gateways in the model are set up correctly, remove the orphaned steps that were connected to the unsatisfied join transition.

In classic BPM you can use Step Iterations Exceeded, which is a special transition that executes when a particular step had been executed a configured number of times. The most common use of this transition isto exit a what is known as an unstructured loop. In classic runtime, if the step exceeded the configured number of iterations, the Step Iterations Exceeded transition would execute and prevent the execution of any other transitions for that step. This transition type is not directly supported by Dynamic Business Orchestrator, but the migration utility replaces it with a conditional transition that is true when the step exceeds the configured number of iterations.

The following example shows a classic model with an unstructured loop that is configured to exit after 3 iterations and the same model after migration. The Step Iterations Exceeded transition is replaced by a normal, conditional sequence flow that examines the StepIteration. This transition executes as expected, but in the classic model the transition labeled "Always True" will be prevented from executing, while Dynamic Business Orchestrator executes that transition. This unstructured loop would executed infinitely following migration. This is one example of the importance of inspecting the migrated model when using the Step Iterations Exceeded transition.

The use of unstructured loops is not advised. If they are absolutely necessary, it is important to inspect the conditional sequence flow that governs the loop and modify the conditions in the migrated model to ensure that the loop will properly exit and not just rely entirely on the Step Iterations Exceeded transition. Alternatively, you can replace the unstructured loop with a subprocess and structured looping.