In this section of the book we will illustrate some cookbook scenarios. These are not meant to be full applications but rather to illustrate how a technique or concept can be achieved.
Scenario - Asynchronously starting one process from another
In this scenario we wish to have one process asynchronously start another process. Consider a process called "Process A". During its execution, we determine that we wish to start an instance of "Process B" but have "Process A" continue in parallel.
We will use the concept of a UCA to achieve this.
Process B looks as follows:
The interesting part of the process is that it is started by a "Start Message Event" step. This means that event has to arrive from an external source in order for the process to begin.
The configuration of this Step has as name a UCA which we called "My UCA".
Now let us look at the details of "Process A".
This contains an activity that is implemented as a General System Service.
The primary step in this service is an Invoke UCA step. This step names "My UCA" as the UCA instance to be invoked.
Scenario – Making a process extensible by others
A customer (lets call them XYZ Corp) of IBPM wanted to build business processes that they sell to their own customers and they wanted to allow their customers to make minor customizations. They faced two problems. The first was that they didn't want the end customers to break the integrity of the business processes they were selling. The second problem was that the original processes were to be updated over time with new revisions and they didn't want to "obliterate" the customizations made by the end customers if the BPDs were replaced with new copies.
One way to achieve this task is to have the core processes make calls to nested BPDs. These nested BPDs become "exit points" in the core process. If an end customer wants to customize the core process, they would customize the sub-processes invoked by the core BPDs. If these sub-BPDs are kept in a separate toolkit from the core Process Application then a replace of the Process Application with a new version will result in the original Toolkits BPDs being called and that is where the customizations would take place. This solves both problems. The core processes become effectively read-only and the sub-processes called by the core become documented "exit points" in the core process. If the core processes are changed and the calls to the exit points left as they were then the sub processes will still be called at the correct times. When the new Process Application version is installed, as long as the Toolkit containing the sub processes is not itself replaced, the core process will continue to call the sub processes as they were before.
Scenario – Starting a process from an external browser
In previous releases of IBPM, there used to be a concept of favorites when it comes to starting processes. A process could be defined as a favorite and then started from a favorite list in Process Portal. This concept is now all but gone from the product but part of the technology still remains.
In Process Portal there is a list of processes that can be started. This list is the set of processes that have had their "Expose to start" entry defined in the BPD editor in the Overview section:
The access to this list of startable processes within the Process Portal is from the New button. When one right click on an entry in this list, the URL link location (where the web link would take you) is available to be copied:
If the result of this link location is pasted into notepad, an entry similar to the following will be found:
Note the number if parenthesis. Let us call this the "favorite id".
If a web browser now visits:
An instance of the process will be started and the first coach (if configured) will be displayed.
It is not known if this recipe is formally defined as part of the architecture of IBPM. No reference to this technique has been found in the product manuals and may not be supported today or work in the future.