The following are the most common errors you might encounter when using the Oracle Database adapter, along with their probable cause and resolution.
Error in loading the adapter bindings
Problem
When you try to start the Add Adapter Service Reference Visual Studio Plug-in or the Consume Adapter Service BizTalk Project Add-in, you get the following error:
There was an error loading the binding, <binding name>, from your system configuration.
ConfigurationErrorsException: Exception has been thrown by the target of an invocation.
Cause
When you try to start the Add Adapter Service Reference Plug-in or the Consume Adapter Service Add-in, WCF loads the adapter bindings for all the installed adapters. In turn, the adapter bindings are dependent on the specific client software for the enterprise application. You might face this issue for one or both of the following reasons:
- The required LOB client software is not installed on the computer where you installed the adapter.
- You did a Typical or Complete installation of the adapter, which installs all three adapters contained in the BizTalk Adapter Pack. However, the LOB client libraries might be installed for only one enterprise application. As a result, the GUI fails to load the bindings for the other two adapters.
Resolution
- Make sure that the required LOB client versions are installed on the computer where you installed the BizTalk Adapter Pack. The following table lists the required Oracle client DLLs:
For 32-bit | For a 32-bit Oracle client you need: - Oracle client version 10.2.0.3.
- Oracle Data Provider for .NET 2.0, 10.2.0.2.20. This is available as part of Oracle Data Access Components (ODAC) 10.2.0.2.21.
You must install the client in the following order: - Install the Oracle client 10.2.0.3.
- Install ODAC in the same destination folder as the Oracle client.
|
For 64-bit | For a 64-bit Oracle client you need: - Oracle client version 10.2.0.3. This is available as part of the following patches:
- 10.2.0.3.0 (patch number 5337014)
- 10.2.0.3 patch 10 (patch number 6344569 )
- Oracle Data Provider for .NET 2.0, 10.2.0.3.02. This is available as part of Oracle Data Access Components (ODAC) 10.2.0.3 for Windows x64.
You must install the client in the following order: - Install ODAC.
- Install Oracle client patch 5337014 in the same destination folder as ODAC.
- Install Oracle client patch 6344569 in the same destination folder as ODAC.
|
- Make sure you do a custom installation of the adapters to install only the adapter you need.
Note |
|---|
| To make sure your application works with the most recent version of ODP.NET, you must have the "policy DLLs" installed on the computer and registered in the GAC. For more information, see the ODP.NET FAQ at http://go.microsoft.com/fwlink/?LinkId=92834. |
The Oracle database adapter does not display in the list of adapters in BizTalk Server Administration console
Problem
Unlike the earlier version of the adapters shipped with BizTalk Server, the Oracle Database adapter shipped with BizTalk Adapter Pack does not show up in the list of adapters in the BizTalk Server Administration console.
Cause
The latest Oracle Database adapter is a WCF custom binding. So, while the BizTalk Server Administration console displays the WCF-Custom adapter, it does not display the WCF custom bindings and hence, does not display the WCF based Oracle Database adapter.
Error in connecting to the Oracle database
Problem
When you try to connect to the Oracle database, the Add Adapter Service Reference Plug-in or the Consume Adapter Service Add-in gives the following error:
Connecting to the system LOB failed.
Could not load file or assembly 'Oracle.DataAccess' Version=2.102.2.20, Culture=neutral, PublicKeyToken=<token>' or one of its dependencies.
The system cannot find the file specified.
Cause
The Oracle client DLL, Oracle.DataAccess.dll, is not added to the global assembly cache (GAC).
Resolution
Add the Oracle.DataAccess.dll to the GAC on the computer where the BizTalk Adapter Pack is installed. The different versions of the DLL required for 32-bit and 64-bit platforms are:
- For 32-bit Oracle.DataAccess.dll (version 2.102.2.20)
- For 64-bit: Oracle.DataAccess.dll (version 2.102.3.2)
This DLL is installed on your computer at <installation drive>:\oracle\product\10.2.0\client_1\odp.net\bin\2.x.
Error while retrieving XML output with more than 65,536 nodes
Problem
The adapter gives the following error when retrieving XML output that has more than 65,536 nodes.
Maximum number of items that can be serialized or deserialized in an object graph is '65536'.
Change the object graph or increase the MaxItemsInObjectGraph quota.
Cause
The adapter cannot serialize and deserialize an object with more than 65,536 items.
Resolution
You can fix this issue by setting the maxItemsInObjectGraph parameter. You can set this in either of the following two ways:
- Set this parameter by changing the
maxItemsInObjectGraph parameter in the ServiceBehavior attribute on your service class.
- Add the following to your application's app.config file.
<behaviors>
<endpointBehaviors>
<behavior name="NewBehavior">
<dataContractSerializer maxItemsInObjectGraph="65536000" />
</behavior>
</endpointBehaviors>
</behaviors>
A sample app.config looks like this.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="NewBehavior">
<dataContractSerializer maxItemsInObjectGraph="65536000" />
</behavior>
</endpointBehaviors>
</behaviors>
<client>
<endpoint behaviorConfiguration="NewBehavior" binding="oracleDBBinding"
contract="IOutboundContract" name="oracle_ICalculator" />
</client>
</system.serviceModel>
</configuration>
Error while performing operation on the Oracle database
Problem
The adapter gives the following error when you perform any operation on the Oracle database.
Microsoft.ServiceModel.Channels.Common.UnsupportedOperationException: The request message cannot have an 'Action' that is empty
Cause
The WCF action for the message is not specified. WCF requires a SOAP action to be specified for every operation, which informs the adapter about the operation to be performed on the LOB application.
Resolution
Specify the SOAP action for the messages that the adapter sends:
- For BizTalk projects, specify the SOAP action in the send port or as a message context property in a BizTalk orchestration. For instructions, see Specifying SOAP Action.
- For the WCF channel model, specify the SOAP action when you create the WCF message instance. For example:
Message.CreateMessage(MessageVersion.Default, action, readerIn);
- For the WCF service model, SOAP actions do not have to be explicitly specified. They are automatically generated in the proxy at design-time as .NET method attributes.
To see a list of actions for each operation, see Technical Reference.
XmlReaderParsingException due to an incorrect operation name in the specified action
Problem
The BizTalk Server Administration Console gives the following error when sending messages to an Oracle database:
Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: Invalid argument:
<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Operation Name="<operation_name>" Action="<action>" />
</BtsActionMapping>
Cause
If you configure a WCF-Custom port by importing the port binding file created by the Consume Adapter Service BizTalk Project Add-in, the action in the port is specified in the following format:
<BtsActionMapping>
<Operation Name="Op1" Action="http://MyService/Svc/Op1" />
</BtsActionMapping>
In the above format, the operation name is governed by the operation you chose while generating the schema. For example, if you generated schema for the Insert operation on a table, the operation name in the action will be "Insert". However, the operation name in the logical port created in the BizTalk orchestration in Visual Studio might be different.
Resolution
Make sure the operation names in both the logical port (in the BizTalk orchestration in Visual Studio) and the physical port (in BizTalk Server Administration Console) are same.
Error while specifying a connection URI for a WCF-Custom port in BizTalk
Problem
BizTalk Server 2006 R2 gives the following error when you specify a connection URI to connect to the Oracle database.
Error saving properties.
(System.ArgumentException) The specified address is invalid.
(System.ArgumentException) Invalid address;
"<connection URI>" is not a well-formed absolute uri.
Cause
The connection URI does not adhere to the standard encoding format. For example, the value for a parameter might contain a space.
Resolution
Make sure the connection URI you specify adheres to the standard encoding format. For example, a blank space must be replaced by "%20".
Invalid cursor exception while invoking stored procedures that take REF CURSOR parameters
Problem
When you invoke procedures in the Oracle database that take REF CURSOR inputs, you might get the following exception:
Microsoft.ServiceModel.Channels.Common.TargetSystemException: ORA-01001: invalid cursor ---> Oracle.DataAccess.Client.OracleException
Cause
The PL/SQL block for the procedure that you are invoking could be piping the REF CURSORs, that is, the IN REF CURSOR could be getting assigned to the OUT REF CURSOR.
Resolution
The PL/SQL block must not pipe the IN to the OUT REF CURSORs without proper processing.
Error while validating the response for the ReadLOB operation using BizTalk Server
Problem
While performing a ReadLOB operation using the Oracle Database adapter with BizTalk Server 2006 R2, the response from the Oracle database fails validation against the Web Services Description Language (WSDL).
Cause
The WSDL contains a StreamBody node name that is defined for execution of service-based requests, but is not needed for BizTalk scenarios. Therefore, when the output XML, which does not contain the StreamBody node, is compared with the WSDL, validation fails.
Resolution
Remove the StreamBody node from the WSDL when validating against the output that was generated using BizTalk Server. Perform the following steps to do so:
- The WSDL containing the StreamBody node looks like this.
<xs:element name="ReadLOBResponse">
<xs:annotation>
<xs:documentation>
<doc:action xmlns:doc="http://schemas.microsoft.com/servicemodel/adapters/metadata/documentation">http://Microsoft.LobServices.OracleDB/2007/03/SCOTT/Table/TBL_ALL_DATATYPES/ReadLOB/response</doc:action>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="1" name="ReadLOBResult" nillable="true" type="ns3:StreamBody" />
</xs:sequence>
</xs:complexType>
</xs:element>
Replace the preceding with the following.
<xs:element name="ReadLOBResponse">
<xs:annotation>
<xs:documentation>
<doc:action xmlns:doc="http://schemas.microsoft.com/servicemodel/adapters/metadata/documentation">http://Microsoft.LobServices.OracleDB/2007/03/SCOTT/Table/TBL_ALL_DATATYPES/ReadLOB/response</doc:action>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="1" name="ReadLOBResult" type="xs:base64Binary" />
</xs:sequence>
</xs:complexType>
</xs:element>
In this step, you removed the reference to type="ns3:StreamBody" in the original XSD and replaced it with type="xs:base64Binary". Also, you removed the nillable="true" value from the original XSD.
- Remove the following from the WSDL.
<xs:complexType name="StreamBody">
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="1" name="Stream">
<xs:simpleType>
<xs:restriction base="xs:base64Binary">
<xs:minLength value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="StreamBody" nillable="true" type="ns3:StreamBody" />
Note |
|---|
| ReadLOB operation is not supported with BizTalk Server. You should use a table Select operation to read LOB data from a BizTalk Server solution. |
Schema validation may fail in polling scenarios
Problem
Schema validation fails in scenarios where the Oracle Database adapter polls database tables that contain fields of type ROWID or UNROWID.
Cause
At design-time, when the adapter generates metadata for the table containing fields of type ROWID or UNROWID, the schema includes “nillable=false”, which means that fields of type ROWID or UNROWID cannot be null. However, at run-time when the adapter retrieves the metadata, the fields of type ROWID or UNROWID contain null values. Hence the schema validation fails.
Resolution
If you are using the Oracle Database adapter with BizTalk Server, you may choose to disable schema validation. Alternatively, you may manually edit the schema to change “nillbale=true” for ROWID and UNROWID data types.
'Unreasonable conversion requested' error when executing stored procedures with Record Types as parameters
Cause
Consider a scenario where an Oracle stored procedure takes a Record Type as a parameter. Assume that the Record Type is declared as <table name>%ROWTYPE, where the table has a column of LONG data type. When the Oracle Database adapter encounters the LONG data type, it sets the size of the data type equal to the value specified for the LongDatatypeColumnSize binding property. However, the Oracle database does not define a size for the LONG data type. So, when the adapter invokes the stored procedure, it results in an ‘Unreasonable conversion requested’ error.
Resolution
If a Record Type has a LONG data type, you must explicitly define it as part of a package.
The adapter does not recognize the action on the physical port even though you use the binding file generated by the Consume Adapter Service add-in to create the ports
Problem
After you use the Consume Adapter Service Add-in to generate schema for a specific operation on the Oracle database, the add-in also creates a port binding file. You can import this binding file using the BizTalk Server Administration console to create physical ports in BizTalk Server. However, when you send messages to the Oracle database using such ports, the adapter fails to understand the action specified on the port and gives an error similar to the following:
Microsoft.ServiceModel.Channels.Common.UnsupportedOperationException: Incorrect Action
<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Operation Name="<op_name>" Action="<action>" />
</BtsActionMapping>. Correct the specified Action, or refer to the documentation on the allowed formats for the Actions.
Cause
When you create logical ports in a BizTalk orchestration, you specify certain names for the operations on those ports or you just use the default names like Operation_1, Operation_2, etc. However, in the binding file generated by the Consume Adapter Service Add-in, the operation name is same as the name of the Oracle database operation for which you generate metadata. For example, if you generate metadata for Select operation on ACCOUNTACTIVITY table in the Oracle database, the action will be set to the following:
<Operation Name="Select" Action="http://Microsoft.LobServices.OracleDB/2007/03/SCOTT/Table/ACCOUNTACTIVITY/Select" />
When you import the binding file, the same action is set on physical port. So, the operation names on the logical port (Operation_1, Operation_2, etc.) do not match the operation names specified in the action on the physical port, resulting in an error.
Resolution
Make sure the operation name in the logical port is the same as the operation name specified as part of the action in the physical port. Do one of the following:
- Change the operation name in the logical port in BizTalk orchestration from Operation_1, etc. to the operation for which you generate metadata, for example Select.
- Change the operation name in the action on the physical port to the operation name in the logical port. For example, you could change the action in the physical port to resemble the following:
<Operation Name="Operation_1" Action="http://Microsoft.LobServices.OracleDB/2007/03/SCOTT/Table/ACCOUNTACTIVITY/Select" />
The adapter fails to execute a stored procedure within a package that does not belong to a user’s default schema
Problem
The adapter gives the following error while executing a stored procedure within a package that does not belong to a user’s default procedure.
Microsoft.ServiceModel.Channels.Common.TargetSystemException:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'TESTER.GET_IB_DETAILS_SIMPLE' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored ---> Oracle.DataAccess.Client.OracleException
ORA-06550: line 1, column 7: PLS-00201: identifier 'TESTER.GET_IB_DETAILS_SIMPLE' must be declared
Cause
The adapter does not append the schema name with the stored procedure name in the namespace.
Resolution
Install the hotfix that fixes this issue. To download the hotfix, refer to the associated KB article at http://go.microsoft.com/fwlink/?LinkId=125090.
Error with RootNode TypeName in BizTalk Projects
Problem
In a BizTalk project in Visual Studio, if the schemas generated from the Consume Adapter Service Add-in contains invalid characters or reserved words for the RootNode TypeName property, the following error will occur while compiling the project:
Node <node reference> - Specify a valid .NET type name for this root node.
The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier).
Resolution
- Right-click the rood node referenced in the error and select Properties.
- For the RootNode TypeName property, remove any illegal characters or reserved words, for example, dot (.).
Adapter fails to reconnect to the Oracle database after the Oracle instance restarts
Problem
If you have configured the adapter to send or receive messages from an Oracle database, and the Oracle session restarts, the adapter may fail to reconnect to the Oracle database.
Resolution
- For a send port configuration
You may choose to do one of the following:
- Restart the WCF-custom send port for the Oracle Database adapter.
- Set the value of UseOracleConnectionPool to false so that the next time an Oracle instance goes down, the adapter creates a new connection and does not use a connection from the pool.
- For a receive port configuration
You may choose to do one of the following:
- Restart the BizTalk Server host instance.
- Set the value of UseOracleConnectionPool to false so that the next time an Oracle instance goes down, the adapter creates a new connection and does not use a connection from the pool.