Troubleshoot operational issues with the Oracle Database adapter
Troubleshooting techniques to resolve operational errors that you may experience using Microsoft BizTalk Adapter for Oracle Database.
Enable tracing
For information about tracing support in the Oracle Database adapter, see Diagnostic tracing and message logging for the Oracle Database adapter.
Known Issues
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 the 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 adapters.
Resolution
Make sure that the required LOB client versions are installed on the computer where you installed the BizTalk Adapter Pack. Supported Line-of-Business (LOB) and Enterprise systems lists the supported client versions.
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 Oracle Data Provider for .NET on Oracle's website.
The Oracle database adapter does not display in the list of adapters in BizTalk Server Administration console
Problem
The Oracle Database adapter inlcuded with BizTalk Adapter Pack is not listed in the list of adapters in the BizTalk Server Administration console.
Cause
The Oracle Database adapter is a WCF custom binding. So, although 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.
Resolution
You can explicitly add the Oracle Database adapter to the BizTalk Server Administration console by following the steps mentioned in Adding the Oracle Database Adapter to BizTalk Server Administration Console.
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
maxItemsInObjectGraphparameter in theServiceBehaviorattribute 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 operations on the Oracle database
Problem
The adapter gives the following error when performing any operation on the Oracle database using BizTalk Server.
For BizTalk Server
System.ArgumentNullException: Value cannot be null.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 in the send port or as a message context property in a BizTalk orchestration. For instructions, see Configure the SOAP action for Oracle Database. See Messages and Message Schemas to see a list of actions for each operation.
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 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, 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" />
Adapter throws an overflow exception (“System.OverflowException”) on executing an operation
Problem
Using the adapter, if you try to perform an operation containing Oracle numeric data types inside DataSets or weakly-typed REF CURSORS, the adapter might throw an overflow exception.
Cause
This happens if you supply a large value for the Oracle numeric data type inside DataSets or weakly-typed REF CURSORS that cannot fit into the respective .NET type.
Resolution
If you want to pass large values for the Oracle numeric data type inside DataSets or weakly-typed REF CURSORS, you must enable safe typing by setting the value of the EnableSafeTyping binding property to true. Enabling safe typing exposes the Oracle numeric data type inside DataSets or weakly-typed REF CURSORS as strings.
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 (.).
Invalid binding warning when using the adapter in Visual Studio
Problem
When you use the adapter to create an application in Visual Studio 2013 and you open the configuration file (app.config) generated by the adapter, you see a warning similar to the following:
The element 'bindings' has invalid child element 'oracleDBBinding'. List of possible elements expected: 'basicHttpBinding, customBinding, ...
Cause
This warning appears because the Oracle Database adapter binding, oracleDBBinding, is not a standard binding shipped with the Windows Communication Foundation (WCF).
Resolution
You can safely ignore this warning.
BizTalk Server throws an exception if you use more than one Notification schema in the same application or use the Notification schema across multiple applications on the same host
Problem
BizTalk Server throws an XLANG exception or an exception stating that the application cannot locate the document specification because multiple schemas matched the message type.
Cause
This happens because of either of the following:
You have generated more than one Notification schema in a BizTalk Server project, deployed it to a BizTalk Server application, and then ran the application to receive notifications from the Oracle database. Because the Notification schemas are common, there is a conflict between the schemas that are deployed in the BizTalk Server application.
In case of multiple projects, you have generated a Notification schema for each of the BizTalk Server projects, deployed each project to a separate BizTalk Server application on the same host, and then ran an application or applications to receive notifications from the Oracle database. Because the schemas and assemblies are accessible across the applications in BizTalk Server, there is a conflict between the common schemas deployed under various BizTalk Server applications and assemblies.
Resolution
Use a single Notification schema file for a BizTalk Server application. If you need to use the Notification schema in multiple BizTalk Server applications on the same host, create an application containing a single Notification schema, and then use the notification schema from all other applications in BizTalk Server.
Memory usage and thread count increases when using the adapter in a transacted inbound operation
Problem
In a transacted inbound operation, such as Polling, if there is no data available in the table being polled and the adapter continues to poll, over a period of time you experience an increase in the memory usage and the thread count.
Cause
If there is no data available in the table being polled, after every receive timeout cycle, Windows Communication Foundation (WCF) spawns a new thread to continue the polling operation. Hence, the thread count and memory usage increases over a period of time. However, if the table being polled has some data, the same thread continues to perform all subsequent polls.
Resolution
We recommend setting the ReceiveTimeout to the maximum possible value, which is 24.20:31:23.6470000 (24 days) so that a new thread is spawned only every 24 days. This will ensure that the memory usage and thread count does not grow too much too soon.
Note
If SqlAdapterInboundTransactionBehavior has been set, make sure the TransactionTimeout is also configured to maximum possible value, which is 24.20:31:23.6470000 (24 days). When using this workaround, we can add the SqlAdapterInboundTransactionBehavior only if the transaction isolation level has to be configured. Else, it is a best practice to remove that behavior.
For more information about the ReceiveTimeout binding property, see Read about the Oracle Database adapter binding properties. For instructions on specifying binding properties, see Configure the binding properties for Oracle Database.
Note
When using the adapter with BizTalk Server, setting the timeout to a large value does not impact the functionality of the adapter.
See Also
Troubleshoot the Oracle Database adapter Troubleshoot installation issues with the Oracle Database adapter
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for