We are running into the scenario where we are trying to submit a document (XML) to Trading Networks (4.0.1) but don’t always have the sender, receiver, and/or document type in the actual data and don’t always have control of the XML (or other data formats). We have thrown around the idea of using an envelope to wrap the XML document but then there are potential issues with being able to query TN, reconcile, etc. because the XML is in a string rather than native XML.
Anbody know how to get around this? I don’t think it is possible to hard code one or more of these values in TN even though we know the information based on the way we are getting data to/from webMethods.
When you post the data to TN, TN will persist the document. In the interface, it will display the first time that it is an unknown document type. If this is TRUE xml, you will be able to key in and query on SOMETHING in the document, or some field so it can be identified. You can then set a doc-type in TN and assign a service that TN will submit the data too based on the doc-type.
If the file is not really XML, then this will not work.
This is true XML, however in my specific example I only have tags for the sender and document type in the XML. I am missing the Receiver ID - logically not necessarily a bad thing since we may want to send this XML document to more than one place and don’t want to have the backend application have to hard code it in.
You mention that I would have the ability to query “something” in the XML with your approach…would this still make sense with my scenario?
Can I grab the 2 fields (sender and doc type) I do have from the XML document and then default or use some type of service to get the 3rd (receiver) before TN (or in TN?)
You can query the doc type and the sender Id. I am curious as to your approach to derive the receiver Id. I assume that you are just passing these messages through to another system or are you the receiver ID?
I would associate some kind of doc type with the initial information that you can derive from the document. Then I would pass the data back to a B2B service that can derive more data from the XML and evaluate the data. Also, the B2B can access database or properties files that could contain data to help determine where to send the message.
I will need more information to specifically help you. If you would like, we can take this offline.
For docs submitted to TN, you should always be able to determine a doc type. The root tag name, the presence of various tags, etc. You say you have the sender info so you’re set there.
For the receiver, you might try a “subscription” approach (this fits along the lines of what Ray suggests). It takes a little bit of set up and planning but it works well. The idea is that you have 1 or more receivers that are interested in getting a particular document type. Within B2B you know what type of document you’re dealing with. Add an extended field to your TN profiles. The field name might be something like “wantXYZ”. During the processing of the “receiver-less” document (no receiver ID) your B2B service looks up all the profiles that have wantXYZ set to true. The service then creates an independent doc for each recipient (TN requires one doc per recipient), sets a receiver field in the doc and submits it to TN. TN delivers the doc to the receiver.
If this sounds like it might serve your needs, we can dig into details further.