The idea of asynchronous provisioning is very similar to the one of manual provisioning. Generally, when midPoint has something to do on a resource (like creating, updating, or deleting an account), the provisioning module asks a connector to do that. For synchronous resources, the connector ensures the execution of the operation, and informs provisioning module about the result. But not in the case of asynchronous provisioning connector. Here the connector sends a request (e.g. a JMS message containing JSON-encoded data about the requested operation) to specified target (e.g. JMS queue), where it will wait until the real target system retrieves and processes it. And because midPoint has no access to the target system to know about the current state of the account, the provisioning keeps all the account attributes in the repository using a mechanism called attribute caching.
When configuring an asynchronous resource, two basic questions have to be answered:
- There is a single JMS target we will send messages to. It resides on a broker reachable via
mainBrokerConnectionFactory(a JNDI name to be resolved), and the specific queue is obtained by resolving
- When transforming operations into requests, the
simplifiedJsonpredefined transformation will be used.
See Asynchronous Resource Configuration (Outbound) page for configuration details.
Current state of the implementation
The design of this feature is highly modular. In theory, the communication with the asynchronous target can use any transport: various kinds of message queuing technologies, REST, SOAP web services, and so on. But the current implementation was created and tested with a particular target in mind:
- Apache ActiveMQ Artemis 2.x;
- using JMS 2.0 to connect to it.
Other JMS 2.0 providers should be pluggable. JMS 1.1 might work as well but there can be some classloading issues. It looks like some engineering effort will be needed to be able to use them with midPoint.