Hooking up BizTalk to JMS doesn't pose too much of an issue thanks to good documentation from JNBridge. Most of the issues that occur is about getting proper access to the servers, having the correct parameters for the JMS topics, setting the Java parameters right and so on.
As soon as those things got properly aligned, we successfully received messages published in the RIB to BizTalk. The next part was to send messages to the RIB.
We could see messages leave BizTalk successfully, but nothing ever appeared in the JMS topic. No errors were logged anywhere on either side.
After some error searching, I turned to do a trace using netsh.exe and analyzing this in NetMon. This showed that we had some handshaking going on coupled with the adapter running checks against the JMS setup to make sure that we could put a message on the topic. This resulted in an ORA-24033: no recipients for message error.
The error message we got is explained in the documentation as:
- ORA-24033: no recipients for message
- Cause: An enqueue was performed on a queue that has been set up for multiple dequeuers but there were neither explicit recipients specified in the call nor were any queue subscribers determined to be recipients for this message.
- Action: Either pass a list of recipients in the enqueue call or add subscribers to the queue for receiving this message.
I looked around for a solution to this error since we couldn't find any issues with the topic itself. There were a subscriber properly set up and no issues regarding access were to be found.
In an older blog post I could find something to point me in the right direction. In order to send messages to Oracle RIB, you have to set a threadValue parameter in the JMS header (which can be read about in the RIB documenation if you know where to look). This is in turn used in the subscription rule on the other end. If this parameter isn't set, there is no subscriber available since it is a mandatory field in the selector.
After setting a threadValue element to "1" using a custom pipeline component, the messages was successfully sent to the RIB which both can be seen in the topic itself as in the trace where the update to the table is visible with the message as a parameter.
NetMon or a similar tool is invaluable when tracking down similar issues. It is not the first time that NetMon (or WireShark) has provided information that is needed in order to get things to work.