Submitting Multiple EDI Interchanges to wmtnreceive

, ,
1

When you submit an Interchange to wm/tn/receive via FTP, TN seems to assume you are signing on to Integration server with an ID equal to the required external ID (in this case the partners sender ID). Otherwise the Interchange errors out in TN as an interchange sent by one partner posing as another. One way I have gotten around this is to use TNAdmin ID rather than a TNPartner ID when signin in to IS. I’m not sure this is a good option, is there another option?

2

JON,
This is a new security feature in TN 4.6.
We have gotten around this issue for XML by writing a custom receive service (instead of using wm.tn/receive). Inside that service we read the data and call routeXML and pass on the node. This will bypass the restriction of using the userID as the required External ID for that partner and you get your data in TN.
I am sure there may be a way to use similar techniques for EDI.

3

Jon,

We ran into the exact same issue a few weeks ago. Our infrastructure team was unwilling to grant us TNAdministrator access to FTP into IS. However they did allow us to run a scheduled service with Administrative rights. So we changed the integration to retrieve the EDI documents using FTP GET and simply scheduled the service to run every hour.

Regards,
Devan

4

I’m assuming wm.EDIINT.receive works the same? Does anyone know this?

5

Hello - WM/TN 4.6 stops the document unless the sender ID matches the B2B username. However, the one B2B marketsite can send XML documents behalf of multiple customers. So I’ve had to write a custom receive service.

This is what we have implemented:

  1. Receive the document
  2. Call wm.tn.doc:recognize
  3. Call wm.tn.doc:getSenderReceiver
  4. Call wm.tn.profile:getExternalID (this returns the DUNS number of the document sender)
  5. Get the B2B username doing the actual posting.
  6. Check if this B2B username is allowed to post for this document sender DUNS number. (permitted B2B username stored as an extended attribute in the document sender’s profile)
  7. Call wm.tn.route:routeBizdoc
  8. Set HTTP response code appropriately. (optional)

By ensuring the sender is a specific party, the security aspect of WM receive is maintained. This is important - if sidestepped, someone may post a document with arbitrary details. For eg: some authorised user can post an invoice from my company to a third company saying “Pay $1000000 to Panama Bank A/c #2134134”. This document would match a TN processing rule that sends invoices out (using our digital certificate!) rather than processing the document inwards.

I hope to submit an article soon to WMusers with more detail about this.

Hope this helps.
Sonam

6

> I hope to submit an article soon to WMusers with more detail about this.

NB: The article is at:
[url=“wmusers.com”]wmusers.com