How to Receive EDI Document from Trading Partner (Inbound EDI doc scenario)

Hello Community,

I am trying to learn & explore MyWebMethods Trading Networks for EDI send/receive. After reading AG documentation, now I know how to setup Enterprise, trading Partners, Document type, Trading Partner Agreement and Processing Rule but I don’t know how to receive EDI document from Partner?

If Partner want’s to send us EDI data then how can I receive that EDI document using MWS Trading Network? Do I need to use some built-in service to receive inbound/incoming data from Partner? E.g. built-in wm.tn.receive service? or is there any other way of receiving EDI data from partner?

Can anyone from the community tell me high level steps to receive EDI document after I have setup Enterprise, Partner Profile and TPA/Processing Rule etc in MWS TN?

Thank you

1 Like

Hi Ahmed,

if I am not completely mistaken, the should be some sort of EDI receive service which can be invoked via WebURL by the EDI partner. The payload will then be presented as a XML string representing the EDI Document structure.
Use pub.xml:xmlString Document if there is no dedicated EDI service for this.

Regards,
Holger

1 Like

As @Holger_von_Thomsen infers, there is a service that can be used at the start. TN and the EDI module can be used together to make incoming and outgoing docs easy to manage. Including for sending 997s.

It’s been many, many years since I’ve worked on EDI stuff, but using TN is definitely what you want to use. The wm.tn:receive service is the main entry point. What is often done is instead of exposing that directly (which can be done), if you want partners to call your system instead of you retrieving docs, is to create a wrapper service that you define and control. You can add various features to that front-end service, such as allowing submission in various ways, better control authentication, and such. Then that service invokes. wm.tn:receive.

TN and EDI for TN will de-envelope for you and you can configure things to process the envelopes and the transactions sets as desired. The processing rules you mentioned. You might consider obtaining guidance from someone who has done this before. Either SAG PS or a contractor. Setting up an EDI processing infrastructure can get pretty complex, depending upon how many transaction types and partners you plan to support. EDI for TN will help a lot but you still need to design and implement your own framework within that framework.

1 Like

Hello @reamon & @Holger_von_Thomsen
Thanks for your valuable feedback.

We tried to use wm.tn:receive service to receive Inbound EDI Document. We can see that upon executing wm.tn:receive service, the appropriate TPA and Processing rule got invoked, however, we are getting (Receiver of document cannot be self) error message as shown below:

For reference, following are the Partner & Enterprise profile IDs as configured currently:

Partner Profile and ID (Sender)
image

Enterprise Profile and ID (Receiver)
image

Processing Rule for Inbound Document
image

EDI Document

As you can see in above EDI document (that we are trying to receive as Inbound), Sender ID is EMEDNYBAT and receiver ID is ETIN.

I am not sure why I am getting Receiver of document cannot be self error here? May be I am making some mistake in defining profiles here.

If anyone in Tech Community is aware of this error message solution or have experience of implementing EDI (inbound/outbound) then please guide/help me

Thanks

1 Like
  1. Please use “Submit Document” of MyWebMethods to send EDI sample file.

  2. Please use “wm.EDIINT:receive” to receive EDI data.
    image

2 Likes

That depends on if one is using the EDIINT protocol. As mentioned earlier, it has been many, many years since I’ve worked on EDI stuff with wM but in the multiple EDI engagements I worked on, did not need to use EDIINT.

+1 for the suggestion to use the submit document helper page. Very useful for dev/test.

1 Like

If I recall, the user account used to submit the document is factored in too. If the account used to call tn:receive is the same as associated with ETIN, that may be the issue. But this is completely a guess!

1 Like