I’m still learning here, but it seems to me that a setting a processing rule in Trading Networks is the same thing as defining a trigger in Developer. Is this true? Any differences? Why would I prefer one over the other? Thanks - MOD
PS - Got all my EDI to flat file mappings done, thanks to the forum. They look terrific. Now I just have to tie these into TN…more docs to read.
Michael,
TN/ProcessingRule used when routing the documents to TN and then to IS/Service.
Developer/Trigger – is used when you are doing (publish/subscribe model) documents routing via IS/Broker and trigger will process the document to a service who ever subscribed the docoument.
HTH,
RMG
Ome more thing is you can use both above options in your integration or either one option depends on your architecture defined.
Hi RMG,
In my case, I’m going to have the wM VAN connectivity poll a mailbox for incoming EDI documents. I’ve been thinking that I’d have that service post them to TN, just as if they’d been sent from an outside client. So I’ll have to set up a processing rule for that customer and document type to handle each incoming doc.
Brilliant! That’s what I needed to see. Thanks so much for the clear, concise explanation. Sincerely, MOD
Hello M.O.D.
I like to use TN with pRules when I want to visually see the documents that are entering. I like the whole TN/pRule setup because I can see each document and what happening with the rules execution. There is also a nice Tasks view if I made and am using a reliable service.
I like the trigger format at times because it is easier to work with custom document formats I create. I also have flexibility with concurrency and TTL of documents because some of them may just exist as message passing structures.
MOD,
There is a benefit to using TN as your interface for document routing and management: If you give permission, your partners can log onto the system and view document processing status.
You can even update the document status (see TN built-in services reference) if there is an internal business rule violation and set a user-defined status. The partners can log on to your system either with the TN Console or TN web interfaces and view the various documents that have processed.
They cannot do this with out of the box functionality with the broker.
Just a few thoughts.
Ray
Hi Yemi & Ray,
Thanks very much. You’re both confirming the direction that I think I should take: prefer TN in this case. Thanks very much for the advice and explanations. I always like understanding the reasons for doing things as best I can. Sincerely, MOD
Michael,
And also most of the Enterprises when doing EDI transactions using WM prefer TN Component in their architecture used for retrieving EDI documents from VAN mailbox(TN Public Queues mechanism) or receiving from internet.
Another general advantage is monitoring inbound/outbound transactions especially when volume is big, this helps production support/Analysts to view and manage the real time transactions Success Vs Errors in one place depends on the custom UserStatuses,and make use of EDITPA’s for internal tracking purposes.
This scenario also applies for different formats XML,FF or Canonical documents routing via TN.
Just some more info,
Technically, one major difference between pub/subscribe and TN routing – pub/subscribe is a broadcast model, and TN is 1-to-1. Or should we say P/S is 1-to-n.
Functionally, due to the different components that are involved in processing and tracking, P/S is normally used in EAI scenarios, while TN is ideal for B2B/EDI scenarios.