| Author |
Message
|
| xeonix |
 Posted: Thu Jan 15, 2015 7:30 am Post subject: .NET how to build message with MQXQH? |
 |
|
Apprentice
Joined: 02 Apr 2013
Posts: 32
|
Hello guys.
According to this:
http://www-01.ibm.com/support/docview.wss?uid=swg27021403&aid=1
when you put a message into remote queue definition - QMgr wraps it with new message of format "MQFMT_XMIT_Q_HEADER" with MQXQH header:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.ref.dev.doc/q101590_.htm?lang=en
Entire message with it's headers is saved to body of Transmission Message.
After these steps - message goes to XMIT queue, and corresponding SDR CHL gets the message and sends it to RCVR CHL.
This is how it works.
What I need to do - is to make these steps by my .NET application.
I want it to be able to build Transmission Message by itself, without creating any Remote Queue Definitions, and to put it directly to XMIT queue in order to deliver it to remote QMgr's queue.
So far I didn't found anything useful in "amqmdnet.dll" to accomplish this. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jan 15, 2015 7:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So why do you actually want to do this?
Are you trying to avoid having to create a remote queue definition for every destination on your remote queue manager?
Or are you trying to avoid all of the security measures that your MQ administrator has correctly put in place to limit what queues you can send messages to?
There are several ways that you can configure your MQ network topology such that a remote queue definition is not required. Most of those ways require additional effort to properly secure. |
|
| Back to top |
|
|
| xeonix |
| Posted: Thu Jan 15, 2015 7:57 am Post subject: |
|
|
Apprentice
Joined: 02 Apr 2013
Posts: 32
|
| mqjeff wrote: |
So why do you actually want to do this?
Are you trying to avoid having to create a remote queue definition for every destination on your remote queue manager?
|
Yes. Nothing to do with security so far.
And I don't want to use Client Connections to remote QMgr's SVRCONN channels - the purpose is to utilize SDR channel, which has all necessary connection information specified. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 15, 2015 8:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are several different ways to construct your MQ topology such that you don't have to use remote queue definitions for every queue on all of the remote queue managers.
And, yes, one of those ways is to use a SVRCONN - but that's a really bad way and the kind of thing you only do as a last resort.
All of the other ways require understanding MQ name resolution.
They all require extra security measures, to avoid not only making the MQ topology unsecure, but opening up the OS of the host system to attack as well. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 15, 2015 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| xeonix wrote: |
| Yes. Nothing to do with security so far. |
At what point will you consider security? At what point will you mention this to your MQ admin, who if he's following best practice will then get a bit cross...
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Thu Jan 15, 2015 8:03 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 15, 2015 8:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I doubt that your management and auditors will approve this.
Transmission queues should be secured so that no application can put a msg directly into them.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| xeonix |
| Posted: Thu Jan 15, 2015 8:10 am Post subject: |
|
|
Apprentice
Joined: 02 Apr 2013
Posts: 32
|
Nothing to do with security, really.
I have two MQ 8 installations (my dev env), each on separate box, and I'm able to do with them everything I want. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 15, 2015 8:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You would be ill-advised to start constructing your own XMIT queue headers in my view (unless you can convince us here that it is essential).
You can send a message to a remote queue, without a remote queue definition quite easily (and without a MQ client connection).
All you need to do, is have your MQ application MOOPEN the target queue you want it to arrive on, and AND code the remote queue manager name as the QM name on the MQOPEN.
MQ detects that the queue manager named on the MQOPEN is not the local one and routes the message to the xmit queue (of the same name as the QM) and constructs the XMIT header for you.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 15, 2015 9:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| xeonix wrote: |
| I have two MQ 8 installations (my dev env), each on separate box, and I'm able to do with them everything I want. |
Fair point.
Why would you spend time developing this (which clearly will work in the environment you describe) when it won't work (or at least won't be allowed) anywhere else? What's the use case?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| xeonix |
| Posted: Fri Jan 16, 2015 1:25 am Post subject: |
|
|
Apprentice
Joined: 02 Apr 2013
Posts: 32
|
| Vitor wrote: |
| xeonix wrote: |
| I have two MQ 8 installations (my dev env), each on separate box, and I'm able to do with them everything I want. |
Fair point.
Why would you spend time developing this (which clearly will work in the environment you describe) when it won't work (or at least won't be allowed) anywhere else? What's the use case? |
It works using RFHUtil, I have already checked.
Use Case is: I got FTE network and I need to write NT Service that would ping them. Don't wanna use client connections, because in this way, I need to create additional configuration options for my NT Service, that would duplicate connection information, specified at SDR channels. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 16, 2015 5:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| xeonix wrote: |
| It works using RFHUtil, I have already checked. |
I meant "won't work" because the administrator won't allow it to work.
| xeonix wrote: |
| Use Case is: I got FTE network and I need to write NT Service that would ping them. |
Of all the ways you can check the health of an FTE network, you decided to write some custom code and use that?
Ok......your site, your choice...... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| xeonix |
| Posted: Fri Jan 16, 2015 5:53 am Post subject: |
|
|
Apprentice
Joined: 02 Apr 2013
Posts: 32
|
| Vitor wrote: |
I meant "won't work" because the administrator won't allow it to work.
|
This thread is all about technical aspects not organizational.
Not organizational.
| Vitor wrote: |
Of all the ways you can check the health of an FTE network, you decided to write some custom code and use that?
|
Custom code is because I need automate some FTE maintenance tasks, not just health check.
To be more specific, I need to check agent status and it's monitors state. If agent is running while monitor is stopped - I need to start that monitor. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 16, 2015 6:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Again, you can easily do this by configuring your MQ network properly.
EVERY SINGLE TIME YOU THINK YOU NEED TO CREATE AN MQXRH header you need to STOP and CONFIGURE YOUR MQ NETWORK instead.
You've already been told one way to do this.
Why are you stuck thinking that you have to build your own transmission header? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 16, 2015 6:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| xeonix wrote: |
| Vitor wrote: |
I meant "won't work" because the administrator won't allow it to work.
|
This thread is all about technical aspects not organizational.
Not organizational. |
Pardon me for trying to add some value, and point out that this technically valid solution has issues.
| xeonix wrote: |
| Custom code is because I need automate some FTE maintenance tasks, not just health check. |
Yes, I guessed that. And as I said, your site & your choice.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| xeonix |
| Posted: Fri Jan 16, 2015 6:30 am Post subject: |
|
|
Apprentice
Joined: 02 Apr 2013
Posts: 32
|
| mqjeff wrote: |
Again, you can easily do this by configuring your MQ network properly.
EVERY SINGLE TIME YOU THINK YOU NEED TO CREATE AN MQXRH header you need to STOP and CONFIGURE YOUR MQ NETWORK instead.
You've already been told one way to do this.
Why are you stuck thinking that you have to build your own transmission header? |
Unfortunately, there's no way to configure FTE in such way, that it would auto-start stopped monitors. And there's no way to start stopped monitor with command-line either - the only option is to recreate it.
Although, there's internal FTE routines, I'm disassembling right now, that controls monitor lifecycle, and they are able to start the monitor. This is command queue related stuff.
Just don't get it, what MQ configuration option(s) can help me in solving this?
As far as I can see - there's no way to process XMIT headers in .NET MQ API. I don't wanna create C/C++ NT Service, although it provides low-level MQ API routines (and for XMIT headers as well). Managed P-Invoke wrappers I don't want to write either.
So far, I decided to stop on standard approach (RQ -> XMITQ -> SRD -> RCVR -> LQ), even if it requires to create a bunch of remote agent's command queue RQs. |
|
| Back to top |
|
|
|
|
