Hi,

In One of my integration we got ‘n’ instance of a same publishable document that gets published for a single request, At the subscriber end we need to wait for all the ‘n’ documents that gets published.

Where we have the the number of documents that will be published is a field in our publishable document.

So that the trigger subscribes all the ‘n’ documents that are published and aggregates them into a single document and then continues the process.

Please let me know how this could be achieved.

Thank you,
Gokul.

is it possible to add the ‘n’ instances in a single document list and publish it just once ?
i am not able to understand the need to publish ‘n’ different documents; subscribing to just one consolidated document would be a lot simpler.

Cant this aggregation be done before publishing itself?

Hi ssagar,

In my case, original request is split and sent to different systems (ex:- creditability / Inventory) for a same Order.Where in case of single order there be several items and each item is sent as a seperate document to the systems (ex:- creditability / Inventory)

The systems (ex:- creditability / Inventory) will publish the document to the webMethods broker were at the webMethods, it needs to collect all the items belonging to the same order and needs to be processed.

Each item will have the following common fields,

orderID
totalNumberOfItems
activationID.

The above mentioned fields are to be used for the aggregation at webMethods. Were these fields are not modified or used by the target / end systems

Thank you,
Gokul

maybe you could try using pub.trigger:createTrigger and pub.trigger:deleteTrigger with some filter conditions using the fields you mentioned.

could it make use of those fields during service execution and the newly created triggers could subscribe to the exact documents necessary?

I haven’t tried this out myself yet, just trying to suggest if it could help…

The “best” approach would be to not split the order into multiple documents. If that is a possibility I’d strongly suggest going down that path. Any process that would need to reassemble the order will be fragile and a constant source of support tickets.