| Author |
Message
|
| newtown |
 Posted: Sun Mar 09, 2003 7:46 am Post subject: WMQI architecture |
 |
|
Novice
Joined: 03 Feb 2003
Posts: 16
|
If any one can advice on this couple of answers for WMQI architecture.
I have three environments, Development, UAT & Production.
The Development machine is setup with MQSI running on NT Domain.
The UAT & Production having the Broker is running on AIX system.
1. Is there a way to configure one CM manager to connect to two different Broker. In this case the UAT and Production having different database for each CM.
I have read that this cannot be possible, but due to some $$$ limitation , is there are way to have single machine having two CM manager...
2. How do I manage access for users when moving msgs form Development to UAT and Production.
Will some pl share link or document which gives an insight of these things...
thanks |
|
| Back to top |
|
 |
| jsware |
| Posted: Sun Mar 09, 2003 8:38 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I don't think it's possible to have a config manager running more than once on a single NT server.
What you could do (this is not a recommendation) is have the development config mgr look after your development broker and also the UAT broker and have a separate one for production only.
My personal recommendation is at least three config managers: a dev/initial test one, a formal test/uat one and a production one.
Regards
John. |
|
| Back to top |
|
|
| simon.starkie |
| Posted: Sun Mar 09, 2003 5:11 pm Post subject: Suggestion - one CM for each environment |
|
|
Disciple
Joined: 24 Mar 2002
Posts: 180
|
I agree with Scott. You probably do need one Config Manager for each of the three environments you have indicated.
Here's another reason why you may need three CM's. Let's say PROD is several "versions" behind the versions of your application code (Message Flows etc) currently running in your UAT and DEV CM's. If there was a significant lag between code being developed and code being UAT'd and code that has been deployed to PROD, you would need to have three CM's, one for PROD, one for UAT and one for DEV to accomodate this (the code is deployed from each of the the CM's).
Here's another thought. You may need 5 CM's instead of the 3 previously mentioned. For example, lets say you need to provide code-fix suppport for either PROD or UAT code. If you had additional "hot fix" CM's to support the version of code running in each environment, this would allow you to more conveniently perform hot-fix maintenance, such as bug fixes, for a particular "version" of the code that may be running in either UAT or PROD without impacting your DEV work. Otherwise, you may be forced to backup what is currently in DEV, revert (restore) to the code version you want to fix, fix the code and then revert (restore) back to your original DEV work and continue developing. Having what I call "hot fix CM's" could avoid this contact admin complication.
Hope that helps.
Simon  |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Mon Mar 10, 2003 1:33 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
I am a bit confused by this discussion. Why not just have different workspaces for each environment?
(Assuming you have good naming conventions, and trust people not to deploy a DEV flow to a PROD broker... or is that the problem?)
Vicky |
|
| Back to top |
|
|
| simon.starkie |
| Posted: Mon Mar 10, 2003 2:56 pm Post subject: |
|
|
Disciple
Joined: 24 Mar 2002
Posts: 180
|
Vicky,
Most "large" shops don't allow anyone near their pristine PROD environments. They also don't let just anyone into their UAT environments either otherwise the credibility of those tests could be compromised. Also, if you are using "common code" subflows, they could be shared across PROD, UAT and DEV Message Flows in the case of a single CM...so you wouldn't be able to change a particular SubFlow without running the risk of affecting UAT or PROD versions of the Message Flows that use it. You wouldn't be able to enforce a policy which precluded someone from redeploying a particular Message Flow, Execution Group or Broker which would pick up the modified Sub Flow. |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Wed Mar 12, 2003 5:45 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
Technically, it is possible to have multiple ALTERNATE ConfigMgrs on a single PC. Each must have its own databases, and only one CM can be active at any time.
To switch, just MQSIDELETECONFIGMGR (but do not delete the databases!) and MQSICREATECONFIGMGR with the other databases. This takes only a few minutes with a script.
So, since UAT and especially Production will usually have very low assign/deploy activity, this might be a solution.
BUT, you will not be able to have different authorizations for UAT and Production. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Mar 12, 2003 6:08 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It would be great to have this single CM per NT box limit removed.
Althought NT boxes are inexpensive, the managed service charge we pay per server amounts to thousands of pounds/dollars per year. And these boxes are hardly used.
Perhaps someone could release a CM switching script as a support pac? |
|
| Back to top |
|
|
| dlapetina |
| Posted: Wed Mar 12, 2003 6:42 am Post subject: WMQI and EJBs |
|
|
Newbie
Joined: 12 Mar 2003
Posts: 3
|
Does anybody know how to access from a message flow an EJB on Webshere Application Server 4.0 ?
Thx. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 12, 2003 6:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Quote: |
| Does anybody know how to access from a message flow an EJB on Webshere Application Server 4.0 ? |
You probably need to write a Java plug-in to call the EJB. |
|
| Back to top |
|
|
| dlapetina |
| Posted: Wed Mar 12, 2003 7:02 am Post subject: |
|
|
Newbie
Joined: 12 Mar 2003
Posts: 3
|
| JeffLowrey wrote: |
| Quote: |
| Does anybody know how to access from a message flow an EJB on Webshere Application Server 4.0 ? |
You probably need to write a Java plug-in to call the EJB. |
Do u have any sample of that ?
I mean any sample of a java plug-in node and how to use it in a message flow ?
An url will be great too.
thx |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Wed Mar 12, 2003 8:00 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
| zpat wrote: |
.....
Perhaps someone could release a CM switching script as a support pac? |
It's simple - You nee 2 sets of databases and queue manager, of course:
1. ConfigA2ConfigB.cmd
mqsistop ConfigMgr
mqsideleteConfigMgr
mqsicreateconfigmgr -i UserId -a PassWord -q QMB -n CMDBB -m MRDBB
mqsistart ConfigMgr
and of course, the reverse ConfigB2ConfigA.cmd
mqsistop ConfigMgr
mqsideleteConfigMgr
mqsicreateconfigmgr -i UserId -a PassWord -q QMA -n CMDBA -m MRDBA
mqsistart ConfigMgr |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 12, 2003 9:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Quote: |
Do u have any sample of that ?
I mean any sample of a java plug-in node and how to use it in a message flow ?
An url will be great too. |
There are support packs available that contain sample java nodes. The RedBook 'Developing Solutions with WMQI' has an entire chapter devoted to writing, installing, and using java plugins. |
|
| Back to top |
|
|
| dlapetina |
| Posted: Wed Mar 12, 2003 9:37 am Post subject: |
|
|
Newbie
Joined: 12 Mar 2003
Posts: 3
|
| JeffLowrey wrote: |
| Quote: |
Do u have any sample of that ?
I mean any sample of a java plug-in node and how to use it in a message flow ?
An url will be great too. |
There are support packs available that contain sample java nodes. The RedBook 'Developing Solutions with WMQI' has an entire chapter devoted to writing, installing, and using java plugins. |
ok thx. |
|
| Back to top |
|
|
| kwelch |
| Posted: Wed Mar 12, 2003 1:18 pm Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Simon,
You bring up a good point. We are struggling with this currently at our shop. We have the three environments DEV, QA, and PROD. We also have what we call our sandbox environment which is a standalone environment for us to develop the initial WMQI code without affecting anyone's testing. None of these environments are at the same level as far as messagesets and messageflows go. If we were to need to apply a production fix we would have to backout of one of the testing environments and make it look like production, apply the fix, then promote it and then restore everything, disrupting the testing in that environment while all this goes on,. We are looking into creating another environment but WMQI is expensive. I would be interested in hearing how other folks deal with these issues. Also, in a recent release where we were deploying a messageflow that called a subflow, we noticed that the subflow automatically went with the messageflow. Is this how it is supposed to work? We only changed one item on the messageflow and did not want the subflow to go as it had changes that were not ready to go to the next environment in it. Has anyone else experienced this?
Karen |
|
| Back to top |
|
|
| simon.starkie |
| Posted: Wed Mar 12, 2003 1:42 pm Post subject: |
|
|
Disciple
Joined: 24 Mar 2002
Posts: 180
|
| Quote: |
| Also, in a recent release where we were deploying a messageflow that called a subflow, we noticed that the subflow automatically went with the messageflow. Is this how it is supposed to work? |
Yes, all the subflows that are referenced by a particular message flow, are deployed with that message flow when is deployed. These subflows are statically bound with the referencing message flow(s) at deploy time. Subflows are not seperate, dynamic pieces of "code" that are called at runtime. They are static and behave a similar manner to #INCLUDE or COPYbooks.
| Quote: |
Technically, it is possible to have multiple ALTERNATE ConfigMgrs on a single PC. Each must have its own databases, and only one CM can be active at any time.
|
I like it. Nice idea. As long as the CM is accessable to those who need. |
|
| Back to top |
|
|
|
|
