We have a requirement to route documents based on ISA or GS ID. The processing rules allow routing based on the profile but not specific IDs.
At first I thought, I could create a document attribute say Receiver ID, extract the ID from the EDI data before routing to TN. That way I can use that attribute in the extended criteria of the rule. But, we have the following two requirements that prevents me from doing that…
There are multiple envelopes in the edi files received. We, submit the entire file to TN which then splits them into individual ISAs. So I cannot extract the attributes for individual envelopes before I submit to TN.
For many partners the split level is set to GS, as we get many different functional groups (IM, QM etc) in one ISA. So the routing rule should be executed on the x12 group and not the x12 envelope. In this case I need to have the Receiver ID attribute set for the X12 group. Which is not even possible before submitting to TN.
Has anyone solved this problem before? Help truly appreciated.
Your processing mentioned above is little to more custom complex based and if you want process via TN.
Can you clarify is all your EDI documents directly hit TN first or is it post processing to TN?
How do you currently receive the EDI IB transactions to TN via a custom gateway service?
Why do you want to process the EDI documents based on the ID’s not what is on the profile?
Can your requiremnet does not support processing ST level from your processing rule to a handler that inturn calls the transaction set specific invoke to the package/folder map service?
They don’t hit TN directly. We have a file poller that monitors a directory and once a file is found it streams data to tn receive.
In our case one profile can have many IDs. And a lot of times data going to say ID1 goes via http, data going to ID2 goes via ftp. So routing happens based on ID rather than the complete profile.
For now, we dont do translation at all. Its only communication. So our job is to simply get the envelope (or sometimes group) and send it (Ftp/http). We ignore the STs.
I believe there is no easier way to handle just with in TN rather implement some custom routing via a DB table specific and invoke the flow’s that does post processing in your case HTTP or ftp or some other route to reach the destination (target app)
You should be able to use GS ID for routing.
Review the doc:
webMethods EDI Module Installation and User’s Guide
section: GSRouting Variables
it has options of:
GSOnly
GS & ISA
Off
Yes those above settings are available on the TPA specific with split option group level??, but I am fully not sure if that helps in the case of routing to rule based on your design needs.
Anyways check it out if it does works for you with out any translation step.
Why doesn’t webMethods TN extract all attributes of envelopes so that we can use them in the processing rule?
Better yet why not let us extract attributes from Envelopes and groups like they let us do for transactions? That way I could have extracted the ISA IDs and then used them in the rule. How hard was that.
Anyways, I think creating separate profiles for the each external ID (for which routing would be different) would be one way to go. Sucks though.
TN Extracts all the attributes of envelope(ISA & GS) by default, run a test transaction in your QA/Dev and see attributes that are available for your use.
Creating couple of partners is one way, webMethods have somany white paper already pulbished to handle these seconorio, contact SAG anf find out best ways to implement.
I did run some tests. Unfortunately ISA IDs and qualifiers are not part of the extracted attributes. These are the attributes available to use
Conversation ID
Date Received
Document ID
Document Type
EDI Acknowledgment
EDI Batch
EDI FA Status
EDI Group Type
EDI Processing Mode
EDI Status
EDI Version
Envelope CtrlNum Status
Group CtrlNum Status
Group ID
Internal ID
Last Modified
Original Receiver
Original Sender
originalFileName
Processing Status
Receiver
Sender
Signature
Yes try to extract them in your custom Gateway service and update the new TN attributes where you can use it per your needs is the possible work around solution.
Apparently I am not very good at reading webMethods guides. The content below is from the EDI users guide. I always knew I could reroute but did not want to do that. Guess I don’t have an option. This or create my own EDI recognizer.
Create a processing rule to process the document. This processing rule does not use
content?based processing. Leave the Extended Criteria tab of the Processing Rules screen
blank. For this processing rule, use the Execute a Service processing rule to invoke a
service that sets the values of the custom attributes (as described in “Setting the
Values of Attributes at Run Time” on page 210). Additionally, this service should
invoke the wm.tn.reroute service to have Trading Networks select another processing
rule for the document. The next processing rule can use your custom attributes as
criteria.