Synchronization Rules in MIIS 2003
Applies To: Windows Server 2003 with SP1
Download Instructions
This document is available for download as a Microsoft Word document at https://go.microsoft.com/fwlink/?LinkId=30737.
Overview
MIIS 2003 synchronization rules are the technical implementation of business rules. They determine how data is synchronized between connector spaces and the metaverse. Synchronization rules are configured in the MIIS 2003 user interface. They are either implemented declaratively or as part of a rules extension. This subject describes the different types of rules and how they affect the data flow of MIIS 2003.
In this subject
What Are MIIS 2003 Synchronization Rules?
How MIIS 2003 Synchronization Rules Work
What Are MIIS 2003 Synchronization Rules?
As part of identity integration, MIIS detects changes to identity data and then process them. The way MIIS processes those changes is determined by the configuration of synchronization rules.
Synchronization decisions are usually based on a broad range of different aspects of a given solution and depend on rules that reflect business requirements instead of the most recent settings. For example, the synchronization process can be configured to update information in connected data sources only when an attribute has a certain value. The synchronization process could even set a recently changed value of an attribute back to a value that meets the specified requirements.
Business requirements are expressed in the form of business rules. Business rules define, at a high level, how identity information should be processed between connected data sources and MIIS 2003.
MIIS 2003 provides a well-defined set of synchronization rules that enable you to adjust the synchronization process to reflect business requirements. The configuration of the synchronization rules governs the entire synchronization process, including inbound synchronization and outbound synchronization. Configuring synchronization rules requires careful planning.
Synchronization rules are either declarative or evaluated as part of a rules extension. MIIS 2003 provides declarative rules that do not require scenario-specific evaluations. You set declarative rules by using the MIIS 2003 user interface.
Rules extensions are compiled code that you create to define scenario-specific operations. You create a rules extension when the declarative rules of MIIS 2003 do not sufficiently address the complexity of your business requirements. These scenario-specific operations are initiated when the associated rule is processed. Some of the common tasks that you can perform using a rules extension are:
Transforming data
Flowing attribute—Data transformation is one of the most common tasks that rules extensions are used for. Data transformation occurs during attribute flow by calculating a target attribute value (or attribute values, in the case of a multi-value attribute). Typically, the source of this calculation is based on source attributes that are imported into FIM, or it is based on information from external data sources.
Finding Join candidates—Data transformation can also be used to find join candidates. This is a special case of calculating a value, or values, that is later used in the join process to find matches in the metaverse.
Creating new accounts—Along with synchronization and data transformation, the most common task that FIM is used for is the creation of new objects, such as user accounts or mail contacts, in single or multiple connected data sources. This is known as provisioning.
Checking for attribute values—Sometimes it is necessary to check for attribute values before making the decision of how, or if, an object is processed by FIM. Attribute values can be checked for objects in the connector space or in the metaverse.
Creating unique attribute values—FIM can be used to ensure uniqueness for specific attribute values (for example, for an e-mail alias or a logon account name). After attribute values are flowed into the metaverse, a search is made of existing attribute values, and a comparison is made for uniqueness.
Creating a unique naming attribute—Every connected data source has a naming attribute for its entries or objects. For example, in a Lightweight Directory Access Protocol (LDAP) directory this would be the distinguished name (also known as DN). Typically, these naming attributes are constructed based on information that is flowed into the metaverse. A rules extension can calculate and apply a naming attribute based on this information, and it can guarantee uniqueness of the naming attribute by determining if an object with that name already exists. In this case, the rules extension can recalculate the naming attribute and retry the operation.
Deprovisioning accounts—Deprovisioning is the process of managing connector space objects after they have been disconnected from a metaverse object under certain circumstances. In some cases you might want to remove the connector space object permanently. In other cases you might want to keep the connector space object in a disconnected state and have it available to link to a metaverse object at a later time.
Moving objects—A common task in administrating directories is to move objects within a hierarchy. Moving an object is accomplished by creating a new naming attribute and assigning this attribute to the object.
Setting initial passwords—During the creation of a new account, it is often necessary to assign an initial password. A rules extension can be written to immediately assign an initial password when a new account is created.
Enabling or disabling accounts—Accounts on different connected data sources can be enabled or disabled by setting specific attribute values for the user account. One example is Active Directory where the userAccountControl attribute determines the state of a user account. A rules extension can modify this attribute at any place during the attribute flow
.
Rules extension code should address only requirements that directly apply to the synchronization rule for which it was called. Do not call external application programming interfaces (APIs) unless they are required for the decision-making process of the synchronization rule.
For most MIIS 2003 rules, you have the option of specifying the rule as a declarative rule or as a rules extension. You can specify either option in the user interface when you configure the rule.
Objects are synchronized as they are processed between the metaverse and the connector spaces. Therefore, synchronization rules apply to operations that occur between the metaverse and the connector spaces, but not to operations that occur between the connected data sources and their respective connector spaces.
Synchronization rules are grouped into the following categories:
Local synchronization rules, which apply to the objects in the connector space of a management agent for a connected data source and their counterparts in the metaverse.
Global rules, which apply to all objects in MIIS 2003.
You configure local synchronization rules when you configure a management agent. Consequently, a rules extension that applies to a specific management agent must be specified during management agent configuration. In contrast, global rules that are not declarative rules must be configured within a single rules extension.
The synchronization rules processed during inbound synchronization and outbound synchronization perform object-level operations first (for example, link management), and then attribute-level operations (for example, attribute flow) on all staging objects that are linked to a metaverse object. MIIS 2003 provides the following synchronization rules:
Inbound synchronization rules
Object deletion rule
Connector filter rule
Join rule
Projection rule
Import attribute flow rule
Outbound synchronization rules
Provisioning rule
Deprovisioning rule
Export attribute flow rule
Attribute flow control rules
Attribute precedence rule
Allow nulls on export rule
Recall attributes from metaverse object on disconnect rule
The following illustration shows where in the identity management process MIIS 2003 uses the synchronization rules. The following sections describe these rules.
.gif "Synchronization Rules")
Password extensions
For file-based, database, and extensible connectivity management agents, which do not support password change and set operations by default, you can create a .NET password extension dynamic-link library (DLL), which is called whenever a password change or set call is invoked for any of these management agents. Password extension settings are configured for these management agents in Identity Manager.
| Password management is supported by default in the management agents for: | By using a password extension, password management is also supported in the management agents for: |
|---|---|
|
|
For more information about creating and using rules extensions and password extensions, see the MIIS Developer Reference.
How MIIS 2003 Synchronization Rules Work
This section describes MIIS 2003 inbound synchronization rules, outbound synchronization rules, and attribute flow control synchronizations rules. This section then concludes with a summary of the synchronization rules and prerequisites for applying them.
Inbound Synchronization Rules
The following synchronization rules are used during the inbound synchronization process:
Connector filter. Determines whether a staging object is further processed during synchronization.
Join. Attempts to locate objects in the metaverse by looking for specified conditions and, when matching objects are found, links staging objects to a metaverse object.
Projection. Determines whether to create a new metaverse object and link a disconnector object to it.
Import attribute flow. Determines how new attribute values available on a staging object are assigned to a metaverse object.
Object deletion. Determines how MIIS 2003 processes an object when a link is removed during inbound synchronization.
The following sections explain each rule in detail. Each section includes a table that summarizes where the rule is applied and notes whether the rule can be a declarative rule or a rules extension
Object Deletion Synchronization Rule
The object deletion rule determines how MIIS 2003 reacts when a link between a staging object and a metaverse object is removed during inbound synchronization. During inbound synchronization, links can be removed only by processing a pending deletion operation on an object.
Objects in the metaverse must be linked to at least one staging object. At the end of each synchronization process, by default, MIIS 2003 deletes each metaverse object that is not linked to a staging object.
The following flow chart shows the sequence in which object deletion rules are applied.
.gif "Object deletion rules")
The following table lists where the object deletion rule is applied and whether it can be declarative or configured as a rules extension.
Object Deletion Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Metaverse |
Yes |
Yes |
Connector Filter Synchronization Rule
The connector filter rule determines whether a staging object is processed further during synchronization. During inbound synchronization, the connector filter rule is applied to all staging objects that are not explicit disconnector objects (connector objects and normal disconnector objects).
The connector filter rule accomplishes two objectives. First, it prevents a disconnector object that does not pass the filtering requirements from becoming a connector object. Second, it disconnects a connector object that does not pass the filtering requirements.
Management agents request data from the connected data source by specifying object location, object type, and an attribute inclusion list. The connector filter rule extends these requirements by evaluating additional conditions for each staging object.
If a connector object does not meet the requirements specified in the connector filter rule, it becomes a disconnector object. If a normal disconnector object fails the connector filter rule, the disconnector object is not processed further during synchronization, which means that the join and projection rules will not be processed for that disconnector object. In such a case, though the connector filter rule has been applied, it has no consequence. If a normal disconnector object passes the connector filter rule, MIIS 2003 next applies the join and projection rules to the object.
Note
A normal disconnector object that passes the connector filter rule can become a connector object if the join and projection rules specify that the object should be linked to a metaverse object.
In most cases, the connector filter rule is applied by evaluating attribute availability and the specific attribute value. For example, this rule might be configured so that user objects that are imported from Active Directory are not processed any further if the account is disabled. In this case, the rule would be configured to evaluate the userAccountControl attribute, which is the attribute of an Active Directory user object that indicates if the user account is active or disabled. The following table summarizes where the connector filter rule is applied and whether it can be declarative or configured as a rules extension.
Important
You should also review your connector filter rules together with your export attribute flow rules to ensure that they do not conflict with each other. Conflicting rules can cause an infinite loop in the synchronization process. For example, an attribute change may be flowed from the metaverse to a connector space object that will cause the connector space object to satisfy the connector filter rule. At the next full synchronization, the connector space object will become a filtered disconnector, and the attribute change will be recalled. After the attribute change is recalled, the filtered disconnector no longer satisfies the connector filter rule, and it will be rejoined on the next full synchronization where the attribute change will be flowed again.
Connector Filter Synchronization Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
Yes |
Join Synchronization Rule
The join rule is an object-level operation that attempts to locate objects in the metaverse by looking for specified conditions and, when matching objects are found, links staging objects to a metaverse object. The join rule has the following components:
Join criteria
Join resolution
You specify join criteria by referencing the object type in the connected data source. The join criteria can be restricted to a specific object type in the metaverse.
To create a declarative join rule, you create a list of connected data source object attributes that are mapped to metaverse object attributes. MIIS 2003 compares these attribute values by using an equal evaluation (that is, if the list of attribute pairs consists of more than one entry, the evaluation uses a logical AND condition). All specified attribute pairs must pass the evaluation.
To perform this mapping, you can use single-valued or multivalued attributes on either side or on both sides of the equation. If you use multivalued attributes, MIIS 2003 uses all of the values to evaluate the mapping.
For string data types, searches are always case-insensitive and locale-sensitive. For numeric and binary data types, MIIS 2003 searches for exact matches.
Note
Only those metaverse attributes that can be indexed are available for the join criteria.
Join criteria also can be specified for an individual attribute by using a rules extension. With a rules extension, you can specify what “equal” means for each individual join criterion. The definition of “equal” can apply to attributes with different data types. For example, if the attribute of the staging object is a number that has to be compared with a metaverse object attribute that is a string, you must specify within the rules extension which values are considered equal.
When using join criteria, MIIS 2003 might find more than one matching object in the metaverse. To account for such a case, you must provide a “resolution decision” within the rules extension. The resolution decision determines which object in the metaverse is the ultimate match.
Often, with non-congruent data sets, the metaverse object type to which the staging objects are ultimately joined might not be determined until later in the join process. In other words, the join resolution process can always change the object type of the metaverse object. In this case, the attribute values that are currently assigned to the metaverse object are deleted before the join resolution process changes the object type and the attribute values are recalculated based on the attributes in the synchronized import holograms of all linked staging objects. The following table lists where the join rule is applied and whether it can be declarative or configured as a rules extension.
Join Synchronization Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
Yes |
Projection Synchronization Rule
The projection rule determines whether MIIS 2003 projects a disconnector object into the metaverse. Use this rule to define the required object type for the disconnector object and the object type for the projected metaverse object.
If the disconnector object matches the specified object type and the join criteria does not apply, the inbound synchronization process creates a metaverse object of the specified type and links the disconnector object to the newly created metaverse object; that is, it converts the disconnector object to a connector object.
The projection rule is the only means by which MIIS 2003 can create objects in the metaverse. The following table lists where the projection rule is applied and whether it can be declarative or configured as a rules extension.
Projection Synchronization Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
Yes |
Both join and projection rules are responsible for connecting staging objects with metaverse objects before attribute values are updated. The major difference between these rules is that the join rule requires that a corresponding metaverse object already exist.
There are dependencies between the join and projection rules, as shown the following illustration.
.gif "Join and Projection Rules")
Import Attribute Flow Synchronization Rule
Import attribute flow occurs after an object-level operation (that is, a join or a projection) has been applied to a connector object after join and projection are complete.
The import attribute flow rule determines how new attribute values that are staged on a connector object are assigned to a metaverse object. If the values of the connector object can be assigned directly to a metaverse object, this rule can be declarative.
Alternatively, if it is necessary to base attribute flow on the evaluation of individual conditions, this rule can be part of a rules extension. For example, you might specify that the value of the attribute that defines a user’s employee ID number is assigned to a metaverse object only if the userAccountControl attribute indicates that the user account is active.
Attribute flow rules are defined by the attribute mappings in the management agent. The following table lists the different kinds of mappings that you can specify.
| Mapping type | Description |
|---|---|
Direct |
Defines a direct relationship between a single source attribute and a single destination attribute. The destination attribute is assigned the value of the source attribute and cannot be modified by a rules extension. The attribute might have different names in the management agent schema and the metaverse schema. For example, you can map employeeID to userID. |
Rules extension |
Defines a direct relationship between one or many source attributes and a single destination attribute. For example, you can map two source attributes such as firstName and lastName to create a single destination attribute fullName. |
Constant |
Defines a single destination attribute and the constant value that the attribute will have. A source attribute does not exist. For example, you can set the value of the destination attribute OU to Contoso, Ltd for all objects. |
Distinguished name |
Defines a mapping between a component of the source distinguished name and a single destination attribute. For example, you might want to assign a username value that does not contain the complete distinguished name (also known as DN) from the hierarchical directory. For the user CN=MikeD,CN=Users,OU=MIIS,O=Microsoft you can map component 1 of the distinguished name to the destination attribute username. The value of username would then be MikeD. |
The following illustration shows examples of the four possible attribute mapping types.
.gif "Management agent rules")
The following table lists where the import attribute flow rule is applied and whether it can be declarative or configured as a rules extension.
Import Attribute Flow Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
Yes |
The following illustration shows how the import attribute flow rule is applied.
.gif "Import Attribute Flow Rule")
Outbound Synchronization Rules
The following synchronization rules apply to the outbound synchronization process:
Provisioning
Deprovisioning
Export attribute flow
The following sections explain each rule in detail. Each section includes a table that summarizes where the rule is applied and whether it can be a declarative rule or a rules extension.
Provisioning Synchronization Rule
Provisioning connects or initiates a disconnection of a metaverse object from staging objects or renames staging objects. Because provisioning is a global rule, it can perform those actions in the connector spaces of all available management agents.
The provisioning rule is responsible for object-level operations on staging objects in the connector space. To implement provisioning, you create and enable a rules extension. When you enable provisioning rules, they affect all objects in the metaverse. Provisioning rules are called whenever a metaverse object is modified by the following methods:
An attribute has been added, modified, or deleted by import attribute flow rules.
A connector space object has been joined to a metaverse object.
A connector space object has been projected to the metaverse.
A connector space object has been connected using Joiner.
A connector space object has been disconnected from a metaverse object and the metaverse object has not been deleted.
A management agent is run with a step type Full Import and Full Synchronization or step type Full Synchronization.
The rules extension for provisioning rules can take advantage of the transactional capabilities of Microsoft® Forefront Identity Manager (FIM) 2010. In a case in which a connector space object is provisioned to multiple connected data sources and one of the provisioning rules fails, the complete synchronization operation will be rolled back by default. However, whenever a provisioning rule fails, it will report a rules exception to FIM. You can write a rules extension to identify exceptions and handle them on a management agent basis by doing the following:
Calling a routine to handle the exception, and then proceeding with the synchronization. In this case the synchronization will succeed.
Calling a routine to analyze the exception and determine its severity. If the exception is too serious to continue, return it to FIM. In this case the entire provisioning transaction will be rolled back.
Letting the exception go directly to FIM. In this case the entire provisioning transaction will be rolled back.
The following flow chart shows the sequence in which provisioning rules are applied.
.gif "Provisioning rules")
The following table lists where the provisioning rule is applied and whether it can be declarative or configured as a rules extension.
Provisioning Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Metaverse |
No |
Yes |
Deprovisioning Synchronization Rule
Deprovisioning determines how a staging object is processed after it has been disconnected from a metaverse object during outbound synchronization. The disconnection can be caused either by an object deletion synchronization rule that has deleted a previously connected metaverse object or by the provisioning synchronization rule.
In such a case, MIIS 2003 must determine what to do with the disconnected staging object. When cleanup operations are required for a disconnected staging object, the deprovisioning rule can specify that any of the following activities can occur:
The staging object is retained as a normal disconnector object in the connector space
The staging object is converted into an explicit disconnector object
The staging object is staged as a pending delete
Although the deprovisioning rule allows MIIS 2003 to perform attribute-level operations, it is recommended that you avoid this practice. Attribute value changes that are applied to a staging object during deprovisioning are lost if an error occurs during an attempt to export them to the connected data source or if they cannot be reimported from the connected data source. Because you cannot control whether these changes are persistently applied to a staging object, it is recommended that you avoid this practice.
The following table lists where the deprovisioning rule is applied and whether it can be declarative or configured as a rules extension.
Table 10 Deprovisioning Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
Yes |
The following figure shows how the provisioning and deprovisioning rule are applied.
.gif "Provisioning and Deprovisioning")
Export Attribute Flow Synchronization Rule
The export attribute flow synchronization rule is similar to the import attribute flow synchronization rule in that export attribute flow occurs as the final step in the outbound synchronization process on all connectors included in the outbound synchronization process. Export attribute flow occurs only on connector objects.
The following table lists where the export attribute flow rule is applied and whether it can be declarative or configured as a rules extension.
Export Attribute Flow Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
Yes |
The following illustration shows how the export attribute flow rule is applied.
.gif "Export Attribute Flow Rule")
Attribute Flow Control Synchronization Rules
Attribute flow control synchronization rules allow the fine-tuning of the attribute flow process. Attribute flow control synchronization rules include the following:
Attribute flow precedence synchronization rule
Allow nulls on export synchronization rule
Recall attributes from metaverse on disconnect synchronization rule
The following sections explain each rule in detail. Each section includes a table that summarizes where the rule is applied and whether it can be a declarative rule or a rules extension.
Attribute Flow Precedence Synchronization Rule
The attribute flow precedence synchronization rule controls when attribute values flow between staging and metaverse objects. When more than one management agent is configured, several different staging objects from different management agents can potentially contribute values to a specific metaverse object. The attribute flow precedence rule allows MIIS 2003 to control attribute flow from staging objects to metaverse objects by prioritizing the management agents that can potentially contribute attribute values.
The attribute flow precedence synchronization rule allows the attribute flow from the staging objects of a particular management agent to change the attribute values of a metaverse object only if the management agent has a priority that is equal to or higher than the priority of the management agent that previously initiated import attribute flow. When the management agent with the highest priority has contributed an attribute value, only this management agent can provide further updates on this attribute.
If the attribute flow precedence rule is a declarative rule, the priority is set by the order in which the management agents are listed in the user interface. You can resort this list. If the attribute flow precedence rule is a rules extension, you define the precedence in the code.
The following table lists where the attribute flow precedence rule is applied and whether it can be declarative or configured as a rules extension.
Attribute Flow Precedence Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Metaverse |
Yes |
Yes |
Export precedence
Export precedence is a set of built-in rules that keep attribute values from lower-precedence connected data sources from flowing out to higher precedence connected data sources. To configure effective attribute flow, it is important to understand how export precedence is applied.
Export precedence rules are applied to export attribute flows that overlap an import attribute flow. An export attribute flow and import attribute flow are said to overlap if:
The flows refer to the same management agent, connector space object type, and metaverse object type.
The export attribute flow has at least one source attribute, which is also the destination attribute for the import attribute flow.
The destination attribute of the export attribute flow is one of the source attributes of the import attribute flow.
Export precedence rules are not applied in the following cases:
When the export attribute flow has no source attributes, that is, if it is a constant or rules extension mapping. In these cases, export attribute flow rules always run. Keep this behavior in mind when you design attribute flow rules.
When the import flow for the attribute is configured for manual precedence. When manual precedence is configured for an attribute, normal attribute precedence rules are ignored, and the precedence is handled by the manual precedence rules extension.
When there is no overlap between any export and import attribute mappings.
If an overlap mapping is determined:
The overlap ranking is determined for the source, or metaverse attribute. The overlap ranking is the precedence ranking of the highest-precedence overlapping import attribute flow mapping from the destination connector space.
The populator ranking is determined for the source, or metaverse attribute. The populator ranking is the precedence ranking of the mapping that populated the source, or metaverse attribute.
If the lineage on the source attribute is not recognized, that is, if it refers to an import attribute flow that has been deleted, the rank is set to the lowest precedence.
If there are no values on the source attribute, a rank cannot be determined and the export attribute flow mapping does not run. This prevents behavior that might lead to unintended data loss.
The overlap ranking and the populator ranking are then compared. If the populator rank is greater than the overlap rank, that is, if the mapping that populated the export flow's source attribute has lower precedence than the import attribute flow mapping from the destination connector space, then the export attribute flow rules do not run, and the status “export-skipped-not-precedent” is returned. Otherwise, the export attribute flow rules run as configured.
Allow Nulls on Export Synchronization Rule
You can use the Allow nulls on export rule whenever you want to prevent a metaverse attribute delete to be exported to a connected data source. Export attribute flow mappings have an additional option to disallow flowing out deletes if the metaverse attribute values are removed. Allow nulls on export can be set for each attribute that is included in the export flow rule.
The following table lists where the Allow nulls on export rule is applied and whether it can be declarative or configured as a rules extension.
Allow Nulls on Export Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Metaverse |
Yes |
No |
Recall Attributes from Metaverse Object on Disconnect Synchronization Rule
The synchronization process can disconnect metaverse objects from staging objects. In this case, you might no longer want the integrated view to contain any identity data that was contributed by the disconnected staging object. You can configure this behavior by invoking the recall attributes from metaverse object on disconnect synchronization rule. By default, when a staging object is disconnected from a metaverse object, all of the attribute values that the staging object contributed to the metaverse object are recalled from the metaverse object.
However, there are certain situations in which those attribute values must remain in the metaverse, even though the source for those attribute values has been disconnected.
Attribute recall can cause a repopulation of attributes in the metaverse, which might affect provisioning. If an attribute used in provisioning is recalled, and is not repopulated, the attribute might be cleared. If the provisioning process requires this attribute to make decisions based on its value, MIIS 2003 throws an exception.
Note
The recall attributes from metaverse object on disconnect synchronization rule does not affect the role of attribute flow precedence. Connected data sources with lower precedence continue to be prevented from replacing higher precedence values that are left by a disconnected or deleted staging object. In addition, higher precedence data sources can replace the values.
The following table lists where the recall attributes from metaverse on disconnect rule is applied and whether it can be declarative or configured as a rules extension.
Recall Attributes from Metaverse on Disconnect Rule
| Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|
Management agent |
Yes |
No |
Synchronization Rules Summary
The following table lists a summary of the synchronization rules, including where they are applied and whether each can be a declarative rule or a rules extension.
Synchronization Rules Summary
| Synchronization Rule | Where the Rule is Applied | Declarative | Rules Extension |
|---|---|---|---|
Connector filter rule |
Management agent |
Yes |
Yes |
Join rule |
Management agent |
Yes |
Yes |
Projection rule |
Management agent |
Yes |
Yes |
Import attribute flow rule |
Management agent |
Yes |
Yes |
Object deletion rule |
Metaverse |
Yes |
Yes |
Provisioning rule |
Metaverse |
No |
Yes |
Deprovisioning rule |
Management agent |
Yes |
Yes |
Export attribute flow rule |
Management agent |
Yes |
Yes |
Allow flow precedence rule |
Metaverse |
Yes |
Yes |
Allow nulls on export rule |
Metaverse |
Yes |
No |
Recall attributes from metaverse object on disconnect rule |
Management agent |
Yes |
No |
Applying Synchronization Rules Prerequisites
Each synchronization rule has a prerequisite, which allows the rule to be defined according to a scope. A scope is a range of values or conditions used to search for objects in the connector space or metaverse. A scope can include such conditions as date, pending import, disconnector objects, and object type. Scoping a synchronization rule by specific elements enables the rules to be triggered more efficiently.
The scoping elements for the synchronization rules include:
Connector space object type
Metaverse object type
Management agent
Attribute flow mapping
Metaverse attribute
Metaverse object change
The following table lists the scoping element for each synchronization rule.
Synchronization Rules Scoping Elements
| Synchronization Rule | Scoping Element |
|---|---|
Connector filter |
Connector space object type |
Join |
Connector space object type |
Projection |
Connector space object type |
Attribute flow |
Connector space and metaverse object types |
Allow nulls on export |
Attribute flow mapping |
Recall attributes from metaverse object on disconnect |
Management agent |
Attribute flow precedence |
Management agent and metaverse object type |
Object deletion |
Metaverse object type |
Provisioning |
Metaverse object change |
Deprovisioning |
Management agent |