bea.com | products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 
Search
e-docs > WebLogic Platform > WebLogic Integration > B2B Topics > Introducing B2B Integration > Overview

Introducing B2B Integration

 Previous Next Contents Index View as PDF  

Overview

Enterprises strive to integrate, automate, and streamline core internal and external business processes to improve their performance in today's dynamic business-to-business (B2B) electronic commerce (e-commerce) environment. These business processes drive a company's e-commerce interactions with their customers, partners, distributors, and suppliers; they can also streamline the company's internal business. Among the target business processes for B2B integration and automation are design and specification, manufacturing and testing, procurement, sales, fulfillment, customer service, and planning. To support these processes, B2B integration must support workflow processing, messaging and routing, and enterprise application integration.

BEA WebLogic IntegrationTM is an XML- and Java-based e-commerce platform that enables you to implement complex e-commerce systems on the Web. It helps you to quickly deploy e-commerce systems that link existing back-end applications, databases, customers, and partners into automatic and flexible electronic collaborations.

WebLogic Integration is a software framework and a set of services built on top of BEA WebLogic ServerTM. It builds upon the WebLogic Server foundation by adding a framework for business process management, application and data integration, and B2B integration. This document is an introduction to the latter component, that is, B2B integration: messaging, connectivity, and business protocols.

WebLogic Integration's B2B integration component is implemented entirely in Java and leverages the J2EE standard APIs. XML is used as a standard format for documents exchanged by business partners. WebLogic Integration supports HTTP because the World Wide Web is the ubiquitous communication medium for e-business.

WebLogic Integration simplifies the implementation and development of business-to-business trading networks, providing opportunities to integrate internal business processes with inter-enterprise business message exchange. A variety of deployment models are supported.

The following sections provide an introduction to B2B integration:

 

WebLogic Integration: Support for B2B Integration

WebLogic Integration provides an infrastructure platform for integrating business processes that can span multiple corporate departments, multiple enterprises across the Internet, or both. The WebLogic Integration platform supports the building of mission-critical, scalable, real-world e-commerce collaborations. Its features include:

Note: Support for trading partner lightweight clients is deprecated as of this release of WebLogic Integration. For information about the features that are replacing trading partner lightweight clients, see the BEA WebLogic Integration Release Notes.

WebLogic Integration also offers a number of features inherited from WebLogic Server, including:

 

Meeting the Requirements of Your E-Business

WebLogic Integration manages enterprise-to-enterprise collaborations, allowing heterogeneous enterprises to interact in diverse business transactions, which can be complex and long-running. The following sections describe requirements for the framework to build such a B2B e-commerce environment, and they explain how WebLogic Integration meets these requirements:

Connecting Trading Partners

A trading partner joins one or more other trading partners to form an e-commerce community with a specific business purpose. Business partners in an e-commerce community can range in size from large enterprises to small divisions within an enterprise. One of the basic building blocks of B2B e-commerce is the trading partner, specifically, the trading partner applications that form the nodes in system-to-system interactions among business partners. An e-commerce community formed by a group of trading partners can:

A trading partner must have a special identity that defines where it fits with the business purpose of the e-community. In the WebLogic Integration environment, a trading partner refers specifically to an entity that has an agreement with another entity to participate in a specific business exchange, or conversation, in a specific role that is defined for the conversation.

To meet the requirements of today's diverse B2B e-commerce activities, an enterprise must be able to use a variety of connectivity options. Such flexibility is necessary if a company wants to participate in business transactions with a large set of trading partners with diverse processes and protocols.

To that end, a WebLogic Integration trading partner application can be configured to communicate directly with other trading partners in a peer-to-peer mode, or through an intermediary in the hub-and-spoke mode, or both. These different configuration modes allow for either direct or mediated messaging among trading partners. An intermediary in the message flow can perform tasks such as routing and filtering of messages, or it can provide services to the trading partners in the conversation. For more details about modeling your B2B integration configurations, see Configuration Models.

Some business partners may have modest back-end integration requirements, or may need to participate in collaborative processes without installing the WebLogic Integration software. WebLogic Integration supports zeroweight clients to give small and medium-size enterprises, or enterprises with little or no back-end integration requirements, a simple integration path through which they can participate in e-business communities. Such enterprises can use a Web browser or a file-sharing client to communicate with business partners who deploy WebLogic Integration. The instance of WebLogic Integration to which they connect acts as a server for their needs. For details about setting up and configuring trading partner lightweight clients, see Running the B2B Integration Samples.

The following figure illustrates a simple scenario in which WebLogic Integration is deployed in peer-to-peer relationships between customers and suppliers in a value chain. A customer or supplier trading partner can support multiple peer-to-peer business partnerships with other trading partners.

Figure 1-1 Peer-to-Peer Messaging Among Trading Partners


 

The following figure illustrates a scenario in which WebLogic Integration is configured in hub-and-spoke mode. The Net Market trading partner, as the hub, provides intermediary services to several trading partners. For example, this might be an auction service, in which the hub is the auction broker.

Figure 1-2 Mediated Messaging in a Hub-and-Spoke Configuration


 

Defining Conversations and Roles

When trading partners join other trading partners to form an e-community with a specific business purpose, they participate in a conversation. A conversation:

The business messages that can be exchanged between participants in the conversation are determined by the roles the trading partners play in the conversation. The roles and other details of a conversation are specified in a conversation definition using the WebLogic Integration B2B Console. A conversation is an active instance of a conversation definition.

A conversation definition:

For details about writing messaging applications using the Messaging API and the cXML API, see Programming Messaging Applications for B2B Integration and Implementing cXML for B2B Integration, respectively.

When you use the WebLogic Integration Studio tool to compose business messages and manage their exchange in a conversation, each trading partner that participates in the conversation in a given role must implement the collaborative workflow required for its role. Collaborative workflows encapsulate the processes required to handle the right business messages at the right time for a given trading partner's role in a conversation.

For example, the following figure represents a simple conversation with two participating roles, buyer and supplier, and hypothetical workflows for the two roles.

Figure 1-3 Collaborative Workflows in a Query Price and Availability Conversation


 

In this figure, note the following:

Managing Business Processes

Using workflows is the recommended approach to composing business messages and choreographing their exchange in conversations. Alternatively, you can write Java messaging applications that use the WebLogic Integration Messaging API or the cXML API. This section discusses the approaches to developing and managing messaging applications for B2B integration.

Workflows are 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 and Private Business Processes

Business processes can be designed as public or private 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 B2B integration, when collaborative workflows are intended to be reused in multiple conversations with different trading partners, the workflows should be designed as public processes.

Participants in a conversation can also implement private, noncollaborative workflows, 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 subworkflows or subprocesses that implement tasks that are part of the public workflow. For example, a trading partner may implement a private workflow that works in conjunction with a collaborative workflow and that implements the processes that occur locally to a trading partner, but that are not necessarily dictated by the conversation definition.

Business Process Management (BPM)

WebLogic Integration provides a business process management (BPM) component. It automates and integrates a business process by managing the sequence of activities in the process and invoking the appropriate resources required by the activities or steps in the process. The components of business process management include a GUI workflow design tool (the WebLogic Integration Studio), a GUI monitoring tool (the WebLogic Integration Worklist), and the process engine that monitors and controls workflows.

In the WebLogic Integration environment, a collaborative workflow is a workflow that implements a role in a conversation definition for a trading partner. The message choreography for a B2B conversation is defined by collaborative workflow templates: one template is defined for each role in the conversation definition, as described in Defining Conversations and Roles.

A B2B integration BPM plug-in extends the already powerful Studio design tool with functionality that allows you to create collaborative workflows for B2B integration. Using the plug-in functionality, you can compose and extract the contents of business messages, specify the message delivery Quality of Service (QoS), handle message tokens, and so on.

See Creating Workflows for B2B Integration for details about how to use the WebLogic Integration Studio to design collaborative workflows.

In summary, WebLogic Integration provides the following business process management functionality:

Using the Messaging API (Deprecated)

As an alternative to using the WebLogic Integration Studio and other business process management capabilities, a trading partner can implement Java-based XOCP messaging applications based on the WebLogic Integration Messaging API. See Programming Messaging Applications for B2B Integration for information about using the Messaging API.

The Messaging API was available with WebLogic Integration Release 2.0. A messaging API (called the C-Enabler API) was also available with the WebLogic Collaborate product.

Using the cXML API (Deprecated)

WebLogic Integration B2B supports multiple business protocols for sending and receiving messages (see Supporting Business Protocols). For the cXML (Commerce eXtensible Markup Language) protocol, WebLogic Integration B2B provides a cXML API. The cXML API provides classes that allow the sending and receiving of cXML messages, the creation and manipulation of cXML documents, the mapping of a collaboration agreement to a message, and so on. For details, see Implementing cXML for B2B Integration.

Supporting Business Protocols

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 (see Business Messages for details).

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. You bind a business protocol to a conversation definition and a delivery channel for a trading partner. A business protocol is bound indirectly to a collaboration agreement through both the associated conversation definition and associated trading partner's delivery channel (see Defining Collaboration Agreements).

WebLogic Integration supports the following business protocols:

By providing the ability to send and receive messages according to these standard protocols, WebLogic Integration gives an enterprise a great deal of flexibility and opportunity in organizing its B2B e-commerce by reducing the need for trading partners to standardize on any single protocol.

You can also customize and extend the supported business protocols beyond their out-of-the-box functionality by using logic plug-ins. Logic plug-ins are Java classes that can intercept and process business messages at run time. WebLogic Integration provides system logic plug-ins, which you can supplement by writing custom logic plug-ins. The system logic plug-ins for XOCP include XOCP Router and XOCP Filter. They are directly involved in the processing of message recipients based on Xpath expressions in the repository. Custom logic plug-ins can perform a wide range of services that are unrelated to routing or filtering, as well as routing and filtering operations. For example, a custom logic plug-in might be used, for billing purposes, to track the number of messages sent from each trading partner.

See Administering B2B Integration and Online Help for the WebLogic Integration B2B Console for details about administering both system and custom logic plug-ins. See Programming Logic Plug-Ins for B2B Integration if you want to write custom logic plug-ins.

XOCP (Deprecated)

The eXtensible Open Collaboration Protocol (XOCP) is a BEA-specific business protocol. The XOCP business protocol supports the standards-based ebXML Transport, Routing, and Packaging (TRP) protocol. XOCP provides the following messaging characteristics:

RosettaNet

WebLogic Integration supports sending and receiving RosettaNet messages according to both RNIF 1.1 and RNIF 2.0. It also supports interoperability with other RosettaNet partners. In addition, WebLogic Integration collaborative workflows can participate in RosettaNet Partner Interface Processes (PIPs).

RosettaNet is a self-funded, nonprofit consortium of major companies (from the information technology, electronic component, and semiconductor manufacturing industries) working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis. (For complete details about the RosettaNet organization, see http://www.rosettanet.org.) To support its mission, RosettaNet provides specifications for the RosettaNet Implementation Framework (RNIF), the Partner Interface Processes (PIPs), and business and technical dictionaries.

RosettaNet (http://www.rosettanet.org) defines its Partner Interface Processes (PIPs) as follows:

"RosettaNet PIPs are specialized system-to-system XML-based dialogs that define business processes between trading partners. Each PIP specification includes a business document with the vocabulary, and a business process with the choreography of the message dialog. PIPs fit into seven clusters, or groups of core business processes, that represent the backbone of the supply chain network. Each cluster is further subdivided into segments, which are cross-enterprise processes involving more than one type of supply chain partner. Within each segment are individual PIPs."

PIPs contain one or more Activities, and Activities, in turn, specify Actions. PIPs apply to the following core processes:

The RNIF provides exchange protocols for implementation of the PIPs. The RNIF specifies information exchange between trading partner servers using XML, covering transport, routing and packaging, security, signals, and trading partner agreements.

For details about RosettaNet support in WebLogic Integration, see Implementing RosettaNet for B2B Integration.

cXML (Deprecated)

WebLogic Integration provides a cXML API so that trading partner servers can send and receive cXML messages according to the cXML standard. The cXML API provides classes that allow the sending and receiving of cXML messages, the creation and manipulation of cXML documents, the mapping of a collaboration agreement to a message, and so on.

The http://www.cxml.org Web site defines cXML as follows:

"cXML is a streamlined protocol intended for consistent communication of business documents between procurement applications, e-commerce hubs, and suppliers."

cXML transactions consist of documents that are simple text files with well defined format and content. Most types of cXML documents are analogous to hardcopy documents traditionally used in business. The main types of cXML documents are Catalogs, Punchouts, and Purchase Orders. cXML defines a common DTD for business messages.

The cXML protocol is designed to link buyers and suppliers in scenarios where buyers browse catalogs and submit purchase orders to suppliers. A buyer can browse a supplier's catalog directly; alternatively, an Ariba exchange (Ariba Commerce Server Network) mediates messages between buyer and supplier.

For details about cXML support in WebLogic Integration, see Implementing cXML for B2B Integration.

ebXML

WebLogic Integration supports the ebXML Message Service Specification v1.0, which defines the message enveloping and header document schema used to transfer ebXML messages with a communication protocol such as HTTP. In addition, WebLogic Integration supports the creation and execution of workflows that model ebXML business messages.

The ebXML Message Service Specification is a set of layered extensions to the base Simple Object Access Protocol (SOAP) and SOAP Messages with Attachments specifications. The ebXML Message Service provides security and reliability features that are not provided in the specifications for SOAP and SOAP Messages with Attachments.

A trading partner that deploys WebLogic Integration can use ebXML to interoperate with a trading partner that deploys WebLogic Integration - Business Connect. WebLogic Integration - Business Connect is a lightweight client that can be deployed in a few hours, enabling enterprises to enlist new business partners quickly by eliminating their barriers to entry.

For information about WebLogic Integration - Business Connect, see Using WebLogic Integration - Business Connect, which is available at the following URL:

 
http://download.oracle.com/docs/cd/E13215_01/wlibc/docs70/index.html

For information about ebXML support in WebLogic Integration, see Implementing ebXML for B2B Integration.

Business Messages

A business message is the basic unit of communication among trading partners. It 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. In WebLogic Integration, the primary method used to prepare a business message to be sent to one or more trading partners is a collaborative workflow. (See Business Process Management (BPM).)

This section describes the basic structure of business messages exchanged in the B2B integration environment. See Creating Workflows for B2B Integration for details about using the WebLogic Integration Studio to compose and manipulate business messages.

XOCP Business Messages

The XOCP business protocol supports the open standard ebXML Transport, Routing, and Packaging (TRP) protocol (see http://www.ebxml.org for the "ebXML Message Service Specification"). The ebXML TRP protocol defines a wire format and protocol for a message service to support XML-based electronic messages.

The following figure represents the structure of a business message exchanged in a conversation based on the XOCP protocol.

Figure 1-4 XOCP Business Message


 

Note the following parts:

Note: The B2B engine supports sending encoded messages. An XOCP business message is encoded using the encoding specified in the WebLogic Integration repository for the recipient trading partner. See Online Help for the WebLogic Integration B2B Console and Working with the Bulk Loader in Administering B2B Integration for information about using the B2B Console and the Bulk Loader to configure trading partners.

RosettaNet Business Messages

WebLogic Integration supports sending and receiving RosettaNet messages according to the RosettaNet Implementation Framework, versions 1.1 and 2.0. A business message exchanged in a conversation based on the RosettaNet 1.1 protocol is called a RosettaNet Object (RNO). The entity exchanged in a conversation based on the RosettaNet 2.0 protocol is called a RosettaNet Business Message (RBM).

A B2B integration BPM plug-in extends the functionality of the Studio with features that simplify the development of RosettaNet business messages and Partner Interface Protocols (PIPs).

The following figure represents the structure of a RosettaNet Object exchanged in a conversation based on the RosettaNet 1.1 business protocol.

Figure 1-5 RosettaNet Business Message


 

Note the following parts:

The RosettaNet Implementation Framework 2.0 introduced the following notable differences in the composition of a RosettaNet Business Message (RBM):

Note: The B2B engine supports sending encoded messages. The B2B engine uses UTF-8 to encode all RosettaNet messages.

cXML Business Messages

WebLogic Integration supports sending and receiving cXML messages. cXML request and response transactions belong to one of four general types: Profile, PunchOut, Order, or Subscription transactions. The following figure represents the structure of an XML request business message exchanged in a conversation based on the cXML business protocol.

Figure 1-6 cXML Business Message


 

Note the following parts:

Note: The B2B engine supports sending encoded messages. The B2B engine uses UTF-8 to encode all cXML messages.

ebXML Business Messages

An ebXML business message contains one XML business document and one or more attachments. An ebXML message is a communication protocol-independent MIME/Multipart message envelope, referred to as a message package. All message packages are structured in compliance with the SOAP Messages with Attachments specification.

For information about ebXML business messages in WebLogic Integration, see Using Workflows with ebXML in Implementing ebXML for B2B Integration.

Ensuring the Security of Transactions

Reliable and secure communications are a crucial element in the B2B e-commerce environment. This is true whether e-business collaborations are between partners within an organization or between partners that span multiple organizations across firewalls and over the Internet.

WebLogic Integration B2B security is built on top of the security features provided by WebLogic Server; it provides advanced security support and services. WebLogic Integration B2B provides support for the following security features:

See Implementing Security with B2B Integration for a comprehensive discussion about security, and details about configuring security services.

Defining Collaboration Agreements

A critical component of B2B e-commerce is the establishment and management of agreements among business partners. In the WebLogic Integration environment, these agreements take the form of collaboration agreements between trading partners. Using collaboration agreements, trading partners agree on the interactions between them, in particular, the conversations in which they participate, and each trading partner's message sending and receiving characteristics.

Parties in Collaboration Agreements

A conversation definition defines two or more roles to be used by trading partners in a conversation. A party in a collaboration agreement binds a role from the conversation definition to a trading partner. For example, consider a collaboration agreement based on the Query Price and Availability conversation described in Defining Conversations and Roles. There are two parties in this collaboration agreement: one buyer and one supplier (see Figure  1-7).

Delivery Channels in Collaboration Agreements

A trading partner's message sending and receiving characteristics are encapsulated in a delivery channel. There is generally one delivery channel per trading partner for each business protocol supported by the trading partner.

Note: Trading partners using the XOCP business protocol require two delivery channels: one hub and one spoke. For details about configuring delivery channels in hub-and-spoke mode, see Hub-and-Spoke Configuration.

An application for a trading partner communicates, through its delivery channel, with another trading partner's delivery channel. The interactions can be direct, that is, peer-to-peer between trading partners, or they can be indirect, that is, they can be conducted through an intermediary (routing proxy) delivery channel.

See Configuration Models for details about peer-to-peer and hub-and-spoke configurations.

You configure and monitor the components of delivery channels using the B2B Console. A delivery channel includes the following information:

Collaboration Agreements in Peer-to-Peer Configurations

Take the Query Price and Availability conversation described in Defining Conversations and Roles as an example. The delivery channels for the participating trading partners isolate the communication details between them.

The following figure illustrates the components of a collaboration agreement between two trading partners participating directly with each other in a business conversation. The trading partners are configured in a peer-to-peer configuration. In this case, the target trading partner for business messages is the other trading partner in the collaboration agreement.

Figure 1-7 Components of a Collaboration Agreement


 

The preceding figure illustrates how each trading partner's delivery channel and the conversation definition (which defines the roles in the conversation) relate to the collaboration agreement between the trading partners.

Collaboration Agreements in Hub-and-Spoke Configurations

When WebLogic Integration is configured so that trading partners participate in conversations through an intermediary (or routing proxy), collaboration agreements are created between each trading partner and the intermediary. In this case, trading partners identify the intermediary trading partner (that is, the routing proxy delivery channel) as the target for their business messages.

If, for example, the Query Price and Availability conversation between Trading Partner A and Trading Partner B goes through an intermediary trading partner (Intermediary A), two collaboration agreements are created.

The following figure illustrates the collaboration agreements created between Trading Partner A, Intermediary A, and Trading Partner B for a Query Price and Availability conversation in which Intermediary A is an intermediary trading partner.

Figure 1-8 Collaboration Agreements Between Trading Partners in a Hub-and-Spoke Configuration


 

Note the following in the preceding figure:

Managing Conversations

Critical to managing successful relationships between trading partners is the ability to provide robust services to ensure the integrity of business messages while they are being exchanged in various types of trading partner collaborations. WebLogic Integration provides a messaging service and a conversation coordination service, as described in the following sections.

Messaging Service

A flexible messaging service facilitates information transfer between trading partners. The messaging component relies on decoupled, deferred synchronous messaging capabilities to allow communication flexibility.

The messaging service offers the following features and characteristics:

Conversation Coordination Service

Business conversations can be complex and long running—some conversations may last several days. Conversations always have life cycles, which are explicitly demarcated by a beginning and an end. The WebLogic Integration software provides a conversation coordination service.

The conversation coordination service is business protocol-specific. Business protocols define their conversation termination protocols in different ways. In the case of XOCP-based conversations, the conversation coordinator does the following:

Managing Systems and Applications

Workflow management is achieved through a process engine that controls the execution of local business processes and manages the integration of back-end enterprise applications with business processes. See Managing Business Processes for more details.

Except for workflows, B2B integration components are configured and managed primarily through the B2B Console, which works together with a repository service.

This section describes management services that support B2B integration:

The following figure represents the WebLogic Integration services described here and in Managing Conversations.

Figure 1-9 WebLogic Integration B2B Services


 

Repository Service

The repository service stores data into the repository. This data is required by trading partners to engage in business-to-business collaborations, and includes:

In addition, the repository:

For details about the repository and the Bulk Loader, see Working with the Repository and Working with the Bulk Loader in Administering B2B Integration.

Administration Services

The administration services support multiple system management functions, including configuring, administering, and monitoring trading partners, conversations, collaboration agreements, and more.

Through these services, an administrator can create, configure, and manage the B2B integration components of the system. Business developers can set up collaboration agreements and monitor system status. In addition, business partners can use the administration services to start and end trading partner sessions, leave or end conversations, and enable, disable, start, or shut down delivery channels.

WebLogic Integration B2B Console

Primary access to the administration services is through the Web-based B2B Console. All configuration information is stored in the WebLogic Integration repository, which is supported by a database management system. You can configure and monitor the following components:

To facilitate data and business process exchange among trading partners, the import and export functions of the B2B Console allow you to export repository data to an XML file, and import data from an XML file to your WebLogic Integration repository.

You can select the scope of the exported data from the repository such that the XML file you create contains either all the data in the repository, or only data related to one of the following entities: trading partners, conversation definitions, collaboration agreements, business protocol definitions, or logic plug-ins.

See Administering B2B Integration and Online Help for the WebLogic Integration B2B Console for complete details about using the B2B Console.

Bulk Loader

In addition to using the B2B Console to export and import data from and to your WebLogic Integration repository, you can use the Bulk Loader facility (from the command line) to export and import repository data. Like the import and export functions of the B2B Console, the Bulk Loader utility supports export of either all the data in the repository or only a subset of the data to the XML file. See Using the Bulk Loader in Administering B2B Integration for complete details about using the bulk loader.

Java Management Extensions Management Beans

For monitoring only, WebLogic Integration supports user-written applications that use Java Management Extensions (JMX) Management Beans (MBeans) to view data and statistics maintained by the administration services.

Trading partners can use the JMX MBeans through an MBean server (a repository for MBeans), which is included in the administration services package, to send and receive messages to and from the administration services.

See Programming Management Applications for B2B Integration for details about programming management applications.

Logging Service

The B2B integration component of WebLogic Integration provides a logging capability for error and information messages. All log messages are time-stamped, and can be sent to the WebLogic Server log, or to a separate log file. For details, see Writing Messages to the B2B Integration Log.

 

Back to Top Previous Next