1 Architecture

This integration takes advantage of the Communication Extension (COMMEXT) framework that already exists in the Oracle Retail Point-of-Service code base. For this specific implementation, the focus is on adding the foundational pieces necessary to integrate with Siebel using its web service interfaces. For the most part, additions are Siebel-specific. A general-purpose WebServiceConnector allows any route to connect to an external web service without falling into specific implementation for that specific service.

Figure 1-1 Point-of-Service to Siebel Context Model

This integration supports basic use cases: Sales, Returns, and Order Inquiry. The following describes these use cases:

• An associate is asked to enter items from an external order system into a customer's transaction. This flow requires that the system contact the external order system to look up the order and bring that order back into the transaction.

• An associate is asked to return items that were originally part of an external order. This flow requires the system to contact the external order system to create a return order.

• An associate is asked to review an order placed in the external order system. This flow operates much like the flow in use case 1.

• The Point-of-Service system must interact with the external order system to find orders and make updates to those orders. This interaction will always be initiated from the Point-of-Service system.

Operational Flows

This section describes operational flows.

External Order Query

Sales associates need the ability to look up orders from their Point-of-Service terminals. They have the ability to enter search criteria and have the system return to them any matches to the criteria. If the remote order system is unavailable, the system displays an error message to inform the associate.

Figure 1-2 External Order Query

External Order Update

Once a sales associate tenders an order, the system updates the remote system with the tender information and moves the order through the completion process. It is imperative that the updated order get sent to the remote system, so the Point-of-Service system provides for guaranteed delivery.

Figure 1-3 External Order Update

System Architecture View

This section details the system architecture view.

System Context Model

The Point-of-Service system has two touch-points with the Siebel system, one for queries and the other for updates. The touch-points access each other through the web service interfaces that Siebel already exposes. The Siebel system is the system of record for orders and order item prices. The Point-of-Service system is responsible for funding transactions containing orders, pricing items not involved in an order, and taxing the transaction. The systems exchange SOAP messages as defined by the Siebel web service interface. These messages will contain transaction information along with any order information necessary for Siebel to move the order through the completion process. These messages are in real-time for the queries and near-real-time for the updates.

Figure 1-4 System Context Model

System Solution Flow: External Order Query

When an associate queries an external order, the Point-of-Service system uses components of the COMMEXT framework to facilitate the web service communications with Siebel. The framework is responsible for creating the appropriate messages and initiating the send. The Siebel integration layer takes this request and ensures the request is properly authorized by verifying the request has appropriate credentials associated with it. Once authorized, Siebel processes the request and returns the appropriate response using the integration layer. The COMMEXT layer is used by the Point-of-Service system to turn the response into the appropriate Point-of-Service objects placed into a Point-of-Service transaction.

Figure 1-5 Order Query Solution Flow

System Solution Flow: External Order Update

When an associate finalizes a transaction containing an external order, the Point-of-Service system uses components of the existing COMMEXT framework to facilitate the web service communications with Siebel. The framework is responsible for creating the appropriate update messages and initiating the send. If the remote system is not responding, the COMMEXT layer is responsible for ensuring guaranteed delivery. The integration layer takes this request and ensures the request is properly authorized by verifying the request has appropriate credentials associated with it. Once authorized, Siebel processes the request and returns the appropriate response using the integration layer. Again, the COMMEXT layer is used by the Point-of-Service system to acknowledge the request was properly handled.

Figure 1-6 Order Update Solution Flow

Architecture Impacts

This section identifies architecture impacts.

Restarting

This solution does not involve any scheduled processes that require restart. However, for guaranteed delivery, the queuing functionality of the COMMEXT framework is used. If the Point-of-Service system is shut down with messages queued for delivery, those messages are addressed when the Point-of-Service system is restarted. The threads on those queues are initiated, and any messages in-queue are handled. The interval at which the queue sends these messages is configurable to prevent flooding Siebel with messages that have been queued for an extended period of time.

Operator Alerting

There are no alerts to the terminal operator that a message has failed to be sent or that the remote system is unreachable. Any failures are logged.