Hi Guys,

I’m sending the EDI document to the TN using a custom service which goes as follows:
pub.file:getFile(reading the file which contains the EDI data)
pub.web:stringToDocument(converting the stream into node)
wm.tn:receive(passing the node as input to this service)

I have created two processing rules, one which handles 214,210 doc types and the other which controls the not recognized document types.so, when i read the EDI file,TN is always the triggering the 2nd processing rule which does’nt recognize the document type.

Can someone help me on this issue.

ramesh

Ramesh,

Are you seeing any error in the Activitylog?
For testing purpose did you tried to disable 2nd processing rule(unrecognized rule)and see if 1st processing rule picking up depends on the documentType you are sending to TN.

Actually try to shiftup and down the processing rules and test the scenarios.

Still problem persists,let us know the in details of your testing.

HTH,
RMG

RMG,

In the second processing rule, i’ve invoked a service.and whenever i pass the EDI document to TN through my custom service, this service is getting invoked and that means the 2nd processing rule is always triggered.what i see in the activity log is the service being invoked by the 2nd processing rule.no error in the activity log.
i disabled the 2nd processing rule and even then it is not picking up the 1st processing rule.

do i have to set anything else in the wm.tn:receive service other than the node?

ramesh.

ramesh,

You don’t need to map any inputs into wm.tn:receive to pass EDI data to TN. Just have your data in a variable called “edidata”.

I’d further recommend calling wm.tn.doc.xml:routeXml instead of wm.tn:receive – it accomplishes the same thing, but doesn’t waste resources validating the user (which isn’t necessary because you’re already in the IS).

TN should do a better job of recognizing your data this way.

Dave

Ramesh,

yes always use the routeXML service and follow the instructions given by Dave for processing edidata(casesensitive) to TN.Even though receive service works the same funcionality,but i prefer to use routeXML all the time.

HTH,
RMG

Dave,

I’m using routeXML service but i’m still the 2nd processing rule is picked up.

pub.file:getFile(reading the file which contains the EDI data)
pub.web:stringToDocument(converting the stream into node)
routeXML(input is the node from the above service)

i dont understand where to set the edidata input parameter

ramesh

ramesh,

You don’t set edidata in routeXML, and you don’t map anything to the node. Just make sure that there’s a stream or string variable in the pipeline called edidata (it might even work if you map your getFile output there).

What is the current doctype in TN that’s causing the 2nd rule to be selected?

Dave

When using routeXML you can send it converting to node or wrap the edi string under a temp record called(rec_scope/edidata-map edistring to edidata)and now set the rec_scope(name)in the Scope section of the routeXML service.don’t need to map edidata explicitly

Can you give some more details on your processing rules setup?

When you see the EDI document in the TransacationAnalysis is the sender/receiver/documentType recognizing and is it as per you 1st processing rule?

Please confirm.

HTH,
RMG

Dave,

I did Map the output of the getFile to node variable of routeXML but still it does’nt work.
X12 4010 214 is the doc type.

ramesh

you can refer to the webMethods_EDI_Module_Users_Guide_6.1.pdf documentation on page no 245 onwards to set the edidata input parameter.

HTH
Ramesh.

RMG,

sender------Any
receiver------Any
Document Type-----X12 4010 204/X12 4010 210/X12 4010 204
User status------Any
Recognition errors-------Has no errors

under Action tab:
calling a custom service

ramesh

Ramesh:

You’ve described your service steps to be

pub.file:getFile(reading the file which contains the EDI data)
pub.web:stringToDocument(converting the stream into node)
routeXML(input is the node from the above service)

As Dave Adler pointed out you don’t need to map anything to routeXml and you don’t need the stringToDocument step. Do this instead:

pub.file:getFile (set loadAs to stream)
MAP body.stream to a new variable named edidata
routeXML (no inputs–TN just looks for edidata variable in the pipeline)

HTH

ramesh,
I am assuming the routing rule you described is the one you want to use can you give the specifics of the other processing rule. If we have all the details for both processing rules maybe we can determine why the wrong one is being used. It sounds like the doctype is being recognized so what ever means you are using to get the document recognized into TN isn’t the issue it sounds to me like it is your processing rule setup. First describe the documents you see in the transaction analysis then give us the specifics of both processing rules. In transaction analysis make sure the sender, receiver, and doctype are being recognized at the 210 or 204 document level that will tell us a lot. Is there anything coming up unknown in the transaction analysis? Also put the processing rule that you want to select at the very top of the processing rule list, the first one, prior to submitting the document into TN.
Thanks,
Dawn

ramesh,
Another tip is to open the document in the transaction analysis and verify that the document envelope (ISA, GS, and ST) is correctly populated. I had trouble similar to this because one piece of the evelope wasn’t populated and I think that was the GS01 that I was missing which indicates the document function. If you copy the envelope here I can look it over for you, I have worked with EDI for almost 20 years so I’m pretty good at debugging issues with it.
Thanks,
Dawn

Dawn,

Here are the processing rules:
#1.Should be selected whenever 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----X12 4010 204/X12 4010 210/X12 4010 204
User status------Any
Recognition errors-------Has no errors

under Action tab:
calling a custom service

#2.Should be selected whenever a doc type other than 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----Any
User status------Any
Recognition errors-------May have errors

under Action tab:
calling a custom service

splitOption in default EDITPA is at Group level.
As Rob said, i did exactly the same way:
pub.file:getFile (set loadAs to stream)
MAP body.stream to a new variable named edidata(string type)
routeXML (no inputs–TN just looks for edidata variable in the pipeline)
and when i run the above service,what i see in the Transaction Analysis screen is:
DocumentType-----Unknown
Sender-----Unknown
Receiver------Unknown
Processing status------Done
I’m attaching the edi doc.

Dawn,

Here are the processing rules:
#1.Should be selected whenever 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----X12 4010 204/X12 4010 210/X12 4010 204
User status------Any
Recognition errors-------Has no errors

under Action tab:
calling a custom service

#2.Should be selected whenever a doc type other than 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----Any
User status------Any
Recognition errors-------May have errors

under Action tab:
calling a custom service

splitOption in default EDITPA is at Group level.
As Rob said, i did exactly the same way:
pub.file:getFile (set loadAs to stream)
MAP body.stream to a new variable named edidata(string type)
routeXML (no inputs–TN just looks for edidata variable in the pipeline)
and when i run the above service,what i see in the Transaction Analysis screen is:
DocumentType-----Unknown
Sender-----Unknown
Receiver------Unknown
Processing status------Done
I’m attaching the edi doc.

Sorry Guys,

It went off twice.

ramesh

Ramesh,

Please also make sure the sender/Receiver profile matching with the same externalID’s/Qualifiers exist matching to that incoming edi document and see if any extra spaces are adding to the DUNS numbers/userdefined.This could be one of the the reason for “unknown” while recognizing the document.As Dawn said it happens some times and after lot of debugging.

HTH,
RMG

Since your processing rule is none sender or receiver specific lets focus on the doctype recognition first. Do one thing for me change your 1st processing rule to error recognition of “may have errors”. This will give us a better chance at seeing what is going on. Do this change, resubmit the document into TN, go to transaction analysis, view the document, go to the activity log tab of the document and give me a rundown on what activities are occurring. Once we get TN recognizing the document contents then we can go from there. Also while you are viewing the document go to the content tab and tell me the name and type you see. Is your EDI document displaying in the content as you had it in the attachment?
Thanks,
Dawn

Hi,

The funny part is when i submit the EDI data from the Home Page of the EDI Module,it is identifying the EDI doc and picking up the correct processing rule.
As RMG said,if the there is any problem with the External ID qualifiers, then the above scenario should’nt work.
I cant understand this abnormal behaviour.If i submit data from http://wexapd05:5555/WmEDI/(submit the data link),the doc is picking up the correct processing rule.

ramesh

“The funny part is when i submit the EDI data from the Home Page of the EDI Module,it is identifying the EDI doc and picking up the correct processing rule.”

This is because the Sender/Receiver set to Any and since the documentType is getting recognized so the correct processing rule is picking up.Is it always picking 1st or 2nd rule in the Activity log?

ramesh,
That is interesting. Please give me the information on the content and activity log for the document in the transaction analysis. It might give us a clue as to why this submission doesn’t work versus the other that does. Compare the results from both and let us know the differnce you see in the document in transaction analysis. The type on the content tab may be the key.
Thanks,
Dawn

RMG,

when i submit the edi data from the EDI Module home page,it is picking up the correct processing rule(1st one).and when i call this custom service which submits the data to TN,it is picking up the 2nd rule.
“This is because the Sender/Receiver set to Any and since the documentType is getting recognized so the correct processing rule is picking up”--------so why does’nt this happen when i submit the same data through a custom service whixh goes as follows:
pub.file:getFile (set loadAs to stream)
MAP body.stream to a new variable named edidata(string type)
routeXML (no inputs–TN just looks for edidata variable in the pipeline)

ramesh

This is a valid transaction set. My system recognized it as a 214 set, even though the sender and receiver were unknown. This held true when I submitted it from the EDI package home page and when I dropped it into a file polling folder that passed it to wm.tn:receive.

This suggests that there is something wrong with the service that’s submitting it to TN. I would want to see the content and attribute tabs from the TN transaction. Specifically, is the edidata there or is there some unknown/unhandled content part.

Tim,

Here is the service code and the edi data.
Can you let me know whatz wrong in the service?

ramesh,
Please let us know what is in the content tab of transaction analysis for this document (both the good one and the bad). What is the type on this tab? Does the contents look the same from the good one to the bad one? Also the activity log for that document will likely give you some recognition error or something that can also give us a clue as to what TN is seeing as the problem in recognizing this document type when submitted this way. Make sure to change your processing rule to “may have errors” and see if it gets selected then. If you see that it works with this change then you identify the error (duplicate document or something) fix the error and then you can change your processing rule back after resolving the error. Process of elimination, one variable at a time, is usually helpful in getting at problems such as these.

Dawn,

Content type under the content tab when i submit through the custom service is application/x-wmidatabin and whereas when i submit through the EDI MOdule Home Page,it is application/EDI; charset=UTF-8.

ramesh

Ramesh,

If it is showing content-type=application/EDI and charset then EDIidata variable will be shown in the content section which is valid processing and recognizes the document.

application/x-wmidatabin is not valid and this is causing unknown recognition.But i bet routeXML should work always and try to convert edistring to node and submit it.

HTH,
RMG

ramesh,
Lets eliminate another variable by using the same service that is used when you submit a sample in the admin console. Use wm.tn:receive to get the document received into TN. Map the stream from your getfile to string edidata. Map the edidata to the node on wm.tn:receive. See what you get in TN after that. If we get this to work then we can trouble shoot the routeXML further, I use both.
Thanks,
Dawn

Hey Dawn,

it worked when i changed the edidata type from string to object and mapped it to routeXml node variable.
Thanks Guys for your valuable suggestions.
Have a Good Day!

I have a small question.I’m processing 204,210,214,990,997 docs for a particular set of trading partners.so, when i create a processing rule,under the document type,do i need to select all the above doc types and also the X12 Group.please suggest.
Note:spiltOption variable in EDITPA is Group.

ramesh.

Ramesh,

I took a look at your service and you are directly mapping the input stream to a string variable called edidata. I think that may be responsible for the unknown content type when it gets to TN. Thanks,

Tim

Ramesh,

Glad to know that it worked finally…see debugging helps a lot…

Hi Guys,

I’m processing 204,210,214,990,997 docs for a particular set of trading partners.so, when i create a processing rule,under the document type,do i need to select all the above doc types and also the X12 Group.please suggest.
Note:spiltOption variable in EDITPA is Group.

ramesh.

Ramesh,

I think the processing rule you need depends on what you’re trying to do. Since you’re splitting at the group level, I assume that you’re using a custom service to extract the individual transactions from the X12 Group document. Your processing rule for that document type only would invoke the custom service. If this service then submits the individual transactions to TN, you would need a separate rule (or rules) for these. I’ve never done splitting at the Group level so someone else can correct me if I’m on the wrong track here. Thanks,

Tim

ramesh,
If all these documents have the exact same requirements of the processing rule then yes one processing rule will do it all. If you need to execute different services for different documents then create a unique processing rule associated to the unique requirements for that doctype or trading relationship.

For example we have the exact same document going to 2 different trading partners. One trading partner requires immediate delivery and the other requires batched documents in a single ISA one time per day. Ultimately they run the same mapping service, but to accomplish the batching the intial program executed is a service that maps and batches while draining a queue. They each have their own processing rule for the same doctype but different receiver Id’s. If the trading partner that wishes to receive the batched EDI file changes their requirements to now have immediate delivery I simply add that receiver to the first processing rule that does not batch and my job is done, no coding necessary. The reverse is also true, less likely, but true. If the immediate delivery trading partner decided they liked batched EDI I simply switch them to the processing rule that batches documents. Again they share the same mapping logic just different delivery processes.

I tend to use processing rules as much as I can to control partner specific requirements to insulate those specific requirements from the coding as often as I can.

One more thing if you do your processing at the document level (210, 214, etc…) then do not add the group envelope as a selected doctype in that processing rule or you will have your service executed twice I believe. Chose your processing to either be at the group level or the individual document level but not both.
HTH,
Dawn