How to Publish Documents When the Broker Is Not Available?

Step 1: A publishing service on the Integration Server sends a document to the dispatcher (or an adapter notification publishes a document when an event occurs on the resource the adapter monitors).Before the Integration Server sends the document to the dispatcher, it validates the document against its publishable document type. If the document is not valid, the service returns an exception specifying the validation error.

Step 2: The dispatcher detects that the Broker is not available and does one of the followings depending on the storage type of the document:

* If the document is guaranteed, the dispatcher routes the document to the outbound document store on disk.

* If the document is volatile, the dispatcher discards the document and the publishing service throws an exception. The Integration Server executes the next step in the publishing service.

Step 3: When the Integration Server re-establishes a connection to the Broker, the Integration Server obtains a single connection from the connection pool

Step 4: The Integration Server automatically sends the documents from the outbound document store to the Broker. To empty the outbound document store more

rapidly, the Integration Server sends the documents in batches instead of one at a time.

Note: The Integration Server uses a single connection to empty the outbound document store to preserve publication order.

Step 5: The Broker examines the storage type for the document, determines that it is guaranteed and stores the document in memory and on disk.

Step 6: The Broker routes the document to subscribers by doing one of the following:

* If the document was published (broadcast), the Broker identifies subscribers and places a copy of the document in the client queue for each subscriber.

* If the document was delivered, the Broker places the document in the queue for the client specified in the delivery request.

* If there are no subscribers for the document, the Broker returns an acknowledgement to the publisher and then discards the document. A document remains in the queue on the Broker until the subscribing client picks it up. If the time-to-live for the document elapses, the Broker discards the document.

Step 7: The Broker returns an acknowledgement to the Integration Server to indicate successful receipt and storage of the guaranteed document. The Integration Server removes the document from the outbound document store.

Notes:

i) After the connection to the Broker is re-established, the Integration Server sends all newly published documents (guaranteed and volatile) to the outbound document store until the outbound store has been emptied. This allows the Integration Server to maintain publication order. After the Integration Server empties the outbound document store, the Integration Server resumes publishing documents directly to the Broker.

ii) If the Integration Server makes 4 attempts to transmit a document from the outbound document store to the Broker and all attempts fail, the audit subsystem logs the document and assigns it a status of STATUS_TOO_MANY_TRIES.

iii) If a transient error occurs while the Integration Server publishes a document, the audit subsystem logs the document and assigns it a status of FAILED.