| Oracle® Retail Integration Cloud Service Hospital Administration Guide Release 22.1.201.0 F56362-01 |
|
 Previous |
 Next |
| Oracle® Retail Integration Cloud Service Hospital Administration Guide Release 22.1.201.0 F56362-01 |
|
Previous |
Next |
Oracle Retail Integration Bus Hospital Administration or RIB Hospital Administration (RIHA) is a tool to manage RIB messages in the RIB hospital error tables.
Using RIHA you can search for hospital records, stop a message from being retried, retry a message for which maximum system-set retries have been tried, and delete a message from the tables. You can insert new records into hospital tables. You can also update existing hospital records and message payloads.
RIHA should be installed only after core RIB components have been installed and verified.
Using RIHA is the recommended way to perform all RIB Hospital error table operations.
The RIB Hospital is a collective term for a set of Java Classes and database tables whose purpose is to provide a mechanism to handle system and business-related errors while meeting the fundamental RIB requirements:
Guaranteed once-and-only-once successful delivery.
Preservation of publication sequence (even in case of failures).
When a message is processed, the adapter checks to see whether the RIB Hospital contains any messages associated with the same businessObjectId as the current message. If so, then the adapter places the current message in the hospital as well. This is to ensure messages are always processed in the proper sequence. If proper sequencing is not maintained, then the subscribing application's data may become corrupted.
If an error occurs during message processing, the subscribing adapter notes this internally and rolls back all work associated with the message. When the message is re-processed (since it is yet to be processed successfully), the adapter now recognizes this message is problematic and checks it into the hospital.
For Publication, there are some RMS publishers that return an 'H' status to denote a problem creating a new message for a specific business object. This status may be due to database locks being held by on-line users of an Oracle Forms application or it could also be due to some data incompatibility found in the GETNXT() procedure. Whenever a publisher recognizes that a message for a business object cannot be published due to one of these conditions, the message must go into the RIB Hospital.
After a message is checked into the RIB Hospital, a retry adapter extracts the message from the hospital and tries to re-publish it to the integration bus.
The RIB Hospital dependency check logic assumes that each message family has a single, unique businessObjectId for all business object entities its messages are associated with. This businessObjectId must be the same for the same business entity across all message types within the message family. If any message for a specific business entity is placed into the RIB Hospital, then the RIB Hospital dependency check logic automatically inserts any subsequent messages for the same business object. This is to preserve the message sequence and guarantees messages are processed exactly once. Otherwise, multiple update messages for a business object may be processed in an incorrect order, creating incompatibilities between applications.
If the businessObjectId is not set, then there is no dependency check. Not all message families set the businessObjectId or it is not set on all message types. See the Oracle Retail application documentation (for example, "Message Publication and Subscription Designs" in the Oracle Retail Merchandising Operations Guide Volume 2).
In the event of failure during message subscription, the error is flagged within the RIB Hospital software, resulting in rollback of the work done in the retail application. The adapter returns a failure so that the database transaction is rolled back as well, and the message is kept on the Integration Bus topic. This is because subscribing adapters are executed within the context of a distributed transaction, using the XA two-phase commit protocol. This transaction is controlled by the Java EE Application Server. Immediately after the roll back, JMS re-delivers the message back to the subscribing adapter and, this time, the RIB Hospital software detects the previously flagged message and inserts the message in to the RIB Hospital tables. The message is then removed from the JMS topic.
When the initial failure occurs while processing the message, the error is flagged within the RIB Hospital software, the adapter returns a failure so that the database transaction is rolled back, and the message is kept on the integration bus topic.
|
Note: The XA interface is a standard protocol between a transaction manager and a database or resource manager. Both the JMS topic connection and the database connection must support the XA protocol.For more information regarding the XA standard, see the URL |
The RIB Hospital tables are:
RIB_MESSAGE - contains the message payload, all single-field envelope information, and a concatenated string made from <id> tags. It also contains a unique hospital ID identifying this record within the hospital.
RIB_MESSAGE_FAILURE - contains all failure information for each time the message was processed.
RIB_MESSAGE_ROUTING_INFO - contains all of the routing element information found in the message envelope.
RIB_MESSAGE_HOSPITAL_REF - contains all of the hospital reference information found in the message envelope.
A database sequence, RIB_MESSAGE_SEQ, is used to maintain a unique message number associated with each message placed into the RIB Hospital.
These tables will have been created during the database portion of the Oracle Retail application installation (for example, RWMS, SIM, RPM, AIP, RFM, OMS, or RMS).
The RIB Hospital tables are internal system tables that maintain the RIB runtime state of the system. The entries in these tables must not be manipulated by non-RIB tools when the RIB is running.
After a message is inserted into the RIB Hospital, the hospital retry adapter is used to re-post the message to the JMS in order to retry its processing. The assumption is that the error is a transitory one; records locked or there is an external dependency that has not been met. The number of times a message is retried is configurable.
The hospital retry is responsible for maintaining state information for hospital records or what has happened to the record or message information. Each time the message is reprocessed, a record is kept of the event along with the results. The design is to provide a means to halt processing for messages that cause errors while allowing continued processing for the good messages.
One element of this information is whether the message has been queued to the JMS topic for re-try processing. So, manually deleting messages from the hospital database using SQL directly may produce severe processing problems. Also, deleting messages directly from the JMS provider may result in a message that is never retried again, as the logic in the retry assumes the message is queued within the JMS.
There are three kinds of hospital retry adapters:
Sub Retry Adapter
JMS Retry Adapter
Pub Retry Adapter
All subscriber-side retrying of messages is handled by the Sub Retry Adapter. The Sub Retry Adapter looks at all messages with reason code SUB, then filters and identifies the messages that are ready to be reprocessed, keeping message ordering in mind.
Oracle Retail applications are unaware that the integrations of business data are happening through a JMS server. RIB abstracts the fact it is using a JMS server from the retail applications. When the JMS server is down or RIB has some problem publishing to the JMS server, RIB will not rollback the transaction as long as it is a recoverable problem. In such a situation, all messages are inserted to the RIB Hospital with a reason code of JMS and publication continues on. The JMS Retry Adapter retries all messages with reason code of JMS at a later time.
All messages with reason code of PUB are retried by the Pub Retry Adapter. Merchandising is the only retail application that needs the Pub Retry Adapter.
When the message first comes through the subscriber, if there is no businessObjectId, then no dependency check is performed. If the message cannot be processed, it is then inserted into the hospital with an attempt_count = 1.
A message that comes through the subscriber, that has a businessObjectId, a dependency check is performed. If there is no dependency and the message cannot be processed, it is then inserted into the hospital with an attempt_count = 1.
A message that comes through the subscriber that does match the ID and family of another message in the hospital is known to be dependent, so it goes to the hospital immediately, with an attempt_count = 0.
Exception to this rib-tafr app, in case of rib-tafr attempt_count is 1, even if the message is inserted into the hospital as a dependent message because tafr adapters work with two topics and message would already be subscribed once by the tafr, therefore it always has attempt_count=1.
JMSXDeliveryCount is a message property set by AQ JMS. This property is checked to determine whether the message is being redelivered by the JMS. If the count MAX_REDELIVERY_THRESHOLD (set to 2) is reached, the RIB subscribers assume that the message is being re-delivered; the message will be determined to be a poison message. In such scenarios, the message is written to the file system (at the same location where application log files are written), and the adapter is shut down. An administrator must decide how this message will be handled.
