none
MDN not being generated RRS feed

  • Question

  • Hi. We are currently experiencing a very strange situation consisting on the following: MDN is not being generated for a particular partner, while for other partner with a similar configuration it is. We were assuming the partner was receiving the MDN because in the AS2/MDN Status window the transaction is reported as Acknowledged_Processed, but, unlike transactions for the other partner, this partner's transaction don't have an mdn associated to them (right-click, ViewMDN message menu option not available). By the way, there are no suspended messages.

    So we used a network traffic monitor and we confimed BT is not creating the MDN for this partner, not even after forcing the Agreement to generate one after ignoring the incoming As2 message's settings.

    Here a comparison of two incoming headers:

    Any ideas much appreciated. Thanks.

     

    Environment: BizTalk 2010 beta, IIS 7.5

      incoming as2 having no mdn generated
      incoming as2 having mdn generated
    1 ACCEPT-ENCODING: DEFLATE, GZIP, X-GZIP, COMPRESS, X-COMPRESS    
    2 AS2-FROM:  PARTNER_A   1 AS2-FROM:  PARTNER_B  
    3 AS2-TO: US   2 AS2-TO:  US  
    4 AS2-VERSION: 1. 1   3 AS2-VERSION: 1. 2  
        4 CONNECTION: CLOSE, TE
        5 CONTENT-DISPOSITION: ATTACHMENT; FILENAME="SMIME.P7M"
    5 CONTENT-LENGTH: 5186   6 CONTENT-LENGTH: 4278  
    6 CONTENT-TYPE: APPLICATION/PKCS7-MIME; SMIME-TYPE=ENVELOPED-DATA 7 CONTENT-TYPE: APPLICATION/PKCS7-MIME; SMIME-TYPE=ENVELOPED-DATA ; NAME=SMIME.P7M  
    7 DATE: THU, 21 OCT 2010 1 9:48:06 GM T 8 DATE: THU, 21 OCT 2010 1 2:23:40 ED T
    8 DISPOSITION-NOTIFICATION-OPTIONS: SIGNED-RECEIPT-PROTOCOL=OPTIONAL,PKCS7-SIGNATURE; SIGNED-RECEIPT-MICALG=OPTIONAL,SHA1 9 DISPOSITION-NOTIFICATION-OPTIONS: SIGNED-RECEIPT-PROTOCOL=OPTIONAL, PKCS7-SIGNATURE; SIGNED-RECEIPT-MICALG=OPTIONAL, SHA1 , MD5  
    9 DISPOSITION-NOTIFICATION-TO: HTTP://address_a   10 DISPOSITION-NOTIFICATION-TO: HTTP:// address_b:8080/AS2/HTTPRECEIVER  
        11 EDIINT-FEATURES: MULTIPLE-ATTACHMENTS, CEM
        12 EXPECT: 100-CONTINUE
    10 FROM: partner_a .COM 13 FROM:  partner_b .COM
    11 HOST: US.COM:9080 14 HOST: US.COM:9080
    12 MESSAGE-ID: < 013496679256565525@partner_.COM > 15 MESSAGE-ID: < MENDELSON_OPENSOURCE_AS2-1287678219687-7@partner_b >
    13 MIME-VERSION: 1.0 16 MIME-VERSION: 1.0
    14 POST /AS2/BTSHTTPRECEIVE.DLL HTTP/1. 0   17 POST /AS2/BTSHTTPRECEIVE.DLL HTTP/1. 1  
    15   18 REC IPIENT-ADDRESS: HTTP://US.COM:9080/AS2/BTSHTTPRECEIVE.DLL  
    16 SUBJECT: AS2 DATA MESSAGE REQUEST   19 SUBJECT: AS2 MESSAGE  
    17 USER-AGENT: RPT-HTTPCLIENT/0.xxx (LINUX)   20 USER-AGENT: MENDELSON OPENSOURCE AS2 1.1 BUILD 33 - WWW.MENDELSON-E-C.COM  
    18   21  

    C# + BizTalk2009 Developer
    Friday, October 22, 2010 3:59 PM

Answers

  • If you are using synchronous MDN and your partner is not expecting the MDN then BizTalk will not send MDN [Not very sure but seen behaviour, this could happen if your partner is using other than BizTalk]. Try sending MDN asynchronously. 
    Best Regards, Vishnu
    • Marked as answer by mape1082 Friday, October 22, 2010 9:15 PM
    Friday, October 22, 2010 6:24 PM
  • Found a solution:

    Moved to using asynchronous instead. Our BT app has a two way static send port, and a two way static receive port. For some reason the Two way receive was causing the following error:  An 'AS2 message was received that did not contain the AS2-From header..".  I assume this is related to a failed creation of an MDN.

    We solved this by creating a dedicated static send port subscribed to asynchronous MDN and to the corresponding AS2 party.

    Thanks for you input.


    C# + BizTalk2009 Developer
    • Marked as answer by mape1082 Friday, October 22, 2010 9:15 PM
    Friday, October 22, 2010 8:55 PM

All replies

  • If you are using synchronous MDN and your partner is not expecting the MDN then BizTalk will not send MDN [Not very sure but seen behaviour, this could happen if your partner is using other than BizTalk]. Try sending MDN asynchronously. 
    Best Regards, Vishnu
    • Marked as answer by mape1082 Friday, October 22, 2010 9:15 PM
    Friday, October 22, 2010 6:24 PM
  • Thanks. We have tried both synchronous and asynchronous. What they say is happening is that in synchronous they are able to send the doc, we receive it, but the mdn never reaches them (like if the  mdn was never generated):

    <incoming as2 message> HTTP/1.1 200 OK
    Content-Length: 0
    Content-Type: application/edi-x12
    Server: Microsoft-IIS/7.5
    X-Powered-By: ASP.NET
    Date: Fri, 22 Oct 2010 15:04:44 GMT
    Connection: close

    A good synchronous response is as follows:

    <incoming as2 message> HTTP/1.1 200 OK
    Content-Length: 4047
    Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="_C745549D-026E-4BCB-819B-82FAC16F9633_"
    Server: Microsoft-IIS/7.5
    AS2-To: THEM
    Mime-Version: 1.0
    Message-ID: <PC-XX_96A717F4-2693-48E1-8036-AE461E16872F>
    EDIINT-Features: multiple-attachments
    AS2-From: US
    AS2-Version: 1.2

     

    Now, in Asynchronous, they say they are getting an error in their system saying that the received message does not specify As2-from nor As2-to headers. I dont have now an http log for an async session, but will get one at the earliest.

     

    Thanks again.

     

     

     

     

     


    C# + BizTalk2009 Developer
    Friday, October 22, 2010 6:36 PM
  • Found a solution:

    Moved to using asynchronous instead. Our BT app has a two way static send port, and a two way static receive port. For some reason the Two way receive was causing the following error:  An 'AS2 message was received that did not contain the AS2-From header..".  I assume this is related to a failed creation of an MDN.

    We solved this by creating a dedicated static send port subscribed to asynchronous MDN and to the corresponding AS2 party.

    Thanks for you input.


    C# + BizTalk2009 Developer
    • Marked as answer by mape1082 Friday, October 22, 2010 9:15 PM
    Friday, October 22, 2010 8:55 PM