none
Biztalk Adapter Pack - WCF Custom - OracleDB - UDT Assembly Error RRS feed

  • Question

  • Hi There :-)

    We have a problem with Biztalk Adapter pack 2.0 :

    Two independent BizTalk 2010 applications on the same Biztalk 2010 server each receives a Flat file XML input. The XML-schema is directly send to a WCF-Custom Two-Way Request-Response port that communicates with a Oracle database for data retrieval and the data are returned to the Request-Response port in Biztalk.

    The response XML_Schema is then send to a flat file send port in Biztalk that writes the xml-data to a XML-file on disk.

    To decode the response from the Oracle database, the Request-Response port use a UDT assembly that was generated during development. The UDT assembly has been placed in c:\program files\biztalk server 2010 Server\ folder and is strongly named.

    The UDT assembly has then been specified in the UserAssemlyLoadPath property on the Binding specification on the Oracle Send/Receive Port in Biztalk.

    userAssembliesLoadPath="C:\Program Files\Microsoft BizTalk Server 2010\BizTalkFredag_UDT.dll"

    Each of the applications works fine, when only ONE of the applications are activated by an incoming XML-file and data are nicely received back from Oracle and written to the output XML-file.

    If the other application afterwards gets activated, the communication with the Oracle database fails with the following message:

    A message sent to adapter "WCF-Custom" on send port "SendPort_Fredag_Oracle" with URI "oracledb://DCK_EDU1" is suspended.

     Error details: System.InvalidOperationException: Custom type mapping for 'dataSource='DCK_EDU1' schemaName='DCK_BIZTALK' typeName='TEST_SKEMATYPE'' is not specified or is invalid.

    If the BizTalk Host instance is then restarted, the other application then works fine, but the first application then fails with exactly the same error message.

    It seems like the first activated UDT assembly gets stuck inside BizTalk or WCF, and then the other UDT assembly fails on activation.

    The described scenario can be recreated with any two Biztalk applications that each uses a different Oracle UDT assembly to decode the Oracle response. If the two Biztalk applications make use of the same UDT assembly everything works fine.

    We have experienced the same scenario on 3 different servers, two of them running Biztalk Server 2009, and on running Biztalk 2010

    Software

    Version

    Version

    Windows Server

    2008

    2008

    BizTalk

    2010

    2009

    Oracle Client

    11.2g

    11.1g

    Biztalk Adapter Pack

    2010

    2.0

    WCF LOB Adapter SDK

    2010

    2.0

    Oracle Server

    10.2g

    10.2g

    We will be very happy to hear from anyone with experience re. the specifed problem, or if anyone has any knowledge about if it is a known bug in the Adapter pack or in the Oracle client software.

    Thanks in advance.

    Thomas
    Copenhagen, Denmark


    Thomas Elbek
    Monday, January 17, 2011 8:52 AM

Answers

  • This is an ODP.NET limitation. You need to have all the UDTs in a single assembly. If ODP.NET finds one assembly with UDTs, it does not try to look any further. Therefore, the UDTs from the first assembly alone work.
    -- Please mark as answered if this answers your question.
    • Marked as answer by Thomas E Wednesday, January 19, 2011 11:44 AM
    Wednesday, January 19, 2011 11:32 AM

All replies

  • The reason for this is that ODP.NET library requires the UDT assembly to be present either in the GAC or in the same folder as the executing process. If you GAC your UDT assembly, the issue should go away.
    -- Please mark as answered if this answers your question.
    Tuesday, January 18, 2011 8:48 AM
  • Both UDT assemblies are placed in C:\Program Files\Microsoft BizTalk Server 2010\ which is the executing path for the Biztalk BTSNTSvc.exe service.

    I also tried to GAC'e both UDT assemblies, but it didn't cause any inprovement or change.

    Please not that each of the two applications can be broght to work, if and when the other application is not activated.

    We have recreated the error on three different servers, with very different UDT assemblies and Biztalk applications.

    Thomas Elbek
    Tuesday, January 18, 2011 1:02 PM
  • This is an ODP.NET limitation. You need to have all the UDTs in a single assembly. If ODP.NET finds one assembly with UDTs, it does not try to look any further. Therefore, the UDTs from the first assembly alone work.
    -- Please mark as answered if this answers your question.
    • Marked as answer by Thomas E Wednesday, January 19, 2011 11:44 AM
    Wednesday, January 19, 2011 11:32 AM
  • Hi Manas


    Thanks for your answer !!, I had just for fun, made such an assembly a few days ago, and it worked very fine. But I kind of disregarded the solution because I didn't find it very manageable with many different UDT assemblies housing totally different UDT types.

    As for now, I have marked your answer as The Answer to the problem. One guy from Microsoft had another idea about creating a new Biztalk App. called BizUDT, and then add all the UDT assemblies to that new app., and then reference BizUDT from the other Biztalk applications.

    But I don't know if it will work at all.

    Have a nice Time :-)

    Thomas




    Thomas Elbek
    Wednesday, January 19, 2011 11:50 AM
  • Hi again

    I found the solution to this problem, since ODT.Net sticks to the first loaded UDT assembly after the host instance has been restartet, the solution is to create a factory assembly that has references to the physical UDT assemblies creted within Visual Studio.

    The Factory assembly will then provide properties with get{} methods for each class in the referenced UDT assemblies.

    The Factory UDT assembly is then copied to Biztalk folder under \program files\ together with the referenced UDT assemblies, and Factory UDT assembly is then referenced on ALL Send/Recieve ports that previously used the specific UDT assemblies in USerAssembliesLoadPath proprty under Bindings.

    ODT.Net will now load the Factory UDT assembly and call it's get{} methods to retrieve instances of the classes from the underlying UDT assemblies, and since all ports reference the same UDT assembly, we get rid of the limitation in ODT.Net

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;

    using DCK_BIZTALK;

    namespace Master_UDT
    {
        public class Master_UDTClass
        {
            public DCK_BIZTALK.TEST_NAVNEKODE TEST_NAVNEKODE
            {
                get { return new DCK_BIZTALK.TEST_NAVNEKODE(); }
            }

            public DCK_BIZTALK.TEST_NAVNEKODE_OBJ TEST_NAVNEKODE_OBJ
            {
                get {return new DCK_BIZTALK.TEST_NAVNEKODE_OBJ();}
            }

            public DCK_BIZTALK.TEST_NAVNEKODE_OBJFactory TEST_NAVNEKODE_OBJFactory
            {
                get { return new TEST_NAVNEKODE_OBJFactory();}
            }

            public DCK_BIZTALK.TEST_NAVNEKODEFactory TEST_NAVNEKODEFactory
            {
                get { return new TEST_NAVNEKODEFactory(); }
            }

            //------------------------------------------------------------------------

            public DCK_BIZTALK.TEST_SKEMATYPE TEST_SKEMATYPE
            {
                get { return new TEST_SKEMATYPE(); }
            }

            public DCK_BIZTALK.TEST_SKEMATYPE_OBJ TEST_SKEMATYPE_OBJ
            {
                get{ return new TEST_SKEMATYPE_OBJ();}
            }

            public DCK_BIZTALK.TEST_SKEMATYPE_OBJFactory TEST_SKEMATYPE_OBJFactory
            {
                get { return new TEST_SKEMATYPE_OBJFactory(); }
            }

            public DCK_BIZTALK.TEST_SKEMATYPEFactory TEST_SKEMATYPEFactory
            {
                get { return new TEST_SKEMATYPEFactory(); }
            }
        }
    }


    Thomas Elbek
    Friday, January 21, 2011 11:10 AM
  • This is an ODP.NET limitation. You need to have all the UDTs in a single assembly. If ODP.NET finds one assembly with UDTs, it does not try to look any further. Therefore, the UDTs from the first assembly alone work.
    -- Please mark as answered if this answers your question.

    At which level does this restriction apply?

    - per Port
    - per Application
    - per Host Instance

    Wednesday, March 29, 2017 8:55 PM