Hello.
The WMEDIforTN module enables by default the recognition of UN/EDIFACT document types by TN for example.
I want TN to recognize custom EDI formats by using a field inside the flat document.
The best would be to enable the use of any custom EDI format in : Web Server Administrator > WMEDI > Document Exchange > Install TN Document Types.
Have you ever tried to extract a type field from a flat EDI document type with TN ?
Thank you.
You must define first the Flat File schema for your custom EDI (and this may involve defining the Data Dictionary as well) you do this from Developer.
Then on TN you have to install a new document type, and point it to the one you created prev on Developer.
After this you just have to define a Processing Rule in TN to associate Sender-Receiver-DocType with processing rule (the process handling the input document).
Hello.
As described aboce I’ve tried to format the incoming EDI flat file with TN.
It hasn’t worked.
I’ve created a Flat File Schema of the Doc Type,
I’ve set the Processing Rule to parse the Doc Type with the Schema.
But the incoming flat file is never recognized !
I suppose that the parsing using the schema doesn’t help TN to match the sent flat file with a Doc Type … is is independant, isn’t it ?
So, is there a simpler way to regognize an EDI Doc Type
than to extract its type in a Gateway Service ?
Because if not then I would have to use Java InputStreams …
Or did I miss a step in the TN parsing procedure ?
Thank you.
Fanilo.
Errrr …
I’ve created a Doc Type pointing to the Flat File Schema on the developer. It didn’t worked.
Does an incoming flat file is directly parsed by TN ? I guess not, because if TN needs to parse the flat file to recognize it then TN would have to try all parsings …
So I guess that the incoming flat file as attributes that tell TN wich parsing to use. Maybe these attributes are set in a Gateway Service …
Any idea ?
Thank you.
No. You must use a gateway service and basically tell TN what the document type is.
The EDI module is able to do what it does because there is a standard way to recognize the envelopes and transaction sets. wM extended the doc recognition functions of TN to support EDI. Unfortunately, for FF we get to do the recognition ourselves, before handing the document to TN.
Have you define the content handler?
Why do you believe a custom content handler is needed in this case?