A static subscription to a Message Broker channel can be specified as suppressible by setting the suppressible attribute for the subscription in the business process. Valid values for suppressible are true and false (the default). Setting suppressible to true specifies that the static subscription is suppressed in favor of dynamic subscriptions. In other words, you can prevent specific messages on a Message Broker channel from starting a new business process; instead the messages can be received, using a dynamic subscription, by a business process that is already running.
A typical use for the suppressible attribute is to design the routing of messages that have the same group ID to the same business process. An ideal scenario is to use a JMS property of messages handled by a JMS event generator as the group ID.
Designing such a scenario includes setting up the business process and the event generators, as described in the following sections:
In this example, we use a JMS property of messages handled by a JMS event generator as the group ID. We design the routing of messages with the same group ID to the same business process.
The following code example shows the property in the JMS event generator:
<JmsEventGenerator>
<property>
<Name>GROUPID</Name>
<Value>100</Value>
</property>
...
</JmsEventGenerator>
To Create a Business Process that Receives all Messages With the Same GROUPID Property Sent on a Specific Message Broker Channel
Note: In this example, we use a channel named /my/orders.
@jpd:mb-static-subscription
@jpd:mb-static-subscription suppressible="true"
$metadata/property[name='GROUPID']
To learn how to design a dynamic subscription, see Message Broker Subscription Control.
To learn how to design looping logic, see Looping Through Items in a List.
Note: To avoid race conditions, steps 1-5 must be performed while in a synchronous message broker subscription. To learn about creating a synchronous subscription, see Subscription Start (Synchronous).
For the suppressible pattern in this example to work correctly, there must be a single publisher for a given group ID. Having a single publisher for the group ID means that the publisher is paused when a new subscriber is subscribing dynamically (see steps 1-5 in the preceding section: Setting up the Business Process), thereby avoiding race conditions with the subscriptions. When you use JMS event generators, there are two ways to ensure that a single publisher publishes a given group ID:
You must manually edit the deployment descriptor to set the JMS event generator pool size. To do so, use the WebLogic Builder tool, which is available from the WebLogic Workshop design console menu bar:
Tools —> WebLogic Server —> WebLogic Builder
Note: You do not need to restrict the pool size of the subscribers.
In the scenario illustrated in the following figure, a queue, which has GROUPIDs in the range 100-299, is defined. Two JMS event generators are defined, one to handle GROUPIDs in the range 100-199, and one to handle GROUPIDs in the range 200-299.
Because the static and dynamic subscriptions described in the preceding section (Setting up the Business Process) are within the Subscription Start (Synchronous) block, the JMS event generator that publishes the GROUPID=101 messages is blocked after delivery of the first message until the dynamic subscription and any other logic within the synchronous subscription block is executed. Then the next GROUPID=101 message is published. With suppressible set to true for the business process' static subscription, the second message does not start a new business process. Instead, it is received by the dynamic subscription on the business process that was started by receiving the first GROUPID=101 message.
![]() |
|