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.
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.