Hi,
we receive daily files from our business partner and send asynchronous MDN afterwards. Usually that works fine. Now for some reason the MDN could not be sent to the partner due to some ssl authentication problem:
Jul 3, 2010 2:14:32 AM de.mendelson.comm.as2.message.AS2MDNCreation signMDN
INFO: mendelson_opensource_AS2-1278116072026-28@XXX: Outgoing MDN has been signed with the algorithm "SHA1".
Jul 3, 2010 2:14:32 AM de.mendelson.comm.as2.send.MessageHttpUploader performUpload
INFO: mendelson_opensource_AS2-1278116072026-28@XXX: Sending async MDN to https://XXX.com/bcgreceiver/target01.
Jul 3, 2010 2:14:40 AM de.mendelson.comm.as2.send.MessageHttpUploader performUpload
SEVERE: mendelson_opensource_AS2-1278116072026-28@XXX: [SSLPeerUnverifiedException]: peer not authenticated
Jul 3, 2010 2:14:40 AM de.mendelson.comm.as2.jms.JMSMessageReceiver run
SEVERE: mendelson_opensource_AS2-1278116072026-28@XXX: Connection problem, failed to transmit data.
Jul 3, 2010 2:14:40 AM de.mendelson.comm.as2.message.store.MessageStoreHandler storeSentErrorMessage
SEVERE: mendelson_opensource_AS2-1278116072026-28@XXX: Raw outgoing message stored to "/opt/mendelson/messages/XXX/error/XXX/20100703/raw/error7026344271671011207.raw".
Subsequently, the partner resent the file resulting in a synchronous error MDN:
An AS2 message with the message id 041bf9b7-3552-4129-b335-86c6e4d9e3f4 has been already processed successfully by the system or is pending. Please resubmit the message with a new message id instead or resending it if it should be processed again.
So the partner sent the file again. This repeated a couple of times until the partner's server gave up.
Now the point that is troubling me: Although our server received and verified the file (more than once actually) it was never stored to the incoming folder but stayed in the pending folder named my the message ID (whereas files in incoming are named by the original file name). Is that the intended behavior? Should not a file that was received correctly be placed into the incoming folder?
Second question. Should the sending server understand the "An AS2 message with the message id 041bf9b7-3552-4129-b335-86c6e4d9e3f4 has been already processed successfully by the system or is pending" bit and how should it react then? What has to be done to get the message from pending to incoming?
Tobias
Tobias,
To the "peer not authenticated" problem: are you sure the certificate is imported as trusted?
To the pending question:
The file will be only moved to the inbound folder if the transaction is completed. As long as the transaction is not complete it will stay in the pending directory which prevents the backend server from processing the data.
I think this behavior is fine?
To the resend question:
The AS2 communication is an automated process. Because that a resend mechanism of messages if something fails makes no sense, the error will just occur n times which does not help (as in your case). That is one reason why our system has no resend mechanism. Our system refuses to retry the communication if a transaction number already exists, this prevents that a file is delivered more than one time by accident. There is no definition in the AS2 server how to deal with transactions that are already pending, its an implementation issue.
Regards
Heller
Hi Heller,
thanks for your answers. They still leave me somewhat puzzled, though. Is there a way the "pending" message could be completed? Your answers make me believe it will stay in the pending folder indefinitely. Correct?
I am not sure I can follow your reasoning about resending messages. As it is an automated process I would expect automated resending, at least a couple of tries. Then I would expect mec to acknowledge correct reception on the second try (it was received, correctly, was it not?). Instead mec replies that the message is pending (which apparently cannot be resolved any longer, though) which makes the sending server believe the message was not received correctly at all. If a pending (but actually failed) message is resent, why not just accept it?
The "peer not authenticated" problem was caused by the partner. No problem any more.
Regards,
Tobias
Tobias,
pending messages are moved to the error directory if the waiting time for a MDN with a "processed" state is exceeded.
The transaction state of a transfer is set to "ok" if the message has been transfered and the MDN was received with the state "processed".
Regards
Heller