Methodology: First Steps With MidPoint: Handling multiple sources
In real deployment we often need to connect multiple source systems to get all necessary data to midPoint.
Scenarios:
Additional source with no object (e.g. users) overlaps with other sources.
For example, you can have source systems for employees and another system for external employees.
This scenario is very simple. Just connect new source system in a same way as you have connected the very first one. Since there are no overlaps, each system will be responsible for own set of objects and their properties. Most likely you won’t have the exact same attributes in both system, therefore you need to count with that when you are defining your outbound mappings. Either you are fine with empty values (and expecting it during simulations evaluation), or you have a mapping script handling that. Otherwise, there is no difference compared to scenario with only a single source system.
Source with same objects but containing additional attributes.
For example, you have primary HR source with all users and their basic attributes and an addressbook source containing the same users and their email and telephone numbers.)
In this scenario we want to correlate account from both system to the same object (typically user) in midPoint. Make sure you have correct correlation rules for both source systems. In practice, it might be hard to guarantee that user is first created in primary source systems, synchronized to midPoint and then created (and synchronized) in the secondary source.
This can be handled in two ways:
-
Do not synchronize account from secondary source system until is will be synchronized from the primary one.
-
Do not set any reaction for the unmatched situation in the resource synchronization settings.
-
Set unlinked situation reaction to link to ensure the accounts for existing midPoint users will be linked.
-
Set up both liveSync and reconciliation task for secondary resource. LiveSync will skip account that cannot be linked at the moment (because midPoint user don’t exist yet) and won’t process them again unless there is a change on that account. Therefore, reconciliation running with reasonable period is needed.
It’s possible to configure synchronization from primary source system to trigger import of particular account from the secondary source during creation of the new user. This is complex configuration far beyond The First Steps methodology. -
Note that users in midPoint will be initially created without the data from the secondary source system. The data from secondary system will be added later by liveSync or reconciliation task. Keep that in mind when evaluating simulations and designing your mappings and data flows.
It might be complicated to automatically decide if unmatched account is only waiting for synchronization from primary source to create and user in midPoint to which this unmatched account will be linked or if this account is orphaned. -
-
If the account in the secondary system is synchronized first, create user with minimal information in draft lifecycle state.
-
Set unmatched situation reaction to add focus to create a new midPoint users if they don’t exist yet.
-
Set unlinked situation reaction to link to ensure the accounts for existing midPoint users will be linked.
-
Set weak mapping for lifecycle state to set draft value. This mapping will be overridden by strong lifecycle mapping in the primary source system.
-
Add mappings for necessary attributes. Don’t forget to add mapping that will be used from correlation from the primary source system (e.g. mapping for personal number).
If a user will stay in draft state for too long and synchronization from primary source system is running, it’s probably an orphaned account that should be handled. -
Same objects are present in both source systems.
For example a university scenario with source for employees and students where one person an be both student and employee.
| This scenario is beyond The First Steps Methodology. Even tough midPoint supports it, it requires complex configuration to handle it in its full complexity. This section describes several approaches, but it might require detailed study of relevant features configuration options. |
-
Make sure you have correct correlation rules for both source systems.
-
It’s recommended to use a single archetype (e.g. Person) for users from both systems. You can use Auxiliary archetypes to differentiate between them. User might be created first with any of them and later needs to be properly correlated when he/she is created in the other source system.
-
Set unmatched situation reaction to add focus to create a new midPoint users if they don’t exist yet.
-
Set unlinked situation reaction to link to ensure the accounts for existing midPoint users will be linked.
-
You need to solve problem of merging same attributes (e.g. given name and family name) from source systems to midPoint properties. This is the most difficult part with several options:
-
Set mapping strength for such attributes to normal. In that case the last change will overwrite the old one. Even though this might seem as a simple solution there might be some practical problem like lack of control on the result including reconciliation processes which are skipping such values. Nevertheless, in some cases this might be practical solution for start and replace it by robust solution later. See mapping strength documentation for details.
-
Create a custom schema extension where you can store attributes from both source systems. For example, you will have attributes like studentGivenName, employeeGivenName. Then, you will add mapping to your object template that will convert these extended attribute to standard midPoint schema base on your requirements. For example, you might decide that data from the employee source system, if exists, will be preferred over data from the student system.
-
Use experimental feature for multiple identity data source. The principle it the same as the schema extension approach, but the configuration is more straightforward. Read about experimental features before using this approach.
-
There are other options, like using conditional mappings with dynamic ranges, that might be preferred in certain situations. Such options are situational and complex to be described specifically. Contact our support if you need help with such case.
-
-
Don’t forget the lifecycle state user property needs to be merged base on state from both systems too.
-
Note that it’s impossible to simulate import from two sources at the same time. You need to connect them one by one at least to correlate users. When you have users correlated, you can simulate mappings from both sources by running simulated recomputation of users.