Introducing Trading Partner Integration
This topic describes basic concepts, architecture, and tasks for creating WebLogic Integration solutions for trading partner integration. It contains the following sections:
For a comprehensive overview of WebLogic Integration, see Introducing WebLogic Integration at the following URL: http://download.oracle.com/docs/cd/E13214_01/wli/docs81/overview/index.html. For a hands-on walkthrough of building and running example ebXML and RosettaNet solutions in WebLogic Integration, see Tutorials for Trading Partner Integration, which is available at:
http://dev2dev.bea.com/code/wli.jsp
http://download.oracle.com/docs/cd/E13214_01/wli/docs81/tptutorial/index.html
WebLogic Integration allows you to automate and manage relationships with your trading partners so that you can streamline your business processes (with customers, suppliers, distributors, and other partners) and get a top-down view of business transactions across the value chain. Trading partner integration is also known as business-to-business (or B2B) integration.
WebLogic Integration provides the following trading partner integration capabilities:
WebLogic Integration leverages the unified programming model and run-time framework of WebLogic Workshop to provide end-to-end business process integration via easily implemented controls and templates.
WebLogic Integration supports the following B2B protocols and standards:
http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/workshop/guide/navBuildingWebServices.html
WebLogic Integration provides sophisticated trading partner management capabilities through the unified WebLogic Integration Administration Console, which enables administrators to easily manage a central repository of trading partner profile information, including protocol bindings used for secure message exchanges between trading partners, services representing public processes, security, and bulk import / export capabilities. Authorized business processes and web services can dynamically access trading partner information via easily implemented controls. In addition to the Administration Console, MBean APIs are also provided so that third-party MBean clients can be written to access the TPM repository, as described in MBean APIs for Third-Party Access.
WebLogic Integration provides flexible run-time tracking, audit, and reporting capabilities to show a top-down view of trading partner activities and business transactions across the value chain.
WebLogic Integration provides fast and reliable business message exchanges between trading partners, supporting the clustered configuration for scalability and fail-over, message persistence for recovery, low-level acknowledgements and receipts, and transactional integrity.
WebLogic Integration ensures the private, secure, and reliable business message exchanges among trading partners using transport level security with SSL and message level security with digital signature and encryption. The certificates and private keys used for various purposes are kept in protected keystores while the passwords are kept in encrypted forms in the WebLogic Integration PasswordStore.
WebLogic Integration works with WebLogic Integration - Business Connect, a lightweight B2B server that is designed for small trading partners who do not have their own B2B server. For trading partners who want a zero-install solution, WebLogic Integration can be easily extended to offer a browser or FTP interface.
The basic building blocks of trading partner integration are trading partner profiles, services, and service profiles. This topic introduces the concepts you need to understand regarding trading partner management. It contains the following sections:
All trading partner profile, service, and service profile information resides in the Trading Partner Management (TPM) repository, which is stored in a relational database. Administrators use the WebLogic Integration Administration Console to maintain the TPM repository.
The following figure shows the Trading Partner Management home page in the WebLogic Integration Administration Console, which allows administrators to manage trading partner profiles, security certificates, protocol bindings, services, message tracking and auditing, trading partner activity, system defaults, and importing / exporting trading partner profile information.
Figure 1-1 Trading Partner Management in the WebLogic Integration Administration Console
For more information about the Trading Partner Management module in the WebLogic Integration Administration Console, see Trading Partner Management in Managing WebLogic Integration Solutions, including the following topics:
In WebLogic Integration, a trading partner is understood to be an entity that has an agreement with another entity to participate in a specific business transaction, or service, by playing a predefined role associated with a distinct business purpose. Trading partner applications form the nodes in system-to-system interactions among business partners.
A group of trading partners can:
A trading partner profile includes the trading partner's identifying information, and any certificates or protocol bindings required to conduct the business transactions. You use the WebLogic Integration Administration Console to manage trading partner information. For more information about managing trading partner profiles, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
By default, each trading partner has the following set of basic properties:
Used for uniquely identifying trading partners in business processes. |
|
Categorizes the type of business ID, such as a DUNs number, customer or vendor ID number, and so on. |
|
Designates whether this trading partner is local to the host system or a remote trading partner. |
|
Makes the trading partner visible (enabled) or hidden (disabled) for certain operations, such as business process or web service access to the trading partner information in the TPM repository. For more information, see "Enabling and Disabling Trading Partner and Service Profiles" in Trading Partner Management in Managing WebLogic Integration Solutions. |
|
If selected, then the trading partner is designated the default trading partner for sending or receiving messages for the local host system in the absence of specific trading partner information. |
|
In addition to these default properties, you can add custom extensions (extended properties) for individual trading partners in the TPM repository to support application-specific requirements. For example, you might want to include additional contact information, bank account information for electronic transfers, or internal vendor IDs to your trading partners. You can retrieve these properties from business processes and web services using the TPM control and also by navigating subtrees within an XML document. For more information about managing extended properties in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
WebLogic Integration uses digital certificates associated with trading partners to authenticate their identity during message exchanges. For more information about how digital certificates are stored and used in WebLogic Integration, see Transport-Level Security. For more information about managing certificates in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
This topic describes services, service profiles, and protocol bindings.
A service represents a business process that is either offered by a local trading partner, or a business process that is being called via a control on a remote trading partner.
For more information about managing services in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
Service profiles encapsulate the concept of an agreement between two trading partners on the service bindings to be used. Service profiles specify the protocol binding and URL endpoints for the local and remote trading partners that offer and call the service. For more information about managing service profiles in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
Protocol bindings specify the business protocol (ebXML 1.0 or 2.0, or RosettaNet 1.1 or 2.0), transport protocol (such as HTTP 1.0, HTTP 1.1, or HTTPS 1.1), URL end-point, time-outs, number of retries, retry intervals, digital certificates, and other information. For more information about managing protocol bindings in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
Note: When you are using the ebXML protocol for Trading Partner messaging, the values used for Retry Number, Retry Interval, and Persist Duration are always the values of the remote trading partner, not the local Trading Partner.
WebLogic Integration provides bulk management utilities that simplify the tasks of managing the TPM repository and exchanging trading partner and service information with other trading partners or porting the information to other servers. Data is exchanged via an intermediary XML data file that conforms to the tpm.xsd
schema that ships with WebLogic Integration. For trading partners that use WebLogic Integration - Business Connect, you can also import a single trading partner profile exported from WebLogic Integration - Business Connect or from WebLogic Integration using the business connect format. To learn more about exporting profiles from WebLogic Integration - Business Connect, refer to the WebLogic Integration - Business Connect documentation, which can be found at the following URL:
http://download.oracle.com/docs/cd/E13215_01/wlibc/docs81/index.html
To perform export, import, or bulk delete operations in WebLogic Integration, you can use either the WebLogic Integration Administration Console or a bulk loader command line utility. For more information about bulk management of the TPM repository, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
When you export TPM data using the console or the bulk loader utility, a file suitable for import is created. To learn more about the required structure, and how the file is used in import, export, and bulk delete operations, see Using the Bulk Loader in Managing WebLogic Integration Solutions.
When you create a new WebLogic Integration domain using the BEA WebLogic Platform Configuration Wizard, the Configuration Wizard automatically populates the Trading Partner Management (TPM) repository with default trading partners and protocol bindings. For more information about the Configuration Wizard, see Creating WebLogic Configurations Using the Configuration Wizard in the WebLogic Platform documentation.
The WebLogic Integration domain provides two preconfigured trading partners for development and testing:
For more information about the Trading Partner Integration tutorials, see Tutorials for Trading Partner Integration.
Each default trading partner comes with the following preconfigured protocol bindings:
Each protocol binding (except ebXML 1.0) is marked as default. At run-time, the default binding can be used automatically in the absence of specific protocol information. If you are using ebXML 1.0, you need to configure protocol bindings explicitly in the WebLogic Integration Administration Console.
WebLogic Integration supports user-written applications that use Java Management Extensions (JMX) Management Beans (MBeans) to access the TPM repository:
For more information about the MBean APIs, see the WebLogic Integration Javadoc.
This topic introduces the concepts you need to understand regarding trading partner business processes. It contains the following sections:
In WebLogic Integration, trading partners communicate with each other via WebLogic Workshop business processes that collaborate using the leading B2B protocols—ebXML or RosettaNet. You build, test, and run business processes using WebLogic Workshop's unified programming model and run-time framework. WebLogic Workshop provides controls, templates, and other mechanisms so that you can implement such business processes easily and quickly. For an introduction to building business processes in WebLogic Workshop, see the following topics in the WebLogic Workshop Help:
For more information about building business processes for particular business protocols, see:
This topic describes conversations between trading partners and the roles that trading partners play in conversations.
When trading partners exchange business messages for a business purpose, they participate in a conversation. A conversation is a series of one or more business messages exchanged between trading partners. The nature of each conversation is determined by its business purpose—whether it is a complex or simple conversation, whether it is a long-running or short-lived conversation, and so on.
The business messages that can be exchanged between participants in the conversation are determined by the roles that the trading partners play in the conversation. Each conversation always involves the following two roles:
These two roles are fundamental to all business processes involved in conversations, as the design patterns for initiator and participant business processes are very different. In a conversation, the business processes perform very different work but in a collaborative manner—the initiator business process sends a request to the participant, the participant business process receives the request and sends the response back to the initiator, and so on.
Each trading partner that participates in the conversation in a given role must implement the collaborative business process required for its role. Collaborative business process encapsulate the processes required to handle the right business messages at the right time for a given trading partner's role in a conversation.
These roles are often named according to the nature of the conversation. For example, if the conversation involves a supplier sending an invoice to a buyer and getting a confirmation that the invoice was received, then the supplier is the initiator of the conversation and the buyer is the participant. The invoice is the request document and the confirmation is the response document.
In the WebLogic Integration environment, a collaborative business process is a business process that implements a role in a conversation for a trading partner. The message choreography for a conversation is defined by collaborative business process.
The following figure shows basic interactive business processes between trading partners. The Buyer business process sends an order to the Seller using an agreed-upon business protocol (ebXML or RosettaNet). The Seller business process receives the request, writes the order to a database, receives an invoice from an internal back-end system, and then sends the invoice to the Buyer using the same business protocol.
Figure 1-2 Collaborative, Role-Based Business Processes In a Conversation
This section describes different categories of business processes within trading partner conversations.
This topic describes the WebLogic Workshop controls and templates that you can use for initiator and participant business processes.
The following table describes the WebLogic Workshop controls that you use in initiator business processes to handle communications with participants:
The ebXML control enables WebLogic Workshop business processes to exchange business messages and data with trading partners via ebXML. The ebXML control supports both the ebXML 1.0 and ebXML 2.0 messaging services. You use ebXML controls in only initiator business processes to manage the exchange of ebXML business messages with participants. For more information about using the ebXML control, see ebXML Control in the WebLogic Workshop Help and ebXML Initiator Business Processes. |
|
Enables WebLogic Workshop business processes to exchange business messages and data with trading partners via RosettaNet. You use RosettaNet controls only in initiator business processes to manage the exchange of RosettaNet business messages with participants. For more information about using the RosettaNet control, see RosettaNet Control in the WebLogic Workshop Help and RosettaNet Initiator Business Processes. |
The following table describes the WebLogic Workshop templates that you use in participant business processes to handle communications with conversation initiators:
Template provides a head start for building public participant business processes for ebXML conversations. Although this file is not required to build ebXML participant business processes, it includes the nodes and business process annotations needed to integrate easily with ebXML initiator business processes. For information about using the participant business processes file, see Building ebXML Participant Business Processes and @jpd:ebxml Annotation in the WebLogic Workshop Help. |
|
Template provides a head start for building public participant business processes for RosettaNet conversations. Although this file is not required to build RosettaNet participant business processes, it includes the nodes and business process annotations needed to integrate easily with RosettaNet initiator business processes. For information about using participant business processes, see Building RosettaNet Participant Business Processes and @jpd:rosettanet Annotation in the WebLogic Workshop Help. |
The TPM (Trading Partner Management) control provides WebLogic Workshop business processes and web services with query (read-only) access to trading partner and service information stored in the TPM repository. Access to the TPM repository is restricted to active trading partners, services, and active service profiles and their children. For more information about using the TPM control in business processes and web services, see TPM Control in the WebLogic Workshop Help. For more information about using web services, see "Building Web Services in the WebLogic Workshop Help.
Business processes and web services can also access data in the TPM repository via Process and Service Broker controls. These controls provide the lookupTPMProperties
XQuery function that can be used in selectors. For more information about these controls, see Process Control and Service Broker Control in the WebLogic Workshop Help.
Business processes can span multiple applications, corporate departments, and business partners (trading partners) behind a firewall and over the Internet. An enterprise's business processes can be divided into two broad categories: public and private.
Public processes are interface processes. Their definitions and designs are known, understood, and agreed upon by the organizations using them, and may be customized or standardized across an industry or industry segment, as in the case of RosettaNet Partner Interface Processes (PIPs). They are part of a formal contract between trading partners that specifies the content and semantics of message interchanges. These processes can be implemented in different ways by different trading partners.
In the context of trading partner integration, when collaborative business processes are intended to be reused in multiple conversations with different trading partners, the business processes should be designed as public processes.
Participants in a conversation can also implement private, non-collaborative business processes, which can integrate their back-end processing. Private processes are the business processes conducted within an organization. Their definitions and designs are specific to that organization and are not visible outside it. Within trading partner enterprises, private processes interface with public processes and with back-end business systems. In the context of public processes, private processes can be thought of as sub-business processes or subprocesses that implement tasks that are part of the public business process. For example, a trading partner may implement a private business process that works in conjunction with a collaborative business process and that implements the processes that occur locally to a trading partner, but that are not necessarily dictated by the service agreement.
In a conversation, business processes have two ultimate outcomes—success or failure:
Business processes need to fully implement and account for all of these possible scenarios using such WebLogic Workshop mechanisms as timer controls, retry loops, parallel branches, and so on.
Each failed business message is saved to a file and the file URI and other information (MessageID, FromTP, ToTP, ProcessURI, ProcessInstance, and Timestamp), if available, is enqueued to a dedicated JMS queue named wli.b2b.failedmessage.queue
. Custom queue listeners or event generator can be created to handle message failures.
This topic introduces the concepts you need to understand how WebLogic Integration handles the delivery of business messages to and from trading partners. It contains the following sections:
WebLogic Integration provides reliable, role-based XML messaging that supports enhanced send and receive capabilities, including support for large messages. To support the fast and reliable exchange of business messages among trading partners, WebLogic Integration provides the following messaging services at run-time:
A business protocol is associated with a business process, which governs the exchange of business information between trading partners. It specifies the structure of business messages, how to process the messages, and how to route them to the appropriate recipients. A business protocol may also specify characteristics of messages related to persistence and reliability.
A business message is the basic unit of communication among trading partners and is exchanged as part of a conversation. A business message contains one or more XML business documents, one or more attachments, or a combination of both.
The contents and format of a business message depend on the business protocol chosen for the conversation. For more information about specific message formats, see the following topics:
Business messages can include attachments in XML and non-XML formats. WebLogic Workshop business process support the following Java types for attachments:
Default. Represents data in untyped XML format. The XML data is not specified at design time. |
|
An array of one or more |
|
Represents any non-XML structured or unstructured data. Examples include PDF, DOC, GIF, JPG, and other binary files. |
|
An array of one or more |
|
Array containing one or more parts of an ebXML or RosettaNet business message. Message parts can be untyped XML data ( |
Note: Attachments can also be typed XML or typed MFL data as long as you specify the corresponding XML Bean or MFL class name in the parameter.
To learn more about these data types, see Working with Data Types in the WebLogic Workshop Help.
To expedite the processing of business messages in JMS queues at run-time, WebLogic Integration stores larger attachments temporarily in a Document Store database.
This section describes how ebXML and RosettaNet business messages are processed at runtime. Inbound and outbound business messages traverse different paths. The overall flow is the same regardless of the underlying business protocol, although WebLogic Integration's messaging infrastructure provides specialized underlying components to handle ebXML and RosettaNet business messages separately.
The following figure shows the path of an outgoing business message:
Figure 1-3 Path for Outgoing Trading Partner Messages
The preceding figure illustrates the following process flow:
Packaging differs based on the business protocol used and settings configured in the TPM repository. For example, the encoder handles encryption (for RosettaNet), digital signatures, generation of required message headers, MIME packaging, message persistence, and so on.
wli.internal.msgtracking.queue
). A message-driven bean that listens to this queue updates the various message tracking tables based on the tracking level set in the Trading Partner Management module of the WebLogic Integration Administration Console.For configuration instructions, see "Configuring the Mode and Message Tracking" in Trading Partner Management in Managing WebLogic Integration Solutions.
The following figure shows the path of an incoming business message:
Figure 1-4 Incoming Message Path
The preceding figure illustrates the following process flow:
B2BdefaultWebApp/WEB-INF/web.xml
.b2b.war
). Unpacking differs based on the business protocol used and settings configured in the TPM repository. For example, the decoder disassembles the various MIME parts of the message, validating the XML components (for RosettaNet), handles any required decryption (for RosettaNet), handles any digital signature verification, and so on.
Note: For ebXML, the decoder does a similar thing, but it depends on which reliable message option you have selected.
wli.internal.msgtracking.queue
). The message-driven bean listening to this queue will update the various message tracking tables based on the tracking level set in the Trading Partner Management module of the WebLogic Integration Administration Console. For configuration instructions, see "Configuring the Mode and Message Tracking" in Trading Partner Management in Managing WebLogic Integration Solutions.
WebLogic Integration the following run-time monitoring capabilities for trading partner integration:
WebLogic Integration tracks the flow and state information of business messages that are sent to, or retrieved from, other trading partners. You can view run-time data and statistics on the Message Tracking module in the WebLogic Integration Administration Console to perform real-time monitoring, process analysis, troubleshooting, and reporting for business messages.
The following example shows a summary of business messages:
The following example shows the details of a single business message:
WebLogic Integration maintains message history information in the run-time repository. You configure the message tracking level for individual services profiles, as described in "Adding Service Profiles to a Service" in Trading Partner Management in Managing WebLogic Integration Solutions. WebLogic Integration maintains message history information in the run-time database, for which you can schedule periodic archives and purges. For more information about message tracking, see "Monitoring Messages" in Trading Partner Management in Managing WebLogic Integration Solutions.
The Statistics module in the WebLogic Integration Administration Console displays run-time statistics for the system and for service profiles. The following example shows system summary statistics:
The following example shows service profile statistics:
For more information, see "Viewing Statistics" in Trading Partner Management in Managing WebLogic Integration Solutions.
This topic provides an overview of the phases, tasks, and tools involved in implementing trading partner integration solutions. It includes the following sections:
The first phase is to plan the solution, which involves:
For more information, see the following topics:
Once you understand the high-level requirements for your trading partner integration solution, you design, build, and test the solution using the following tools:
http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/integration/tutorial/tutWLIProcessIntro.html
http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/integration/dttutorial/tutWLIDataTransIntro.html
http://dev2dev.bea.com/code/wli.jsp
For more information about the tasks associated with each business protocol, see the following topics:
Once you have designed, built, and tested the trading partner integration solution, you deploy it in a production environment using the following tools:
http://download.oracle.com/docs/cd/E13214_01/wli/docs81/manage/index.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/index.html
http://download.oracle.com/docs/cd/E13214_01/wli/docs81/manage/bulkloader.html
For more information, see the following topics:
http://download.oracle.com/docs/cd/E13214_01/wli/docs81/deploy/index.html
http://download.oracle.com/docs/cd/E13214_01/wli/docs81/deploy/intro.html
Once you have deployed a trading partner integration solution in a production environment, you use the same tools—the WebLogic Integration Administration Console and the WebLogic Server Administration Console—to monitor and tune your deployment.
For more information, see the following topics:
http://download.oracle.com/docs/cd/E13214_01/wli/docs81/manage/index.html
At this point, you can proceed to the following topics: