Hi,

How do I set the retry count for sending EDIINT transmissions? My IS 4.6 appears to only try once.

Thanks in advance.

Go to Partner profile/Delivery method/ and set the value for Delivery Maximum Retries.

HTH
DG

Thanks DG!

I also noticed Polling Methods/Polling Frequency options in the Delivery Method.

Currently I have a scheduled service to poll a different partner’s ftp site for XML, loop through the files and push (wm.tn.recieve) the files to the TN. Would it be preferable for me to use this TN setting to do this? What are the best practices?

I set the following in the Delivery Method:

Delivery Maximum Retries: 10
Wait Between Retries: 10000
Retry Factor: 1
Poling Methods:
Polling Frequency 00

However, I still find that my TN doesn’t re-try. My EDIINT transmissions stay in SendMsg:WAITMDN status. It doesn’t try to re-send the transmission.

What am I doing wrong?

Michael,

Are you sure it’s waiting to send or is it waiting to receive?
Are you config for AS1 or AS2?

Chris,

I am using AS2 to send a message. The transmission is waiting indefinitely for an MDN. I expected it to re-send the transmission if no MDN was received.

It’s waiting to receive the MDN. But I want it to re-send if the MDN is not received.

Michael,

To the best of my knowledge, it will remain in the SendMsg:WAITMDN User Status indefinitely if it does not ever receive an MDN. I do not believe there is a way to configure TN EDIINT otherwise.

Indeed it will stay on SendMsg:WAITMDN forever. The users status is changed to DONE at the moment you will receive the MDN from the partner. But it is not a good idea to have the EDIINT automatically re-send if the MDN is not received, because you don’t know what happened, either the EDIINT didn’t arrive at the partner, or you didn’t reeive the MDN the partner has sent. In the last case the partner will receive the same EDIINT message twice.

OK. So what is common practice with EDIINT in the TN. Should I simply monitor for transactions that are ‘stuck’ in “SendMsg:WAITMDN” and ask our partner if they had received/processed the message?

Also, what does the retry configuration in the EDIINT TN Profile Delivery Method achieve?

Wer’e thinking of creating our own service to check for transactions stuck on WAITMDN for a certain amount of time, or create a feature request on advantage. At the moment, we check this manually.

The retry configuration works for sending EDIINT messages, not for receiving the MDN. If TN is not able to make an HTTP connection, it retries until maximum retries is exceeded, if it still fails, the status changes to sendMsg:ERROR.

Thank for your help Andre.

One more question, whats the best way to re-send my EDIINT messages. I am unable to sucesfully “Reprocess”/“Resubmit” the EDIING transaction from the TN. Do I really need to re-start my initial document (the one that was mapped to EDI and then sent via “send”)?

Michael,

Yes, you will need to reprocess your original document. It sounds like after you map to X12, you immediately invoke wm.EDIINT:send. A better approach is to submit the X12 data to Trading Networks, and then create a processing rule that will deliver your X12 data to another Flow service that will invoke wm.EDIINT:send. This approach allows you to reprocess the X12 document within TN if the EDIINT message needs to be resent. It will also give you more flexibility down the road if some partners do not want to receive via AS2. They may want to communicate via FTP. If you always invoke wm.EDIINT:send after mapping to X12, you will not have this flexibility.

Also, by submitting your X12 data to TN, you can perform FA Reconciliation if you want to.

HTH

Thanks for the advice Chris.

I was wondering about the EDIINT system status. I had an EDIINT entry in the TN that failed to send the transmission (the partner server was down). In the activity log, I can see the “error” statments for each failed re-try, however my System Status (for the EDIINT entry) still says “Done”. Shouldn’t it say “Done w/errors”. Alternatively, my user-status is stuck in “SendMsg”, shouldn’t this say “SendMsg:ERROR”?

I am confused about how to quickly identify transmission failures.

Michael,

I would expect to see “DONE” for the system status. The system status will only be set to “DONE W/ ERRORS” if errors occurred during document recognition and/or document processing.

As for the user status, the only reason I can think of why it’s hanging on the “SendMsg” status is if it’s waiting for a synchronous MDN. Are you requesting asynchronous or synchronous MDNs?

Chris

I am requesting a synchronous MDN. If I were to change to asynchronous MDN’s, how long would webMethods wait before the SendMsg status changes?

Are asynchronous MDN’s preferable in webMethods?

Hi Michael,

My experience is that directly after the EDIINT message is sent, the user status changes to SendMsg:WAITMDN and stays that way until the MDN is received. If it doesn’t succeed sending the EDIINT message after the retries, the status changes to SendMsg:ERROR, so it looks like it is still retrying.

We are using asynchronous MDN’s. Using synch MDN’s the session will be kept open until the MDN is received. Which can take some time.
Be aware that changing the requestMDN parameter to “asynchronous” is not enough. You have to enter the URL where you want to receive your MDN’s in the extended field AS2MDNURL at the partner’s profile. Took me some time to figure that one out.

Michael,

My experience is the same as Andres. We are also using asynchronous MDNs, which in my opinion is preferable to synchronous. B2B messaging is not generally supposed to be “real-time”, so asynchronous is usually the way to go.

When requesting an asynchronous MDN, the EDIINT document will wait in “SendMsg:WAITMDN” status forever until it receives the response MDN.

HTH

Thanks guys. You have really helped me understand the EDIINT process much better.

One thing that I’ve noticed that there is a way to re-send failed EDIINT transmissions (without having to re-process the orignial document).

If I view (double-click) the EDIINT entry (for the document that failed to be sent), I can select the “Tasks” tab. From here, I can right click and select “Restart” which restarts the conversation/task and sends the EDIINT again.

Thanks again for all your help.

Michael, how do you have your EDI solution setup ? I do not have tasks associated with my EDI transactions on the tasks panel.

We are using TN predominantly for transmission instead of translation. We are just writing the EDI data to a flat file on the inbound side. And on the outbound side we are filepolling for similar flat files and creating AS1 messages to send to our partners.

If I am able to incorporate this “restart” functionality, I would certainly do so- Any suggestions would be great!!

Jessica

Jessica, we are sending AS2 messages via the wm.ediint.send service (IS4.6). Basically our services push an xml file to the TN, and then we have a processing rule for that xml doctype to execute a service that translates the message to EDI and executes the send service (with the translated payload).

I am unfamiliar with AS1, but with AS2 the transmissions are visible as tasks (showing the http-tries). If I view the EDIINT in the TN, I can select the ‘tasks’ tab and re-start failed tasks. Possibly AS1 transmissions don’t associate smtp traffic with tasks? Are you using the wm.ediint.send service?