Is there a way to hold documents in the Broker without firing the handler service for the trigger, until a certain number of documents (of the same kind) have reached it? A traditional join will not help us, since we cannot differentiate between the documents on a static basis. We are trying to do this to group about 1000 documents of the same kind into one IDoc, instead of creating one for each document.
Any help is appreciated.
If the desired functionality is to group a bunch of documents, (and not a specific number of documents), you could keep the trigger in a suspended state and use a scheduled IS service that would reactivate the trigger every <time> minutes (services in pub.trigger can suspend/enable triggers). The handling service can then retrieve documents and append to an IDoc. The tricky part would be to share the in-process IDoc among successive invocations of the handling service, and to signal end of queue to publish the IDoc to SAP.
Alternatively, you could use a scheduled java service that uses the Broker API to fetch documents from the queue (you could eliminate the trigger entirely and just use a broker subscriber client). Here, you can fetch as many documents as you want in each run, hold the IDoc in memory in the same service, and know exactly when to send the IDoc.
Hope that helps,
Did you find a solution to this problem? How can you hold an IDoc in memory between invocations of subscribing service? How do you know when to stop and process the IDoc? I am curious to know.
You can have a static java collection object (vector/arraylist) and keep appending to that list until the end of queue. If there is a specific attribute (for eg customer id), on the basis of which you are grouping the documents, you can use a static java Hashtable (or HashMap) with the attribute as the key, and a vector of IDocs as the value.
Regarding when to stop, the answer would be application specific - the grouping service would need to know the overall count that it needs to expect, or it would need to check a flag that signals the end of incoming docs.
For all it may still be worth - I heard this was possible with JMS queues in wM 7.1.1