| Oracle® Retail POS Suite Implementation Guide, Volume 4 – Point-of-Service External Order Release 14.1 E54477-01 |
|
 Previous |
 Next |
| Oracle® Retail POS Suite Implementation Guide, Volume 4 – Point-of-Service External Order Release 14.1 E54477-01 |
|
Previous |
Next |
The Communication Extension framework (COMMEXT) provides a useful structure for separation of concerns between connectivity to a protocol and the formatting of domain object to message content. This framework was used to provide connectivity to Siebel for this integration.
The component model shown in Figure 2-1 depicts the Point-of-Service Communication Extension Framework. Data structure manipulation or transformation, and handling connectivity to a service, are divided between the Formatter and the Connector. More detailed descriptions of each of the components shown in the following model are contained in this section.
This is the integration point between the Point-of-Service tier and the communication framework. This abstract class creates and configures the MessageDispatcher based on the configuration script. Access to the MessageDispatcher is through the sendMessage method. A BaseTechnician class provides integration with the Point-of-Service tier for utilizing the framework within a technician role. This class was omitted from Figure 2-1 for clarity.
Extension of the BaseManager class provides the application-level API for accessing the service. The ServiceManager prepares messages and performs post-response processing of responses from the external service. The ServiceTechnician is not shown in Figure 2-1, but provides the application level APIs in a similar manner to the ServiceManager class.
MessageDispatcher is the core of the communication framework. Its primary function is to dispatch messages to mapped routers. Also, MessageDispatcher performs administrative and control operations on the associated connectors.
MessageRouter coordinates the processing of a message using the associated routing rule and the RouterConnectors. The MessageRouter attempts to send the message to a RouterConnector. The results of the attempt are sent to the routing rule, and a control action is returned to the MessageRouter. The MessageRouter responds to the control action and can exit as a completed request, throw an exception, retry the current RouterConnector, or try an alternate RouterConnector to process the request.
RouterConnector provides an association between a message type, connector, and formatter. This decouples the formatting of the message from the chosen connector.
ConnectorIfc handles the communication between the application and the external service. It is responsible for locating the service, establishing a connection, and interacting with the service using appropriate protocols.
FormatterIfc translates the raw data from the message into the format expected by the external service. It also translates the response from the remote service into the format expected by the application.
RoutingRuleIfc determines the action to be taken by the MessageRouter after sending a message to a connector. The available actions are continue processing, retry the current formatter/connector, successfully completed and return to caller, or throw an exception.
MessageIfc defines the interface for a container with the message type and the raw data for the message.
MessageResponseIfc defines an interface for a container with the translated response to the request.
The core functionality of the communication framework is provided by the MessageDispatcher and MessageRouter. The BaseManager delegates the message call to the MessageDispatcher, which in turn delegates the message handling to a specific MessageRouter. See Figure 2-2 for a view of the MessageRouter and related components.
The MessageRouter has a collection of potential routes to send the message. Having multiple routings available provides options for distributing the message to multiple connectors or alternative sources in case of a failure. Specification of the mapping between message types with routing rules, formatters, and connectors is done with a configuration file supported by the BaseManager class. Figure 2-3 shows the sequence diagram for how messages are processed within the MessageRouter.
The Connector is a base class implementation of the ConnectorIfc. It is recommended that new ConnectorIfc implementations extend Connector or a subclass of Connector. The Connector class provides basic JMX instrumentation for connector operations and coordinates the administrative operations. The extending class must provide an implementation of three abstract protected methods.
The Chained Connectors provide opportunities to link connectors head-to-tail. The framework uses this structure to provide store-and-forward operations implemented in QueuedConnector. Other possible uses might be for encryption/decryption or statistics collection.
The QueuedConnector class provides an implementation of ChainedConnectorIfc utilizing a local file to queue requests. The requests are forwarded to the associated ConnectorIfc chainedConnector and removed from the queue if the sendMessage() on the downstream connector is successful.
The ForwardOnFailConnector is a component to provide request/response operations if successful, with the option to forward the message to an alternate routing on failure.
The TechnicianConnector provides a connector implementation to communicate with Point-of-Service technicians. The message data must be translated by the formatter into an appropriate ValetIfc implementation for use with the associated technician.
The WebServiceConnector represents connector implementations for interacting with web services exposed by target systems.
The following are COMMEXT patterns that support interaction behavior.
Figure 2-5 shows the COMMEXT pattern for providing Store-and-Forward message processing.
Figure 2-5 depicts how the framework is configured to provide Store-and-Forward message processing. Store-and-Forward message handling uses a QueuedConnector instance, which is a subtype of a ChainedConnector to provide the buffering for the message. The Client sends a message that is delegated to the MessageRouter by the MessageDispatcher. The MessageRouter uses the RouterConnector to link a formatter and connector. The Formatter class shown is an implementation of the FormatterIfc. After the message is formatted, it is sent to the QueuedConnector where it is persisted and the submittal of the message from the client ends. A background thread in the QueuedConnector checks to see if messages are present in the queue. If a message is available, the message is read from the head of the queue and passed to the chained connector. If the message is successfully handled by the associated connector, the message is removed from the head of the queue. If the message is not successfully processed by the downstream connector, the message is left on the queue for a later retry.
Figure 2-6 depicts how the framework is configured to provide a request/response operation on successful processing, with store-and-forward handling of the message when immediate processing is not successful. The client will be aware that the message has failed on the immediate attempt.
The client sends a message that the MessageDispatcher directs to the appropriate MessageRouter. The MessageRouter delegates the original message to the RouterConnector to apply the necessary formatting and connector, in this case the ForwardOnFailConnector. The ForwardOnFailConnector first sends the message to the Connector. If the message processing succeeds, the process is complete and control returns to the client. If the message processing in the Connector fails, the ForwardOnFailConnector catches the exception, repackages the payload into the a new message, fwdMsg, and uses the message forwarding capabilities of the COMMEXT framework to send the new message to the MessageDispatcher. Handling of the fwdMsg is the same as the Store-and-Forward pattern described in the previous section.
