BizTalk and JBoss A-MQ / ActiveMQ. RRS feed

  • Question

  • A possible solution for an asynchronous interaction between two organization would be to use a message broker, either ActiveMQ or the Red Hat’s version of it, A-MQ. One side would queue messages by using AMQP.Net Lite client library and the other side needs to collect those messages via BizTalk. How easy/difficult would it be? After all, AMQP 1.0 is something Microsoft promotes. I can wait for BizTalk 2016.

    I have neither hands-on knowledge of BizTalk nor do I want to get into it. Basically, all I need is to be sure that it is worthwhile persuading BizTalk guys to look into this solution.

    Wednesday, September 21, 2016 8:04 PM


All replies

  • Any message queue has a rather heavy footprint.  Why do you think you need it?

    It's pretty easy to do async between apps using http.  Disconnected scenarios are really the only place where a queue's benefit outweighs the complication.

    • Edited by Johns-305MVP Wednesday, September 21, 2016 8:53 PM
    Wednesday, September 21, 2016 8:52 PM
  • I'm not sure what do you mean with "a rather heavy footprint". The queuing infrastructure is already in place and functions flawlessly with other applications. Very easy to make robust solutions with it.

    The main reason for going for asynchronous messages is that there is no guarantee for the availability of BizTalk (disconnected scenario, as you call it). So, the option to just drop a message to BizTalk is not there. Which is a pity, as BizTalk also provides for reliable queuing.

    Thursday, September 22, 2016 6:17 AM
  • Hi Borjan

    You should be able to send/receive from ActiveMQ pretty seamlessly over HTTP. BizTalk 2013 and above ships a WCF-WebHttp adapter that can use the REST interface exposed by ActiveMQ. Refer below sample-

    If you need something more native, JNBridge has a JMS Adapter that BizTalk can use to talk to ActiveMQ. Note that you need a license for it-

    Thanks Arindam

    Thursday, September 22, 2016 6:54 AM
  • Well, there you go!  If you have a disconnected scenario, you need a queue, it's not really an option at that point.

    I would first say just use whatever queue you already have, WMQ, MSMQ, RMQ etc.  It is highly unlikely the BizTalk app would notice or care about the difference.

    Compared to http, even RMQ is heavy since there's the server, the client, lots of config etc.  Unfortunately, I've seen instances were a queueing layer was wedged into an app where all the systems were literally right next to each other.

    But, if you need it, use it.

    Thursday, September 22, 2016 11:20 AM
  • Thanks Arindam,

    the WCF-WebHttp adapter is probably the most opportune way to go - I’ve looked briefly into the Blog describing it. So, basically, one application would drop a message on a queue (provided by the ActiveMQ broker) and a Biztalk application would have to poll the REST service for input. I have to check with an ActiveMQ person whether or not it could be done the other way around (ActiveMQ invoking a REST service exposed by BizTalk).

    What still bothers me is why BizTalk provides nothing regarding AMQP (besides the SB-Messaging adapter). What is the point of an open standard if Microsoft supports it in a way that excludes non-Microsoft’s products?  

    Thursday, September 22, 2016 12:32 PM
  • I agree that having a native AMQP protocol adapter in BizTalk Server going forward will enable a few scenarios, esp., with the growth of IoT.

    Thanks Arindam

    Thursday, September 22, 2016 1:45 PM
  • So, here's the problem.  AMPQ is still a moving target.  There's lots of support for .9 and increasing support for 1.x which aren't exactly compatible with each other.

    AMQ REST is neither so now we're talking about 3 different ways to do the same thing.

    If you have AMQ, I would go with AMQ REST since bypassing AMQP gives it the broadest support from the start.  To BizTalk, it's just another WCF http endpoint.

    Thursday, September 22, 2016 1:47 PM