locked
Error in NonRepudiation module RRS feed

  • Question

  • Can anyone tell me what would cause the following error on a BTS 2006 server w/MS BizTalk Accelerator for RosettaNet 3.3?

    ___________

    There was a failure executing the receive pipeline: "Microsoft.Solutions.BTARN.Pipelines.Receive, Microsoft.Solutions.BTARN.PipelineReceive, Version=3.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Pipeline " Receive Port: "RNIF_Async_Receive" URI: "/BTARNHttpReceive/BTSHTTPReceive.dll?xRNResponseType=async" Reason: Unable to remove the message non-repudiation details of an incoming message.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    ___________

     

    Thanks.

    Monday, September 15, 2008 3:53 PM

Answers

  • Usually the non-repudiation information is a certificate or digital signature so that it cannot be denied that the message was sent from some person or party. Here is a good link on the RNIF protocol that mentions it uses S/MIME with digital signatues for non-repudation: http://www.rosettanet.org/cms/export/sites/default/RosettaNet/Downloads/whitePapers/RNIF2x1x1x.1.pdf.

     

    It sounds like a message is coming in and the RosettaNet accelerator is having trouble determining who the digital signature belongs to so it cannot route the message successfully. Are you sure that you have setup the certificates for all of your trading partners for received messages? Also, I noticed the URI is running asynchronously. Have you configured the party properties to be aware that an asynchronous response is signed?

     

    Thanks,

     

    Wednesday, September 17, 2008 4:23 AM
    Moderator

All replies

  • Seems "message non-repudiation details" are some security information like certificates. Try to find out the description of the security mechanisms in this accelerator.
    Monday, September 15, 2008 11:34 PM
    Moderator
  • Usually the non-repudiation information is a certificate or digital signature so that it cannot be denied that the message was sent from some person or party. Here is a good link on the RNIF protocol that mentions it uses S/MIME with digital signatues for non-repudation: http://www.rosettanet.org/cms/export/sites/default/RosettaNet/Downloads/whitePapers/RNIF2x1x1x.1.pdf.

     

    It sounds like a message is coming in and the RosettaNet accelerator is having trouble determining who the digital signature belongs to so it cannot route the message successfully. Are you sure that you have setup the certificates for all of your trading partners for received messages? Also, I noticed the URI is running asynchronously. Have you configured the party properties to be aware that an asynchronous response is signed?

     

    Thanks,

     

    Wednesday, September 17, 2008 4:23 AM
    Moderator
  • Thanks. The information you provided is very useful. Since this particular trading partner has been setup in our system for several months now, the error was rather unexpected. Subsequent transmissions have been received successfully.
    Wednesday, September 17, 2008 8:12 PM
  • Hello Everyone ,

    can anybody suggest how to resolve this error .

    This error comes atleast once in a weak .

    Microsoft.Solutions.BTARN.Pipelines.Receive, Microsoft.Solutions.BTARN.PipelineReceive, Version=3.3.0.0, Culture=neutral, PublicKeyToken=************

    Pipeline RNIF_Async_Receive /BTARNHttpReceive/BTSHTTPReceive.dll?xRNResponseType=async

    Unable to update the message non-repudiation details of an incoming message.

    Regards,

    Mohit Gupta

    Wednesday, April 8, 2015 2:11 PM
  • Hey Mohit,

    Are the above suggestions didn't proved any helpful for you? check below article as well.

    https://msdn.microsoft.com/en-us/library/bb950340%28v=bts.10%29.aspx?f=255&MSPPError=-2147217396


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Thursday, April 9, 2015 5:56 AM
  • Hi Prashant,

    As per above answers , the issue is related to security but in our setup partner was setup from last 2 years and we daily sent invoices to them .

    we are getting this error few times in month for few Ack .

    Regards,

    Mohit

    Thursday, April 9, 2015 7:49 AM