Simulation

Before the simulation capability was introduced to midPoint (version 4.7), the only way to simulate the trajectory of any change in your midPoint deployment was to have a separate test instance. While variants of this approach may work in factories or for "usual" software development, mirroring live system such as midPoint is cumbersome, to say the least. Any discrepancy in data between the instances may lead you to think that the change you are testing has no ill side effects only to face catastrophic consequences after deploying it to production.

With simulation, you safely test on the real production system, no artificial environment required. The simulation feature works with import, reconciliation, recomputing focal objects and shadows, changes in roles or assignments, i.e., most of the devices your midPoint deployment uses on day-to-day basis.

Importantly, simulation does not run in an artificial sandbox; midPoint uses the production data, it just does not change them in the simulation mode. A simulated task yields exactly the same results as if it was not a simulation, except that it is only to report what the outcome would be. Nothing is written to the repository or remote resources.

You may be asking, "How do you differentiate the production configuration from the one you are preparing and want to use in a simulation?"

The answer is straightforward. Whatever configuration you want to test (use in a simulation), be it a mapping, role, or resource, you set it to the proposed lifecycle state instead of the usual active one. No proposed objects are used for any production operation. They constitute a virtual testing environment and cannot cause any harm until activated.

In tandem with lifecycle states, simulated tasks use different task execution settings in regards to mode and configuration. Tasks handling production run in the full execution mode with the production configuration. When you need to simulate a task, you use the preview execution mode with the development configuration. The difference between the two is that the former works with objects in active and deprecated lifecycle states and actually executes the computed changes, while the latter uses objects in proposed and active states to compute what would happen.

After a simulated task finishes, you get a detailed report of what would have been done were it not a simulation. The report is not a raw log file you would need to decipher laboriously. Simulated tasks produce an object called simulation result which is then presented to you in a structured form in the midPoint graphical user interface (GUI). You can review it thanks to easy to skim tiles and tables with the numbers of affected repository objects, shadows, changes that would be done on the objects, as well as how long the simulation took or where it failed, should that happen.

This means that before you go live with your adjustments to the configuration, you know exactly what is going to happen. No blind spots, no all nighters fixing an edge case you got no warning about.

When you spot anything out of place, you adjust the proposed configuration and then run the simulated task again. This way you immediately get updated results of your configuration and quick feedback based on the real living data in your midPoint repository.

Once you get the results you expect, you switch the lifecycle states from proposed to active on objects you want to deploy, and you are done. The new configuration is live. No environment cloning, no configuration transfer between repositories.

The simulation feature has certain limitations of which it is good to be aware, particularly in more advanced deployment configurations.

Refer to Simulation usage reference for details.

This feature is related to the following compliance frameworks: