What may cause (intermittent) bad responses from an Oracle db to 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开发者_如何学C 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.

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:

• Another developer had a similar orchestration set up on another server. This would send similar messages to Oracle in parallel to the orchestration that was under development.

This is why we would only get one log message since only the orchestration I knew about had that implemented.