| Oracle® Retail Integration Bus Implementation Guide Release 13.0 |
|
 Previous |
 Next |
Each PL/SQL based application uses a Message Family Manager (MFM) specific API for publishing all messages within a specific message family. This API is the interface to a stored procedure package and wrappers the staging table and additional business logic surrounding the message publication.
The RIB Publishing Adapter polls the API by calling a routine in the MFM called "GETNXT()". The MFM "GETNXT()" PL/SQL stored procedure may contain simple or complex logic that is specific to the message types published. For example, a simple Create Vendor message may involve merely selecting and then deleting a single record from the vendor staging table. On the other hand, a Create Purchase Order message requires fairly complex logic to create because of the business process dependencies. Many changes may be made to a PO before it is approved.
The RIB Subscribing Adapter invokes the API by calling a routine in the MFM called CONSUME().
The RIB Pub Hospital Retry Adapter invokes the API by calling a routine in the MFM called PUB_RETRY().
The main facet of this API involves the use of Oracle CLOBs (Character Large Object Binaries) as the means to pass information to and from an Oracle stored procedure. The stored procedure is responsible for parsing or building the message payload.
There are only a few of this type remaining in RMS.
API's using CLOBs have internal triggers that are fired when a specific database table is modified. The trigger retrieves all of pertinent information to create a specific type of message (XML payload) and inserts it into a staging table using an application specific Message Family Manager (MFM) API. The payload is contained in an Oracle Character Large Object Binary (CLOB). The staging table that holds the payload data must also maintain the following:
The order that messages are created
The CLOB containing the "payload" XML
Any routing or filtering key values
The message type associated with the business event that created the message. The message type is specific to the message family and a single business event may produce multiple messages of differing types within different families.
These application interfaces use Oracle Objects to pass information to and from the stored procedure. Each RIB Object corresponds to the XSD that defines the RIB Message payloads for that message family. This is the predominant type of PL/SQL API used in Oracle Retail integration via the RIB.
When a message is ready for publication, the Message Family Manager GETNXT() Stored Procedure examines its staging tables and creates the appropriate RIB Object for publication. In many cases, these staging tables contain columns that are themselves declared a specific type of RIB Object. Once the complete RIB Object is ready, the GETNXT() Stored Procedure returns this(RIB Object) to the calling RIB Adapter, which then converts the RIB Object into an equivalent XML string.
When a subscribing adapter gets a message from the JMS topic it constructs the Oracle Object by parsing the incoming payload xml. The newly created Oracle Object is passed in to the CONSUME() stored procedure to process the message.
PL/SQL stored procedures use three tables to refine their behavior: RIB_SETTINGS and RIB_TYPE_SETTINGS and RIB_OPTIONS. Not all applications use these.
The RIB_SETTINGS table defines, on a per message family basis:
The number of channels to use when publishing (see RIB Operations Guide - Multi-channel ).
The maximum number of details to publish within a create, update, or delete message. Oracle Retail applications typically do not have a limit to the number of details a specific business object can have. Hence, a purchase order may be created containing tens of thousands of detail lines - each line a specific item/location combination. A single PO Create message containing 30,000 or so lines require a vast amount of resident memory to parse. This column limits the PO Create and subsequent PO Detail Add messages to a set number of details.
The RIB_TYPE_SETTINGS table is used internally by the application.
The RIB_OPTIONS table is used by the CLOB API's for the creation of XML.
These interfaces to the RIB are via Message Driven Bean (MDB) for subscribers and by Stateless Session Bean (SLSB) to publish messages to the JMS. This architecture uses Payload Java Beans to communicate event information from the RIB code to the application messaging processing logic.
The internal architecture of RIB is very similar between Oracle Retail PL/SQL applications and Oracle Retail Java EE applications. The only significant difference is in the publishing adapter types. For PL/SQL Retail applications RIB keeps on polling the stored procedure every few seconds to find out if there is any work. When the stored procedure returns some data (that is, when there is some work), RIB goes and does the work. In Oracle Retail Java EE applications RIB does not do any polling. The roles are reversed where the Oracle Retail application requests RIB to publish a message. Thus, there are two types of publishing adapters in RIB depending on the connecting Oracle Retail application type. Java EE application uses request-driven publishers and PL/SQL application uses timer-driven publishers.
