Author |
Message
|
jack_the_ripper |
Posted: Mon Oct 27, 2003 11:51 am Post subject: [Solved]UPES with multiple systems in a sysgroup |
|
|
 Apprentice
Joined: 12 Feb 2003 Posts: 46 Location: NJ
|
Hai,
Consider a scenario of multiple systems in a systemGroup and UPES is defined in SYSTEM1. (Remember, In buildtime the UPES has a attribute of system). So, now when an UPES activity is being executed in different system (SYSTEM2), how does it reach this UPES?
Thanks,
Jack _________________ Jack,
IBM Certified in Websphere MQSeries
IBM Certified in Websphere MQSI
IBM Certified in Websphere MQWorkflow
Last edited by jack_the_ripper on Mon Nov 03, 2003 7:07 am; edited 1 time in total |
|
Back to top |
|
 |
vennela |
Posted: Mon Oct 27, 2003 12:25 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Where you define UPES is one thing and where the UPES queue is hosted is a different thing.
In Buildtime you define a UPES like this
Network-> Expand Domain -> Expand Group -> Select the SYSTEM Right click and select New User Defined Program Exec Server.
Now in the GENERAL tab you give the Name of the UPES and select the SYSTEM.
In the message Queueing tab you will select the Queue Name and Queue Manager name. TheQMGR for the workflow system and the QMGR that hosts the UPES queue can be completely different. But, both the queue managers should be connected to each other using distributed queueing technics.
Now coming to your question if UPES is defined on SYSTEM1 then you should not even worry about connecting the two QMGRs because SYSTEM1's QMGR and SYSTEM2's QMGR are both already in a CLUSTER and both talk to each other. |
|
Back to top |
|
 |
jack_the_ripper |
Posted: Mon Oct 27, 2003 2:47 pm Post subject: |
|
|
 Apprentice
Joined: 12 Feb 2003 Posts: 46 Location: NJ
|
Yes, I know the UPES queue/qmgr could be on a different m/c than wrkflow system. But the definition of UPEs itself is associated with a system. Consider System1 has the definition of UPES. Does the system2 need connection to the UPES Q/QMGR directly or does it go thru the system1 (where UPES is defined) to reach the q/qmgr of the UPES? If later is the case, what happens if the system1 goes down? _________________ Jack,
IBM Certified in Websphere MQSeries
IBM Certified in Websphere MQSI
IBM Certified in Websphere MQWorkflow |
|
Back to top |
|
 |
snan2020 |
Posted: Wed Oct 29, 2003 7:32 am Post subject: |
|
|
Apprentice
Joined: 06 Jun 2003 Posts: 36
|
I think Venny gave a clearcut answer already. UPES q/qmgr doesn't need a direct connection with System2. And about what if Systmes1's down, I am not sure, but I think it still works even if System1 is down.
Snan. |
|
Back to top |
|
 |
jack_the_ripper |
Posted: Wed Oct 29, 2003 1:07 pm Post subject: |
|
|
 Apprentice
Joined: 12 Feb 2003 Posts: 46 Location: NJ
|
Snan, Venny,
Workflow System2 DOES need a direct connection to communicate to UPES QMGR. because Workflow wont use the CLUSTER XMIT Q when it finds no direct connection unless it (UPES Q) is a cluster Q. In this case, the UPES QMGR is not part of cluster. FYI, the MQ Queue Resolution happens in the following way.
{
This para is from admin guide of MQ :
When the sending queue manager is part of a cluster, the default action, if there is no transmission queue with the same name as the destination queue manager, is to use SYSTEM.CLUSTER.TRANSMIT.QUEUE, except when the destination queue is not part of the cluster.
} _________________ Jack,
IBM Certified in Websphere MQSeries
IBM Certified in Websphere MQSI
IBM Certified in Websphere MQWorkflow |
|
Back to top |
|
 |
vennela |
Posted: Wed Oct 29, 2003 2:20 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
It has been a while since I have done some testing on workflow. I would have passed on this thread too (and the reason for not posting a reply for the last two days) but then ...
Quote: |
Workflow System2 DOES need a direct connection to communicate to UPES QMGR. because Workflow wont use the CLUSTER XMIT Q when it finds no direct connection unless it (UPES Q) is a cluster Q. In this case, the UPES QMGR is not part of cluster. FYI, the MQ Queue Resolution happens in the following way.
|
Jack:
I am afraid I have to disagree with you on this.
Quote: |
If later is the case, what happens if the system1 goes down? |
You don't have to worry about this too because as long as MQ is up your UPES is good.
This is what I have done today:
ConfigId: FMC
FMCGRP
FMCSYS
FMCQM
ConfigId: FMC1
FMCGRP
FMCSYS1
FMCQM1
UPES (Pointing to a Local (not clustered) queue on FMCQM1.
Defined a process that has a UPES activity:
Brought the SYSTEM1 down.
Executed the Process.
I could see the UPES message on UPES queue on FMCQM1.
And the reason I was sure this works was:
I have UPES queues on web client QMGR and I always point my UPESs to the queues on the WebClient QueueManager and I don't do anything special.
Hope this helps
------- |
|
Back to top |
|
 |
jack_the_ripper |
Posted: Wed Oct 29, 2003 3:33 pm Post subject: |
|
|
 Apprentice
Joined: 12 Feb 2003 Posts: 46 Location: NJ
|
Venny,
Ok, Even I am afraid that ur setup was not ideal for testing what we want to achieve here. Consider the following setup
Workflow System1
-----------------------
Machine : M1
Workflow Config: WF1
Workflow System: FMCSYS1
Workflow Group: FMCGRP
QMGR hosting the workflow: WFQM1
Workflow System2
-----------------------
Machine : M2
Workflow Config: WF2
Workflow System: FMCSYS2
Workflow Group: FMCGRP
QMGR hosting the workflow: WFQM2
UPES QMGR
---------------
Machine : M3
QMGR: UPESQMGR1
Bi-Directional Communication links between
---------------------------------------------------
1) WFQM1 and WFQM2 - by the very fact of being part same cluster (FMCGRP)
2) WFQM1 and UPESQMGR1 - set up by XmitQ,sender,receiver channels
Notes
-------
1) UPESQMGR1 is NOT part of any cluster
2) No direct communication channels between WFQM2 and UPESQMGR1
Now consider the UPES activity is being run on workflow system FMCSYS2, how will it reach UPES Queue ??
My argument is, UPES message wont go thru FMCSYS1 (ie queue manager WFQM2) to reach UPES q/qmgr, because of the underlying MQ Queue resolution process, which I have mentioned in the previous post. So, the UPES activity will be InErr state.
We can take up the case of one system going down in the next post. !
-Jack _________________ Jack,
IBM Certified in Websphere MQSeries
IBM Certified in Websphere MQSI
IBM Certified in Websphere MQWorkflow |
|
Back to top |
|
 |
vennela |
Posted: Wed Oct 29, 2003 4:16 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Quote: |
1) UPESQMGR1 is NOT part of any cluster
2) No direct communication channels between WFQM2 and UPESQMGR1
|
This is not what you have said in your earlier post.
I agree that your above setup will not work if WFQM2 and UPESQMGR1 cannot talk to each other. But, if the QMGR hosting the UPES can talk to each of the WF QMGRs, then either of the WF SYSTEMs going down will not have effect the availability. |
|
Back to top |
|
 |
|