我们让Biztalk通过调用存储过程从Oracle中的表中读取数据。存储过程返回一个强类型的游标,它在Oracle12上工作得很好。
更新到Oracle18会返回一个响应,就好像游标是弱类型的一样:https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/adapter-oracle-database/message-schemas-for-ref-cursors
此链接具有我们所面临的确切问题,但光标是强类型的。
我尝试使用record和explicity指定列名和类型来返回引用游标。它没有起作用。Biztalk版本是2013 R2。
有没有人在Oracle 18中遇到过这个问题?与Oracle12配合使用很好。
强类型游标是
TYPE t_ReqCursor is REF CURSOR RETURN REQUEST%ROWTYPEBiztalk正在阅读的内容是这样的
<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>发布于 2020-10-14 06:24:01
我在连接Oracle19c的BizTalk 2016上也遇到了同样的问题,目前的设置是BizTalk2016和Oracle12c。甲骨文计划更新到最新的Oracle19c版本。
因此,基于此设置,我们知道BizTalk2016将不支持Oracle19c DB。我们使用紧密耦合的WCF-OracleDB适配器。我们尝试了所有常见的方法,比如升级BizTalk服务器中的Oracle Client和ODAC组件。未将以下格式更改为原始格式,

因此,我们尝试在Oracle端进行分析,以比较Oracle12c和Oracle19/18c之间的变化。基本上,我们浏览了两个数据库文档中的所有折旧功能。我们发现了下面的内容,
摘自Oracle“如果您希望继续在参数视图中收集事件和相关的用户视图、ALL_TYPE_ATTRS和ALL_COLL_TYPES,则可以将事件设置为ALL_TYPES =‘10946,level 65536’。设置此事件会将参数视图恢复到12.1之前的Oracle数据库发行版中的行为,其中DATA_LEVEL可以大于0,并且该类型和任何嵌套类型的描述性元数据都包含在视图中。如果进行此更改,则必须在设置事件后重新编译受影响的包。当您重新编译受影响的包时,编译器会重新收集其他元数据。此事件还会将OCIDescribeAny()恢复为早于12.1的Oracle数据库版本中的行为。“
基于最新版本DB中的上述文档,他们将参数列表移动到三个不同的表中,
这对BizTalk很重要,因为BizTalk正在此表中查找架构信息。
all_arguments现在Oracle将模式/元数据信息移动到新的表中,BizTalk的模式呈现与Oracle12与Oracle19/18c不同。
因此,我们在一个会话中设置/复制了上面提到的事件,并尝试仅重新编译BizTalk包,BizTalk2016开始照常工作。
1. alter session set events '10946 trace name context forever, level 65536';
2. alter package <package_name> compile;这只是一个变通的方法,而不是一个实际的解决方案。但在短期内,在我们重写代码之前,这是可行的。
注意::我们仍在测试解决方案的所有方面,比如解决方案中的性能/负载测试。我们还没有弄清楚这个解决方案的副作用。如果我们发现了什么我会随时通知你。
发布于 2019-10-19 03:22:39
Oracle数据库11.2是technet文章BizTalk Server: Supported Line-of-Business (LOB) and Enterprise systems中指定的Biztalk 2013 R2的最新支持版本。
我猜你已经证明了BizTalk对于Oracle18来说不是完全失败的,而是部分失败的。从长远来看,您可以使用Oracle2016进行一些测试,因为它支持BizTalk数据库12.1。仍然不是您想要的版本,但值得一试(或者等待Oracle2020的预览版,并希望实际支持BizTalk 18 )。
发布于 2021-10-26 20:10:35
我们在BizTalk 2016和Oracle19C上遇到了类似的问题。即使使用BizTalk 2020也是如此。
微软建议这是一个已知的问题,我们需要通过设置上面列出的事件来填充元数据表,并重新编译包。
您可以使用以下查询验证元数据。
select * from SYS.ALL_ARGUMENTS WHERE PACKAGE_NAME = <Package Name>注意:这需要在同一会话中使用BizTalk连接的用户来完成
问题: BizTalk 2016 Cu8 +ODCA12和BizTalk 2020 +ODAC19.3
https://stackoverflow.com/questions/58434047
复制相似问题