Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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:17]
svandav [System scheme] 		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>connector mapping system configuration }}+{{tag>connector mapping system configuration merge authoritative skip excluded }}
  
 ===== Connector configuration ===== ===== Connector configuration =====
 +{{tag>connector configuration}}
 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>connector pool}}
  
 **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 170: Line 172:
  
 ==== MERGE (Merge) ==== ==== MERGE (Merge) ====
-{{tag>merge}}+{{tag>merge controlled}}
  
 <note warning>Since version **9.3.0** was provisioning merge completely reimplemented!</note> <note warning>Since version **9.3.0** was provisioning merge completely reimplemented!</note>
Line 197: Line 199:
 That persisted 'cache' is evicted when definiton for that attribut is changed on the role (SysRoleSystemAttribute). That persisted 'cache' is evicted when definiton for that attribut is changed on the role (SysRoleSystemAttribute).
  
-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>Since version **9.7.5** is recalculation of evicted attribute **not starts on save a attribute** (SysRoleSystemAttribute)! Attribute on the system is **marked as evicted only**. Recalculation will be processed during first using of controlled values. This is typically on first **update provisioning**. **Beware** if new account is created and create provisioning is executed, then recalculation is not executed, because in this situation are controlled values not needed!</note> 
 + 
 +<note important>The merge attribute value must be a **constant**. For performance reasons, all system merge values are cached and this cache is recalculated only if the corresponding **role attribute changes**! **If the value is dynamic, the cache will not contain the correct data!**</note>
  
 {{ :devel:documentation:systems:dev:controlledvaluestask.png |}} {{ :devel:documentation:systems:dev:controlledvaluestask.png |}}
  • by svandav