Page tree
Skip to end of metadata
Go to start of metadata

Planned feature

This page describes a feature planned for future midPoint versions.

This feature is roughly designed and it was evaluated as feasible. However, there is currently no specific plan when it will be implemented because there is no funding for this development yet. In case that you are interested in supporting development of this feature, please consider activating midPoint Platform subscription.

Background

MidPoint used to contain an embedded workflow engine in the past. But is did not make much sense. Therefore midPoint is completely workflowless now.

Even though midPoint has policy-based approvals, there is still a need for a processes. Maybe there is an enrollment process for a new employee. Maybe that employee needs to get company badge, get keys to the office, attend health&safety training and so on. We may need an algorithmic process which is full of human interaction. That is still a very valid requirement. Process is needed. There is usually a company-wide workflow system those days. Therefore the natural way for midPoint to interact with workflow processes is to connect to existing enterprise workflow engine.

MidPoint should be able to forward a process to a workflow system and continue the process when workflow engine is finished.

Solution

MidPoint has an ability to suspend existing processes. This ability is used for internal approvals in midPoint. The same ability can be used to integrate midPoint with an external workflow engine.

Workflow integration plugin is needed as a glue code between midPoint and a workflow engine. The plugin can integrate into midPoint processes using clockwork hooks. The hooks can be used to intercept the process and suspend it (switch it to "background"). Then a similar mechanism is used to resume the process once the external workflow is finished.

Theoretically the implementation is quite straightforward. However, there is a lot of potential problems:

  • Clockwork hook interface is not officially a public interface. Yet. It is used for internal integration. But it was not completely validated and interface definition may change. This interface needs to be stabilized, documented and open to public use. It is expected that first integration with an external workflow engine will needs some changes or extensions in the interface.
  • There is no robust plugin system in midPoint. Therefore the plugin has either to be bundled into midPoint or there must be a custom build by using overlay project.
  • How to pass parameters to workflow and how to interpret to results? Do we need a hardcoded "midPoint interface" to workflow processes? Or do we need expressions that can be used to easily customize the integration?
  • Expression-based plugin will require that midPoint expression evaluation code is exposed to third-party plugins, interfaces need to be stabilized and documented. We also need to think about security (e.g. Expression Profiles).
  • How to synchronize status of midPoint and workflow engine in case of failures? E.g. in case that the notification about completed process is lost.
  • Plugin configuration - where do we store that? Do we need a new object type? Can we use system configuration?
  • How to monitor the status of the plugin? How do we know that the midpoint-workflow connection went down?

Those issues can be resolved during the course of midPoint development. However, some changes into midPoint code may be needed to properly support all the workflow use cases.

Workflow engines

It is obvious that every workflow engine will need its own plugin in midPoint. The plugin will either be hardcoded to a specific set of processes. Or it may be a more generic plugin where data translation is driven by expressions.

One of the first candidates for workflow integration is Camunda.

See Also

  • No labels