What are collaborations?

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.

Note:
For an introduction to how collaborations function as a component of the IBM InterChange Server Express system, see the chapter on collaborations in the Technical Introduction to IBM WebSphere InterChange Server. This section concentrates on defining a collaboration in terms of how it is developed.

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.

Collaboration templates

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:

Creating a collaboration template

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.

Building a collaboration template

Within Process Designer Express, building a collaboration template involves a two-level development process:

Creating the activity diagrams

A collaboration template consists of:

Figure 1 is an example of an activity diagram.

Figure 1. 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.

Implementing Java code fragments

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:

Compiling a collaboration template

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.

Table 2. Collaboration files
File type Description Location
.class
Final executable class file that Process Designer Express produces during compilation After compilation:
ICLProject\Templates\Classes

After deployment:
classes\UserCollaborations

.java
Source code file that Process Designer Express produces during code generation After compilation:
ICLProject\Templates\Src

After deployment:
classes\UserCollaborations

.txt
Message file that contains all of the message text you added to the template during development
After compilation:
ICLProject\Templates\messages

After deployment:
\messages

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.

Collaboration objects

Although a collaboration template contains the collaboration's execution logic, you must take the following steps before the collaboration can execute:

  1. Create a collaboration object.

    A collaboration object is an instance of a collaboration template. To create a collaboration object, you use System Manager.

  2. Configure the collaboration object.

    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.

Collaborations as long-lived business processes

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.

Collaborations and the IBM InterChange Server Express system

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)

Note:
An access client is an external process that can request execution of collaborations through the Server Access Interface API. For more information, see the Access Development Guide.

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)".

Copyright IBM Corp. 2003, 2004