Provisioning providers

Messaging queue provisioning provider

Local messaging queue

ActiveMQ Artemis 2.x is used as JMS Broker.

By default, Artemis creates a queue with the name "Provisioning" (Artemis extends it with the prefix "jms.queue"). In addition, Artemis creates the following two queues:

• An expiration queue with the name ExpiryQueue. Messages whose configured time to live is expired are moved to this queue.
• A dead letter queue with the name DLQ. Messages are moved to this queue when the maximum of 10 failed delivery attempts has been reached.

These queue names are fixed and cannot be changed. Internally, nevisIDM connects via anin-vm connector. External clients can access the queues via TCP.

The JMS queue for standalone instances supports AMQP protocols (in additoin to the Core protocol of ActiveMQ Artemis).

Local messaging queue setup

You can use the properties in the file nevisidm-prod.properties to configure the JMS provisioning module.

Messages are paged to disk, when the size of all messages in memory for an address exceeds the maximum size. Paging of messages is done transparently into and out of memory as they are needed.

Disk Space

Make sure that there is always enough disk space available for writing to the messaging queue. Writing to the messaging queue will block the current transaction when the corresponding disk reaches 99% disk usage. You set the messaging queue location in the property application.modules.provisioning.jmsqueue.storage.location of the nevisidm-prod.properties file.

The messaging can also be configured to provision events to a remote message queue. The events are transmitted with the AMQP protocol, therefore the remote message queue must support AMQP.

Remote messaging queue

Note that if you configure a remote Provisioning queue, the local messaging queue is not exposed over TCP anymore.

Duplicate Messages

In case of failures after transmission but before acknowledgment, the message transmission is repeated. Hence, the destination might receive duplicate messages after a failure. If supported, the destination queue provider should enable automatic duplicate message detection and removal.

Remote messaging queue setup

To enable provisioning to a remote message queue, configure the messaging.remote.uri property in the "[nevisidm-prod.properties]" file.

To enable transferring messages to a remote ExpiryQueue message queue, configure the messaging.remote.expiryQueueUri property in the "[nevisidm-prod.properties]" file.

To enable transferring messages to a remote Dead Letter Queue message queue, configure the messaging.remote.dlqUri property in the "[nevisidm-prod.properties]" file.

The following formats are supported:

• A URI according RFC 2396 of the format <scheme>://<username>:<password>@<host>:<port>/<queuename>
  • scheme: Supported schemes are amqp and amqps (for TLS, uses application truststore).
  • username: Username of the remote queue user (may be optional)
  • password: Password of the remote queue user (may be optional)
  • host: Host of the remote queue
  • port: Port of the remote queue (may be optional)
  • queuename: Name of the remote queue (may be optional)
• An Azure service bus endpoint, that is, a Primary Connection String of the format: Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=<sasKeyName>;SharedAccessKey=<sasKey>=;EntityPath=<queuename>
  • namespace: Azure namespace
  • sasKeyName: Shared access keyname
  • sasKey: Shared access key
  • queuename: Name of the remote queue

Example

# AMQP:
messaging.remote.uri=amqp://user:[email protected]:5672/remoteQueue
messaging.remote.uri=amqps://user:[email protected]:5671/remoteQueueTls
messaging.remote.uri=Endpoint=sb://example-namespace.servicebus.windows.net/;SharedAccessKeyName=ClientSharedAccessKey;SharedAccessKey=<SasKey>=;EntityPath=<queuename>
Endpoint=sb://nevisidm-test.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=hWmCLiwtWSeaEaTVTg=;EntityPath=remote-queue

XA transactions to bring DB and JMS transactions together

The system must only send a JMS message about a provisioning event when the database commit was successful and the database operation is ready. If either the database operations or the sending of the JMS message is erroneous, the database transaction(s) must be rolled back.

In nevisIDM, the database and the JMS transaction commits and rollbacks are orchestrated. In case of any database error, nevisIDM will roll back both the database and the JMS operations and not send the JMS message. If an error arises when sending the JMS message, nevisIDM will not save any data to the database and not send any message.

To avoid possible data loss, if there is an error during the commit of the JMS transaction (for example, the JMS queue is unavailable at the time of commit), then the database transaction will also not be committed because of XA transactions.

External JMS server for Provisioning

You can configure external JMS server as provisioning target instead of using embedded Artemis broker and messaging bridge.

Advantages:

• On Kubernetes it is possible to stuck messages in the IDM pod with embedded Artemis broker when the Kubernetes controller decide to stop the pod.
• The external JMS destination is also part of the XA transaction, as opposed to the bridge, which operates independently of the built-in Artemis broker.
• You can centralize the provisioning with a dedicated JMS server pod as target for all your IDM pods on Kubernetes to save lots of resources.

Limitations:

• IDM can support only JMS servers with XA transaction support.
• The configured connection factory must implement jakarta.jms.XAConnectionFactory and destination must implement jakarta.jms.Destination.

On Kubernetes we suggest to use external JSM server instead of embedded Artemis broker and AMQP bridging.