Biztalk 无法使用强类型引用游标读取 Oracle 18 存储过程答案

【问题标题】：Biztalk unable to read Oracle 18 stored procedure with strongly typed ref cursorBiztalk 无法使用强类型引用游标读取 Oracle 18 存储过程
【发布时间】：2020-02-14 11:00:48
【问题描述】：

我们让 Biztalk 通过调用存储过程从 Oracle 中的表中读取数据。存储过程返回一个强类型游标，它在 Oracle 12 中运行良好。

更新到 Oracle 18 会返回一个响应，就好像游标是弱类型的： https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/adapter-oracle-database/message-schemas-for-ref-cursors

这个链接有我们面临的确切问题，但是光标是强类型的。

我尝试使用记录返回一个引用游标，并明确指定列名和类型。它不起作用。 Biztalk 版本是 2013 R2。

有人遇到过 Oracle 18 的这个问题吗？适用于 Oracle 12。

强类型游标是

TYPE t_ReqCursor is REF CURSOR RETURN REQUEST%ROWTYPE

而 Biztalk 正在阅读的内容是这样的

<GenRecordRow xmlns="http://Microsoft.LobServices.OracleDB/2007/03">
        <GenRecordColumn>
            <GenRecordColumn>
                <ColumnName>AGNCY_RQST_ID</ColumnName>
                <ColumnValue>545</ColumnValue>
                <ColumnType>System.Int64</ColumnType>
            </GenRecordColumn>
            <GenRecordColumn>
                <ColumnName>RQST_ID</ColumnName>
                <ColumnValue>4344</ColumnValue>
                <ColumnType>System.Int64</ColumnType>
            </GenRecordColumn>
</GenRecordRow>

【问题讨论】：

标签： xml oracle cursor biztalk

【解决方案1】：

Oracle 数据库 11.2 是 Biztalk 2013 R2 支持的最新版本，如技术网文章 BizTalk Server: Supported Line-of-Business (LOB) and Enterprise systems 中所述。

我猜你证明了 BizTalk 对于 Oracle 18 并没有完全损坏，而只是部分损坏。从长远来看，您可能会对 BizTalk 2016 进行一些测试，因为它支持 Oracle 数据库 12.1。仍然不是您想要的版本，但值得一试（或等待 BizTalk 2020 的预览版并希望获得实际的 Oracle 18 支持）。

【讨论】：

【解决方案2】：

我在 BizTalk 2016 连接 Oracle19c 时遇到了同样的问题，当前设置是 BizTalk2016 和 Oracle12c。并且Oracle计划更新到最新的Oracle19c版本。

因此，基于此设置，我们知道 BizTalk2016 将不支持 Oracle19c DB。我们正在使用紧密耦合的 WCF-OracleDB 适配器。我们尝试了所有常见的疑点，例如升级 Oracle 客户端、BizTalk Server 中的 ODAC 组件。没有将以下格式更改为原始格式，

所以我们尝试在 Oracle 方面进行分析，以比较 Oracle12c 与 Oracle19/18c 之间的变化。基本上，我们在两个数据库的文档中都浏览了所有折旧的功能。我们发现了以下内容，

参考：https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/behavior-changes-deprecated-desupport-oracle-database.html#GUID-543498D6-3799-4217-9BE3-4BB8630FC32D

Oracle 文档摘录“如果您希望继续收集 ALL_TYPES 和关联的用户视图、ARGUMENTS 视图中的 ALL_TYPE_ATTRS 和 ALL_COLL_TYPES，那么您可以将事件设置为 events='10946, level 65536'。设置此事件会将 ARGUMENTS 视图恢复为早于 12.1 的 Oracle 数据库版本中的行为，其中 DATA_LEVEL 可以大于 0，并且视图中包含类型和任何嵌套类型的描述性元数据。如果进行此更改，则必须在设置事件后重新编译受影响的包。当您重新编译受影响的包时，编译器会重新收集额外的元数据。此事件还将 OCIDescribeAny() 恢复为早于 12.1 的 Oracle 数据库版本中的行为”

根据最新版本数据库中的上述文档，他们将参数列表移动到三个不同的表中，

**ALL_PLSQL_TYPES
ALL_PLSQL_TYPE_ATTRS
ALL_PLSQL_COLL_TYPES**

这对 BizTalk 很重要，因为 BizTalk 正在此表中查找架构信息。

all_arguments

现在 Oracle 将 Schema/Meta 数据信息移到了新表中，BizTalk 的 Schema 渲染与 Oracle12 Vs Oracle19/18c 不同。

因此我们在会话中设置/复制上述事件，并尝试仅重新编译 BizTalk 包，BizTalk2016 开始正常工作。

1. alter session set events '10946 trace name context forever, level 65536';
2. alter package <package_name> compile;

这只是一种解决方法，而不是实际的解决方案。但是在我们重新编写代码之前，这将在短期内起作用。

注意：我们仍在各个方面测试解决方案，例如解决方案中的性能/负载测试。我们还没有弄清楚这个解决方案的副作用。如果我们发现任何东西，我会继续发布。

【讨论】：

【解决方案3】：

我们在 BizTalk 2016 和 Oracle 19C 中遇到了类似的问题。即使是 BizTalk 2020。

Microsoft 建议这是一个已知问题，我们需要通过设置上面列出的事件(alter session set events '10946 trace name context forever, level 65536') 来填充元数据表并重新编译包。

您可以使用以下查询验证元数据。

select * from SYS.ALL_ARGUMENTS WHERE PACKAGE_NAME = <Package Name>

注意：这需要使用 BizTalk 用于连接的用户在同一会话中完成

问题：BizTalk 2016 Cu8 + ODCA 12 和 BizTalk 2020 + ODAC 19.3

【讨论】：