I’m new to the whole EDI thing (webMethods too for that matter) but I think I’m getting a handle on most of it. There is one thing that has me stumped though, and I’d appreciate a little help with it.

We receive an X12 850, convert this (in webMethods) to a flatfile format, then send it to our mainframe via ftp. The mainframe will then process the 850, and send a flatfile to the IS containing the details of an X12 855 (POAck).

Using BI for conversation management is finally starting to make sense to me, but when I get to the part where the mainframe sends back the flatfile, I’m stumped. How do I represent this in BI?

The “trigger” document isn’t coming in through TN because it’s a non EDI flat file. Am I missing something? How is the conversation management supposed to deal with this type of situation?

Thanks a million in advance - I’ve been lurking and learning here for quite some time

This is a common question in regards to how trading networks handles flat files. This is taken care of out of the box in webMethods 6.0, however in 4.6 and earier, you can’t just send a flat file to trading networks. The approach i’ve taken is to create a custom xml wrapper. something simple with a and a . You can just map your flat file string into the body document. I would also recommend putting and nodes in their too… so then you can define a custom document type in TN. Then in BI you can import this custom document type into your ‘documents and system’ and use it in your process models/conversation scripts.

that last post deleted some words due to my bracket tags…

This is a common question in regards to how trading networks handles flat files. This is taken care of out of the box in webMethods 6.0, however in 4.6 and earier, you can’t just send a flat file to trading networks. The approach i’ve taken is to create a custom xml wrapper. something simple with a ‘header’ and a ’ body’. You can just map your flat file string into the body document. I would also recommend putting ‘receiver’ and ‘sender’ nodes in their too… so then you can define a custom document type in TN. Then in BI you can import this custom document type into your ‘documents and system’ and use it in your process models/conversation scripts.

Greg,

I asked the same question.
Here’s the link with all the responses.
[url=“wmusers.com”]wmusers.com

Chris,

I’d read your thread, but wasn’t clear that this is what I had to do…

Am I supposed to be submitting all kinds of documents to TN to keep the conversation coherent?

I really have no idea what I’m doing

Greg,

In my case I’m not using Conversation Management. Our EDI document flow is not that complicated. I’m also using IS not BI.
The thread I referred you to solved my particular problem.
Sorry I couldn’t have been more helpful.

I’m sure someone will chime in with the correct response.

Using conv mgt is probably unecessary in this case. Using CM is useful for when you want to track process progress within the IS/TN environment. Chances are, the app you’re connecting to on the mf is doing this and IS simply needs to pass things back and forth.

The question to answer: do you need to be able to connect a PO ack with a PO within the IS/TN environment? If not, then you don’t need to use CM and BI. In this case, the information provided by Ryan and Chris should help get the data flowing as needed.

If you do need to use CM, then yes, you’ll need “…to be submitting all kinds of documents to TN to keep the conversation coherent?” TN can’t track a conversation if you go around it. I don’t think it matters that the PO ack from the mf isn’t EDI. As Ryan points out, you just need to take steps to get that flat-file data to TN in a form that it can use it. The trigger is the receipt of a particular doc type (the info from Ryan & Chris describe how to get your flat file into the right doc type form) with a particular conversation ID. This is the critical piece–and possibly a stumbling block. The conversation ID, created and assigned to the PO on the way in, needs to be preserved in the trip to and from the mf. The wMTN_ConvMgmtGuide.pdf has a good explanation of the process.

HTH

Ah. Sadly, the mainframe doesn’t track conversations (or match POAcks with PO’s or even FA’s with any document)

Unfortunately our old translation software took care of all of that for us. I’m fighting an uphill battle with the “current” edi developer, since he’s been spoiled by the current (very expensive, very tied to the VAN) solution.

The more I look at it, the more it seems that the best way to do it is to create my own simplified “conversation database” that tracks documents as they flow through the system. I think using BI/TN for this seems a bit like swatting a fly with a sledgehammer.

Thanks for the help.

My Question is maybe not related to this thread, but it concerns TN.
I am working on WM4.6 and at some stage on our production site the database connection changed from External to Internal, either by itself or by some hacker. Anyway, changed it back, but now neither the Conversations nor the Conversation Scripts Buttons are showing in TN Console. How can I get them back?

Never mind, The solution is simple: In the WmTN\config folder the properties file must be edited to contain the entry:

tn.ping.cmVisible=true