Messaging architecture
When IBM Cúram Social Program Management is containerized on Kubernetes, it uses IBM MQ to manage JMS messages for Cúram Deferred Processes and Cúram Workflows.
Each Social Program Management application, such as Cúram, Citizen Portal, Rest, and so on, must have its own dedicated queue manager. The following reference diagram illustrates the JMS-based messaging architecture:
For more information about the Social Program
Management
JMS Producer, see the Transaction
Isolation topic.
Multi-instance queue manager support
For IBM MQ Cluster, Social Program Management supports only multi-instance queue managers, with one active/primary queue manager, and one standby/secondary queue manager. Multi-instance queue managers are instances of the same queue manager that are configured on different servers. One instance of the queue manager is defined as the active instance, and another instance is defined as the standby instance. If the active instance fails, the multi-instance queue manager restarts automatically on the standby server.
For more information about multi-instance queue managers, see the IBM MQ product documentation.
IBM MQ and queue managers for Social Program Management
The cardinality between queue managers and IBM MQ servers is flexible. You can configure all queue managers on one IBM MQ cluster, or you can configure one queue manager per IBM MQ cluster. For example, you can configure some queue managers for an internal application in one IBM MQ cluster, and some queue managers for external applications in another IBM MQ cluster. The same cardinality applies to the remote data storage. The configuration depends on the level of fault tolerance and security isolation that is required by the application in production.