| Author |
Message
|
| jared_hagel |
 Posted: Tue Mar 08, 2005 6:31 pm Post subject: Writing to the Dead Letter Queue using .NET Classes |
 |
|
Apprentice
Joined: 23 Jun 2004
Posts: 29
|
This question has been asked already, but not answered.
Is there a way to fill in the Dead Letter Header of a message using .NET classes?
We need to do this to replicate the behavior of IBM's RUNMQTRM program in our own program. Our program should be identical to RUNMQTRM except it will use MQ Client libraries and it will start a triggered process on a remote machine.
From the Application Programming Guide (concerning RUNMQTRM):
| Quote: |
If the RUNMQTRM trigger monitor in MQSeries for OS/2 Warp and WebSphere MQ on UNIX systems detects an error in either the:
- Structure of a trigger message
...
It puts the trigger message on the dead-letter (undelivered message) queue, having added a dead-letter header structure (MQDLH) to the message. It uses a feedback code in the Reason field of this structure to explain why it put the message on the dead-letter (undelivered message) queue.
|
Thanks,
Jared |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Mar 08, 2005 9:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Try and work with
runmqtrc instead of runmqtrm
 |
|
| Back to top |
|
|
| jared_hagel |
| Posted: Wed Mar 09, 2005 5:52 am Post subject: |
|
|
Apprentice
Joined: 23 Jun 2004
Posts: 29
|
runmqtrc doesn't solve my problem because it can't start a process on a remote machine. It can only start a process on the same machine it's running on.
I need our program to write to the dead letter queue in case it can't start the remote process (ie- if the machine containing the remote process is down).
Thanks again,
Jared |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Mar 09, 2005 9:26 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Well, instead of re-inventing the wheel (runmqtrc), why not trigger a local app that fires off the remote app.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 09, 2005 9:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What mechanism do you intend to use to tell the remote machine to start a process?
Can you write a script that can be called from runmqtrm to use that mechanism?
Have you considered the security implications of allowing a machine to accept remote requests to start processes?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 09, 2005 12:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jared_hagel wrote: |
runmqtrc doesn't solve my problem because it can't start a process on a remote machine. It can only start a process on the same machine it's running on.
I need our program to write to the dead letter queue in case it can't start the remote process (ie- if the machine containing the remote process is down).
Thanks again,
Jared |
No but you run it on the remote machine to start a process there locally.
Same principle as runmqtrm but in the "client" space.
Enjoy  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 09, 2005 3:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jared_hagel wrote: |
| I need our program to write to the dead letter queue in case it can't start the remote process (ie- if the machine containing the remote process is down). |
Why not just monitor queue depth on the queue that the remote process is supposed to get from?
You seem to be trying very hard to reinvent a lot of wheels, when it is not clear that your requirements, well, require it!
And you seem to be going down a road that will be difficult to support securely and robustly over time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 09, 2005 5:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
To sum it up:
ServerA has the Queue Manager
ServerB has the app you want to start.
On ServerB, use the client version of the trigger monitor, runmqtrmc. It will run on ServerB, so it can starts the app on ServerB. But it will client connect to ServerA to watch the INIT queue for trigger messages.
If ServerB is Windows, use Support Pack MA7K instead of runmqtrmc.
And when you need to put a message to a queue announcing a problem, use your own exception queues. Leave the DLQ alone for use by the MQ system.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jared_hagel |
| Posted: Wed Mar 16, 2005 8:44 am Post subject: |
|
|
Apprentice
Joined: 23 Jun 2004
Posts: 29
|
Thanks. We did decide to use our own exception queue.
We did use Support Pack MA7K, but this support pack doesn't do everything we need.
There are actually 3 servers.
ServerA has the Queue Manager
ServerB has the MQ Client (MA7K is run on this server)
ServerC has the app you want to start.
We started the app on ServerC through a call on ServerB. The security on ServerC was surprisingly simple to set up. Here's the code used on ServerB:
| Code: |
public static void ExecuteRemoteProgram (string applicationPath,
string remoteComputerName,
string userData)
{
ManagementClass processClass = new ManagementClass ("\\\\" +
remoteComputerName + "\\root\\CIMV2:Win32_Process");
ManagementBaseObject inParams = processClass.GetMethodParameters ("Create");
inParams ["CommandLine"] = applicationPath + " \"" + userData + "\"";
ManagementBaseObject outParams = processClass.InvokeMethod ("Create", inParams, null);
if (outParams ["ProcessId"] == null)
throw new ApplicationException ("Attempt to start the remote triggered application failed.");
}
|
Also, here's the process used to setup security on ServerC (assuming WMI is installed on ServerC, which is the case for Windows 2000 and more recent versions)
1. Click Start, click Run, type wmimgmt.msc, and then click OK.
2. Right-click WMI Control, and then click Properties.
3. Click the Security Tab
4. Expand the Root node, and select the CIMV2 node
5. Click the Security Button
6. Add the desired Active Directory ID
7. Checkmark all boxes
8. Click OK 2 times
Thanks,
Jared |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 16, 2005 9:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You must have some strange security requirements, that will allow you to make remote process calls but not allow you to install an MQ Client.
You'd be almost better off using the server trigger monitor on your QMgr box, if you're still going to invoke a remote process from the trigger monitor.
There's really no good reason, in my opinion, to do this the way you have. A trigger monitor and an MQClient is very light weight both in disk space and in cpu/memory utilization. So there's no reason not to put it on ServerC.
And you've opened up a security hole on your ServerC that might not otherwise be needed. WMI is just another Microsoft technology, and therefore just as likely as any other Microsoft technology to be vulnerable to attacks and exploits.
At least the exploits available to a trigger monitor are a lot easier to know about and control.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jared_hagel |
| Posted: Thu Mar 17, 2005 9:46 am Post subject: |
|
|
Apprentice
Joined: 23 Jun 2004
Posts: 29
|
The reason why we haven't installed the MQClient on ServerC is because all MQ Put and Get requests are handled through a web service on ServerB. This web service on ServerB makes use of the MQClient.
This configuration cuts down the on number of MQClient licenses we have and standardizes how applications make use of MQ.
Thanks for your feedback,
Jared |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 17, 2005 10:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jared_hagel wrote: |
| This configuration cuts down the on number of MQClient licenses we have and standardizes how applications make use of MQ. |
MQ Client Licenses are free!
Either I don't understand what you're doing, or again I disagree with your design.
What I think you're saying now is that you use MQ Triggering to start a process over the network on ServerC. This process on Server C then turns around and calls back to a web service (over the network) on Server B, which accesses MQ to process the messages, and hands the information from the messages back as an HTTP Reply (over the network).
Why are you using MQ at all? The whole point of MQ is that applications don't have to know about the network!
But this is all just my opinion, and you're the one that has to support the system you've built, not me.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
