MidPoint 4.0 “Gutenberg” is really a revolutionary midPoint release. It is a long-term support (LTS) release. But it also brings groundbreaking features. The support for archetypes is certainly one of those features that can be a real game-changer in the future. First part of this post told the story how the idea of archetypes evolved during the course of midPoint development. This part will describe how archetypes work and how they can be used.
The idea of archetypes is both simple and complex. The simple part is really simple: archetypes can be used to distinguish object types. There would be an archetype for business role, another archetype for application role, yet another archetype for employee, customer, partner, department, project, work-group and so on. Administrator will no longer create “user” or “role”. The administrator will create “employee” or “business role” instead. There could be nice icons and colors for archetyped objects in midPoint user interface. Archetypes can be used in object lists (views) in midPoint menu. Overall, archetypes make midPoint user interface nicer. That is the simple part.
The complex part has everything to do with the idea of metaroles. Metarole is quite a strange kind of an animal. Ordinary roles are usually applied to users. But metaroles can be applied to anything: users, orgs, services – and even roles themselves. Hence the term “metarole”, meaning “role applied to another role”. Metaroles can change the behavior of the object they apply to. Metaroles can be used to implement very elegant provisioning patterns. Metaroles can apply policies. Overall, metaroles can be incredibly powerful.
Simply speaking, archetypes are just metaroles wearing a nice suit. Archetype can do anything that a metarole could do. Which makes them quite powerful already. In addition to that, archetype can change the look and feel of the “archetyped” objects. But there is still more. Archetypes are designed to specify how archetyped objects should fit into your customized midPoint configuration. An archetype can specify assignment relation constraints. For example, “project” archetype could specify, that it can have members and managers and those must be users. No other relation could be made to a “project”. Therefore midPoint user interface will not offer to assign project owner or approver. Only member (“default” relation) and manager (“manager” relation) assignments are allowed. And those assignments must be placed in user objects. Roles, orgs and services cannot be members of a project. This may seem like a small thing. But this approach has a great potential to significantly simplify and streamline midPoint user interface – which is getting quite complex already. The big idea is that archetypes could make midPoint user interface more accessible to non-technological users.
Archetypes are a huge leap forward. But there is still a long way to go. Archetypes in midPoint 4.0 are powerful, but they can still be improved. It would be nice if archetypes could define a custom schema for archetyped objects. Or if they could specify custom lifecycle model. And the user interface part can always be improved to make it more user-friendly. The funding to develop archetypes in midPoint 4.0 was provided by a platform subscription. Another such subscription can be used to improve archetypes further. That is how midPoint evolves.