Skip navigation.

Introducing Trading Partner Integration

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Introduction

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:

 


About Trading Partner Integration

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:

Visual Public/Private Process Integration

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.

Support for Leading Industry Protocols and Standards

WebLogic Integration supports the following B2B protocols and standards:

Trading Partner Management (TPM) and Repository Access

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.

Easy Access to Run-Time Information

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.

High Performance and Availability

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.

High Security, Auditing, and Non-Repudiation

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.

Trading Partner Enablement

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.

 


Trading Partner Management Concepts

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:

About Trading Partner Management

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

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:

Trading Partners

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.

Types of Trading Partners

A group of trading partners can:

Trading Partner Profiles

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:

Basic and Extended Properties

By default, each trading partner has the following set of basic properties:

Table 1-1 Basic Trading Partner Properties

Property

Description

Business name

Name of the trading partner.

Business ID

Used for uniquely identifying trading partners in business processes.

Business ID type

Categorizes the type of business ID, such as a DUNs number, customer or vendor ID number, and so on.

Type

Designates whether this trading partner is local to the host system or a remote trading partner.

Status

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.

Description

Brief description of the trading partner.

Default Trading Partner

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.

Contact information

Email, address, phone, and fax 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:

Digital Certificates

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:

Services, Service Profiles, and Protocol Bindings

This topic describes services, service profiles, and protocol bindings.

Services

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

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

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.

Exchanging Data in the TPM Repository

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.

Default TPM Repository Settings

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.

Default Trading Partners

The WebLogic Integration domain provides two preconfigured trading partners for development and testing:

Table 1-2 Default Trading Partner Configuration in WebLogic Integration Domain 

Trading Partner Name

Trading Partner ID

Description

Test_TradingPartner_1

000000001

Default local trading partner. In the tutorials, this trading partner is usually the initiator of conversations.

Test_TradingPartner_2

000000002

In the tutorials, this trading partner is usually the participant in conversations.


 

For more information about the Trading Partner Integration tutorials, see Tutorials for Trading Partner Integration.

Default Protocol Bindings

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.

MBean APIs for Third-Party Access

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.

 


Trading Partner Business Process Concepts

This topic introduces the concepts you need to understand regarding trading partner business processes. It contains the following sections:

About Business Processes for Trading Partner Integration

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:

Conversations and Roles

This topic describes conversations between trading partners and the roles that trading partners play in conversations.

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.

Roles: Initiators and Participants

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:

Role-Based Design Patterns

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.

Role Naming

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.

Collaborative Business Processes

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.

Sample Conversation

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

Collaborative, Role-Based Business Processes In a Conversation


 

Types of Business Processes

This section describes different categories of business processes within trading partner conversations.

Initiator and Participant Business Processes

This topic describes the WebLogic Workshop controls and templates that you can use for initiator and participant business processes.

Initiator Business Processes and WebLogic Workshop Controls

The following table describes the WebLogic Workshop controls that you use in initiator business processes to handle communications with participants:

Table 1-3 WebLogic Workshop Controls Used in Initiator Business Processes 

Control Name

Description

ebXML Control

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.

RosettaNet Control

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.


 

Participant Business Processes and WebLogic Workshop Templates

The following table describes the WebLogic Workshop templates that you use in participant business processes to handle communications with conversation initiators:

Table 1-4 WebLogic Workshop Templates Used in Participant Business Processes 

Business Protocol

Description

ebXML participant business process file

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.

RosettaNet participant business process file

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.


 

TPM Control For Business Processes and Web Services

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.

TPM Repository Lookups Via Process and Service Broker Controls

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.

Public and Private Business Processes

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 Business Processes

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.

Private Business 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.

Success and Failure Paths

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.

 


Messaging Concepts

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:

Messaging Services for Trading Partner Integration

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:

Business Protocols

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.

Business Messages

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.

Business Message Formats

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:

Attachments

Business messages can include attachments in XML and non-XML formats. WebLogic Workshop business process support the following Java types for attachments:

Table 1-5 Types of Attachments in Business Messages 

Data Type

Description

XmlObject

Default. Represents data in untyped XML format. The XML data is not specified at design time.

XmlObject[]

An array of one or more XmlObject elements. Only available for ebXML messages.

RawData

Represents any non-XML structured or unstructured data. Examples include PDF, DOC, GIF, JPG, and other binary files.

RawData[]

An array of one or more RawData elements. Only available for ebXML messages.

MessageAttachment[]

Array containing one or more parts of an ebXML or RosettaNet business message. Message parts can be untyped XML data (XmlObject data type) or non-XML data (RawData data type). Used when sending different kinds of payloads (XML and non-XML) in the same message. The actual number of message parts might not be known until processed. To learn about working with MessageAttachment objects, see Using Message Attachments in the WebLogic Workshop Help.


 

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.

Run-Time Processing of Business Messages

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.

Outgoing Message Path

The following figure shows the path of an outgoing business message:

Figure 1-3 Path for Outgoing Trading Partner Messages

Path for Outgoing Trading Partner Messages


 

The preceding figure illustrates the following process flow:

  1. A business message is sent from a WebLogic Integration business process.
  2. The applicable encoder (RosettaNet or ebXML) packages the message appropriately using input from:
  3. 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.

  4. The message is persisted in the WebLogic Integration document store and forwarded it to the applicable JMS queue:
  5. The message-driven bean associated with the queue sends the message out asynchronously over HTTP(S) to the endpoint URL for the remote trading partner.
  6. Message tracking information for the outbound message is sent to the message tracking queue (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.
  7. For configuration instructions, see "Configuring the Mode and Message Tracking" in Trading Partner Management in Managing WebLogic Integration Solutions.

Path for Incoming Trading Partner Messages

The following figure shows the path of an incoming business message:

Figure 1-4 Incoming Message Path

Incoming Message Path


 

The preceding figure illustrates the following process flow:

  1. An incoming trading message, sent to the local trading partner, is received by the Transport Servlet Filter, which is specified in B2BdefaultWebApp/WEB-INF/web.xml.
  2. The Transport Servlet Filter inspects the URL and determines whether the incoming request is a TPI URL / request.
  3. The Transport Servlet sends the message to the applicable decoder (RosettaNet or ebXML), which unpacks the message.
  4. 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.

  5. The decoder persists the message (payload in ebXML, or Service Content in RosettaNet), plus any attachments, in the WebLogic Integration Document Store.
  6. The decoder determines the destination and originator parties, the service name, and other relevant information that helps in dispatching the message.
  7. The decoder dispatches the message to the Async Dispatcher Queue.
  8. The message parts will be packaged as appropriate for the receive node's method signature.

  9. For RosettaNet, the decoder also responds to the sending trading partner that the business message was received.
  10. Note: For ebXML, the decoder does a similar thing, but it depends on which reliable message option you have selected.

  11. The Async Dispatcher Module dispatches the message to the appropriate receive node on the business process.
  12. Message tracking information for an inbound message is sent to the Message Tracking queue (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.

 


Run-Time Monitoring Concepts

WebLogic Integration the following run-time monitoring capabilities for trading partner integration:

Message Tracking

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:

Incoming Message Path


 

The following example shows the details of a single business message:

Incoming Message Path


 

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.

Viewing Run-Time Statistics

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:

Incoming Message Path


 

The following example shows service profile statistics:

Incoming Message Path


 

For more information, see "Viewing Statistics" in Trading Partner Management in Managing WebLogic Integration Solutions.

 


Summary of Trading Partner Integration Phases

This topic provides an overview of the phases, tasks, and tools involved in implementing trading partner integration solutions. It includes the following sections:

Phase 1: Plan the Solution

The first phase is to plan the solution, which involves:

For more information, see the following topics:

Phase 2: Design, Build, and Test the Solution

Once you understand the high-level requirements for your trading partner integration solution, you design, build, and test the solution using the following tools:

For more information about the tasks associated with each business protocol, see the following topics:

Phase 3: Deploy the Solution

Once you have designed, built, and tested the trading partner integration solution, you deploy it in a production environment using the following tools:

For more information, see the following topics:

Phase 4: Administer and Tune the Solution

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:

 


Next Steps

At this point, you can proceed to the following topics:

 

Skip navigation bar  Back to Top Previous Next