> ### 6.14 Interstage BPM Integration with Other Workflow Servers

> Interstage BPM integration allows the run-time interaction of processes between your local Interstage BPM Server and some other remote process server (another Interstage BPM server, CollaborationRing or other SWAP or ASAP compatible process engine) running on your Intranet. With this feature, you can start a remote subprocess from your local Interstage BPM Server, have the local process wait for the remote process to complete, and incorporate the results of the remote process back into the local process. This feature extends the capabilities of your local Interstage BPM Server by allowing access to these remote processes and their inherent functionality.

> Interstage BPM Integration employs the Simple Workflow Access Protocol (SWAP) and Asynchronous Service Access Protocol (ASAP). These open protocols pass XML messages over HTTP between the servers.

> How Interstage Business Process Manager Integration Works

> Interstage BPM uses a Remote Subprocess Node to start a process on the other server. There are four parts to this interaction:

> 1. When a Remote Subprocess Node is activated, it sends a StartProcess request to the remote server, carrying with it the UDA values that the new process will work on.
> 2. That remote server must receive this request, and start a workflow process.
> 3. Later, when the remote process completes, its Server send a "ProcessCompleted" message back to the local server, carrying with it the results of the subprocess.
> 4. The local server must receive this message, incorporate the results, and complete the Remote Subprocess node allowing the process to continue to the next step.

> For a local process to successfully invoke a remote process, the two processes must agree on a "signature" of the subprocess. The signature involves three parts:

> 5. The URL of the remote process definition.
> 6. The names of the set of data values that will be passed back and forth.
> 7. The possible result values of the subprocess.
> Process Definition URL

> The Remote Subprocess Node needs to be configured with a Process Definition URL. Every Process Definition (Plan Process Definition) that can be started remotely will have such a URL. It is not important to know how the URL is composed, or what information is contained in it, but it is important to get from the remote server the exact URL required to start a given process.

> Interstage BPM shows you the URL for a process definition in two places: The first is in the BPM Console in the Process Definition Properties dialog box, on the General tab. The second place is in the BPM Console, on the Process Definition detail description page. This is where you would find it if the remote process is going to be running on an Interstage BPM Server. If the remote server is going to be some other product, please refer to documentation of that product on how to find the URL for invoking a given process definition through the SWAP or ASAP protocol.

> Note Special users must be authenticated on the local Interstage BPM and the remote server to ensure the proper integration. For instructions, see the "Required Users for SWAP Integration" section of the Interstage Business Process Manager Administration Guide.

> Data Exchange

> The "CreateProcess" request carries with it context data to be used to the start the process on the remote server. This context data is a just like a set of UDA values: each value has a name. If the remote server is an Interstage BPM server, then the names in the context data will match the names of the UDA values in the remote process. If the remote server is a CollaborationRing server, then the names of the context values will match the process variables in the invoked process.

> The "ProcessCompleted" message that the remote server sends back to the local server also carries context data in it that came from the remote process. This may be the same set of values, or it may be different.

> Within the Remote Subprocess Node, you are asked to map UDA values of the parent process, to values in the remote process. This is because the name of the variable holding the value might be different in the remote subprocess (just as it might be different in a regular subprocess). Each mapping is marked as "in", "out", or both of these. Those mappings marked as "in" are included in the "CreateProcess" message that is sent at the beginning. Each mapping that is marked as "out" are used to copy values from the "ProcessCompleted" message back into the UDAs of the local process.

> Process Decision Results

> The Remote Subprocess Node may have one or more arrows coming from it. Each arrow has a name. Only one of these arrows will be selected when the parent process resumes. The arrow that is selected is the one that has the name that matches the result of the subprocess. The result of the subprocess corresponds to the name of the exit node that completed the process.

> Note The "matching" process that compares the name of the subprocess EXIT node to the names of the arrows outgoing from the remote subprocess node is case sensitive.

> This mechanism allows an easy way for a decision in the remote subprocess to be reflected in a different path in the local parent process.

> Designing Process Definitions for Workflow Integration

> Plan process definitions (actually, the processes made from them) intended for integration with other servers must be designed with care. The parent process and the child process must agree on a signature; the parent process calls that signature while the child process implements that signature. The signature consists of the three elements mentioned above: the URL of the remote process definition; the names of the set of data values that will be passed back and forth; and the possible result values of the subprocess.

> In order to describe how to set up two such processes, we will use an example. This example uses Interstage BPM for the parent process as well as for the child process simply for documentation purposes. Clearly, either the child or the parent could be a different product, but please look to that product's documentation on how to configure that product to play that role.

> For this example, the remote process is one capable of determining whether a customer is to be approved for a loan. For this example, this is a manual process involving a user of the remote server. The parent process is a loan application process that handles most of the loan process, but calls the remote process for getting the final approval. We will design the plan process definitions around the following signature:

> 1. The URL of the child process

> 2. The data items that will be sent to the subprocess:

> Name - the name of the customer sent from parent to child
> SSN - the social security number sent from parent to child
> Loan Amount - the dollar value of the proposed loan sent from parent to child
> Approval Limit - the dollar limit returned to the parent from the child

> 3. The results of the child process will be "Approved" or "Rejected".

> Examples using this signature are shown in the subsections below.

> Creating Child Process Definitions (for Remote Subprocesses)

> Create a new process definition that you want to use for your subprocess. This process definition must contain UDA variables for `Name', `SSN', `LoanAmount', and `ApprovalLimit'. These UDA variables must match exactly the names that will be used to transfer data from parent to child. You may also add as many other variables as you want for the running of the process. For instructions adding UDAs, see the "Define the set of user-defined process attributes" section.

> Figure 108: Defining UDAs in Child Process

> Make two exits nodes, name one of them "Approved" and name the other "Rejected". The names of these exit nodes must match the results part of the signature. Using the figure below as an example, say that the child process completed by exiting through the "Approved" Exit node, the "ProcessCompleted" message would include the result "Approved".

> Fill the process out with Activity nodes as required for your process. The simplest process (used in this example) is a single activity, but there is no restriction; the child process can use any normal process construct including JavaScript, JavaActions, and any of the node types. Connect the Activities, the Start Node, and the Exit Nodes with arrows appropriately.

> Publish this process definition using the Update Process Definition Version utility in the Administration Client. Only published plan process definitions can be invoked remotely unless the process definition belongs to the linkage user. *The linkage user can invoke remote draft process definitions. For instructions, see the Administration Client chapter of the Interstage Business Process Manager Administration and Installation Guide.

> Open the process definition properties dialog box and in the General tab information you will find the URL for this process definition. Note this down because you will need it for the parent process' Remote Subprocess Node. Fujitsu recommends using copy and paste to transfer this URL without any typographical errors.

> Figure 109: Interstage BPM Process Definition for Child Process

> Figure 110: Interstage BPM Child Process Definition URL (URI)
> Creating Parent Process Definitions to Start Remote Subprocesses

> This section provides instructions for creating parent process definitions that can call a subprocess. It can call the Interstage BPM process configured in the previous section, or it can call a process in any other product, as long as that process implements the specified signature.

> Create a process definition that you want to use for your parent process.

> Add any UDAs that you will need to run the process. The only requirement is that you must have 4 UDA variables that will hold the four values in the signature: `Name', `SSN', `LoanAmount', and `ApprovalLimit'. It does not matter what the name of those variables are. If you a reusing an existing process, you may already have a UDA variable defined to hold such a value. For example, and existing process may have a UDA variable called "SocialSecurityNumber" and that can be used as long as it hold the value in the same format that is required by the child process "SSN" variable. While the names are not constrained, you must have a UDA variable for each of the four values in the signature. For the case of this example, create the following UDA variables:

> CustomerName (STRING type)
> SocialSecurityNumber (STRING type)
> LoanAmount (FLOAT type)
> ApprovalLimit (FLOAT type)

> Figure 111: Defining UDAs in Parent Process

> Add a remote subprocess node to the process definition and define it using the information from the intended child process definition. Get the URL of the subprocess from the remote server, and paste it into the Current Sub-Plan field on the Data Mapping tap of the Remote Subprocess Properties.

> Figure 112: iFlowParent Data Mapping

> Configure the Data Mapping so that the CustomerName is mapped to `Name' as input to the subprocess (output is not necessary). Map SocialSecurityNumber to `SSN' for input. Map LoanAmount to `LoanAmount' as input. Finally, map ApprovalLimit to `ApprovalLimit' this time only as output. This is the data-mapping signature.

> Create two arrows coming out of the Remote Subprocess Node. Name one of the arrows "Accepted" and the other "Rejected". These names must match the results of the subprocess. If there is no arrow that matches the result that comes back, the process will go into an error state. There are no constraints on where the arrows may point; the process can continue in whatever manner you wish after the subprocess completes.

> Note The "matching" process that compares the name of the subprocess EXIT node to the names of the arrows outgoing from the remote subprocess node is case sensitive.

> The following is a process created from the iFlowParent process definition. It is displayed in the BPM Console:

> Figure 113: Interstage Business Process Manager Parent Process
> Running the Example Parent/Child Process

> Acting on the first activity node of iFlowParent moves us to the remote subprocess node. Moving to the remote subprocess node will send a request to the remote server to start the subprocess. If the remote subprocess starts successfully, the remote subprocess node turns yellow indicating that it has an active subprocess.

> Figure 114: Interstage BPM Parent Process with Active Subprocess

> The following process is started from the iFlowChild process definition. The process takes its name from the parent process definition:

> Figure 115: Interstage BPM Child Process Started from iFlowParent

> Acting on ChildActivity by clicking ToApprove moves the process to the Exit Node named Approved. This completes the subprocess. The process resumes on iFlowParent and will cause iFlowParent to exit the remote subprocess node through the arrow named Approved.

> Figure 116: Selecting ToApprove on ChildActivity
> CollaborationRing and Interstage Business Process Manager

> Now that Interstage BPM and CollaborationRing can be integrated, they extend each other's capabilities. Interstage BPM brings Java's programming and people-intensive flexibility into the equation, and CollaborationRing brings in its C++ stability and advanced Enterprise Application Integration (EAI) capabilities. Processes that run best in the C++ environment can be run on CollaborationRing and start subprocesses on Interstage BPM that are better suited to the Java environment.

> CollaborationRing uses the subprocess capability of its activity nodes to start processes on Interstage BPM

> An example of Interstage BPM processes starting CollaborationRing subprocesses is depicted below. In this example, the Interstage BPM process is being used for the people-intensive part of the process of entering information and routing it to another person for approval. This is the domain where Interstage BPM excels. Finally, there is a step in the process to go and "do it" which involves updates to a number of back-end systems. This is a domain where CollaborationRing excels. The Interstage BPM Server starts a process on CollaborationRing, giving it the data it needs, and waits for it to complete. The CollaborationRing server executes that process as quickly as possible, returning any results back to Interstage BPM.

> The capability to start and monitor a subprocess is reflexive. That is, one is able to define a process in CollaborationRing that calls a subprocess in Interstage BPM. An example of this is an EAI style process, which gets executed 1000's of times an hour, and that normally can be handled completely automatically. Occasionally, the data falls out of the anticipated ranges, and people need to be called in to do some manual handling on that process. This is depicted below as an "exception". It is an advantage to use Interstage BPM to run this process because of its better support for human processes. Once the human workflow process is done, the control returns to CollaborationRing where the parent process can continue.

> The following is an example of how one might deploy multiple servers for scalability. It presents a possibility where different departments or divisions work through a people-oriented workflow up front, and finally, the result is submitted to a CollaborationRing server for centralized processing and update of shared resources.

> SWAP (Simple Workflow Access Protocol) was originally designed to afford this kind of runtime integration. It was developed as one of its primary modes of communications. Interstage BPM supports a proprietary extension to the original SWAP specification.

> About Interstage Business Process Manager to CollaborationRing Data Transfer

> The following data transfer limitations should be considered when integrating Interstage BPM and CollaborationRing:

> · Only STRING-type variables in CollaborationRing can be used for exchanging data with Interstage BPM.
> · UDAs of all data types can be used in Interstage BPM for exchanging data with CollaborationRing.
> · Interstage BPM UDAs of all data types can be mapped to CollaborationRing variables of the STRING data type.
> Appendix F
> Glossary

Business Process Manager Help-Fujitsu Computer Systems Corporation Interstage Website Voice: (888) 248-9273 Interstage BPM Information