Scenario: Purchase Order Mediation
From SWS Challenge Wiki
Contents |
Process and Data Mediation
In this part of the SWS Challenge scenario we focus on interoperability problems of existing systems. The aim is to show how semantic Web technologies can help to overcome the need for manual development of mediation systems.
In our initial scenario description we provide relevant information about the systems involved in two forms: using current Web service description (WSDL) and natural language text annotations. Using current state-of-the-art technologies a programmer has to interpret the information given and to code components that overcome the heterogeneity between the different systems. In the SWS Challenge participants are asked to extend the syntactic descriptions in a way that their algorithms/systems can perform the necessary translation tasks in a semi or fully automatic manner.
For this challenge we focus on the very basic scenario of purchasing goods using a simplified version of the RosettaNet specifications. While the external interfaces must follow the RosettaNet specification, internally Moon uses a propriety legacy system in which data model and message exchange patterns differ from those of RosettaNet. Participants shall basically enable Moon to "talk RosettaNet" and implement the Purchase Order receiving role part of the interaction described in the RosettaNet PIP 3A4.
There are three main components taking part in the process are depicted in Figure 1:
- Company Blue, which is a customer (service requester) ordering products
- Mediator, which is a piece of technology providing automatic or semi-automatic mediation for Moon company
- Legacy System of Moon Company
Note that the Moon legacy systems and the customer Web services (Blue) are provided by the challenge organizers and can not in principle be altered (although their description may be semantically enriched). The sketch of the mediator shall be implemented by the participants.
Scenario Details
Interactions between Blue and Mediator
The incoming and outgoing RosettaNet PIP3A4 message have a different data format then required by the Moon backend system. The messages used in the challenge are the simplified versions of the original specification. RosettaNet Partner Interface Processes (PIPs) define business processes between trading partners. To describe context of messages we provide simplified PIP3A4 as RosettaNet XML Schemas. Within the RosettaNet PIP3A4 specification the information is given using a DTD. We have converted this DTD to XML Schema and removed fields to make the message less complex. Tag names, their meaning and structure have not been changed. The original specification can be found at RosettaNet website
The PIP 3A4 enables a buyer to issue a purchase order and to obtain a quick response from the provider that acknowledges which of the purchase order product line items are accepted, rejected, or pending. Figure 2 presents the flow of messages between Buyer Service (Blue Company) and Seller System (Mediator of Moon Company). The blue box on this diagram represents a Web Service provided by challenge organizers and a yellow box is a Web Service which should be implemented by the participants.
A RosettaNet PIP3A4 business process is initiated by the buyer when it sends the Purchase Order message to the endpoint exposed by a mediator (this one has to be provided by challenge participants). The Purchase Order message must be synchronously confirmed by an Acknowledgement of Receipt message. The original RosettaNet specification allows 24 hours for confirmation of the Purchase Order Action. We changed it and for the sake of practicability, the Purchase Order Confirmation should be issued no later than 5 minutes since Mediator received Purchase Order. The complete list of Message Exchange controls can be found in Table 1.
| Name | Time to Respond to Message | Time to Respond to Message Action | |
|---|---|---|---|
| (1) | Purchase Order Request Action | synchronous - immediately (message 2) | 5 minutes (message 3) |
| (2) | Receipt Acknowledgment | no acknowledgement | no action required |
| (3) | Purchase Order Confirmation Action | synchronous - immediately (message 4) | no action required |
| (4) | Receipt Acknowledgment | no acknowledgement | no action required |
- We define elements of Purchase Order Request in simplified PIP3A4 Purchase Order XML Schema. We provide an example of PO Request Message, which can be used for testing purposes. Challenge participant must build an endpoint to which POR messages can be sent. A Blue Agent has been created allowing to send RosettaNet PIP3A4 Purchase Orders Requests to Mediators and to receive Acknowledgements.
- We define elements of Receipt Acknowledgment in Acknowledgment of Receipt XML Schema document. An example of the Receipt Acknowledgement message which should be sent from Mediator in response to POR to Service Requester is available as Acknowledgement message. The Mediator must send this acknowledgement back to Blue in synchronous mode, once it receives POR (step 1).
- We define elements of Purchase Order Confirmation in simplified PIP3A4 Purchase Order XML Schema documents. We also provide an example of a PO Confirmation Message, which can be used for testing purposes. The endpoint of Blue to which these messages should be sent from the Mediator is available as a Web Service.
- Finally we define elements of Receipt Acknowledgment in Acknowledgment of Receipt XML Schema document. An example of the Receipt Acknowledgement message which should be sent in response to POC to Service Requester is available as Acknowledgement message. This time Blue Company acknowledges Purchase Order Confirmation by sending a message to endpoint registered with the user profile.
RosettaNet messages contains no specific information about product, but only Global unique product identifier. RosettaNet has adopted the Global Trade Identification Number (GTIN). GTIN is the EAN.UCC System identifier for trade items, which encompasses both products and services. GTINs provide the capability to deliver unique identification worldwide. For the purpose of this challenge we provide a list of products, which can be ordered from Moon in Table 2. The rules for assigning GTINs ensure that every variation of an item (product or service) is allocated a single reference number that is globally unique. On the other hand the organizers recognizes that this number remains quite meaningless from the perspective of Semantic Web. Nevertheless we decided not to change existing specification, expecting participants of the challenge to present ideas how to make use with GTIN numbers on the Semantic Web.
| Description | Item | Level | GTIN |
|---|---|---|---|
| (Dell W5001C 50" High Definition Plasma TV | 1 Unit | Consumer | 00614141000012 |
| SANDISK 1 GB Secure Digital Card | 96 Units | Case | 00614141000029 |
| Dell W3706MC 37" High Definition LCD TV | 1 Unit | Consumer | 00614141000777 |
| Dell Laser 1710 | 6 Pack | Consumer | 00614141000883 |
| SYMANTEC CORPORATION Norton Internet Security 2006 | 12 Pack | Consumer | 00614141000999 |
| SUNBELT SOFTWARE Downloadable Counterspy with 1-Year Maintenance | 2x12 Pack | Case | 10614141000996 |
| SOFTWARE ADVANTAGE MCAFEE Wireless Home Network Security V1.0 | 4x12 Pack | Case | 30614141000990 |
| DELL 512 MB High Speed USB 2.0 Memory Key | 8x12 Pack | Case | 50614141000994 |
Interactions between Mediator and Legacy System
In the RosettaNet standard a purchase order is sent using just a single message, however, in order for Moon to be able to process an order, several steps have to be made. The overall ordering process of Legacy System is more complex that the one defined by RosettaNet protocol and the Mediator must take care of this. This process has been presented in Figure 3.
First, the Mediator communicates with the Legacy Customer Relationship Management System to obtain relevant customer details. As a next step it requests to create a new order by communicating with another endpoint of Legacy Order Management System. The same endpoint is used to submit individual line items. Once all the line items have been submitted, the order has to be closed. Challenge participants must provide an endpoint for their mediators to which the response back from Legacy System can be sent. The complete list of Message Exchange controls can be found in Table 3.
| Name | Time to Respond to Message | Time to Respond to Message Action | |
|---|---|---|---|
| (1) | Search Customer Action | synchronous - immediately (message 2) | no action required |
| (2) | Receipt Customer Details | no acknowledgement | no action required |
| (3) | Create New Order Action | synchronous - immediately (message 4) | no action required |
| (4) | Acknowledgment | no acknowledgement | no action required |
| (5) | Add Line Item Action | synchronous - immediately (message 6) | no time constraints (message 9) |
| (6) | Acknowledgment | no acknowledgement | no action required |
| (7) | Close Line Item Action | synchronous - immediately (message 8) | no action required |
| (8) | Acknowledgment | no acknowledgement | no action required |
| (9) | Order Confirmation Action | synchronous - immediately (message 10) | no action required |
| (10) | Acknowledgment | no acknowledgement | no action required |
- Before an order can be created in the Legacy System of Moon, it needs to be verified that the RosettaNet message is issued from a registered customer. Moons Customer Relationship Management System allows to search for customers using their business identifier. Moon allows only registered customers to order electronically. Schema for messages for Moon CRM system has been defined in Complete Moon CRM Schema. A sample Search Customer message has been provided.
- The result of Search Customer Action is a message containing customer details. Schema of this message is part of Complete Moon CRM Schema. A sample Search Customer Response message has been provided.
- Once the customer has been identified, the Mediator must contact Order Management System to create an order. Schema for messages for Moon Purchase Order system has been defined in Complete Moon OM schema. A sample Create New Order message has been provided. Additionally authToken must be included in the message. Challenge participants obtain this authToken while registering with a system for a first time.
- The response for Create New Order message is Create New Order Response. Both XML Schema and a sample Create New Order Response message have been provided.
- After the order has been created, line items can be submitted individually. The incoming RosettaNet message needs to be split into several parts if it contains more than one product item and an internal customer identifier has to be added. XML schema for Add Line Item message is part of Complete Moon CRM Schema. A sample Add Line Item message has been provided.
- Line items are confirmed by Acknowledgements. An example of Acknowledgement message has been provided.
- Once all line items have been submitted, the order must be closed. Also for this step Order Management System must be used. Close Order message must conform with Complete Moon CRM Schema. A sample Close Order message has been provided.
- Closing of Order is confirmed by Close Order Response. An example of Close Order Response message has been provided.
- The last phase is initiated by Legacy System, which confirms individually every line item, which was previously submitted to CRM system. Confirmation message must conform with Complete Moon Client Schema. The sample message LineItem Confirmation has been provided. Out-in operation is defined in Order Management WSDL. The endpoint this message is sent to is specified using the test bed interface within the registration page.
- Mediator must Acknowledge Order Confirmation Object. Out-in operation is defined in Order Management WSDL. Any message can be sent to make this acknowledgement (but there must be any).
Hidden Assumptions
- Purchase Order Request Action should be confirmed in 5 minutes. If before 5 minute time frame, the mediator does not have all the single line items confirmed by a legacy system, it can still issue a confirmation with a status Pending
- If no ReceiptAcknowledgement is sent after Purchase Order Request, the Blue assumes failure and may reattempt to send it one more time. If it receives Purchase Order Confirmation after it, it will not confirm it, so the whole process fails.
- Mediator cannot submit a new line item if order was not created. Otherwise an error is returned.
- Mediator cannot submit a new line item, after order was closed. Otherwise an error is returned.
- Although the search for a customer in CRM system gives a Mediator already an information such as for example AddressInfo or ContactInfo, still the information that is provided in particular RosettaNet messages should be used instead.
Quick Links
Web Services
XML Schemas
Sample Messages
