Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
devel:documentation:systems:dev:system-mapping [2019/07/02 09:15] svandav [AUTHORITATIVE_MERGE (Authoritative merge)] |
devel:documentation:systems:dev:system-mapping [2020/02/05 10:59] svandav [MERGE (Merge)] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Connector configuration and attribute mapping ====== | ====== Connector configuration and attribute mapping ====== | ||
- | {{tag> | + | {{tag> |
===== Connector configuration ===== | ===== Connector configuration ===== | ||
+ | {{tag> | ||
Creation of a newly connected system will be demonstrated on a database connector (ConnIdDBBundle). | Creation of a newly connected system will be demonstrated on a database connector (ConnIdDBBundle). | ||
Firstly, we will create a new system named **Table** and choose the database connector. | Firstly, we will create a new system named **Table** and choose the database connector. | ||
Line 12: | Line 13: | ||
==== Connector pool configuration ==== | ==== Connector pool configuration ==== | ||
+ | {{tag> | ||
**The connector pool** is a very useful feature that avoids unnecessarily creating a new connector instance each time a connector is called. Typically, each connector instance also creates a connection to that target system. It is effective to maintain these connections for **longer periods and for multiple calls**. | **The connector pool** is a very useful feature that avoids unnecessarily creating a new connector instance each time a connector is called. Typically, each connector instance also creates a connection to that target system. It is effective to maintain these connections for **longer periods and for multiple calls**. | ||
Line 37: | Line 39: | ||
===== System scheme ===== | ===== System scheme ===== | ||
+ | {{tag> | ||
When the connector is configured correctly, we can move on to the **System scheme** tab. There, we will create the scheme either manually or we will use the scheme which will be returned by the connector itself (according to the filled-in configuration). | When the connector is configured correctly, we can move on to the **System scheme** tab. There, we will create the scheme either manually or we will use the scheme which will be returned by the connector itself (according to the filled-in configuration). | ||
Line 52: | Line 55: | ||
===== Attribute mapping ===== | ===== Attribute mapping ===== | ||
+ | {{tag> | ||
When the system scheme is created, we can move on to attribute mapping in the **Attribute mapping** tab. Mapping serves two basic purposes: | When the system scheme is created, we can move on to attribute mapping in the **Attribute mapping** tab. Mapping serves two basic purposes: | ||
Line 121: | Line 125: | ||
====== Mapped attribute strategy ====== | ====== Mapped attribute strategy ====== | ||
+ | {{tag> | ||
The attribute strategy defines how will the attribute and primarily its value be dealt with during provisioning and synchronization. | The attribute strategy defines how will the attribute and primarily its value be dealt with during provisioning and synchronization. | ||
Line 167: | Line 172: | ||
==== MERGE (Merge) ==== | ==== MERGE (Merge) ==== | ||
- | {{tag> | + | {{tag> |
<note warning> | <note warning> | ||
Line 194: | Line 199: | ||
That persisted ' | That persisted ' | ||
- | The evicted cache is **recalculated** by using the **AttributeControlledValuesRecalculationTaskExecutor** task, which is run after each save of attribute mapping on a role. In this case, this task recalculates the cache for all evicted attributes of the provisioning mapping. | + | The evicted cache is **recalculated** by using the **AttributeControlledValuesRecalculationTaskExecutor** task. This task recalculates the cache for all evicted attributes of the provisioning mapping. |
+ | |||
+ | <note important> | ||
+ | |||
+ | <note important> | ||
{{ : | {{ : |