什么可能导致 Oracle 数据库对 Biztalk 的（间歇性）错误响应？
我的编排有一个发送-接收端口，直到找到发送形状为止，所有正在操作的消息都完全相同。即我最终通过发送-接收端口发送 Oracle 数据库的消息是相同的。
本质上，我向数据库发送一个请求，说明我想要哪个表的最新更改以及该表的所有者是谁。正如我所提到的，在比较有效的更新和无效的更新时：到目前为止，两个请求消息都是相同的。
问题：数据库的响应可能是空的，但它不应该是空的。我期待表中的完整行发生变化，有时我什么也没有收到。
详细信息：我只更改最简单的字段来触发这些测试，并且始终相同 - 一个整数字段，我从 99 递减或递增到 98 到 97 到 98...等等。第一次可能有效，但第二次就不行，有时甚至相反。
任何其他字段都可能产生此错误。
更多详细信息...：Oracle 的运行似乎可能出现问题。即，它处理时间戳的方式可能会导致 Oracle 返回空记录，因为它假设 Biztalk 已经收到更改通知。在研究数据库的内部结构时，我们发现我最后一次更改尝试的时间戳都精确到同一秒（请注意，这在物理上是不可能的）。
看起来，当我向 Oracle 发送消息时，它会执行两次操作，这似乎导致了错误（顺便说一句，有问题的表上没有触发器）。在我的编排中，我在发送消息之前写入事件日志，并且该消息仅写入一次......
看起来这可能是 Oracle 问题。现在，一贯工作的领域不起作用，而其他领域有时起作用 - 我想这是之前抽签的运气。
为什么我认为发生这种情况：我要求它向我提供（数据库告诉我）已更改的客户端，并且它（不知何故 - 这是谜团）运行其检索两次。当它起作用时，它是第一次检索将消息返回到 Biztalk，因此具有实际信息。如果没有，这是因为第二次检索要求最新的更改，但没有任何更改，因为第一次检索已经获取了它们，因此返回空记录。
My orchestration has a send-receive port and until the point where the send shape is found all messages being manipulated are exactly the same. I.e. the message I end up sending the Oracle db through the send-receive port are identical.
Essentially, I'm sending the db a request that states which table I would like the latest changes from and who the owner of the table is. As I mentioned, when comparing an update that worked and one that didn't: up until this point, both request messages are the same.
The problem: The response from the db might be empty and it should never be. I'm expecting the complete row from the table that changed and sometimes I receive nothing.
Details: I'm only changing the simplest of fields to trigger these tests and always the same one - an integer field that I decrement or increment from 99 to 98 to 97 to 98... etc. One number may work the first time but not the second or sometimes it's the opposite.
Any other field may produce this error.
More details...: It seems that Oracle's functioning may be at fault. I.e. the way it handles timestamps may cause Oracle to return an empty record because it assumes Biztalk was already notified of a change. While looking into the innards of the db, we saw that my last change attempts were all timestamped to the same exact second (physically impossible, mind you).
It also seems like, when I'm sending Oracle a message, it does its thing twice which seems to be causing the error (no triggers on the offending table, by the way). In my orchestration I write to the eventlog right before I send the message and that message is only written once...
Seems like it might be an Oracle problem. Now the consistently working field doesn't work and other fields work sometimes - I guess it was luck of the draw before.
Why I think this is happening: I ask it to give me the client that (the db told me) has changed and it (somehow - this is the mystery) runs its retrieval twice. The times it works, it's the first retrieval that returns the message to Biztalk and, thus, has the actual information. When it doesn't it's because the second retrieval asks for the latest changes and there are none because the first retrieval already got them and so returns an empty record.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
虽然我没有针对您的问题的具体解决方案，但也许解决方案在于考虑如何处理获得空响应的实例。如果发生这种情况，则会导致下游问题，因此如果您无法解决它，那么您可能应该编码以接受空响应作为有效响应。
那么，您在响应中期望的实际数据可能必须委托给另一个下游进程来检索。
然而，即使在某些情况下您需要进行多个不同的调用，这仍然可以被视为单个逻辑接口。
要处理空响应，您可以通过将入站响应强制转换为 XmlDocument 来修改入站端口，以期望收到非类型化消息。
希望这有帮助。
Although I don't have a specific fix for your problem, perhaps the solution lies in thinking about how to handle the instances where you get the null response. If this happens it causes a downstream problem, so if you can't resolve it then you should probably code to accept a null response as a valid response.
It may then be the case that the actual data you were expecting in the response will have to be delegated to another down stream process to retrieve.
However, even though in some situations you need to make more than one distinct call, this can still be considered as a single logical interface.
To handle the null response you can modify the inbound port to expect an un-typed message by casting the inbound response to XmlDocument.
Hope this helps.
问题如下：
这就是为什么我们只会收到一条日志消息，因为只有我所知道的编排才实现了这一点。
The problem was the following:
This is why we would only get one log message since only the orchestration I knew about had that implemented.