Skip to main content
Version: 7.2402.x.x RR

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

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.