Hi All

I have a requirement where the xmls are sent to wM broker queue and at the end of a batch, a trigger is sent to invoke a service which retrives the xmls from the queue and start processing. (Transactional client is used to pick the xmls from the wM)

The same can also be performed using wM Trading networks, is it preferable to use wM broker or wM TN.

Please suggest

Thanks
Rocky

I would use Trading Network if I were you since you are dealing with external parter(client) and you can archive the queue functionality in Trading Network also.

Thanks Talha for your suggestion,
The xmls are sent by their own application (say an ERP) to another application through wM.
We are not dealing with external partner here… however i need to store those xmls for my audit trails.
Please suggest…

Well if you use the Trading Network then that other application(say an ERP) can send xml directly to Trading Network without going through webMethods IS and when Trading Network recieves it, it can put that in TN queue which behind the scenes stores in TN database which you can use for your audit trails since those xmls will be in TN database. Using TN would be also beneficial in this case also because you can track each xml(transaction) in TN itself using the activity log which will not only show the xml but the sender and receiver too and you can be creative by adding more info in activity log of TN according to your needs. In other words by using TN the transactions(xmls) will be more easy to monitor and track down.

“…can send xml directly to Trading Network without going through webMethods IS…”

Minor clarification–TN is hosted on IS so there really isn’t a notion of going “directly to TN without going through IS.” You might have meant without going through a custom IS service? I would recommend always going through a custom entry service and never invoking tn:receive directly from outside of IS.

Rocky, what’s the driver behind queuing and batching?

My bad, i should have mentioned what Rob just clarify. TN is indeed hosted on IS. I thought that you Rocky was publishing the document to broker from another wM IS which would get subcribed to the IS which had TN. As Rob mentioned it is also best to have a gateway service before sending the document to TN using routeXML service to make your solution more flexible by performing any operation.

Ok…
Let me explain the scenario in detail.
A financial application sends an Accounting xml whenever there is an event eg, trade , settlement etc… to wM Broker queue1 (which can be wM TN ). At the end of day another trigger is sent to wM service which picks up all the events (in the form of xmls) from the broker queue in a batch, which indicates the end of the events and then wM starts processing for business.
After applying the business logic, input xml is mapped to target xml and sent parallely to two different broker queues and further sent to SAP and EDW respectively.
In case one of the publish fails, the whole transaction must be rolled back, so that i can resubmit the document again from the wM Broker1.

I would like to replace the use of wM Broker and use wMTN here, ie store the documents in wM TN and resubmit from there.

Thanks
Rocky !

Thanks for the additional info. I guess I’m still not clear on the specifics of the need to treat the group of docs as a single atomic entity. I ask because eliminating batching can simplify things quite a bit.

What components are used to send data to SAP and EDW (what is EDW?)? I ask because that may factor in on recommendations.

Note that using Broker provides a relatively easy way to deliver a doc to multiple targets. With TN, you’ll need to do some extra work (not a lot) to deliver a document to multiple targets.

Which is more prevalently used in your org, Broker or TN? Is there an overall strategy or set of principles within the org that guides the use of one or the other?

To answers to your questions,

1. I need to group the docs as single atomic entity, as they belong to the postings of one account.
2. SAP Adapter is used to send the data to SAP and JDBC Adapter for EDW (Enterprise Data Warehousing). The need to send them through broker is if there is error, it can be reprocessed from the broker…
3. Brokers are prevalently used in the org. There is no overall strategy as such.
   Thanks for your time

Rocky

1. Okay. One approach might be to collect the various XML docs in a TN queue, like you imply and Tahla suggests. Then the end of day process collects them into a single target doc. Be sure to store this resulting doc into TN as well. Then publish this doc to the Broker for distribution to SAP and the EDW. Will the doc size allow for this approach? Multi-MB docs published to the Broker is usually bad mojo. But if the resulting docs is only a couple of MB or less, then this may be the way to go.

2. Cool.

3. I would suggest leveraging Broker where reasonable. In this case, since batching isn’t one of Broker’s strong areas (it’s kind of a pain actually), use TN for queuing and batching, Broker for distribution.

HTH!