We are sending an AS2 transaction to a partner.
They get the transaction I get the MDN only if requestMDN = synchronous.
When TP sends us a transaction I get the payload and WM sends an MDN with user status IGNORED. TP says they DO NOT get the MDN.
The MDNs and transaction are being sent to the EXACT same TP’s URL.
Why would they not get the MDNs I am sending?
Why can I only get a MDN if my requestMDN is synchronous?
Do you have the AS2MDNURL set in the ‘EDIINT’ extended field group for both profiles? This field is only used for async MDNs as the return address is not needed when the MDN reuses the original HTTP session.
Tim
Also, what fixes/service packs for EDIINT have you applied? There is a fix that addresses a problem where an asynchronous MDN is generated before the original document is processed. I believe this could cause the MDN to be ignored because it would not be matched up to anything. Check Advantage for details on this.
Tim
Is you partner requesting async or sync MDN??When MDN gets IGNORED it should be selecting Default rule and then obviously it wont get delivered to your partner.
Pls make sure you have given the AS2MDNURL in the ExtendedFields group in the both partners profile.
HTH,
RMG
My partner requested async MDN
You said “When MDN gets IGNORED it should be selecting Default rule…”
Actually when the MDN is ignored my Document type is EDIINT MDN and the EDIINT Delivery URI; Message ID and Message Type is all present with the appropriate data.
I have now set up the AS2MDNURL in the ExtendedFields group in the partners profile for our company and the asynchronous IS working!!!
You are both good with your answers Thanks
Glad to hear it is working…
Cheers(:
When I recieve a AS2 payload from my TP
the MDN that is generated processes w/o error per TN Transaction log
Yet the MDN never leaves the server for delivery to the TP
I can send an AS2 payload to the exact SAME ip and it processes normally
The MDN they want is asynchronous
I DO have the AS2MDN extended field set to the correct IP
It was suggested there may be a ServicePack and fix that needs to be installed. We hesitate to do this because it requires a java upgrade.
Do you know of a workaround
For the MDN that is never delivered: what are the processing and user statuses, what rule was invoked to process it (see the Activity tab) and was there a delivery task created?
The fix I mentioned earlier basically just implements a 30 second delay before attempting to deliver the MDN to ensure that the originating document has been processed. There would be a variety of ways of approximating this yourself, but then you would be reinventing the wheel, as it were. Upgrading the JVM for IS is not really that bad. If you search these forums there are a number of threads that discuss how to do this.
Tim
I am so NEW to this
The user status is IGNORED
We invoke No rule to process it it goes to a Default Rule
We tried using processing rule yesterday with user status ignored
I believe your questions have given me a place to start. I assumed that WM sees it is an MDN and automatically knows how to process it with sender and reciever. Looking back I can see all the pieces may not be there I need to use EDIINT:send
is that correct
What is the user status of the MDN before the default rule sets it to ignored? You should be able to see that in the activity log.
Tim
We have had issues with our EDIINT Processing Rules. Some things were changed and we BELIEVE we have them properly fixed them.
From the documentation this is my understanding of the MDN OutBound process. The document comes in
Is EDIINT suppose to automatically take care of the MDN and it’s delivery or do I have to create my OWN processing rules?
Why is the automatically generated MDN choosing the default rule PR?
Why is it ending with a process of IGNORED?
Is this something I am doing or NOT doing?
Does this seem like a system issue?
I know it is a long post… AS2 implementation has not been easy for us.
TN should handle this, as long as the profiles are set up correctly. It’s very straightforward with synchronous MDNs, asynch is a little trickier.
Because the MDN must also be status ‘SendMNDMsg’ when it comes in to trigger the correct rule.
The default rule changes all documents it handles to ‘IGNORED’. That’s why I wondered what the status was before it got changed.
If there’s any chance your EDI processing rules have been changed, see if you can do a clean install somewhere and compare them to make sure everything is correct. In particular, make sure that the User Statuses associated with each rule are correct.
Tim
Tim
As I typed out a line by line answer to your question I found the answer. When the Processing rule EDIINT Send MDN Message does NOT have a document type it chooses the default rule.
You have been an AWESOME help to me
Sincerely
Cheryl
I had this problem earlier and I found out the document type was null in the default EDIINT processing. I’m not sure if someone modified the processing rule before but I was the first one to configure AS2 in my company…
Anyway, it works after I change the processing rule to correct document type.
From the above post, I’ve seen this happen before as well. We’ll define the document processing rule for an AS/2 customer, and then for some reason the document type specified in the processing rule become blank. After resetting it, things work fine. Not sure what caused the problem.
_brett.