(For more resources on Trivadis Integration and SOA, see here.)

Service-oriented integration scenarios

These scenarios show how the service-oriented integration business patterns can be implemented. These business patterns are as follows:

• Process integration: The process integration pattern extends the 1: N topology of the broker pattern. It simplifies the serial execution of business services, which are provided by the target applications.
• Workflow integration: The workflow integration pattern is a variant of the serial process pattern. It extends the capability of simple serial process orchestration to include support for user interaction in the execution of individual process steps.

Implementing the process integration business pattern

In the scenario shown in the following diagram, the process integration business pattern is implemented using BPEL.

Trigger:

An application places a message in the queue.

Primary flow:

1. The message is extracted from the queue through JMS and a corresponding JMS adapter.
2. A new instance of the BPEL integration process is started and the message is passed to the instance as input.
3. The integration process orchestrates the integration and calls the systems that are to be integrated in the correct order.
4. A content-based router in the mediation layer is responsible for ensuring that the correct one of the two systems is called. However, from a process perspective, this is only one stage of the integration.
5. In the final step, a “native” integration of an EJB session bean is carried out using an EJB adapter.

Variant with externalized business rules in a rule engine

A variant of the previous scenario has the business rules externalized in a rule engine, in order to simplify the condition logic in the integration process. This corresponds to the external business rules variant of the process integration business pattern, and is shown in the form of a scenario in the following diagram:

Trigger:

The JEE application sends an SOAP request.

Primary flow:

1. The SOAP request initiates a new instance of the integration process.
2. The integration process is implemented as before, with the exception that in this case, a rule engine is integrated before evaluating the condition. The call to the rule engine from BEPL takes the form of a web service call through SOAP.
3. Other systems can be integrated via a DB adapter as shown here, for example to enable them to write to a table in an Oracle database.

Variant with batch-driven integration process

In this variant, the integration process is initiated by a time-based event. In this case, a job scheduler added before the BPEL process triggers an event at a specified time, which starts the process instance. The process is started by the scheduler via a web service call. The following diagram shows the scenario:

Trigger:

The job scheduler building block does a web service request at a specified time.

Primary flow:

1. The call from the job scheduler via SOAP initiates a new integration process instance.
2. As in the previous variants, the BPEL process executes the necessary integration steps and, depending on the situation, integrates one system via a database adapter, and the other directly via a web service call.

Implementing the workflow business pattern

In this scenario, additional user interaction is added to the integration process scenario. As a result, the integration process is no longer fully automated. It is interrupted at a specific point by interaction with the end user, for example to obtain confirmation for a certain procedure. This scenario is shown in the following diagram:

Trigger:

An application places a message in the queue.

Primary flow:

1. The message is removed from the queue by the JMS adapter and a new instance of the integration process is started.
2. The user interaction takes place through the asynchronous integration of a task service. It creates a new task, which is displayed in the user’s task list.
3. As soon as the user has completed the task, the task service returns a callback to the relevant instance of the integration process, and by that, informs the process of the user’s decision.
4. The integration process responds to the decision and executes the remaining steps.