Collaborations are software modules that describe business processes and that run within IBM InterChange Server Express (ICS). These business processes are programs that contain the business logic for application integration. A collaboration can perform various types of Java operations. However, most commonly, collaborations perform operations on business objects, such as:
As Table 1 shows, a collaboration is a two-part entity, consisting of a
repository definition and a runtime object.
Table 1. Parts of a collaboration
Repository entity | Runtime object |
---|---|
Collaboration template | Collaboration object |
When you install a collaboration, you install a collaboration template. A collaboration template contains all of the collaboration's execution logic, but it is not executable. To execute a collaboration, you must first create a collaboration object from the template. The collaboration object becomes executable after you configure it by binding it to connectors or to other collaboration objects, and specifying other configuration properties.
In this book, both collaboration templates and collaboration objects are often referred to as simply collaborations, unless it is necessary to distinguish between a template and an object.
A collaboration begins as a collaboration template. A collaboration template is a specification of the logic within the collaboration. You define a collaboration template with the Process Designer Express tool, which stores the appropriate information in System Manager. Development of a collaboration template involves the following steps:
When you develop a collaboration, you use a tool called Process Designer Express to develop a collaboration template. Process Designer Express provides an easy-to-use, graphical user interface (GUI) that eliminates much of the coding usually required to develop a program. This interface makes it easy for you to declare variables, write code fragments, and so on. IBM InterChange Server Express also provides generic collaboration templates to facilitate the development process. Using Process Designer Express, it is simpler to develop a collaboration template than to write a standard programming language program. However, the end result of collaboration development is a program, in the form of a Java class.
Process Designer Express saves the collaboration template information in System Manager until deployment. After a collaboration is deployed, the collaboration information is available in InterChange Server, where it can be accessed when the collaboration receives a triggering event. For more information on Process Designer Express, see Overview of Process Designer Express.
Within Process Designer Express, building a collaboration template involves a two-level development process:
Compiling the template converts the diagrams and their associated code to an executable Java class.
When a template is compiled, the message content is placed in a message file within System Manager. After the collaboration is deployed, the message file is also stored in InterChange Server, where it is accessed during runtime. For more information, see Creating a message file.
A collaboration template consists of:
When developing a collaboration template, you first divide the collaboration's business logic into one or more scenarios.
Every collaboration template is partitioned into one or more units called scenarios. A scenario specifies exactly how the collaboration responds to a particular flow trigger. The scenario is like a method in that it describes the actions that will be taken by the collaboration.
You can create multiple scenarios or put all of the collaboration's logic into one scenario.
For each scenario, you create an activity diagram that graphically describes the scenario's process. An activity diagram is a graphical implementation of the scenario, including actions, execution flow, and external calls. Activity diagrams are based on Unified Modeling Language (UML), a standard notation for modeling business processes. The use of visual programming in diagrams makes it easy to create a scenario and reduces the amount of actual coding.
The various steps of the activity diagram are the individual actions, or code fragments.
Every scenario contains at least one, top-level diagram that represents the entry point of the scenario during execution and contains the overall logic flow of the scenario. Subdiagrams can divide the details of scenario logic into multiple nested levels.
An activity diagram looks somewhat like a flow chart. Unlike a flow chart, however, an activity diagram can create the executable Java code that the activity diagram represents.
Figure 1 is an example of an activity diagram.
The basic unit in an activity diagram is an action , represented by a rectangle. An action specifies a unit of work in the collaboration and is used to create and store Java code fragments.
The activity diagram represents all the possible behavior at execution time. The activity diagram in Figure 1 has multiple execution paths. An execution path is represented by a set of symbols and links that flow from the top Start symbol to one of the End symbols at the bottom. A symbol that has multiple outgoing links is a decision node; it is at this point that the collaboration decides to follow one path of logic instead of another.
Each action contains a Java programming language code fragment (called an activity definition) to which a developer can add custom code in the form of function blocks. Process Designer Express embeds the activity definition in the collaboration template code that it generates and executes the generated code when the collaboration object executes, as part of the collaboration flow.
You can add a custom activity definition, if desired. You can:
Much of the business logic in a collaboration template consists of calls to the InterChange Server Express collaboration API. Add your own activity definition or customize the activity included with the Item Synchronization collaboration by using Activity Editor. Activity Editor is a GUI that facilitates adding activity definitions by enabling you to graphically model the programming logic with function blocks.
You can import external packages of Java classes into the collaboration and use their methods inside actions.
When you finish the definition of a collaboration template--you have defined its scenarios, built the activity diagrams, customized its code fragments, and created its message file--you compile the entire template. The collaboration compilation process creates three types of files ( .class, .java, and .txt) that the collaboration runtime uses.
When you compile a collaboration, these files are automatically created in
your Integration Component Libraries (ICL) project within System
Manager. When you deploy your collaboration object to the server, these
files are moved into the productDir\collaborations
directory. Table 2 describes the files and shows where they are
located after compilation and deployment.
Important |
---|
Make all changes to messages only through Process Designer; never make changes directly to the message text file. After a collaboration has been deployed, this file is used by the runtime environment; directly editing it can cause errors. |
After you have compiled a collaboration template, you can use System Manager to create collaboration objects and deploy these objects and the template to InterChange Server. See Implementation Guide for WebSphere InterChange Server.
Although a collaboration template contains the collaboration's execution logic, you must take the following steps before the collaboration can execute:
A collaboration object is an instance of a collaboration template. To create a collaboration object, you use System Manager.
The collaboration object becomes executable after you configure it. To configure the collaboration object, you bind it to connectors or to other collaboration objects, and specify other configuration properties
The process of specifying the objects with which a collaboration object interacts is called binding. A collaboration object can be bound to any of the following:
For more information on using System Manager to create and configure collaboration objects, see the Implementation Guide for WebSphere InterChange Server.
Figure 2 illustrates the creation of a collaboration object called OrderStat from the template OrderStatus.
Figure 2. Creating a collaboration object
The OrderStatus collaboration template was created with two defined ports, through which the collaboration expects to communicate with its source and destination objects. As part of configuring the OrderStat collaboration object, you bind it to two external objects. Figure 3 shows that the OrderStat collaboration object is bound to the SAP connector and to the Vantive connector.
Figure 3. Collaboration object bound to connectors
After a collaboration object is bound and configured, you can use System Manager to test it and deploy it in the runtime environment. A collaboration object can be configured to run in one thread or in multiple threads, with each thread handling one triggering event. For concurrent handling of multiple triggering events, you run a collaboration object in multi-threaded mode.
Collaboration objects can be deployed as long-lived business processes, enabling asynchronous communication between business processes. As a result, business processes can span a greater length of time. In a long-lived business process, the event flow context (including global template or port variables and business object variables created in Process Designer Express, as well as runtime workflow information) persists throughout a service call.
Service call timeout values can be specified for asynchronous inbound and synchronous service calls to further define the parameters of a long-lived business process.
If you plan to use a collaboration object as a long-lived business process, you must configure the collaboration template accordingly. Before building your collaboration template, see the information in Designing for long-lived business processes. After you have designed your template, see Building a collaboration template for information about the specific configuration tasks required to provide support for long-lived business processes.
The InterChange Server business integration system uses a business object to carry data and action requests from one application to another. A collaboration begins execution when a scenario within a collaboration object receives a particular business object and an action (verb). This combination of business object and verb whose receipt by the collaboration triggers the execution of a scenario is called a flow trigger. As part of the design of the collaboration template, the collaboration developer specifies the business objects (and verbs) that act as flow triggers for each scenario. As part of the configuration of the collaboration object, you bind the incoming port of the collaboration to a particular source for the flow trigger. The type of source that sends the flow trigger to the incoming port determines the type of flow trigger that the collaboration receives.
As Table 3 shows, a flow trigger can be one of several types, based on
the source of the incoming business object:
Table 3. Types of flow triggers
Flow trigger | Source of incoming business object |
---|---|
Triggering event | Connector or another collaboration |
Triggering access call | Access client (through the Server Access Interface within ICS) |
Because connectors are the most common source of flow triggers, the term "triggering events" is often used to refer to the incoming business objects of a collaboration. For example, the Template Definition window includes a tab called Ports and Triggering Events. From this tab, you can define collaboration ports and assign triggering events to its scenarios. However, even though the titles of this tab and the associated table within this tab include the term "triggering events", this tab handles assignments of either type of flow trigger: triggering events or triggering access calls. If the scenario receives its business object from a connector, its flow trigger is a triggering event (as the name of the tab indicates). If the scenario receives its business object from an access client, its flow trigger is a triggering access call. In this case, you would still use the Ports and Triggering Events table to assign a triggering access call to a scenario.
The type of flow trigger for the collaboration is not actually determined until the port of the collaboration object is configured:
For more information on how to configure a collaboration object, see the Implementation Guide for WebSphere InterChange Server. For more information on the Ports and Triggering Events tab of the Template Definition window, see "Defining ports and triggering events (the Ports and Triggering Events tab)".