Message Brokers
Smile CDR uses a message broker for Subscription processing.
The message broker is associated with the overall Smile CDR cluster, meaning that one single logical broker is shared by all modules (although this broker may itself be clustered).
There are two broker technologies supported by Smile CDR:
The number of threads allocated to subscription processing is configured in the storage module using these properties:
module.persistence.config.subscription.consumers_per_matching_queue =2
module.persistence.config.subscription.consumers_per_delivery_queue =5
These determine the number of consumers (threads) that listen to the two different types of subscription queues used by Smile CDR. See Smile CDR Subscription Architecture.
consumers_per_matching_queue is the number of listener threads that match new resources against active subscriptions
consumers_per_delivery_queue is the number of listener threads created per subscription. These threads deliver subscription matches to subscription endpoints.
Smile CDR performs subscription matching by registering an interceptor with a FHIR Storage module and submits all incoming resources to the Subscription Matching Queue on the configured Message Broker. (In the case of Kafka, Kafka topics are used in place of JMS queues.) A Smile CDR Subscription Matching module subscribes to this Subscription Matching Queue and matches all incoming resources against all active subscriptions. Each active subscription has its own dedicated Delivery Queue. When a resource matches a subscription, it is placed on the Delivery Queue for that subscription. A separate consumer within the Subscription Matching module then picks up the matched resource from the Delivery Queue and attempts to deliver it to the endpoint specified by that subscription. If a single endpoint is down, only queues for subscriptions delivering to that endpoint are affected; deliveries to other endpoints continue unimpeded.
All Subscription Queue names end with -[NODE_ID]-[STORAGE_MODULE_ID] where [NODE_ID] and [STORAGE_MODULE_ID] are the Node ID and FHIR Storage module ID for the module that is submitting the events for processing. In the default Smile CDR configuration these will be Master and persistence respsectively.
The name of the Subscription Matching Queue is subscription-matching-[NODE_ID]-[STORAGE_MODULE_ID].
The name of each rest-hook delivery queue is subscription-delivery-rest-hook-[NAME]-[NODE_ID]-[STORAGE_MODULE_ID] where [NAME] depends on the value of module.subscription.config.delivery_queue_naming. The value of delivery_queue_naming can be one of the following options:
SUBSCRIPTION_ID: Create one delivery queue per subscription with the NAME equal to the subscription id. This is the default for backwards compatibility.
SHARED Create a single delivery queue shared by all subscriptions
DELIVERY_GROUP: Look for the extension https://smilecdr.com/fhir/ns/StructureDefinition/subscription-channel-delivery-group on each subscription and use the value of that extension for the name of the delivery queue.
The following three options derive the delivery queue name from the REST endpoint url of the subscription. E.g. if the subscription endpoint url is http://some.hostname.org:1234/app/path/subpath?foo=bar&baz=some/path then the queue name for that subscription delivery queue will be as follows.
ENDPOINT_HOST: "some-hostname-org"
ENDPOINT_HOST_PORT: "some-hostname-org-1234". This is the recommended value for enterprise installations. The advantage of this option is that if there are issues delivering to a particular endpoint, those issues will be constrained to the single threadpool managing deliveries for that queue.
ENDPOINT_HOST_PORT_PATH: "some-hostname-org-1234-app-path-subpath"
Similarly, the name of each email delivery queue is subscription-delivery-email-[NAME]-[NODE_ID]-[STORAGE_MODULE_ID].
The following list shows the modules that require the message broker when enabled:
If you do not want to use message brokers, ensure that none of these modules are enabled.
It is possible to send your own messages to custom topics or queues on your configured message broker. This can be done for example from these places:
To do this, you must include the IPublicBrokerSender as an autowired bean in your custom class, and make use of its
single public API method, as follows:
import ca.cdr.api.broker.IPublicBrokerSender;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.messaging.MessageHeaders;
@Autowired
private IPublicBrokerSender myPublicBrokerSender;
private void sendMessageToBroker() {
MessageHeaders headers = new MessageHeaders();
headers.put("some-header", "some-value");
String topic = "my-custom-topic";
String payload = "This is the custom message payload.";
myPublicBrokerSender.send(topic, payload, headers);
}