| Author |
Message
|
| bruce2359 |
 Posted: Tue Mar 06, 2012 10:41 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I.still smell an auditor...
_________________
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 |
|
 |
| BBM |
| Posted: Tue Mar 06, 2012 12:07 pm Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Thanks for all the replies.
I agree the situation is far from ideal and not the best use of MQ.
We need to be absolutely sure which message came down which channel in case one of the external companies sent something that appeared to be from another company for whatever reason. Once they were able to send us a message they could potentially send us any data at any time so we need to be sure which message is from where. We cannot rely on the message content/header being correct to validate it's origin. By tagging the message as it comes through we can compare the transaction in the message to what is expected from that particular external company. If it contains data purporting to be from another company we can bin the message.
The real problem is the back end application server, if that was more scalable we wouldn't have this issue in the first place and could use one local queue per external. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 06, 2012 12:12 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| BBM wrote: |
| The real problem is the back end application server, if that was more scalable we wouldn't have this issue in the first place and could use one local queue per external. |
The real problem is that you continue to think of the back end application server as the real problem.
As I said, write a NEW application that reads from the front end queues, and appends the necessary tagging and does the necessary validation, and then forwards the message to the single queue being read by the back end server.
Ideally, make sure that the back end server is connecting to a different queue manager than any of the front end queues are hosted on.
And, again, you can consider using DataPower for this solution instead of writing a new application. It's very good at message security solutions and can augment and forward MQ messages. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 06, 2012 1:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
 with Jeff.
If you are averse to DataPower, the front-end solution Jeff suggests could imbed the channel source info you desire in MessageProperties in each message, then send the message(s) along to the back-end server queue.
_________________
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 |
|
|
| BBM |
| Posted: Wed Mar 07, 2012 3:52 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
OK thanks guys, this is a good solution.
I guess I was hoping for something off the shelf that I could bolt onto MQ to make this happen, but I guess life is never that simple.
I will engage our developers to write an app as you describe. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 07, 2012 4:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| BBM wrote: |
OK thanks guys, this is a good solution.
I guess I was hoping for something off the shelf that I could bolt onto MQ to make this happen, but I guess life is never that simple.
I will engage our developers to write an app as you describe. |
DataPower is off the shelf..  |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Aug 07, 2012 1:08 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
So we have come up with a solution to this problem - I'm wondering whether anyone can see a flaw with our plan?
To recap we have many inbound channels and we would like to stamp the incoming messages to determine where they came from before they land one a single local queue.
The solution we came up with is this:
Create a topic for each incoming flow
Create aliases for each external client to target that in turn target the topics - permission each alias so that each channel can only access it's specific alias, using the user specified in each channel's MCAUSER
Create subscriptions for each topic pointing to the single local queue, specifying PSPROP(RFH2) attribute in subscription. This will add the topic string to the RFH2 header which can then be picked up by the app.
This should mean that as the messages are aggregated to the single queue they are 'stamped' with the unique topic string relating to the channel they came through.
Not being a pub/sub expert I'm wondering if there are any drawbacks in using pub/sub relating to assured delivery etc?
Thanks
BBM |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 07, 2012 1:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| If you use durable, administrative subscriptions to a queue with persistent messages, you shouldn't compromise the assured delivery. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 07, 2012 9:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You may need to set the permissions on your pub/sub topics so that only authorized subscribers can get the messages...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| BBM |
| Posted: Wed Aug 08, 2012 3:48 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Wed Aug 08, 2012 11:36 pm Post subject: Re: Can MCAUSER set message User Identity? |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| PeterPotkay wrote: |
| On QM to QM channels yes, but its different on SVRCONN channels, where the MCAUSER value of the SVRCONN channel will dictate the MQMD's User Identity field. |
Peter, I am bit confused! AFAIK MQMD.Userid is populated by either QMGR (default context option, the id under which app is running) or by the app putting the message itself, if app id has authority to set context. So what role MCAUSER plays?? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 09, 2012 2:41 am Post subject: Re: Can MCAUSER set message User Identity? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| girish_tharwani wrote: |
| MQMD.Userid is populated by either QMGR (default context option, the id under which app is running) or by the app putting the message itself, if app id has authority to set context. |
It can't be populated by the queue manager for a client application because there's no queue manager for a client. So it becomes the id that's running the putting application or (in some cases) whatever id the application populates the field with.
| girish_tharwani wrote: |
| So what role MCAUSER plays?? |
The MCAUser on a SVRCONN is used to close this hole by forcing the user id to an administrator - defined value. Combined with SSL this allows the proper control of clients.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
