![]() |
![]() |
|
|
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
Before attempting to design the integration solution, an integration specialist needs to understand the WebLogic Integration architecture. For an overview of the WebLogic Integration architecture, see The Road to e-Business Integration in Introducing BEA WebLogic Integration.
Specifically, an understanding of the following WebLogic Integration components is important.
Table 3-1 Key Components of the WebLogic Integration Architecture
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:
For more information about defining integration solution requirements for human users, see Human Users.
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.
Table 3-2 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.
For information about developing custom Worklist clients, see Programming BPM Client Applications.
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 lightweight 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 Lightweight Clients" at the following URL:
http://download.oracle.com/docs/cd/E13214_01/wlintegration/v2_1/interm/b2bhome.htm
E-mail Messages
The WebLogic Integration process engine can send e-mail messages containing either free text or XML data, as described in "Sending E-Mail Messages" in Defining Actions in Using the WebLogic Integration Studio. To enable an application to receive e-mail, WebLogic Integration provides sample code for an application integration e-mail event adapter. An adapter developed with this sample code can receive an XML message in e-mail and forward it to a BPM process (such as those represented by the start/event and event nodes in the WebLogic Integration Studio), as described in The E-mail Adapter in Developing Adapters.
Note: The sample eMail Adapter is deprecated as of this release of WebLogic Integration, and will be removed from the product in a future release.
Integrating with EIS Applications
WebLogic Integration provides multiple mechanisms for integrating with EIS applications. The following sections describe these mechanisms:
A method must be chosen for each application separately. Whenever possible, EIS applications should connect to WebLogic Integration through a LAN. For more information about defining integration requirements for EIS application integration, see Application Integration—Enterprise Information Systems (EIS) Applications Used for Application Integration.
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:
http://www.bea.com/products/elink/EAI_business_wp.shtml
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
WebLogic Integration provides an Application Development Kit (ADK) for developing application integration service and event adapters. For more information, see Developing Adapters.
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:
The source code to the adapter can be extended if necessary. For more information, see The DBMS Adapter in Developing Adapters.
E-Mail Integration—Sample Application Integration E-mail Adapter
WebLogic Integration provides the source code for a sample application integration e-mail event adapter that can be used in an integration solution. The event adapter can receive e-mail containing an XML document and forward that XML document, as a JMS message, to the WebLogic Integration process engine.
Sample code for a service adapter that sends e-mail is also provided. Instead of using this sample code, however, we recommend using the WebLogic Integration process engine to send e-mail.
For more information, see The E-mail Adapter in Developing Adapters.
Note: The sample eMail Adapter is deprecated as of this release of WebLogic Integration, and will be removed from the product in a future release.
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 Developer Center at the following URL:
http://developer.bea.com/code/sampleswli.jsp
The sample adapter supports both services and events.
Integrating with Other WebLogic Integration Clusters
Within an enterprise, it might be necessary to integrate with other administrative domains (such as offices in other countries), as described in Defining the Network Topology and Scope of Administrative Control. If these domains are managed centrally and are visible to the integration solution over a WAN, then WebLogic Integration clusters can be installed at each site and WebLogic Integration can coordinate communication among them.
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.
For more information about WebLogic Integration clusters, see Configuring WebLogic Integration Clusters in Deploying BEA WebLogic Integration Solutions.
Integration Options
WebLogic Integration clusters can be integrated using the following WebLogic Integration features:
http://developer.bea.com/techtracks/xml/index.jsp
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:
http://developer.bea.com/techtracks/xml/index.jsp
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:
http://download.oracle.com/docs/cd/E13227_01/wtc/wtc10/index.html
http://download.oracle.com/docs/cd/E13182_01/elink/index.html
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
The architecture of a B2B integration solution depends on whether it is a value chain integration (peer-to-peer configuration) or a B2B exchange (hub-and-spoke configuration). For a detailed discussion that compares these architectures, see "Configuration Models" in Getting Started with B2B Integration in Introducing B2B Integration.
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
In the peer-to-peer configuration, a single trading partner (enterprise) is the Channel Master (CM)—the controlling entity to which all other trading partners (suppliers, customers, or both) are connected. This configuration model is also used when a business requires trading partners to communicate using the RosettaNet, cXML, or EDI protocol. Hub-and-Spoke Configuration in B2B Exchange Solutions 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
In the hub-and-spoke configuration, a single enterprise acts as a hub that coordinates B2B messages among enlisted trading partners (spokes). B2B applications communicate through an intermediary delivery channel using the XOCP protocol. This configuration model provides an intermediary in the message flow that performs value-added services such, as routing and filtering of messages, quality of service, and services for the trading partners in the conversation. 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:
For a detailed discussion that compares these different business protocols, see "Supporting Business Protocols" in "Meeting the Requirements of Your E-Business" in Overview in Introducing B2B Integration.
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
A WebLogic Integration solution might require the creation of a custom BPM plug-in that implements the BPM plug-in framework. For more information about designing and developing BPM plug-ins, see Programming BPM Plug-Ins for WebLogic Integration.
Custom Adapters
A WebLogic Integration solution built on application integration functionality might require the creation of a custom application integration adapter.
Logic Plug-Ins
A WebLogic Integration solution built on B2B integration functionality might require the creation of custom logic plug-ins, which are Java classes that perform specialized processing of business messages. Specifically, logic plug-ins insert rules and business logic at strategic locations as business messages travel through a node. For more information, see Programming Logic Plug-Ins for B2B Integration.
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:
These definitions should be stored in the WebLogic Integration repository. Whenever possible, use an event name as the name of the entity in the repository that holds the metadata. WebLogic Integration automatically stores this information in the repository when application integration adapters are being configured.
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:
For more information about data transformations, see Data Integration in Introducing BEA WebLogic Integration and Translating Data with WebLogic Integration.
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
The most common sources of XML data include:
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
Contivo Analyst browses the repository to select source and target message definitions. Once the selected definitions are read into the Contivo Analyst, the mapping from source to target is specified graphically. When the mapping is complete, the Contivo Analyst generates the XSLT and saves it directly in the WebLogic Integration repository. The WebLogic Integration process engine executes the XSLT using the XSL Transform workflow action. 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
In this illustration, Contivo Analyst generates the XSL stylesheet that the XML Transformer EJB uses to translate XML data between customers. 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. Using the RosetteNet-to-IDOC transformation scenario described in About XML-Based Data Transformations, the following steps show how Contivo Analyst fits into an integration solution:
The formats are either DTD or XSD. They can be located in the WebLogic Integration repository or the local file system.
The XSLT transformation file is an XML file (named with a .XSL extension) that is passed at run time to the XSLT engine, along with the input document (a purchase order).
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
An integration specialist usually designs the deployment environment before construction of the integration solution begins. An integration specialist needs this information to plan for deployment resources and costs. For information about deploying WebLogic Integration solutions, see Deploying BEA WebLogic Integration Solutions.
For example, to provide more workload capacity and higher scalability, an integration solution is usually deployed on a WebLogic Integration cluster. A cluster is a group of servers that can be managed as a single unit. For information about designing clusters, see "Designing a Clustered Deployment" in Configuring WebLogic Integration Clusters in Deploying BEA WebLogic Integration Solutions
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:
For more information about tuning the run-time performance of WebLogic Integration deployments, see Tuning Performance in Deploying BEA WebLogic Integration Solutions.
Message Persistence
Message persistence is a WebLogic Integration feature that improves data recovery in the event of a hardware or network failure. If enabled, however, message persistence slows overall system performance because it adds the processing overhead required for saving or purging messages in a persistent data store (that is, in a database or file).
Message persistence can be enabled in two areas:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/jms/appa.html
To improve overall system performance, use message persistence only when absolutely necessary.
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:
Use the WebLogic Integration B2B Console to configure large message support for B2B integration functionality. For more information, see "Defining B2B Integration Parameters" in Configuring B2B Integration in the Online Help for the WebLogic Integration B2B Console.
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:
To use a validating event queue, pass the -validate parameter to the MDBGenerator utility. For more information, see "Configuring a Custom Java Message Service Queue" in Customizing WebLogic Integration in Starting, Stopping, and Customizing BEA WebLogic Integration.
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:
Conditions
If performance is important, avoid using event conditions in BPM start or event nodes, if possible. For more information, see "Understanding Event Conditions" in Defining Workflow Templates in Using the WebLogic Integration Studio.
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:
wlai.jms.asyncServiceTransFlag=false
To solve this problem, increase the number of asynchronous processor threads by setting the wlai.numAsyncServiceRequestProcessors property in the wlai.properties file to a larger number. You might need to add this property to the wlai.properties file. The default value for this property is 2, which means that, by default, only 2 asynchronous service requests are processed at any given time on a given server instance.
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:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/logging.html
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:
These sections describe how the requirements defined in Determining Integration Solution Requirements, are mapped to components in the WebLogic Integration architecture. For a detailed description of the design for the sample WebLogic Integration application, see Learning to Use BEA WebLogic Integration.
Automating Business Processes Through the WebLogic Integration Studio
To automate the business processes described in Specifying the Integration Solution and Business Processes, the sample WebLogic Integration application uses the WebLogic Integration Studio to model and manage the following business processes:
These business processes use private and collaborative workflows among trading partners. They encapsulate the business events described in Specifying Business Events and the data flows described in Specifying Data Flow Requirements.
For detailed information about the workflow design, see "Business Process and Workflow Modeling" in Understanding the Sample in Learning to Use BEA WebLogic Integration.
Integrating the Supply Chain with B2B Integration
To manage business transactions with external entities (suppliers) in the supply chain, the sample WebLogic Integration application uses the B2B integration functionality provided by WebLogic Integration. Specifically, it is build on a hub-and-spoke configuration (described in Integrating with External Trading Partners) that provides mediated messaging among trading partners via the XOCP protocol. By using XOCP, the sample WebLogic Integration application meets the Quality of Service (QoS) requirements described in Specifying the Quality of Service.
The sample WebLogic Integration application deploys four business entities: a hub, a buyer, and two supplier trading partners. However, although the scenario calls for a topology in which suppliers run their own software on separate machines outside GCS, all entities are collocated on the same machine in the sample WebLogic Integration application to simplify using the sample. For more information about running this code in a clustered environment, see Deploying BEA WebLogic Integration Solutions.
For detailed information about incorporating B2B integration functionality into your design, see "B2B Integration" in Understanding the Sample in Learning to Use BEA WebLogic 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.
For detailed information about the application integration adapter, see "Application and Data Integration" in Understanding the Sample in Learning to Use BEA WebLogic Integration.
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:
For detailed information about data integration, see "Application and Data Integration" in Understanding the Sample in Learning to Use BEA WebLogic Integration.
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|