|
|
This topic provides an introduction to implementing RosettaNet solutions with WebLogic Integration. It contains the following sections:
This topic focuses on information that is relevant to RosettaNet solutions only. Before you begin, be sure to read the Introduction to learn basic concepts for integrating trading partners using WebLogic Integration. In addition, for a hands-on walkthrough of example RosettaNet solutions, see "Tutorial: Building RosettaNet Solutions," in Tutorials for Trading Partner Integration, which is available at:
A RosettaNet solution is any WebLogic Integration solution that involves exchanging business messages with trading partners using the RosettaNet business protocol. This topic describes RosettaNet and how it is supported in WebLogic Integration. It contains the following sections:
RosettaNet is a business protocol that enables enterprises to conduct business over the Internet. The RosettaNet Consortium ( http://www.rosettanet.org) is an independent, nonprofit consortium of major information technology, electronic component, and semiconductor manufacturing companies working to create and implement industry-wide, open process standards. These processes are designed to standardize the electronic business interfaces used between participating supply chain partners. The RosettaNet Implementation Framework (RNIF) specification (available at http://www.rosettanet.org) is a guideline for applications that implement RosettaNet Partner Interface Processes (PIPs). These PIPs are standardized electronic business processes used between trading partners. For a list of PIPs, see http://www.rosettanet.org.
The following RosettaNet documents are necessary reading if you want to implement your own PIP using the support for RosettaNet provided by WebLogic Integration, and recommended reading if you want to fully understand the sample RosettaNet PIP implementations. These documents are available at http://www.rosettanet.org:
This topic describes supported and unsupported RosettaNet features in this release of WebLogic Integration.
WebLogic Integration supports the following RosettaNet 1.1 and RosettaNet 2.0 features:
This release of WebLogic Integration does not support the following RNIF 2.0 features:
This topic describes RosettaNet concepts that you need to understand before implementing PIPs in WebLogic Integration. It contains the following sections:
The RosettaNet protocol layer provides the ability to send and receive messages by way of the Internet according to the RNIF 1.1 and RNIF 2.0 specifications for transport, message packaging, and security.
When a WebLogic Integration trading partner receives a RosettaNet message, the transport servlet forwards the message to the RosettaNet decoder. The RosettaNet decoder processes the protocol-specific message headers, identifies the trading partner that sent the message, and forwards the RosettaNet message to a JMS queue. When a WebLogic Integration trading partner sends a RosettaNet message, the RosettaNet encoder takes the message from the send-side JMS outbound event queue and forwards it to the transport service.
RosettaNet PIPs define the public processes in which trading partners participate while performing transactions. A PIP defines the roles, choreography, contents of business messages, and other design details for a particular RosettaNet message exchange. For example, PIP 3A2 (Query Price and Availability) defines the process that a Customer trading partner performs with a Product Supplier trading partner to get information about the price and availability of goods that the Customer wants to buy and the Product Supplier wants to sell. Trading partners participating in PIPs need to implement the public process defined by their role in the PIP, and they need to connect their internal systems, as well as their private processes and business processes, to the public process.
RosettaNet business processes follow the RosettaNet design strategy of separating public and private business processes. Public business processes provide for the exchange of business messages between trading partners, while private business processes interact with internal, back-end systems. Public business processes have standardized, highly structured PIP choreographies, while private business processes are highly customized to a trading partner's internal environment. Private processes communicate with public processes via well-defined interfaces, typically based on JMS queues. For more information, see Public and Private Business Processes.
RosettaNet PIPs follow one of the following design patterns:
In WebLogic Integration, RosettaNet PIPs are implemented as public business processes. Because the RosettaNet PIPs follow just a few general design patterns, once you have implemented a single PIP, you can easily implement other PIPs with similar design patterns by copying the implementation and making a few changes (such as changing the business message schema definitions and business process properties).
For more information about RosettaNet design patterns and choreography, see the RosettaNet Implementation Framework Core Specification (version V02.00.01) at http://www.rosettanet.org.
The asynchronous single-action (or one-action) activity design pattern involves a single action (business message) from the sender and a signal (a protocol response, such as an acknowledgement, ack-reject, or error) from the recipient back to the sender:
This design pattern is typical of one-way sends with acknowledgements, such as notifications from one trading partner to another. An example of this design pattern is PIP3B2 (Notify of Advance Shipment), which is described at http://www.rosettanet.org.
The following figure shows an example of how, in WebLogic Integration, public and private business processes might be involved in an asynchronous one-action collaboration.
In this sample scenario, the message flow proceeds along the following path:
| Note: | For outbound and inbound messages, WebLogic Integration automatically handles the packaging of the non-payload portion of RosettaNet business messages (such as the version, content length, headers, and digital signatures), as well as transport-level security and message-level security. |
Alternatively, the private business processes on either end could handle the conversion from the private data format to the appropriate RosettaNet PIP. In addition, private and public business processes might use internal means to indicate whether or not the overall process succeeded.
The asynchronous two-action activity design pattern involves two actions—a single action (business message) from the sender to the recipient, and a single action (business message) from the recipient back to the sender, and their corresponding signals (protocol responses, such as acknowledgements, ack-rejects, or errors) to each other:
This design pattern is typical of two-way, bi-directional communications between trading partners, such as a request / reply activities, that require mutual confirmation. An example of this design pattern in PIP3A4 (Request Purchase Order), which is described at http://www.rosettanet.org.
The following figure shows an example of how, in WebLogic Integration, public and private business processes might be involved in an asynchronous two-action collaboration.
In this sample scenario, the message flow proceeds along the following path:
| Note: | For outbound and inbound messages, WebLogic Integration automatically handles the packaging of the non-payload portion of RosettaNet business messages (such as the version, content length, headers, and digital signatures), as well as transport-level security and message-level security. |
As with the single-action activity design pattern, the private business processes on either end could handle the conversion from the private data format to the appropriate RosettaNet PIP. In addition, private and public business processes might use internal means to indicate whether or not the overall process succeeded.
RosettaNet also specifies synchronous versions of the asynchronous design patterns, in which an immediate response is required. The current release of WebLogic Integration does not support synchronous design patterns.
WebLogic Integration supports sending and receiving RosettaNet messages according to the RosettaNet Implementation Framework (RNIF) 1.1 and 2.0. A business message exchanged via the RosettaNet 1.1 protocol is called a RosettaNet Object (RNO). The business message exchanged via the RosettaNet 2.0 protocol is called a RosettaNet Business Message (RBM).
| Note: | In this document, we refer to both RNOs and RBMs as RosettaNet business messages. |
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. Some elements of RosettaNet messages are common across all RosettaNet messages, while other elements are unique to specific PIPs. To ensure that RosettaNet messages are structured and processed in a consistent manner, each PIP comes with a message guideline and XML document type definition (DTD).
| Note: | WebLogic Integration supports character encoding for sending messages. WebLogic Integration uses UTF-8 character encoding in all RosettaNet messages. |
This section describes the components of RosettaNet business messages.
The following figure shows the components of a RosettaNet business message for RNIF 1.1.
The following table describes the components of an RNO:
The RosettaNet Implementation Framework 2.0 introduced the following notable differences in the composition of a RosettaNet Business Message (RBM):
The following figure shows the components of an RBM:
The following table describes the components of a RBM:
When sending and receiving RosettaNet business messages, WebLogic Integration automatically handles the non-payload portion (version, content length, headers, and digital signatures) of the business message, as well as packaging, transport-level security, and message-level security, so that WebLogic Workshop business processes can focus on Service Content and attachments.
The RosettaNet PIP definitions contain detailed validation rules for messages exchanged in the PIP. These rules are significantly more stringent than the validation expressed within an XML Document Type Definition (DTD). The required validation rules are expressed in XML schema documents (XSD), which are based on the World Wide Web Consortium (W3C) 2000 XML Schema Definitions (XSD) schema.
WebLogic Integration provides message validation services for both RNIF 1.1 and RNIF 2.0 messages. The validation performed depends on the following factors:
validateServiceHeader variable settings. If this is set to true, the service header of all messages sent and received for a template are validated. The type of validation performed is dependent on the validation settings of the business process.To configure these options in the WebLogic Integration Administration Console:
For more information about RosettaNet message validation, see the following documents:
This topic describes WebLogic Workshop business processes that implement RosettaNet PIPs. It contains the following sections:
The specification for each RosettaNet PIP is highly structured. It specifies roles, message choreography, business message structure, and other design details. Implementing a RosettaNet business process requires adherence to the PIP specification for that PIP role. Therefore, when designing business processes for RosettaNet solutions, consider the following guidelines:
For a list of PIPs, see http://www.rosettanet.org.
setProperties method. You can also use XQuery selectors to extract the business IDs and other information from incoming messages.127.0.0.1:7001. For more information, see Default TPM Repository Settings.In WebLogic Integration, initiator business processes use a RosettaNet control to enable 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. The RosettaNet control provides methods for sending business messages, acknowledgements, and errors, and it provides callback methods to handle responses from participants.
For detailed information about using the RosettaNet control in business processes, see the following topics in RosettaNet Control in the Using Integration Controls Guide:
For an introduction to initiator business processes, see Initiator and Participant Business Processes.
In WebLogic Integration, you can easily create a new RosettaNet participant business process using a WebLogic Workshop template (the RosettaNet participant business process file). This template provides a head start for building public participant business processes for RosettaNet message exchanges. 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, as well as standard choreography patterns such as acknowledgements, time-outs, retries, and errors. For information about creating participant business processes, see:
For an introduction to participant business processes, see Initiator and Participant Business Processes.
This topic provides a high-level, end-to-end overview of the tasks involved with implementing a RosettaNet solution. It includes the following topics:
| Note: | This topic describes, in a general way, the tasks that are typically involved in implementing a RosettaNet solution. The process of implementing RosettaNet solutions is iterative, and it can vary in scope and sequence depending on your unique business requirements and environment. |
Before you begin implementing a RosettaNet solution, we recommend that you review the following documents:
Once you have decided to use RosettaNet as the business protocol for your trading partner integration (as described in Phase 1: Plan the Solution), you need to plan the solution by determining certain factors in your implementation:
The Tutorials for Trading Partner Integration provide examples of different RosettaNet solutions. To learn more, see Tutorial: Building RosettaNet Solutions available at http://download.oracle.com/docs/cd/E13214_01/wli/docs81/tptutorial/rosettanet.html
After planning your RosettaNet solution, you build the business processes that implement the PIP(s) according to the RosettaNet PIP specifications. For more information about design-time tools, see Phase 2: Design, Build, and Test the Solution. For conceptual information about RosettaNet business processes, see RosettaNet Business Processes.
The Tutorial: Building RosettaNet Solutions in Tutorials for Trading Partner Integration (available at http://dev2dev.bea.com/code/wli.jsp) provides a detailed walkthrough of the typical tasks that are required to build a RosettaNet solution.
To build a RosettaNet solution, you would typically complete the following steps:
pip and pip-version attributes (and others if needed) in the
@RosettaNetControl.RosettaNetAnnotation, which is described at the following URL:pip-name and pip-version attributes (and others if needed) in the
@com.bea.wli.jpd.RosettaNet which is described at the following URL:
http://download.oracle.com/docs/cd/E13214_01/wli/docs92/wli.javadoc/com/bea/control/RosettaNetControl.RosettaNet.html| Note: | When you first set up connections to RosettaNet trading partners, it is a good idea to run your configuration in Test mode to take advantage of the additional debugging features provided by this mode. To run your Web Logic Integration RosettaNet configurations in Test mode, you specify two annotations in the setProperties method: |
| Note: | -Set global-usage-code to Test. |
| Note: | -Set debug-mode to true. |
| Note: | For more information about the setProperties method, see
RosettaNet Control Interface, available at: http://download.oracle.com/docs/cd/E13214_01/wli/docs92/wli.javadoc/com/bea/control/RosettaNetControl.html |
Once you have built and tested your RosettaNet solution, you deploy the solution in a production environment. For more information about deployment tools, see Phase 3: Deploy the Solution. For detailed information about deploying WebLogic Integration solutions, see Deploying WebLogic Integration Solutions, which is available at the following URL:
To deploy a RosettaNet solution, you would typically complete the following steps:
| Note: | If you have already defined trading partner information in your development environment, you can export this information to an external file, and then import this file into the production environment. For instructions, see "Exporting Management Data" and "Importing Management Data" in Trading Partner Management. |
Once you have deployed your RosettaNet solution, you would typically monitor run-time performance, message volumes, resource utilization, and other factors to ensure optimum operation on your solution. For more information about monitoring tools, see Phase 4: Administer and Tune the Solution.
For instructions on monitoring trading partner integration resources, see the following topics in in Trading Partner Management in Using WebLogic Integration Administration Console Help:
|