none
BizTalk Picks up messages it didn't send to IBM MQ. RRS feed

  • Question

  • We have multiple BizTalk servers listening to the same queue for messages.  We have local developer machines, DEV, TEST and PROD.  Our problem is that when a message gets put out to a queue it is random which BizTalk server will pick up the message.  Even if machine A sent the request machine B might pick it up and machine A sits there waiting for a response.  It seems that BizTalk picks up the messages first and then checks the correlation ID after.  Is there a way around this?  Is there some way to check the correlation ID before BTS picks up the message from the queue?  Is there a way to specify that only the BTS that sent the request should pick up the response? 

    We are definitely setting our correlation IDs correctly.  We have two ways of doing this.  One is through C# code generating random GUIDs and the other is having MQ generate the correlation ID and then we set the message ID equal to the correlation ID.  Ultimately our solutions work when only one server is turned on.  The problem comes when there are two or more machines listening to the same queue.  What is the ideal way to handle this type of infrastructure?

    Thank you all in advance,

    Derek

    Tuesday, June 21, 2011 8:02 PM

All replies

  • Just to make sure, are you following the correlation pattern like documented here: http://msdn.microsoft.com/en-us/library/aa559871(v=BTS.10).aspx? It sounds like your second approach is the first approach mentioned in the link.

    In most companies you would have a different queue per environment so one for dev, one for test, one for prod.

    Thanks,

     


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Tuesday, June 21, 2011 11:10 PM
    Moderator
  • Yes, that is exactly the way we are doing it.  In fact, the C# code to generate a random correlation ID was only used because we didn't know about this feature when we first got into this.  We are not using solicit-response ports.  Is this something that we should be doing?  I think the only reason we shied away from this was because we couldn't get them configured to work properly when we first began our venture into BizTalk and IBM MQ. 

     

    You are correct.  Ideally we would have different queues for DEV, TEST, and PROD and I can bring that up with our MQ administrator.  However, if we can't do that is there a way to have all machines polling from the same queue and just make sure that only the machine that sent the message receives the message?  Maybe this could just be done with a solicit-response port?  Is that the key we have been missing?  If so, we have always had problems with transaction supported with solicit-response.  As a rule we turn transaction supported off for MQ send and receives. 

     

    Thanks again. 

    Wednesday, June 22, 2011 2:23 PM
  • So you are not using the solicit-response, that is probably the reason the correlation is not exactly right. I think for a solicit-response port it adds another context property to the subscription to tell which send port sent the message. If you go to the groub hub page and create a custom query for all subscriptions and just look for a solicit-response port it will show the additional subscription information.

    Using solicit-response would be better if you had 2 ports both receiving from the same queue on one BizTalk server, but there is nothing that prevents the other BizTalk servers from pulling from the queue too in your case. If you cannot create a new queue for each environment you would have to go with a single receive port for an orchestration that can route back to the originating BizTalk server.  This would be more complicated and definitely violates the notion of isolated environments.

    Thanks,

     


    If this answers your question, please use the "Answer" button to say so | Ben Cline

    Wednesday, June 22, 2011 4:43 PM
    Moderator
  • We do have different MQ servers for DEV, TEST and PROD.  From our local environments when testing we use the DEV queue.  It just sometimes causes confusion.  Ultimately it's not a show stopper problem in test and production.  It's just irritating shutting down the listener on DEV and making sure that no one else has their application running when you are trying to test.  I just figured maybe there was something that we were missing that could easily be implemented. 
    Wednesday, June 22, 2011 7:34 PM