none
Biztalk Oracle Transaction and update/insert into the Oracle database RRS feed

  • Question

  • Hi

     

    Kindly help us or advice us how to avoid the below issue.

     

    Issue 1:
    Scenario: Sending iDoc into this interface. BizTalk will create an Oracle Transaction and update/insert into the Oracle database.

    Affected interface:
    1) Shell.BizTalk.EP.PM.EPBP.EDSClassCharacteristic
    2) Shell.BizTalk.EP.PM.EPBP.MaintChel

    Event Type: Error
    Event Source: BizTalk Server 2006
    Event Category: (1)
    Event ID: 5754
    Date:  7/28/2008
    Time:  10:33:34 AM
    User:  N/A
    Computer: AMSD2A-S-6015
    Description:
    A message sent to adapter "WCF-Custom" on send port "Shell.BizTalk.EP.PM.EPBP.EDSClassCharacteristic.SendPortToEDS" with URI "oracledb://eds_classchar/" is suspended.
     Error details: System.InvalidOperationException: The Inner Channel to use was not found for the key {3C3796D7-F4C2-4ECD-9E29-5D669F799B34}_{ACD5DEDE-5D0D-42A0-AA8B-D4E4114AEF05};URI=oracledb://eds_classchar/. Specify a valid key.

    Server stack trace:
       at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
       at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
       at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
       at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
     MessageId:  {832DD4FD-3D6D-418B-A552-36E1152DE5F7}
     InstanceID: {529597E7-67DB-48E1-8F04-17F3C54D7A0D}

     

     

    Adding more context to the Issue :

    Current Design:
    Refer to the following URL
    http://blogs.msdn.com/adapters/archive/2007/10/24/enablebiztalklayeredchannel-property-in-oracledb-adapter.aspx

    We are using this transaction design for processing header (first message) and line item records (second message) in a single transaction, which is not running in the UAT enviroinment with 2 of the 2 DBSendHostx64 host instances started.

    Suspected cause:
    The error is happening at the 2nd message with transaction satus as "REUSE". As BizTalk is load balancing messages among these 2 Host Instances, transaction started in first host instance (with first message transaction status "START") is some how not visible to the second host instance to reuse the same transaction.

     

     


     

    Wednesday, July 30, 2008 7:45 AM

Answers

  • The Adapter is loaded in-proc in a BTS host instance.

    Since separate host instances are separate processes, the adapter can not remember / retain state between them.

    Monday, September 15, 2008 7:45 AM

All replies

  • In your scenario, are you sending the subsequent message to the same send port? If so it should be going to the same host instance.

     

    Can you explain your multiple host instance scenario some more? Have you tried using a single host instace and does that work?

    Thursday, July 31, 2008 4:58 AM
  • Hello Jayanthi,

    Thanks for the reply.

    Yes the messagezs are sent to the same send port.

    We are having two host instances to balance the load. And with single host instance it works fine.

    Any thoughts on this??

     

    Regards,

    Shoba.

    Friday, August 1, 2008 10:31 AM
  • The Adapter is loaded in-proc in a BTS host instance.

    Since separate host instances are separate processes, the adapter can not remember / retain state between them.

    Monday, September 15, 2008 7:45 AM
  • Please note that Oracle Transactions in this manner are not supported, and will stop functioning in the BizTalk Adapter Pack V2. (For example, we have removed the blog post which you refer to above) (also, this scenario was not present in the documentation).
    Monday, September 15, 2008 11:01 AM