Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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