Creating the JMS Adapter Send Port
I'm assuming that creating a send port is already known for someone reading this post. Setting the send port properties of the JMS Adapter are pretty straightforward and all dependent on the queue you are connecting to:
The first section of properties entitled "Adapter Behavior" are pre configured and I left the default settings alone. I haven't played around with these settings at all, but they revolve around how the send port handles exceptions and timeouts.
The next section of properties to configure is under the title "Connection Properties". The Host Name and Port Number coincide with the JMS server you are connecting to and the port in which the JMS server is listening on.
The third section is called "JMS Operation Properties" and have to do with the specific instance of JMS being connected to. The JMS Object Name is the actual name of the Queue or Topic that messages will be sent to. The JMS Object Type is a pull down list with either Queue or Topic. For Message Type, this is another pull down list of the different message types. In my case, I selected Text, but the options are: Bytes, Map, Text, Text ISO-8859-15, and Text UTF. Lastly, the Transactions Enabled property tells the port whether or not transactions are enabled.
The last section is called "Overrride Transmit Handler Properties", and although I didn't configure these, I'm assuming you can use this to override what was configured in the JMS send adapter transport handler.
After creating the send port, you will need to spend some time getting communication between BizTalk and your JMS server working. Some of the less obvious issues you will run into could be security related but those are too environment specific to go into detail here. Additionally, you may run into issues with how the JMS server is configured. For instance, I had created multiple ports to communicate with the JMS server, but the server was configured to only allow one connection. This caused the JMS adapter to throw infrequent errors when trying to communicate. It took several tests to isolate the issue and change the configuration on the JMS server to allow multiple connections.
Lastly, there are other aspects to consider before implementing the use of the JMS adapter. In my opinion, two of the more important aspects are that of security and cost. Depending on how mission critical this adapter is to your business, the former may weigh more heavily on the decision rather than the later. This was the case in my scenario.
Security
From a high level, this should always be in the back of your mind as to how to handle security with any adapter being used. In my opinion, defense in depth is always the way to go. If your unfamiliar with this term, it essentially means the more security you have, the better. Still, there are considerations to take, like whether messaging is internal only or external (meaning outside of your network). What kind of infrastructure support you have to help set up security. What type of data is being messaged could come into play as well.
Cost
The only negative about this adapter has been the cost. Since my environment consists of migrating code through four different environments, there was a cost associated with the adapter for each environment. Since my current company leverages an integrated test environment that mimics our production environment, the cost for the adapter was even higher. This is something to consider before going forward with the adapter.
All in all, I've been really happy with the adapter and how we were able to spin up a proof of concept fairly quickly. Not having any prior experience with integrating BizTalk and JMS, this adapter helped bridge that gap. It does a lot of the heavy lifting so that I didn't have to become an expert in JMS.
No comments:
Post a Comment