| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Are User Exits the Answer to My Problem? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jmwolfe1008 |
 Posted: Mon May 03, 2010 10:26 am Post subject: Are User Exits the Answer to My Problem? |
 |
|
Newbie
Joined: 06 Apr 2010
Posts: 5
|
Hello All, and especially Exit gurus with some experience with the new WCF Custom Channel for .NET offering in MQ7.
I have been RTFMs for a few days now, and saw several admonitions to post what you want to do FIRST before wrestling with user exits. So I think I have enough background to do so and get your feedback.
We have a product that has long-supported MQ Series, and are rewriting our product to take advantage of 7.0.1's .NET Custom channels.
As we looked into a proof of concept, it became more obvious that we have a kind of impedence mismatch...
the WCF Custom channel stuff expects a certain SOAP or at the minimum a bare-bones service XML structure in order to receive messages on the custom channel. However, our clients are putting messages into the queue from a mainframe, pretty much as a "raw string." We use an old MQ API app in C++ to monitor the queues and get the message.
We're trying to find a way to leverage the beauty of the WCF custom channel technology without having our customer retool on their client side to wrap everything from the mainframe side of things, especially because we do not have IBM mainframes in-house to develop against.
At first it seemed like message exits were "the answer", as we could put a message exit on the host side of the WCF Custom Channel (receive side, via the CCDT) which would read the 'raw' message and wrap it up all nice for our service, injecting the needed message header data that we need to save in our db.
More research showed that only "channel exits" can be written in .NET. "Message Exits" are going to require C (or maybe C++ but the parameters of that don't seem to be explained in any forums). We might be able to tackle C++, but C is almost out of the question. Where could I find Visual Studio C++ message exit examples?
THe bigger question: what is the best method to bring in a 'raw' message into a .NET managed environment, complete with critical header info like CorrelationId and MessageId? Do we need to scrap the Custom Channel and write our own? Is there some way to wrangle a channel exit to do what we need to do?
Any insights and pointers will be most appreciated.
Jesse M. Wolfe |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon May 03, 2010 11:19 am Post subject: Re: Are User Exits the Answer to My Problem? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| jmwolfe1008 wrote: |
THe bigger question: what is the best method to bring in a 'raw' message into a .NET managed environment, complete with critical header info like CorrelationId and MessageId? Do we need to scrap the Custom Channel and write our own? Is there some way to wrangle a channel exit to do what we need to do?
Any insights and pointers will be most appreciated.
Jesse M. Wolfe |
Any message delivered to a client (whether COBOL, C, C++, C#, Java, JMS, etc ...) has the basics i.e. information on message identity (See MQMD structure) and a payload (which may be null).
The information you want to pass goes into the Payload. Depending on setup some properties (RFH2) or chained headers may also go into the payload.
As to your question :"are user exits the answer to my problem?" I would say there is a million ways to skin a cat.
You could, for instance, write a quick application that moves the messages from queue A to queue B and provides the payload with the wrapper you need. No user exit in play....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 03, 2010 11:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't know the WCF well enough to provide a lot of input here.
But I'm unclear on some of what you are saying... are you saying that the WMQ support for WCF requires SOAP and XML structures? Or are you saying that WCF itself requires SOAP and XML structures?
If it's the WMQ support that requires SOAP and XML structures, then you should be able to write a .NET application that acts as a plain WMQ->WCF bridge, rather than using the official WCF support. (for whatever value of official there is).
Just read a message using the MQ .NET api, write it to a WCF channel and Bill's your uncle. |
|
| Back to top |
|
|
| jmwolfe1008 |
| Posted: Mon May 03, 2010 4:20 pm Post subject: |
|
|
Newbie
Joined: 06 Apr 2010
Posts: 5
|
fjp_saper...
Thanks for spelling out the payload approach... I did finally find some reference to that down in the bowels of the interface definitions. Someone there really should write up nice overview document about exits, explaining the relationship between all the various exit types. So poorly documented.
I think however your statement is only correct when dealing with regular MQ Client programming. When you use the MQ Custom channel, MQ and message header details are more or less "invisible." You're just using it as a transport for a web service call. However, in our case, we DO want some of the message header info so we need some kind of wrapping code.
And yeah, that secondary queue idea came to me after posting as well... however we really need to keep the time overhead low for the messaging part as we have a time-based SLA for our service. Seems the other approach as the one that mqjeff threw out might time out a little better (since we will never be working with local queues).
MQJeff, WCF web services require XML and prefer SOAP. Othwerwise, how would it match the incoming information with a contract?
Because the MQ Custom Channel is using WCF technology it, in turn, expects the incoming service call to have been called by another WCF client with the right setup to wrap the message as expected. Thanks for the additional idea. Definitely was missing the forest for the trees kinda thing.
Thanks both for your input,
Jesse |
|
| Back to top |
|
|
| markrp |
| Posted: Fri May 14, 2010 3:18 am Post subject: |
|
|
Newbie
Joined: 13 May 2010
Posts: 2
|
We haven't tried this, but believe that the best way to tackle this would be to use the extensibility that Microsoft provide up in the WCF layer.
WCF provides a separation between the transport code (in this case the WMQ custom channel) and the way that messages are handled (the message encoder). These are all wrapped up in a binding which is used by the protocol (or directly by the application ).
As you've seen, the problem in your case is that the message encoder, and protocol are expecting SOAP messages and so can't handle the raw message payload. However we believe that it should be possible to define a simple custom message encoder that can receive a message as a bytestream and pass it straight through without trying to convert it to XML. If you use this message encoder in a custom binding and combine it with a simple Router pattern then you should be able to pass the raw message data up to your application.
If we get a chance we'll give this a try and post an update, but in the meantime I hope this gives you something else to try. Let us know if you have any success.
Cheers
Mark |
|
| Back to top |
|
|
| jmwolfe1008 |
| Posted: Fri May 14, 2010 6:19 pm Post subject: |
|
|
Newbie
Joined: 06 Apr 2010
Posts: 5
|
Mark,
Thanks for the idea. Yes, someone on our team suggested the same.
However, considering our deadlines, we don't really get many "wins" trying to stay with WCF, so we have elected to write a simple adapter in the C# API that will watch the queue and launch the message onto the workflow.
We also have to carry some of the message header info into the workflows, and even if you can tweak the message in the WCF layer, I am not sure you will have any access to the Header info. Plus, I think this approach still has a funny "smell" to it, because I don't see how it will know which service to call, and thus will it be able to invoke ANYTHING in the WCF layer? I don't know WCF well enough to say for sure... perhaps it lets you munge the message before WCF even tries to match it to a service. If so, that MIGHT work. But you won't have header info I bet.
Anyway this wraps up this thread, I think. Sometimes, it's just way more efficient to not go for the new bell and whistle if it constrains what you can really do with it. WCF Custom Channel does seem to have that "limiting" feeling to it.
Thanks all,
Jesse |
|
| Back to top |
|
|
| markrp |
| Posted: Sat May 15, 2010 5:46 am Post subject: |
|
|
Newbie
Joined: 13 May 2010
Posts: 2
|
Hi Jesse, thanks for the reply. I think it is possible with WCF - the endpoint URI would help to identify the service to call, and the encoder could return a subclass of message which includes MQ header information, but this is all extra work, and clearly with the time constraints you've got you're best off implementing the pragmatic approach with your C# adapter.
I hope that in the future IBM will be able to extend the WCF custom channel so that it has better support for native message patterns like this one.
Regards
Mark |
|
| Back to top |
|
|
| jmwolfe1008 |
| Posted: Wed Jun 02, 2010 11:11 am Post subject: |
|
|
Newbie
Joined: 06 Apr 2010
Posts: 5
|
Hi Mark...
Hey, I got some time/impetus to check out custom encoders, because when we looked at a poller using the .NET classes for MQ, we may end up writing our own multi-threading for throttling and a lot of other things that WCF provided. This is a bummer. 
So to avoid dealing with multthreading, I tried out custom encoder, and for posterity, it's not the answer either. The encoder gets only the raw message that was on the queue. So It will permit us to use WCF to get legacy datagram/non-soap messages from the queue, but it still doesn't give us any access to the header information.
I'll look to see if we can get it further up the chain, but I don't think so, since encoder pulls the bytes off the wire. The thing is the transport itself doesn't put anything except the MQ message body into the wire in the first place. :\
Looks to me the only way to get at it might be to write our own custom channel... but from what I am reading online, this is not good for a high-performance situation which is what I have.
Anyone have any other insights? |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jun 02, 2010 4:05 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Quote: |
check out custom encoders ... poller ... writing our own multi-threading for throttling ... to avoid dealing with multthreading, I tried out custom encoder ... write our own custom channel ...
|
Whoah. That's a post full of new stuff. 
| Quote: |
| We have a product that has long-supported MQ Series, and are rewriting our product to take advantage of 7.0.1's .NET Custom channels. |
Just asking, but why do this? You have something that works (not written using the "new stuff", but I assume it works) and now there's a plan to rewrite the same thing using some new stuff.
So (help me out, I'm a bit slow..  ) what's the benefit you are aiming to achieve? |
|
| Back to top |
|
|
| jmwolfe1008 |
| Posted: Wed Jun 02, 2010 6:17 pm Post subject: |
|
|
Newbie
Joined: 06 Apr 2010
Posts: 5
|
Good question!
The rewrite of the MQ piece is only part of the story. We are rewriting our whole app which was written using older technology into .NET 3.5 WCF/WWF.
Our old adapter is in C++ and isn't quite in the right architecture to work with our new app design.
If we can get this in WCF, it just makes all the pieces that much easier to configure.
But we do need speed, so from what I gather, a lower level solution might be required anyway.
I just found Charlie Martin (MQ Development team) posting on the gmane.network.mq.devel MQ series LISTSERV on gmane.org, so I've posed my dilemma there. I'll post back what he says. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
