What is the recommended and best practice to configure the BC shared connection in BW projects ?
Article ID: KB0085887
Updated On:
| Products | Versions |
|---|---|
| TIBCO ActiveMatrix BusinessWorks | - |
| Not Applicable | - |
Description
Resolution:
1) all consumption(Inbound) and publication ( outbound) of BC messages are to be handled in a set of BW processes (set-A), pointing to the same shared-resource (res-B)
2) configure the shared resource (res-B) as a "Distributed-Queue" transport
3) configure the shared resource (res-B) to have auto-confirm OFF
4) deploy multiple engines, each engine hosting the set of BW processes (set-A). This is optional but recommended. IF you want to do some load balancing using "Distributed queue" feature, you can deploy multiple engines across different machines.
5) If #4 is followed which is preferred you need to be aware of the CM name parameter in the BC shared connection. If you choose "Distributed queue(DQ)" as the transport type then all inbound requests to BW engine will use DQ which only needs the queue name to be specified. But you still need to specify "CM name" which will be used to send responses back to the the BC server. So the CM name is used for outbound messages.
Due to nature of RVCM, each engine will have to have it's own unique CM-Name, i.e the (res-B) on each engine has to run differently with a new CMName. This can be accomplished by using a global variable name for the CM name.
IMPORTANT :- Only one shared connection needs be created in the project per protocol and installation combination and follow the above guidelines. Otherwise there could be problem with unneccessary RVCM listeners getting registered at the BC publisher which could lead to problems.
1) all consumption(Inbound) and publication ( outbound) of BC messages are to be handled in a set of BW processes (set-A), pointing to the same shared-resource (res-B)
2) configure the shared resource (res-B) as a "Distributed-Queue" transport
3) configure the shared resource (res-B) to have auto-confirm OFF
4) deploy multiple engines, each engine hosting the set of BW processes (set-A). This is optional but recommended. IF you want to do some load balancing using "Distributed queue" feature, you can deploy multiple engines across different machines.
5) If #4 is followed which is preferred you need to be aware of the CM name parameter in the BC shared connection. If you choose "Distributed queue(DQ)" as the transport type then all inbound requests to BW engine will use DQ which only needs the queue name to be specified. But you still need to specify "CM name" which will be used to send responses back to the the BC server. So the CM name is used for outbound messages.
Due to nature of RVCM, each engine will have to have it's own unique CM-Name, i.e the (res-B) on each engine has to run differently with a new CMName. This can be accomplished by using a global variable name for the CM name.
IMPORTANT :- Only one shared connection needs be created in the project per protocol and installation combination and follow the above guidelines. Otherwise there could be problem with unneccessary RVCM listeners getting registered at the BC publisher which could lead to problems.
Issue/Introduction
What is the recommended and best practice to configure the BC shared connection in BW projects ?
Feedback
Yes
No
Powered by
