Integration Server 10.3 | Publish-Subscribe Developer’s Guide | Understanding Join Conditions | Subscribe Path for Documents that Satisfy a Join Condition | The Subscribe Path for Documents that Satisfy an All (AND) Join Condition
 
The Subscribe Path for Documents that Satisfy an All (AND) Join Condition
When Integration Server receives a document that satisfies an All (AND) join condition, it stores the document and then waits for the remaining documents specified in the join condition. Integration Server invokes the trigger service if each of the following occurs:
*The trigger receives an instance of each document specified in the join condition.
*The documents have the same activation ID.
*The documents arrive within the specified join time-out period.
The following diagram illustrates how Integration Server receives and processes documents for All (AND) join conditions. In the following example, trigger X contains an All (AND) join condition that specifies that documentA and documentB must be received for the trigger service to execute.
Subscribe path for documents that satisfy an All (AND) join condition
Step
Description
1
Integration Server requests documents for a trigger from the messaging provider.
2
Integration Server receives documents for the trigger, including documentA and documentB. Both documentA and documentB have the same activation ID.
3
Integration Server places documentA and documentB in the trigger’s queue on Integration Server.
4
Integration Server pulls documentA from the trigger queue and evaluates the document against the conditions in the trigger. Integration Server determines that documentA partially satisfies an All (AND) join condition. Integration Server moves documentA from the trigger queue to the join manager.
Integration Server starts the join time-out period.
Note:
If exactly-once processing is configured for the trigger, Integration Server first determines whether the document is a copy of one already processed by the trigger. Integration Server continues processing the document only if the document is new.
5
The join manager saves documentA to the ISInternal database. Integration Server assigns documentA a status of “pending.” Integration Server returns an acknowledgement for the document to the messaging provider.
6
Integration Server pulls documentB from the trigger queue and evaluates the document against the conditions in the trigger. Integration Server determines that documentB partially satisfies an All (AND) join condition. Integration Server sends documentB from the trigger queue to the join manager.
7
The join manager determines that documentB has the same activation ID as documentA. Because the join time-out period has not elapsed, the All (AND) join condition is completed. The join manager delivers a join document containing documentA and documentB to the trigger service specified in the condition.
8
Integration Server executes the trigger service.
9
After the trigger service executes to completion (success or error), one of the following occurs:
*If the service executes successfully and documentB is guaranteed, Integration Server acknowledges receipt of documentB to the messaging provider. Integration Server then removes the copy of the documentA from the ISInternal database and removes the copy of documentB from the trigger queue.
*If a service exception occurs, the service ends in error and Integration Server rejects the join document. If documentB is guaranteed, Integration Server acknowledges receipt of documentB to the messaging provider. Integration Server then removes the copy of the documentA from the ISInternal database and removes the copy of documentB from the trigger queue. Integration Server sends an error notification document to the publisher.
*If the trigger service catches a transient error, wraps it, and re-throws it as an ISRuntimeException, then Integration Server waits for the length of the retry interval and re-executes the service using the original document as input. If Integration Server reaches the maximum number of retries and the trigger service still fails because of a transient error, Integration Server treats the last failure as a service error. For more information about retrying a trigger service, see webMethods Service Development Help.
Note:
A transient error is an error that arises from a condition that might correct itself later, such as a network issue or an inability to connect to a database.
Notes:
*If the join time-out period elapses before the other documents specified in the join condition (in this case, documentB) arrive, the ISInternal database drops documentA.
*If documentB had a different activation ID, the join manager would move documentB to the ISInternal database, where it would wait for a documentA with a matching activation ID.
*If documentB arrived after the join time-out period started by the receipt of documentA had elapsed, documentB would not complete the join condition. The ISInternal database would have already discarded documentA when the join time-out period elapsed. The join manager would send documentB to the ISInternal database and wait for another documentA with the same activation ID. Integration Server would restart the join time-out period.
*Integration Server returns acknowledgements for guaranteed documents only.
*If a transient error occurs during document retrieval or storage, the audit subsystem sends the document to the logging database and assigns it a status of FAILED. You can use webMethods Monitor to find and resubmit documents with a FAILED status if the documents were published locally or received from Broker. For more information about using webMethods Monitor, see the webMethods Monitor documentation.
*If a trigger service generates audit data on error and includes a copy of the input pipeline in the service log, you can use webMethods Monitor to re-invoke the trigger service at a later time. For more information about configuring services to generate audit data, see webMethods Service Development Help.
*You can configure a trigger to suspend and retry at a later time if retry failure occurs. Retry failure occurs when Integration Server makes the maximum number of retry attempts and the trigger service still fails because of an ISRuntimeException. For more information about handling retry failure, see webMethods Service Development Help.