Skip to main content
Version: 2.82.x.x LTS

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>
  • 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>

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

Best effort 1-phase commit with database as inner transaction

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.

But there is one limitation: 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 be committed but the JMS message will not be sent. For this to happen, the JMS queue has to go down after the JMS sending operation and before the JMS transaction commit. This is very rare.