Process Steps for Planning Synchronization Rules
Applies To: Windows Server 2003 with SP1
Previous Section
The process for planning your synchronization rules involves using the documentation that the project team created in the earlier stages and involves completing additional worksheets, which include the following:
Metadirectory Object Policies worksheet
Connector Filter Rules worksheet
Projection Rules worksheet
Import attribute flow rules worksheet
Join rules worksheet
Export attribute flow rules worksheet
Deprovisioning rules worksheet
Object deletion rules worksheet
For illustration purposes, scenarios in this section refer to the Design and Planning diagram used in the previous planning documents. While the rules planner plans the synchronization rules, consolidate the information from the tables into the “Metadirectory Object Policies Worksheet” in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. The following steps outline this process:
Gather the data from the system dataflow design document that you are using to plan your synchronization rules. Copy the documents and worksheets that the project team produced in the earlier stage of the project so that you can modify them, preserving the original copies for reference.
Identify invalid data situations. Study each connected data source object for import, and find out if it is likely to contribute invalid data.
Identify synchronization tasks. Determine how your synchronization rules will work together to achieve an end-to-end dataflow; how the result of one rule affects the action of the other rules; and, when you have completed these steps, analyze the overall synchronization for conflicts between synchronization rules.
Step 1: Gather Data From the System Dataflow Design Document
Table 1 should identify all of the general information you need to plan your synchronization rules. For more details about the specific information that is summarized in the table, see the system dataflow design document.
Table 1: Synchronization Rules Planning Requirements
| Required information | Design choices |
|---|---|
Synchronization scenario type |
Homogeneous object scenario Single master scenario Heterogeneous object scenario |
Metaverse object mappings |
Connected data source-to-metaverse mapping information for all data source objects types |
Metaverse attribute definitions |
Name, data type, value, indexing |
Mapping type for each metaverse attribute |
Direct Advanced (subtypes: rules extension, constant, DN=component) |
Management agents |
Name and description for each defined management agent |
Attribute precedence |
Evaluation of each management agent to determine attribute precedence configuration |
Definition and evaluation of invalid data |
Processes that can change attribute Setting required or optional Support for null values Maximum and minimum values Default value Allowed value range Legal values to match Connected data source support for duplicate values Support for duplicate values between data sources |
Error reporting |
Deployment scenario policies for reporting data errors |
Step 2: Identify Invalid Data Situations
To decide what synchronization rules you want to use for handling invalid data, study each connected data source object for import, and find out if it is likely to contribute invalid data. Invalid data is any data that might violate assumptions made about the synchronization rules needed for the synchronization scenario. You can then decide on customized synchronization rules to handle this data. This kind of customization usually requires rules extensions to include error checking mechanisms, such as a value range test.
Examine the attribute values of the mandatory attributes that you have specified in worksheets or the system data flow design document, and note the ways in which each value can corrupt the data. This new information should be included in the system dataflow design document. Examples of the value considerations are:
processes that can set the value
requirement for the value to be set
support for null values
maximum value
minimum value
default value
allowed value range
necessity for legal values to match
support for duplicate values in the connected data source
support for duplicate values between data sources
Specify an action for MIIS 2003 to take in each instance of invalid data. For example, if objects in both the HR SQL data source and the Telephone data source have Boolean attributes for synchronization, you might plan an import attribute flow rule to cover the situation in which the two data sources interpret Boolean values in different ways. Specifically, one source might define True as 1 and False as 0, while the other source might define True as 0 and False as 1.
Plan your synchronization rules to handle any invalid data situations. You can plan error checking for any synchronization rule that might be susceptible to invalid data.
Repeat steps 2 through 3 for all mandatory attributes.
Step 3: Identify Synchronization Tasks
.gif "171eaa59-a595-4b12-8153-e2bb6cec3379")
The following scenarios are categorized by task for clarity. Synchronization rules work together to achieve an end-to-end dataflow, and the result of one rule affects the action of the other rules. Therefore, after you have planned all the rules, you should carefully analyze the overall synchronization to look for conflicts.
I want to bring user objects from my HR SQL database into the metadirectory so I can evaluate them before processing them
No synchronization rules are required to simply stage objects in the connector space. However, no attributes are imported if you don’t select any attribute flow mappings, and no filtering or object linking are configured. Create the management agent with the synchronization rules that you require, and create a stage-only run profile. Creating this management agent and run profile brings the selected objects into the connector space and stops the management agent before it runs any synchronization rules.
Check for invalid data. You can create a connector filter rule to check for valid or existing attribute values. For example, a connector filter rule can verify that each employeeStatus value equals Active, or a connector filter rules extension can be written to verify that the employeeID attribute is in a valid range.
Use the following sample tables as guides to completing the Connector Filter Rules worksheet in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about connector filter rules, see “Synchronization Rules Reference” earlier in this subject.
| Filter # (Precedence) | Attribute | Operator | Value |
|---|---|---|---|
1 |
employeeStatus |
Equals |
“Active” |
|
branchID |
Ends with |
“SEA” |
2 |
hireDate |
Contains |
2002 |
| Rules ext | Description |
|---|---|
Rules extension |
EmployeeID must be within the valid range of 999 - 9999 |
I have verified my staged objects and want to populate the metaverse
To create new objects in the metaverse, configure your projection rules to link the connector space object type to a specified metaverse object type.
Use the following example tables as guides to completing the Projection Rules worksheets in Design and Planning Worksheets for MIIS 2003. For more information about projection rules, see “Synchronization Rules Reference” earlier in this subject.
| Source object type | Metaverse object type or rules extension | Description of rules extension |
|---|---|---|
Person |
Person |
|
Person |
Rules ext |
If from Forest A, then map to contact object type. |
| Other rules ext | ||
|---|---|---|
Error handling |
Rules ext |
If projection fails, write error code to log. |
Because projection rules only create links between objects, configure your import attribute flow rules to actually synchronize attribute data between the linked objects.
One import attribute flow rule is required for each defined import attribute mapping for each management agent. MIIS 2003 applies import attribute flow rules when changes in the defined connector space objects occur. Your list of import attributes should be marked in the system dataflow design document.
Indicate the precedence for each attribute. The precedence should also be on the list of import attributes should be marked in the system dataflow design document.
Use the following example table as a guide to completing the "import attribute flow rules worksheet" in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about import attribute flow rules, see “Synchronization Rules Reference” earlier in this subject.
| CD attribute | Mapping type | Mapping type details | Destination object | Destination attribute | Precedence |
|---|---|---|---|---|---|
employeeID |
Direct |
N/A |
Person |
UID |
2 |
firstName, lastName |
Rules Extension |
Combine first and last names. The rule name is cd.person:firstname,lastname->mv.person:fullname |
Person |
fullName |
1 |
N/A |
Constant |
ABC Corp |
Person |
OU |
N/A |
DN |
Distinguished name |
Map only component 1 |
Person |
userName |
1 |
| Other rules extensions |
|---|
Error handling |
Projecting new objects to the metaverse is also a good time to analyze how you want to bring new objects into the metaverse. There are two approaches:
Strategy A – Filter objects during inbound synchronization. Bring all objects into the connector space, and use the connector filter rule to block objects that you don’t want to project to the metaverse. For this scenario, invalid data checks should be handled in a connector filter rules extension.
Strategy B – Filter objects during outbound synchronization. Project all objects to the metaverse, and use provisioning rules to determine if objects are to be created in other connector spaces. For this scenario, invalid data checks should be handled in the provisioning rules extension.
For more information about these strategies, see “Synchronization Rules Reference” earlier in this subject.
this subject.
Add Telephone values to the attributes of the existing metaverse objects
To flow data from the PhonePerson objects to the metaverse Person object, you must first configure your join rules to create a link between the objects.
MIIS 2003 evaluates join rules in order from first to last until a single match is found, or in the situation of a rules extension, multiple matches are found and possibly resolved by the rules extension. When setting the precedence of your join rules, set the precedence in the order that they are most likely to find a unique attribute match.
When you define your join criteria, use only attributes that have their indexed property set to Yes in the metaverse schema. You increase the efficiency of your searches by using only these attributes.
Indicate any scenarios that require a join resolution script.
Use the following sample table as a guide to completing the Join Rules worksheet in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about join rules, see “Synchronization Rules Reference” earlier in this subject.
| Rule # (Precedence) | Source attribute | Mapping type | Metaverse object type | Metaverse attribute | Resolution script | Resolution script description/location |
|---|---|---|---|---|---|---|
1 |
employeeID |
Direct |
Person |
employeeID |
Yes |
|
2 |
givenName |
Direct |
Person |
givenName |
No |
|
|
Sn |
Rules Extension |
Person |
Sn |
Yes |
|
| Rules ext | Description |
|---|---|
Rules extension for #2 |
Concatenate the sn and givenName if successful resolution found |
Create new users in a Microsoft® Active Directory™ directory service domain by using the metaverse user objects
To create objects in other connected data sources from metaverse objects, you need to configure provisioning rules. Creating the objects in the data source is actually a two-step process. Provisioning creates the objects in the target connector space, and then the management agent for that connector space is configured to export those objects to the related data source.
Indicate if initial passwords need to be set on new connector space objects.
For a homogeneous object synchronization scenario, determine if a master is connected to the metaverse object. If so, indicate if an object needs to be created. If not, indicate whether all objects have to be deprovisioned if there is no master.
Use the following sample table as a guide to completing the Provisioning Rules worksheet in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about provisioning rules, see “Synchronization Rules Reference” earlier in this subject.
| Scenario | Action |
|---|---|
Create a new connector space object |
If status = “active,” then create a new account Set Initial password to userName |
Move a connector space object |
If status = “disabled,” move object to HoldOU |
Delete a connector space object |
If status = “terminated,” disconnect from connector space, deprovision account |
Check for invalid data |
|
The provisioning process creates a new object in the target connector space. To flow data between the objects, you need to configure your export attribute flow rules.
Indicate if the allow nulls on export rule is to be applied. For more information about allowing nulls on export, see “Other Rules That Are Applied During Attribute Flow Control“ earlier in this subject.
One import attribute flow rule is required for each defined export attribute mapping for each management agent. MIIS 2003 applies export attribute flow rules when the defined connector space objects change. Your list of export attributes should be marked in the system dataflow design document.
Use the following sample table as a guide to completing the Export Attribute Flow Rules worksheet in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about export attribute flow rules, see “Synchronization Rules Reference” earlier in this subject.
| Metaverse attribute | Mapping type | Mapping type details | Destination object | Destination attribute | Allow nulls |
|---|---|---|---|---|---|
employeeID |
Direct |
N/A |
Person |
UID |
|
firstName, lastName |
Rules Ext |
Combine names |
Person |
fullName |
|
N/A |
Constant |
ABC Corp |
Person |
company |
|
| Rules ext | |
|---|---|
Rules extension for #2 |
|
Remove a connector space or metaverse object
You control removal of a metaverse or connector space object through the deprovisioning and object deletion rules. When a connector space object is disconnected from its linked metaverse object, deprovisioning rules determine what happens to the connector space object. The object deletion rules then determine what happens to the metaverse object.
Decide if connector space attributes should be recalled from the metaverse on disconnect. For more information about recalling attributes, see “Recall Attributes from Metaverse on Disconnect Rules” earlier in this subject.
The deprovisioning rule can stage an object deletion to a connected data source. However, the object is only removed from the connector space if and when the object deletion is confirmed by the connected data source.
Use the following sample table as a guide to completing the Deprovisioning Rules worksheet in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about deprovisioning rules, see “Synchronization Rules Reference” earlier in this subject.
| Management agent | Make a disconnector | Make an explicit disconnector | Stage the object for deletion | Rules extension/details | Enable attribute recall |
|---|---|---|---|---|---|
HR MA |
|
|
X |
|
Yes |
AD MA |
|
|
|
Set status = disabled, move object to HoldOU |
No |
For either a homogeneous or heterogeneous object synchronization scenario, plan the object deletion rule to use a rules extension. Because object deletion is based on object type, in these scenarios, determine the master source, and base your decision on that.
You can use a declarative object deletion rule for a single master object synchronization scenario.
Use the following sample table as a guide to completing the Object Deletion Rules worksheet in Design and Planning Worksheets for MIIS 2003 in this collection of the MIIS 2003 Technical Library. For more information about object deletion rules, see “Synchronization Rules Reference” earlier in this subject.
| Metaverse object type | Delete when last connector is disconnected (default) | Delete when connector from this MA is disconnected | Delete using rules extension | Details/description |
|---|---|---|---|---|
Person |
|
|
X |
If attribute department = Sales, then delete object |
Group |
|
AD MA |
|
|
| Other rules extensions | ||||
|---|---|---|---|---|
Error handling |
|
|
|
If object deletion fails… |
Summary
Synchronization rules enable you to determine how data is synchronized in MIIS 2003 by using the MIIS 2003 UI. To ensure that your MIIS 2003 solution is as efficient as possible, build your synchronization rules by using the following process:
Identify your synchronization scenario.
Determine a connector filter strategy.
Plan for projecting new metaverse objects, and determine how you want to bring new objects into the metaverse.
Plan joins of connector space objects to metaverse objects.
Plan for import attribute flow.
Plan for object deletion, provisioning, and deprovisioning.
Plan for export attribute flow.
Document all planning decisions in the synchronization rules specification.
After you incorporate your planning into the synchronization rules specification, you can include the specification as part of the system dataflow design document. The rules extension builder can use your synchronization rules specification to build the appropriate rules extensions.