|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Looking for rules/best practices on broker + MQ marriage |
« View previous topic :: View next topic » |
Author |
Message
|
Vitor |
Posted: Tue May 19, 2015 5:45 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ruimadaleno wrote: |
there must be some guideline in place to avoid issues ... the same for MQ .. right ?  |
Vitor wrote: |
All the coding rules you'd apply to a well - behaved MQ application (don't use a string as a message id, don't browse the queue looking for a specific message like it's a database table, etc).
Specific gotchas:
- don't put an MQGet node in a loop within a flow
- don't use WMQ with anything other than the supplied nodes (i.e. do not use JMS inside a JCN) |
joebuckeye wrote: |
The main one would be to allow MQ interactions only through the nodes provided by the broker. No MQ calls inside JCN's! |
_________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zpat |
Posted: Tue May 19, 2015 6:19 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5867 Location: UK
|
It's ironic how IBM and others recommend using Java developers to code WMB/IIB flows.
Personally I would feel much safer if they did not know any Java. Then they would be forced to use WMB's facilities and look up the info center.
Anyone reading queues via Java in WMB deserves to be shot. _________________ 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: Tue May 19, 2015 7:36 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
zpat wrote: |
Anyone reading queues via Java in WMB deserves to be shot. |
I settle for pointing them to the section in the InfoCenter that says it's unsupported. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ruimadaleno |
Posted: Tue May 19, 2015 8:23 am Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
zpat wrote: |
Anyone reading queues via Java in WMB deserves to be shot. |
Such a violence in this post  _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
ruimadaleno |
Posted: Tue May 19, 2015 8:25 am Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
Vitor wrote: |
All the coding rules you'd apply to a well - behaved MQ application (don't use a string as a message id, don't browse the queue looking for a specific message like it's a database table, etc).
|
Hi Vitor, can you elaborate further on why the usage of a string as a message id is not good for this marriage ?  _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
Vitor |
Posted: Tue May 19, 2015 8:41 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ruimadaleno wrote: |
Vitor wrote: |
All the coding rules you'd apply to a well - behaved MQ application (don't use a string as a message id, don't browse the queue looking for a specific message like it's a database table, etc).
|
Hi Vitor, can you elaborate further on why the usage of a string as a message id is not good for this marriage ?  |
The use of a string as a message id is not good WMQ - nothing to do with broker.
The 2 id fields (message and correlation) are not string fields; they are 24 byte hex fields. As that link says up front, no two messages should have the same id and, as most strings tend to have some business meaning (such as an account or order number) the odds of duplication are high. Most such "business strings" are not 24 characters long, so have to be padded with spaces further increasing duplication risk.
It's also a problem when messages move between platforms; unless you stick to Latin alphanumerics the values of the strings are different on machines using different code pages so the id comes out garbled. If you have a mainframe anywhere in the mix even that doesn't work as z/OS speaks EBCDIC not ASCII.
Before you say "but can't you fix that by getting WMQ to do conversion", WMQ only converts the payload (if it's MQFMT_STRING) and the character parts of the MQMD - WMQ believes these fields are 24 bytes of hex. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|