Migration of Step Types
Unless specifically mentioned, classic BPM step types are migrated to the same step type in Dynamic Business Orchestrator and there is no difference in runtime behavior.
Service Tasks
The classic BPM Service Task is implemented with a wrapper service that is generated by Designer and located in the model package. The intent of the wrapper service is to provide a place to do mapping and/or build a complex service implementation. Depending on how the wrapper services are created, the wrapper service could contain input mapping, execution of logic, and output mapping all in one place. It is possible to invoke a custom service from the generated wrapper service and the invoked custom service lives outside the model package.
A Dynamic Business Orchestrator Service Task is implemented by 3 components:
1. Input Mapping
2. The Service
3. Output Mapping
If a wrapper service contains more than one invoke step, Dynamic Business Orchestrator configures the migrated service task to use the wrapper service (just as classic BPM does). If the wrapper service contains a single invoke of another service, the migration utility configures the migrated service task to use the invoked service, eliminating the need for the wrapper service in the deployed solution. In either case, you can embed your Input and Output mapping directly into the model.
Send Tasks
Send Tasks are not supported by Dynamic Business Orchestrator. They are functionally replaced by Throwing Message Events.
A classic BPM Send Task with outbound sequence flow is migrated to a Throwing Message Event. When a Send Task has no outbound sequence flow, it is migrated to an End Message Event
Receive Tasks
Receive Tasks are not supported by Dynamic Business Orchestrator. They are functionally replaced by Catching Message Events.
If a Receive Task has no inbound sequence flow, it is migrated it to an Intermediate Catching Message Event along with an inserted sequence, connecting the Start Event in scope to the migrated Message Event. A Gateway is also inserted to deal with the multiple outbound sequence flow from the Start Event. The image below illustrates this behavior for a Receive Task in a top-level process.
If a Receive Task without sequence flow appears in a subprocess, a Start None Event is inserted to connect to the Intermediate Message Event.
If there is inbound sequence flow and outbound sequence flow, the step is migrated directly to an Intermediate Message Event.
Deprecated webMethods Subprocess
Classic BPM supports two types of Subprocess: webMethods Subprocess and BPMN Subprocess. The webMethods Subprocess was deprecated in BPM Version 8.2 and is not supported by Dynamic Business Orchestrator. A webMethods Subprocess is migrated to a BPMN Subprocess, but it is possible that the migrated subprocess will execute differently in Dynamic Business Orchestrator than it did in classic BPM. You must manually verify that your migrated subprocess behaves as desired and make changes as necessary.
Deprecated webMethods Referenced Subprocess
webMethods Referenced Subprocess was deprecated in BPM Version 8.2 and is not supported by Dynamic Business Orchestrator. A webMethods Referenced Subprocess is migrated to a call activity, but the migrated result might not execute as it did in classic BPM. You must manually verify that your migrated webMethods Referenced Subproces behaves as desired and make changes as necessary.
Dynamic Call Activity
Compared to classic BPM, the document required to setup the execution of a Dynamic Call Activity is modified in Dynamic Business Orchestrator. You must manually modify the Input and Output Mapping for a migrated Dynamic Call Activity.
End Terminate
The End Terminate step in classic BPM is configured to end the process instance with a particular status (Copmpleted, Cancelled, Failed). In Dynamic Business Orchestrator, an End Terminate has a single definition: to abnormally terminate the process instance. A classic End Terminate Event is migrated differently depending on the configured status as follows:
A configured Completed status results in an End None Event after migration.
A configured Cancelled status results in an End Terminate Event after migration.
A configured Failed status results in an End Terminate Event after migration.
Note: Dynamic Business Orchestrator does not support model notation to cancel a process instance. A classic End Terminate Step, configured for "Cancelled", is migrated to an End Terminate Event, which has a different runtime behavior. In Dynamic Business Orchestrator, a process instance can be cancelled using the service pub.dbo.instance.control:cancel.
