For transactions that do not arrive in a known order:
Define a field or datalink object for the data area that is the key.
Use the dbInsert filter to copy the data to the appropriate collection file. The production object then sends the transaction off to a null destination or to any delivery AIM that may need just that transaction’s data.
Because the acquisition AIMs do not send the transactions in a predictable order, each production object needs to contain the rules for gathering all the data from the collection files. In other words, each production object must make all of the dbSelect calls needed to gather all of the necessary data from the collection files.
To find out which files hold the data you want, call dbDiskList with the appropriate search field. Remember to make each call to the dbSelect filter from within an empty rule component object.
Remember, the dbSelect filter does
not perform concatenation. If there is already data present in the
current message area, this filter overwrites it.
Before each dbSelect call, use the dbExist qualification function in the qualification object of the rule component that makes the dbSelect call. If the dbExist function fails, then some of the transactions have not arrived yet and the production object should stop trying to gather the data from the collection files.
Send the output transaction to the delivery AIM that routes to the application endpoint that required these pieces of data in one transaction. Optionally, use recycling to send the output transaction back through transaction production for further processing before passing it on to the delivery AIM.
Each production object must contain either all the logic necessary for processing and sending the completed transaction to the delivery AIM, or the production objects must all recycle to another production object that contains that logic.
If desired, use the dbDelete filter to delete the entries from the collection files.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
