Can anyone of you help me on this. I would like to how the various Externally ID types that we define in TN are linked. I have a case where our partner is using DUNS, where as our Trading Networks is setup to use ‘Mutually Defined’ External ID Type.
Even though I have defined the DUNS number and Mutually Defined numbers for the partner, TN does not do a match on DUNS, but only does it on Mutually Defined numbering type. How could I utilize the DUNS number, instead of forcing my partner to use Mutually Defined numbering type.
My understanding is that you can only use one external ID type, so if you’re using ‘Mutually Defined’ then all partners must use this type and there will be a user with the same id in IS.
You might want to create your own ‘receive’ service which coverts the DUNS to the Mutually Defined type…
And pls make sure in the TN documentType section, there is an Extract Tab where you will be extracting Sender,Receiver ID’s and there select the DUNS option depending on if Sender uses (DUNS or MutuallyDefined or UserDefined) and Receiver uses (DUNS or MutuallyDefined or UserDefined)roles.
It works perfectly well if the sender and receiver is using Mutually Defined type. The problem only comes, when one of them is using something else than Mutually Defined.
Also regarding Will’s suggestion to convert from DUNS to Mutually Defined, I have already tried this approach. The problem with this is since the sender is using DUNS and sender as identified in TN is Mutually Defined, there is a mis-match between user and sender extracted in the document. So TN gives a security error.
To rephrase my previous statement - TN out-of-the-box functionality expects you to use one default type throughout, but you can create multiple ids for each profile. This means if mutually defined is used, TN will check that the connected user matches the mutually defined sender in the doc. Therefore I suggested bypassing this security check (by adding a new entry service) which would change the XML from the DUNS to the Mutually Defined BEFORE it goes to TN for the security check. You would take the DUNS from the XML, lookup the mutually defined id from the TN profiles, replace the DUNS in the XML with this, THEN send it to the receive service (there are other variations to this solution).
One of the things you can do is receive the document and submit it to a processing service that extracts the relevant IDs from the relevant fields and then returns (or resubmits) the document back to TN.
Another possibility, depending on your licensing and resources, is to have two instances of TN, one for each type of unique ID.
I would receive every document into a generic service that wraps the document into an internal canonical for processing. Then I would submit the document to TN. You will need to create a redirect service for receipts for each message to send back to the partner. This will allow you to manipulate the data irrespective of type, and then use a generic set of processing rules rather than needing to change the processing rules for each document as the rules change.
The sender has only DUNS number, the problem is not really in sender indentification, but the user sender mis-match. If I understand your solution, which is what I tried, I change the XML with the new Mutually Defined ID, before I submit to TN. But still we cannot manipulate the user who has logged on. The problem, really lies here. The sender has only DUNS, so he will only use DUNS number to logon. How can this problem with user id be solved, because obviously any transalation can be done on the server, but cannot be done on partner side for logon user id.
Sender Verification is the purpose for which these different IDs are used. Standard provided is DUNS, but others are customized ones.
For the entire TN instance there can be only one sender identifier, which depends on the settings in the TN server SETUP. So it is betteer to follow the rules or the framework supported.
To overcome that, as suggested by other members you could have…
2 TN instances with different sender identifiers and route partners depending on the ids.
Build Wrapper service, to identifying documents and then manipulate things to make it correct identifies and resubmit documents.
Replace the sender identification logic from the receive service to custom service which does not check the sender with IDs, where you are compromiszing security.
Can you cut and paste your ISA segment if it is EDI. What is qualifier in the ISA. The qualifier for DUNS should be 01 then TN will match the external id with DUNS. If qualifier is ‘zz’ TN matches the id with mutually defined. I would like to know what that qualifier is in your ISA segment.
A profile can have multiple external IDs. The required external ID is used as the username that must be used to log on. The default required external ID is DUNS. You’ve indicated that they’ve configured their required external ID to be Mutually Defined, which is an okay thing to do.
When the partner logs on, they must log on using the required external ID to be able to submit docs to TN receive and have the doc pass the security check.
The doc itself can use any single external ID, which is controlled by the doc type attribute extract configuration. If the doc type specifies that the extracted sender is DUNS, then the doc must contain the DUNS identifier. For your setup, to pass the security check, the DUNS must be for the same profile as the Mutually Defined identifier used to log on.
I assume the partner is submitting documents directly to receive. The Ezine article at [url=“wmusers.com”]wmusers.com identifies several drawbacks to doing this.
If you want to bypass the security check, create your own entry service and submit the doc to TN by calling wm.tn.doc.xml:routeXml instead of wm.tn:receive. The only difference between these two services is that routeXml doesn’t perform the additional security check.
So, for your setup the partner must log in using the Mutually Defined identifier (and the password you assign) and the document must use the external ID defined by the doc type (the discussion so far has said it is DUNS). Having the partner use the Mutually Defined ID to log on shouldn’t be a big deal. Their docs can have DUNS and still pass the security check.
Well described Rob.
Only 1 TN instance is required for this solution. Wrapper services are required if the XML does not contain tags that can be used to identify to document/TP, which again is not the case for this problem.
Another point is if you use the HTTPS transport, then the login can be accomplished with a request for a client authentication certificate. The certificate is saved in TN against the profile containing the DUNS value.
I’m confused. Did someone suggest multiple TN instances?
Wrapper services are useful in more cases than just when the XML does not contain identifying tags (and depending on what you’re doing, you might not need these either). In this case, a wrapper service helps resolve the security check issue, though it has its own set of issues (namely, security!).
there were a couple of suggestions in this post to have more than 1 TN instance to resolve the issue.
My point about the wrapper service is that it is not required to solve the originally stated problem. Standard wm.tn.receive and TN config will work.
From the above postings the best possible option looks like a wrapper service, which uses routeXML, and explicitly checking the login user with one of the external ids defined.