Hi All,
I have an intresting question for you.
I have two processing rules, one for the X12 Envelope which executes a custom service and one for the X12 Group which also executes another custom service.
so, for a particular condition while processing the X12 Envelope, i want to stop the execution of this service and also dont want the X12 Group to pick up the processing rule meant for X12 Group.
I really appreciate your suggestions.
ramesh.
Hi,
Can we control the order of execution of the processing rules.because always the X12 Group is executing before the X12 Envelope.My situation is i have to process the X12 Group only if the SenderId and ReceiverId in the ISA Header matches the profiles in TN.
I know that we can create processing rule for the particular trading partners.but our situation is we are developing a product for ‘n’ number of partners.so we are using a single processing rule for all the partners.
Can anyone tell me how to handle these kind of situations.
ramesh.
I can see a couple of options. You could set the TPA for that partner not to split the envelope into groups, process the entire envelope yourself and only submit the group to TN if the service processing the envelope meets your criteria.
I also think the following basic idea would be possible. You could define a custom attribute for your X12 Group. Your processing rule for the group would only fire when the custom attribute was set. Only set this attribute in your interchange processing service when your criteria are met. Then you could call the wm.tn:reroute service for the group to pick up the rule. I’m not sure of the specifics on how you pick up the related group document from the envelope, but I’m sure it could be done.
I have a suggestion that might work, haven’t tried it. It will require one more processing rule that would have a higher precidence then you current X12 Group (top of the list of processing rules). Simply create a processing rule that selects unknown sender and/or receive and simply ignores the document. That will allow only the known sender/receivers to get to your other processing rule without having to select them all.
Good luck!
Dawn
What Dawn describes will indeed work. I’ve done that in all my EDI projects, though in reverse. Dawn’s suggestion is to have a rule above all others that traps Unknown senders/receivers. We did the reverse in that our higher rules were explicit about the senders/receivers to process, with a catch-all others rule at the bottom to alert us when something unexpected came in. The difference in the approaches is the catch-all-others-at-the-bottom method can avoid processing documents from known partners that they shouldn’t be sending. e.g. Known partner ABC can send 850 but shouldn’t send an 855. If you don’t need this sort of behavior, then the approach Dawn described will be less work/maintenance.
As far as controlling the order of processing, I don’t believe it to be possible. The EDI for TN facilities do the deenveloping and control when documents get submitted to the main TN engine for processing. AFAIK there is no way to control the order of the deenveloping and submission.
Rob,
That is exactly the way we implemented the unknown as well to send an email notification alerting us of an unknown sender/receiver/doctype. When I was monitoring the system in TN one day I noticed a bunch of documents with unknown as one of the above and no one was checking them out since they do not throw an error. That was when we implemented the processing rule to notify us so someone can immediately respond and trouble shoot the document in question. It works for us.
Thanks,
Dawn
Hi,
As Dawn said, i have created two processing rules on top,one for unknown senders and one for unknown receivers.when i send an EDI doc with unknown sender or receiver in the ISA Header,the X12 Envelope is either picking up one of the processing rules i created i.e for unknown sender or unknown receiver,depending on the situation.till then it is ok,but the issue is, i dont want the X12 Group to be processed even if GS Header segment contains valid sender and receiver, but the ISA Header contains invalid sender or receiver.
can someone tell me how to handle this situation?
ramesh.
ramesh,
This is all doable it just takes some work. The way I have controlled situations like these is using a custom attribute like Tim was suggesting. Its a bit more work but it works well. What you will do is add a custom attribute and assign that attribute being equal to a certain value that you designate in your X12 group envelope processing rule under the extended criteria. In your service that processes the ISA envelope when the correct conditions are met you then update that custom attribute and receive (I used routeBizdoc) the document (group envelope) into TN again where it will be recognized as matching your group envelope processing rule. Since you will be getting 2 group envelope documents you might want to not persist the one that does not have the custom attribute set to keep TN clean. If you need more details on how to do this let me know because it does get a little complicated but it does also work well and give you back control of the process. Here are the basics:
wm.tn.doctype:view with the input typeName X12 Group which gets the bizDocType
wm.tn.doc:createNewEnvelope the typeId comes from the view above
wm.tn.docattr:view with the input attribName EDI Batch (use what is applicable to your custom attribute I was using the standard one for EDI Batch so I did not have to create my own)
wm.tn.doc:setAttribute with the inputs attribId and attribName from view above
wm.tn.doc:updateAttributes with input of bizDocEnvelope from the createNewEnvelope above
pub.string:stringToBytes with input of edidata mapping the output to Content in the bizDocEnvelope above
wm.tn.doc:addContentPart with inputs of your bizDocEnvelope, bytes to PartBytes, partName EDIdata, mimeType application/EDI; charset=UTF-8
wm.tn.route:routeBizdoc
Good luck!
Dawn
Dawn,
I would really appreciate if you can let me know in detail.
ramesh.
ramesh,
I am in the middle of an important test right now. If I get time later I will post more details. In the mean time maybe someone else can provide some assistance to you or I will for sure try to get to this on Monday. What I described above was how to update the attribute in your executed flow service at the ISA level. In TN you will have to create a document attribute in Document Types. Then determine a value you want to use for that attribute to control your processing. Add the code I suggested earlier to your service for ISA to assign the appropriate value to your attribute and route the document back to TN of coarse only if it meets the conditions you require. On your processing rule for the GS level that you want to condition add the attribute and it’s associated value in the extended criteria. Thats most of it. Sorry! Wish I had more time to help!
Good luck!
Dawn
Dawn,
I got it working.the bizdoc is being routed to TN with a custom attribute set to some value whenever sender/receiver is valid.but the problem is the bizdoc does’nt contain the senderId,receiverId,DOcumentId,GroupId(all are null) from the original document.
can you tell me how resolve this?
ramesh
ramesh,
Yes I forgot to indicate that when you createNewEnvelope you need to map all that information to the input of the new envelope. Sounds like you made a lot of progress.
Thanks,
Dawn
Dawn,
all is fine.but the problem is i need some info like senderIdentifier,receiverIdentifier,Transaction type to log them into the DB.but when i reroute it into TN,these values are there in the pipeline but when i map them into the adapter service,they are passed as nulls.before using this reroute technique,i was able to pass them into DB.
what might be the problem?
ramesh
Dawn,
I tried using envelopeProcess service and got the Values object in the pipeline and tried to map the ISA06 to senderIdentifier,ISA08 to receiverIdentifier,ST02 to transaction type.but when i map them to the adapter service,these are passed as nulls.
what might be the problem?
ramesh
ramesh,
I wish I could be of more help here but I’m not sure what is going wrong. What are you seeing in the transaction analysis? Is the document recognized as a standard X12 group? Are you persisting in the processing rule (preprocessing- save all documents- make sure you have content, attributes, and activity log all checked)? In transaction analysis are the send and receiver id’s recognized for the document that you used your custom attribute?
Thanks,
Dawn
Dawn,
The document is being recognized as X12 Group and in the transaction analysis screen,i see the senderId and receiverId.everything is working fine.but some problem in the pipeline.
I would really appreciate if you can clear a question of mine, which is related to the above problem.
i’m trying to call the envelopeProcess service and get the Values object,but when i map some data from the values object,i’m not able to get the output(for eg:delimiters).
here is the attached code.
ramesh
test_values.zip (2.1 k)
test.edi (20.3 k)
ramesh,
I haven’t used the envelopeProcess service before so maybe someone else will be able to provide better advice on this. My first instinct is maybe this service requires processing at the ISA level and not the group level (GS). Anyone out there have any ideas as to what is going wrong here?
Thanks,
Dawn