Simply speaking archetype is a well-defined object subtype. Employee, contractor, project, workgroup, application, ... each of them is an archetype. The idea is that archetype builds on top of existing midPoint types such as User, Org or Role. A project is just a special case of organizational unit. As is division, section, company, workgroup or any other concept that groups identities. An application is a special case of service. As is mobile device, printer, cloud service, web API endpoint and so on. All those concepts are just specializations of the object types that midPoint already has. And there is actually enormous advantage to reuse existing midPoint concepts. If projects are modeled as organizational units then they "inherit" all the functionality of an organizational unit out-of-the-box. Therefore projects can have managers, they may be used for delegated administration, they can grant privileges to members and managers and so on. All of this is already implemented for organizational units and all of this can be instantly reused for projects. In a similar fashion application can inherit existing functionality of service (e.g. ability to grant privileges). This kind of reuse is very convenient and it is also extremely powerful mechanism. Following table lists commonly-used archetypes and their mapping to primary midPoint object types:
|Primary Object Type||Archetype|
Employee, Contractor, Partner, Supplier
Company, Division, Department, Section
Project, Team, Workgroup, Task force, Committee
Class, Research team
Business role, Application role, Metarole
Protection scope, Consent target
Application, Device, Printer
Web API endpoint
Archetype definition is a special midPoint object (ArchetypeType). Being a midPoint object, archetype has an natural persistent identifier: OID. OID of the archetype definition is also identifier of archetype itself. Each object of that archetype will contain archetype definition OID. E.g. every employee will contain OID of employee archetype definition object. This OID is used internally by midPoint to process archetypes. But it can also be used for searching objects of a particular archetypes by the custom code or midPoint API clients.
MidPoint 3.x used mechanism of subtype to implement parts of the functionality provided by archetypes. Archetypes should provide complete replacement for subtype functionality (with some limitations). Subtype will still work in midPoint 4.x, but it is no longer a recommended mechanism - except for assignment subtype, which is still useful. Subtypes will be most likely deprecated sometime during midPoint 4.x lifetime and the plan is to remove it completely in midPoint 5.0.
Historical note: the original idea was to implement archetypes as an extension of the subtype functionality. But it was discovered during the detailed design of archetype functionality that we can do it much better. Current form of archetype functionality fits perfectly with existing midPoint features and it is much more powerful than originally planned. Therefore the idea of subtype-based archetypes was dropped.
- Archetype Configuration
- Archetype Improvements (Planned Feature)
- Organizational Structure
- Advanced Hybrid RBAC