Designing the Integration Solution

The integration specialist builds upon the material gathered in the requirements definition phase and designs an integration solution for the WebLogic Integration environment. The integration specialist needs to know how to map the business and technical requirements to the WebLogic Integration architecture, and how to design an integration solution that makes the best use of the available WebLogic Integration architecture and features.

With one exception, the following sections describe issues to consider when designing the solution for an integration project. The final section shows how these issues relate to a high-level design specification for the sample WebLogic Integration application.

Understanding the WebLogic Integration Architecture

Specifically, an understanding of the following WebLogic Integration components is important.

Mapping the Integration Solution Topology to WebLogic Integration

With an understanding of the WebLogic Integration architecture, an integration specialist can map the integration topology specified in the requirements to the appropriate WebLogic Integration features. The integration specialist must determine how the following will be implemented:

Defining the Network Topology and Scope of Administrative Control

In an enterprise with a geographically distributed WAN, separate locations might have separate domains. For example, an organization with its headquarters in New York and field offices in London and Tokyo might have three separate domains.

When designing a WebLogic Integration solution, it is essential to understand how these locations are managed because the type of domain administration determines the design approach to use.

Domains can be administered in the following ways:

Defining Human User Interaction

WebLogic Integration supports two kinds of human user interaction:

Worklist Users

Worklist users are assigned work directly by the business process. Users who are assigned tasks in this way work closely with a business process. WebLogic Integration supports the assignment of tasks to users through a client application called the Worklist. Through the Worklist a task can be assigned to either a user or a role, an alias for a designated group of users, any of whom can perform the assigned task. The Worklist also allows you to specify that the assigned user must execute the task before the process can continue. Worklist users interact with WebLogic Integration using one of the following types of Worklist clients.

For a JSP-based client and a command-line client, sample code is provided with the software in the WLIHome/samples/bpm_api directory.

Client Users

Client users interact with a business process indirectly, by using applications that are part of the process. For example, a sales person might log into a JSP-based application, create a sales order (which starts a workflow to process the order), and receive an e-mail confirmation.

Client users interact with the BPM through an asynchronous message-based exchange using one of three types of messages, which are described in the following sections:

Mailbox-Based Messages

In WebLogic Integration, the B2B integration component provides an HTML-based zeroweight client that interacts with a BPM process via database-based mailboxes. XML messages placed in a mailbox by the browser client are sent to the WebLogic Integration process engine. XML messages placed into the mailbox by the WebLogic Integration process engine can be read by the browser client. A library of JSP tags is provided to enable browser clients to interact with the mailboxes. The browser client must process the XML messages. For more information, see "Working with Zeroweight Clients" at the following URL:

E-mail Messages

Integrating with EIS Applications

WebLogic Integration provides multiple mechanisms for integrating with EIS applications. The following sections describe these mechanisms:

Application Integration Adapters

The most commonly used method for integrating WebLogic Integration with external EIS applications is through an application integration adapter. Depending upon the target EIS, an off-the-shelf adapter might be available for purchase. Alternatively, a developer can write a custom adapter. The following sections describe the benefits of application integration adapters:

For more information about application integration adapters, see the white paper entitled Enterprise Application Integration (EAI): Providing Stability in the Whirlwind of E-Commerce at the following URL:

Functional Capabilities

Because application integration adapters are based on the J2EE Connector Architecture (J2EE-CA), they provide significant functional capabilities, such as connection management, transaction management, and security management. The underlying J2EE CA engine provided by WebLogic Server supports these capabilities.

A key advantage is connection pooling. A connection to an EIS application can be an expensive resource, and the WebLogic Integration connection pooling functionality allows that resource to be shared among many WebLogic Integration requests.

Generic Nature

An application integration adapter is a generic adapter that is configured for the integration requirements. Adapters are configured through browsers. Therefore, those who configure the adapter do not need to be developers. Instead, they should be people with experience in running the application being integrated. This generic adapter design also supports dynamic integration environments.

Business-Level Interface

The interface presented to the WebLogic Integration process engine by the service and event adapters is a business-level interface (for example, create_new_customer), rather than an EIS application-specific API call. As a result, the BPM process designer can concentrate on the functionality of the process rather than on the mechanics of programmatically integrating with the application via the API.

All application integration service and event messages are defined as XSDs in the WebLogic Integration repository.

Integration with BPM

BPM and application integration functionality are directly integrated at both design time and run time. Application integration events and services are visible in the WebLogic Integration Studio to the workflow designer building the workflow.

Application Development Kit

Other Integration Techniques

Other integration techniques for EIS applications include:

BPM Business Operations

WebLogic Integration solutions can use BPM business operations to implement a request/response model initiated by the WebLogic Integration process engine. With business operations, a developer creates an EJB or Java class that wraps the EIS application interfaces that are used in the integration solution. Using business operations, this EJB or Java class can then be integrated with the WebLogic Integration process engine and invoked by a workflow. Integration specialists use business operations to invoke an EIS from the WebLogic Integration process engine synchronously.

JMS Wrappers

WebLogic Integration solutions can use JMS wrappers to implement an asynchronous integration model. A developer can create a JMS wrapper that can send messages from an EIS application to WebLogic Integration and vice versa. These messages can be created in either of the following formats:

Integration specialists use JMS wrappers to invoke an EIS from the WebLogic Integration process engine asynchronously.

Developing a Custom Application Integration Solution

The easiest way to provide integration with an EIS application is to purchase an off-the-shelf application integration adapter. If such an adapter is not available for custom applications, however, a custom integration solution must be developed. The integration specialist must decide whether to develop an application integration adapter, a business operation, or a JMS wrapper.

The drawback of using an off-the-shelf application integration adapter is that it might require more development effort than a custom integration. The model for which application integration adapters are designed is one in which a developer builds an adapter once and makes it available for use in many integration environments. Such a model provides the perfect rationale for developing commercial off-the-shelf adapters.

If, however, the EIS application integration requirements are simple and static (for example, if an application is designed to invoke only two API methods that are not going to be changed), then using a business operation or a JMS wrapper might involve less development effort.

Database Integration—Sample Application Integration Database Adapter

WebLogic Integration provides the source code for a sample application integration database adapter that can be used in an integration solution. The adapter supports both services and events:

File and FTP Integration—Sample Application Integration Binary File Adapter

The source code for a sample application integration binary file adapter is provided on the BEA dev2dev Online at the following URL:

The sample adapter supports both services and events.

Integrating with Other WebLogic Integration Clusters

In this scenario, each WebLogic Integration cluster should be treated individually: its business processes should be customized for the requirements of the local WebLogic Integration cluster. The business processes in WebLogic Integration clusters are then integrated using XML messages that are exchanged by those business processes. The DTDs or XSDs that define these XML messages should be stored in the WebLogic Integration repository in each WebLogic Integration cluster.

Integration Options

WebLogic Integration clusters can be integrated using the following WebLogic Integration features:

Sample Integration

Suppose an enterprise runs a global distribution system with a central sales office in New York and regional warehouses worldwide. The New York office uses an order management system and each warehouse location runs a distribution application. Each location is running a WebLogic Integration cluster.

In this scenario, the order management application receives the order, determines which region should fulfill the order, and notifies that region. At each regional site, a workflow can handle the request and send the response back to the order management system.

Integrating with Other Domains in the Enterprise

Within an enterprise, it might be necessary to integrate with other administrative domains (such as offices in other countries) over which the integration solution has no control or into which it has no visibility. The other domains might or might not use WebLogic Integration for their own integration requirements.

WebLogic Integration domains can be integrated using the following WebLogic Integration features:

Integrating with BEA TUXEDO and BEA eLink

A WebLogic Integration solution can involve the integration of applications that are already deployed on a WebLogic Server:

Integrating with External Trading Partners

The most commonly used method for integrating with external trading partners is to develop a B2B integration solution. The following sections provide fundamental information about the B2B integration functionality provided by WebLogic Integration:

B2B Integration Architecture

Peer-to-Peer Configuration in Value Chain Integration Solutions

A value chain integration solution involves either or both of the following types of integration:

The peer-to-peer configuration is used in value chain integration solutions, as shown in the following diagram.

Figure 3-1 Peer-to-Peer Configuration for Value Chain Integration Solutions

Hub-and-Spoke Configuration in B2B Exchange Solutions (Deprecated)

A B2B exchange solution enlists trading partners for B2B transactions. A B2B hub-and-spoke architecture is used in B2B exchange solutions, as shown in the following diagram.

Figure 3-2 Hub-and-Spoke Configuration for B2B Exchange Solutions

Hybrid Architectures

A WebLogic Integration solution might use a combination configuration that includes both peer-to-peer and hub-and-spoke configurations. This configuration model supports the exchange of messages among trading partners using XOCP for some trading partners and peer-to-peer protocols (RosettaNet, cXML, or EDI) for others.

Supported Business Protocols

A business protocol specifies the structure of business messages exchanged between trading partners, a method for processing the business messages, and a method for routing them to the appropriate recipients.

WebLogic Integration supports the following business protocols:

Integrating Custom Application Development

While designing the overall architecture of a WebLogic Integration solution, the integration specialist needs to identify gaps that require the development of custom code. Application customization options include BPM plug-ins, custom adapters, and logic plug-ins.

BPM Plug-Ins

Custom Adapters

A WebLogic Integration solution built on application integration functionality might require the creation of a custom application integration adapter.

Custom Logic Plug-Ins (Deprecated)

Implementing the Business Processes

Once the integration solution topology has been defined, then the integration specialist can start implementing business processes. For each business process defined in the integration solution requirements, several items must be implemented, as described in the following sections:

Business Events

Business events are the events that flow between the end-points of an integration solution. Some events might be sent to a process as input, while others might need to be generated within processes. In WebLogic Integration, business messages are sent in an XML or binary format.

For each business event, the integration specialist must define the following:

Conditional Data

Conditional data information that is required to make processing decisions, such as criteria for routing messages or for conditionally executing code. Such data is usually extracted from business messages. It might be constructed dynamically during the business process, however, from other data. Each piece of conditional data should be represented by a workflow variable.

Business Rules

Processing rules are applied to conditional data to determine the run-time execution path of the process. These rules are represented as decision nodes in a BPM workflow. In some scenarios, it is necessary to apply a number of complex conditions against a set of data. The outcome of these conditions determines the content of the workflow. A Java class should be developed to apply these conditions and return the result. This result can be used by decision nodes in the BPM workflow. The Java class you create to obtain this result can be called from the WebLogic Integration process engine as a business operation.

Mappings

Mappings define the data transformations between input and output business messages.

Business Transactions

A process might contain one or many business transactions. It must define both the business transactions and the compensating actions—actions that are performed when the business transaction needs to be rolled back.

Defining Data Transformations

The following sections describe data transformations for WebLogic Integration solutions:

About XML-Based Data Transformations

XML is the message format most commonly used in WebLogic Integration. The  following illustration shows how XML-based data transformation fits into the architecture of WebLogic Integration solutions.

Figure 3-3 XML-Based Data Transformation

XML is a common language with many dialects. Each source of XML data might use a different dialect, which means that a mechanism is required to handle the translation between different dialects. XSLT transformation is used as this mechanism.

For example, suppose a buyer sends a purchase order in RosettaNet format to a seller, and the seller needs to import the data into a back-end SAP ERP system, which accepts data only in SAP IDOC format. XSLT transformation can be used to convert the purchase order data from RosettaNet to IDOC.

Defining Binary-to-XML Transformations

While XML is the message format most commonly used in WebLogic Integration, at times, WebLogic Integration might need to integrate with environments in which a binary message interface is used. The data integration functionality of WebLogic Integration performs bidirectional translation between XML and binary formats. Such translations do not alter the data structure and content of the message; they change only the message format (XML or binary).

The format of the binary data is described via a Message Format Language (MFL) document created graphically using the Format Builder application. The MFL document is used by the data integration runtime class to parse and translate the binary data into an XML document.

Defining Binary-to-Binary Transformations

Binary-to-binary transformations and any combination (such as binary-to-XML and XML-to-binary) are supported by the combined used of two tools:

Defining XML-to-XML Transformations

The data transformation process is one of mapping the data structure and/or content of a source message to a new data structure and/or content in a target message. WebLogic Integration supports data transformation only for XML messages, using XSLT as its data transformation mechanism.

Users can create XSL stylesheets using graphical mapping tools such as Contivo Analyst (which is bundled with WebLogic Integration), or they can create them manually. XSL stylesheets are stored in the WebLogic Integration repository.

At run time, all transformations are executed by the WebLogic Integration process engine. The input message is provided in a workflow variable. To perform the conversion, the WebLogic Integration process engine references the XSL stylesheet in the WebLogic Integration repository. It stores the output message in another workflow variable.

Using Contivo Analyst to Define XML-to-XML Transformations

WebLogic Integration includes Contivo Analyst, a design-time graphical mapping tool that can be used to generate XSL stylesheets. The WebLogic Integration process engine can execute these XSL stylesheets at run-time to transform a source message to a target message. The source and target messages are defined using either DTDs or XSDs, and these definitions are stored in the WebLogic Integration repository. For more information about installing, configuring, and using Contivo Analyst, see your Contivo product documentation.

Contivo Analyst Integration with the WebLogic Integration Repository

Contivo Analyst is integrated directly with the WebLogic Integration repository, as shown in the following illustration.

Figure 3-4 Contivo Integration with the WebLogic Integration Repository

Role of Contivo Analyst in an Integration Solution

The following diagram shows how Contivo Analyst fits into a WebLogic Integration solution.

Figure 3-5 Role of Contivo Analyst in a WebLogic Integration Solution

Note: In addition to the XSL-based translation component, this illustration shows many other elements of a WebLogic Integration solution, including BPM workflows, application integration adapters, and adapters using data integration to perform binary-to-XML transformations using a Message Format Language (MFL) document created using the Format Builder application.

Creating a Detailed Design

After determining which WebLogic Integration components will be used in an integration solution, an integration specialist works with business analysts, developers, and system administrators to create a detailed design and begin constructing the integration solution.

The following sections provide information related to creating a detailed design for WebLogic Integration solutions:

Using Integrated Design Tools

To help create the detailed design, use the following WebLogic Integration tools:

Designing the Deployment Environment

Performance Considerations in Integration Design

The following sections describe factors that affect performance in WebLogic Integration deployments. An integration specialist needs to consider these factors when designing an integration solution:

Message Persistence

Message Size

Large messages, especially when exchanged in large volumes, consume more system resources than small messages. As a result, they can slow performance. Large messages are created in two forms:

Note: By enabling large messages, you might slow the processing of smaller messages.

XML Parsing and Validation

XML parsing can be an expensive process and it should be avoided as much as possible. XML validation is even more expensive and it should be avoided in all deployments in which high performance is a requirement. To control XML parsing/validation, keep in mind the following considerations:

Workflows

This section provides performance tips for WebLogic Integration workflows.

Synchronous Operations

WebLogic Integration allows you to use a called subworkflow instead of a workflow called via a JMS event. In general, called workflows are faster, but they consume more resources. Higher consumption results, for example, from the fact that called workflows block the calling workflow during execution.

For deployments in which high performance is a requirement:

Asynchronous Sending of Business Messages

You can design workflows to take advantage of the high-availability features of WebLogic Integration. In fact, WebLogic Integration now requires that business messages using the RosettaNet protocol must be sent asynchronously. (Synchronously sending of business messages is no longer supported.)

Sending business messages asynchronously offers performance benefits: After a task node that sends a business message has completed execution, workflow processing can immediately pass to the next node, if desired. It is not necessary to suspend the execution of the workflow while awaiting the business message return status. This section describes how to design asynchronous message sending in your RosettaNet-based workflows.

To design a workflow that sends a business message asychronously, you must define the following:

The following figure shows an example of how four nodes (T5, T8, C1 and E1) are associated with an asynchronous Send Business Message task in a RosettaNet-based workflow.

Figure 3-6 Send Business Message Workflow

Message Timeout

After you define and connect the nodes associated with a Send Business Message task, you typically pass execution from the task node that specifies a timeout value to a decision node. The decision node typically evaluates the HTTP status, and then determines the flow of execution as appropriate.

It is important to specify a timeout value that is large enough to avoid the "late message" problem. This problem is likely to occur if the timeout value is reached before the workflow receives the HTTP status event from the recipient trading partner. If the status event arrives after the timeout period has elapsed, the workflow ignores the status event.

As a rule of thumb, especially when dealing with remote trading partners, start with a timeout value of two hours. Testing should help you fine-tune the timeout value as appropriate.

Message Retries

Depending on the business protocol on which your workflow is based, there are different mechanisms available in WebLogic Integration that allow you to specify that a business message should be resent in the event that earlier attempt to send the business message has failed.

For workflows based on the RosettaNet protocol, the Studio allows you to design logic into your RosettaNet-based workflows that incorporates a "message resend" feature.

For ebXML-based workflows, however, you specify message retry in the B2B Console, not in the workflow. You specify this value when you configure the doc exchange for a trading partner who is participating in the ebXML conversation associated with the workflow. When you specify a message retry value, and choose OnceAndOnlyOnce in the Delivery Semantics selection box, the B2B engine uses that value to determine the number of times it should resend a business message in the event that a previous attempt has failed. Once the sending of a business message is successful, no further attempts are made. This assures that a message is sent once and only once. (If you select BestEffort in the Delivery Semantics selection box, the B2B engine ignores the retry value.)

Conditions

Using XPath

When using XPath, consider the following guidelines:

Using Temporary Variables

To increase BPM performance, set temporary variables to NULL before a quiescent state. This prevents it from being written to disk on a transaction boundary (like an event).

Disabling Statistics Gathering

To increase BPM performance, disable statistics gathering by setting the following flag:

-wli.bpm.server.nostatistics=true

Once statistics gathering is disabled, statistics are no longer displayed in the WebLogic Integration Studio.

Application Integration

By default, application integration functionality depends on the use of transactional and persistent message delivery for asynchronous requests and responses. This type of delivery can cause unwanted messaging overhead. To improve overall system performance, disable transactional and persistent delivery using the following solutions:

Application Logging

To enhance overall WebLogic Integration performance in a production environment, applications should perform minimal logging. To disable logging output, see "Using  Log Messages to Manage WebLogic Servers" in the BEA WebLogic Server Administration Guide at the following URL:

Secure Sockets Layer

To enhance performance in WebLogic Integration deployments in which B2B integration functionality is use, limit your use of Secure Sockets Layer (SSL) to those situations in which secure messaging is required. SSL adds processing overhead by performing such tasks as encrypting and decrypting business messages, which can slow overall system performance.

Specifying a High-Level Design for the Sample WebLogic Integration Application

The following sections discuss the high-level design of the sample WebLogic Integration application in relation to the design issues described in previous sections:

Automating Business Processes Through the WebLogic Integration Studio

Integrating the Supply Chain with B2B Integration

Integrating the ERP System with Application Integration Adapters

To integrate with the ERP purchase order system, the sample WebLogic Integration application uses application integration adapters. On the buyer side, it uses an event adapter to add the purchase order to the ERP system. It uses service adapters to update the purchase order, based on the purchase order acknowledgment received from the selected supplier.

Managing Data Transformations with the Data Integration

To handle XML-to-binary and binary-to-XML data transformations, the sample WebLogic Integration application uses data integration functionality. The WLIS_SupplierPOPrivate workflow performs the following conversions: