Process Steps for Planning the Metaverse
Applies To: Windows Server 2003 with SP1
Previous Section in This Guide
This topic takes you through the process of transforming a logical metaverse design into a physical design. Before proceeding, be sure you understand the information provided in “Overview of Metaverse Planning” and “Metaverse Concepts.”
The process for planning the physical metaverse involves expanding on the documents produced in the earlier stages, and more importantly, modifying them to optimize the design (balancing storage, performance, and physical limitations) so that all the elements of the plan still meet the solution proposal. As a first step, copy the following documents so that you can modify them, preserving the original copies for reference:
Real-World Identity Objects
Connected Data Sources
Object-level Policies
Included Attributes
Outbound Attribute Flow
Metaverse Object Design
During this stage, you also produce additional worksheets:
Metadirectory Object Policies
Inbound Attribute Flow
Metaverse Attribute Design
As you change your design from a logical design to a physical one, be sure to update any diagrams that are affected.
At this stage, you are documenting a physical design for the metaverse; your changes can affect the requirements that are placed on the rules planner. Although you are not concerned with the details of how those rules are implemented, you must understand and clearly document the requirements. The output of the metaverse design specification that you are developing becomes the final input for the rules planner.
Typically, you will need more than one pass through the worksheets to complete your design — some iteration is required to refine the design.
Tasks outline for the Physical Design Process
Prepare for Metaverse Planning
Step 1: Collect your planning documents and worksheets. Copy the documents and worksheets that the project team produced in the earlier stages of the project so that you can modify them, preserving the original copies for reference.
Step 2: Review how to choose names for object types and attributes. Check that all names for object types and attributes meet the MIIS 2003 naming constraints; make changes as necessary.
Refine the dataflow design
Step 3: Establish object-level policies. Prepare a Metadirectory Object Policies worksheet for each of the metaverse object types that you logged on the set of Object-Level Policies worksheets. For each of the metaverse object types that you define and log, examine the corresponding Real-World Identity Objects and then consider the requirements for the these policy types: filter, join, project, provision, deprovisions, and delete.
Step 4: Establish all required outbound flow. For each metaverse object type, identify metaverse attributes to hold outbound flow data. Then fill in an Outbound Attribute Flow worksheet for each pairing of metaverse object type and connected data source object type that has any outbound flow.
Step 5: Establish metaverse attribute requirements. For outbound flow and joining, determine attribute requirements for each metaverse object type, adding this data to the Metaverse Object Design worksheets.
Step 6: Establish inbound flow.Determine the sources for each metaverse attribute by defining inbound flow: fill in an Inbound Attribute Flow worksheet for each pairing of metaverse object type and connected data source object type that has any outbound flow.
Review and refine your decisions
Step 7: Review all precedence policies. Determine whether you can simplify them by specifying different object types. For any new precedence policies, add to the existing worksheets and update all other worksheets that are affected by the additions.
Step 8: Review and adjust outbound transformations. For each outbound attribute flow policy that involves a transformation of data (include related inbound and outbound flows in your review), evaluate whether outbound data transformation is the optimal arrangement. Consider changing to one or more inbound attribute flow transformations (if possible).
Step 9: Review and adjust the attributes used for joining. Where possible, make the attributes an indexed type; consider whether any data types should be transformed to an indexable type, especially in the case of the first join condition. Use the Metaverse Object Design worksheet to determine whether an attribute will be used for a join.
Step 10: Consider storage limitations. Review for possible storage issues and take appropriate action.
Step 11: Complete the Metaverse Attribute Design worksheet. Determine the overall attribute requirement, which is an aggregation of what is required by each object type.
Step 12: Document the reasons for your changes to the logical design.
During these steps, you prepare a number of worksheets, initially adding some data, then returning to the worksheets many times, gradually refining the data in them.
Sample worksheets are provided that give detailed examples of how to use the Design and Planning Worksheets for MIIS 2003. Refer to these worksheets together with the detailed steps that follow.
Preparing for Metaverse Planning
Before you begin your metaverse planning, two preparatory steps are required:
Collect your planning documents and worksheets. Gather all the design and planning documents that you have started or completed up to now and make copies of them. Because the design and planning process is iterative, you will be updating these documents during the metaverse and synchronization rules planning.
Review how to choose names for object types and attributes. Be sure you know the naming requirements and understand the reasons behind choosing appropriate names for your metaverse objects and attributes.
With the knowledge gained by this preparation, you can better refine your dataflow design and implement your selected solution.
Step 1: Collect Your Planning Documents and Worksheets
Collect the worksheets and documents that you completed in earlier phases of this project, preparing to complete additional worksheets and to fine-tune the worksheets and documents that you completed earlier.
Table 1 outlines the prerequisite worksheets that the project team should begin or complete before you begin your metaverse plan. For more information about these prerequisite worksheets, see “Initiating Your Identity Integration Project” and “Designing a System Dataflow Model for MIIS 2003,” which are other topics in this technical library.
Table 1: Documents To Complete or Begin Before You Design Your Metaverse Plan
| Documents or Worksheets | Description |
|---|---|
For this deployment, obtain a copy of the solution proposal, which includes: |
|
Vision Statement and Solution Objectives worksheet |
Provides context and framework for designing and planning your MIIS 2003 deployment including the metaverse plan. |
Real-World Identity Objects worksheet |
Includes one object type for each real-world identity type in the logical dataflow design. |
When you designed your dataflow model, the dataflow design document and worksheets were your primary deliverables. Those worksheets defined the logical metadirectory design and the dataflow document provided the details and explanations that were needed to understand the design fully.
During the metaverse planning phase of the project, the metaverse planner will produce a physical design based on the logical metadirectory design and may modify or fine-tune the earlier worksheets based on the work done in this phase. Table 2 outlines the worksheets that you began during the logical metadirectory design phase and will continue to use and refine during this phase of planning.
Table 2: Documents You Began in Dataflow Design and Use for the Metaverse Plan
| Documents or Worksheets | Description |
|---|---|
A dataflow design document, which includes the following set of worksheets:1 |
|
Real-World Identity Objects worksheet |
Includes one object type for each real-world identity type in the logical dataflow design. |
Connected Data Sources worksheet |
Includes all relevant object types and how they correlate with the real-world identities (and hence, with the metadirectory object types). |
Object-Level Policies worksheet |
Defines how newly connected data source objects are to be created, what should happen as a result in the metadirectory and other connected data sources, and under what circumstances they might get removed. |
A set of Connected Data Sources worksheets and associated Included Attributes worksheets |
For each object in the connected source directory, lists all the relevant attributes of each connected data source object and their characteristics, including whether outbound flow is required. Using these worksheets, you can define the logical set of metaverse attributes for each object type. |
Outbound Attribute Flow worksheet |
For each connected data source that maps to a metaverse object, shows how each attribute is to be populated. |
Metaverse Object Design worksheet |
For each object type in the logical metaverse design, indicates the attributes you want to include, their connected data source, and any relevant precedence policies. |
1. The project team modifies the worksheets during the designing of the physical metaverse.
Table 3 outlines additional worksheets to complete during the physical phase of the design. The worksheets in Tables 8 and 9 become the core documentation in your metaverse design specification.
Table 3: Additional Worksheets to Work on During the Physical Design
| Worksheet | Description |
|---|---|
Metadirectory Object Policies worksheet |
For each real-world identity and associated metaverse object types, indicates the object policies (rule type and details). These policies are refinements of those found in the real-world identity worksheet. |
Inbound Attribute Flow worksheet |
For each object type in each connected data source, shows which metaverse attributes it may provide. |
Metaverse Attribute Design worksheet |
Is completed after all metaverse object types are fully defined. This new worksheet holds the details of all the metaverse attributes that are shared across all object types. |
After you complete your metaverse design specification, the rules designer completes and uses the combined worksheets and documents to generate a set of rules.
Step 2: Review How to Choose Names for Object Types and Attributes
A best practice is to choose names for the metaverse object types or attributes that reflect what the types or attributes represent, and the data they contain. When you choose names, remember these requirements:
Metaverse object type names
Unique to the metaverse and limited to a maximum of 128 characters. The characters a–z, A–Z, 0–9; the hyphen (-); and the underscore (_) are allowed.
Metaverse attribute names
Unique to the metaverse and limited to a maximum of 128 characters. However, because of SQL Server 2000 limitations, a best practice is to limit characters to 126. The characters a–z, A–Z, 0–9; the hyphen (-); and the underscore (_) are allowed.
In addition to following the preceding naming requirements, review these naming tips:
Use meaningful names. For example, if you store a user’s first name in a metaverse attribute called Field_15, other team members — and even you — cannot easily intuit or remember the type of data that is stored in that field.
Use consistent naming conventions. Object type and attribute names have few technical constraints, but a consistent naming convention helps the project team and those who maintain MIIS 2003. For example, you might base your naming convention on either of the following naming schemes:
The names that you used in the connected data sources.
The identity objects and attributes that they represent in the real world.
The latter option might be the better option because connected data source naming conventions vary.
For example, if company employees are represented in Active Directory as users, in SQL Server with no particular object type, and in Active Directory Application Mode (ADAM) as inetOrgPerson, you might use the default metaverse object type of person or create a new object type and name it employee.
Likewise, you can name each metaverse attribute. For example, if a common logon name is stored as the userPrincipalName attribute in both Active Directory and ADAM, create an attribute in the metaverse called userPrincipalName. Optionally, use the default uidattribute, or you might create an attribute called networkLogonIDbecause you have additional purposes for the attribute name and the created name is more descriptive of its real-world use.
Note
Whichever approach — or combination of approaches — you use, choose consistent and meaningful names so that other members of the deployment and operations teams can quickly understand and easily use your names.
Refining the Dataflow Design
The goal of the dataflow model is to define the data that is imported into the metadirectory and the data that is exported from the metadirectory. This data is for use by various connected data sources as required by your business rules. The dataflow model identifies the data sources, objects, and attributes that will provide the data going into the metadirectory as well as the data sources, objects, and attributes that will use or be defined by the data coming out of the metadirectory.
As you move from designing a logical dataflow model to the detailed planning phase of the physical metaverse plan, you continue to iterate through the worksheets, adding more and more detail each time.
The steps for refining your dataflow design are:
Establish object-level policies for each Metaverse object type. These policies affect filters, joins, projections, provisioning, deprovisioning, and deletions.
Establish outbound flows to connected data sources that you identified earlier in your design.
Establish metaverse attributes to make the link between the metaverse and the connector space for the outbound flow.
Establish inbound flow by determining attribute precedence for each metaverse attribute.
Step 3: Establish Object-Level Policies
Prepare a new Metadirectory Object Policies worksheet for each of the metaverse object types that you logged in the worksheets during the dataflow design phase. Use the set of Object-Level Policies worksheets in your solution proposal. Try to fully complete these worksheets — although you can return later to further refine them.
For each metaverse object type that you defined earlier, examine the corresponding Real-World Identity Objects worksheet, which contains a list of connected data source object types that relate to this metaverse object type. For each of these data source object types, examine the Object-Level Policies worksheet and consider the requirements for the following policy types, filling in the Metadirectory Object Policies worksheets as you go:
Filter
Join
Project
Provision
Deprovision
Deletion
During the process, also identify and record the policy for metaverse object deletion.
Filter Policy
Identify here any requirements for selecting a subset of data from the connected data source that you want to associate with the metaverse. The data subset can include references to partitions, contexts, domains, organizational units (OUs), containers, and attribute values.
In the connector space, MIIS 2003 uses a connector filter, which is a rule that prevents connector space objects from linking to metaverse objects. The connector filter examines objects and can prevent them from being represented in the metaverse.
Table 4 uses object-level policies from the Fabrikam scenario to demonstrate how policies are physically applied to an object.
Table 4: Fabrikam Scenario: How Policies Are Physically Applied to an Object
| Object-Level Policy | Metadirectory Object Policies |
|---|---|
Include in this solution, either of the following: Current, permanent employees. Employees who left on or after 1/1/2000. |
EmployeeType="Permanent"or LeftDate<"2000/01/01" 1 |
Import only your typical Active Directory users; that is, do not import special accounts, such as backup, service, and admin. |
dc=Fabrikam, dc=com, |
1. The metaverse and rules planners will decide whether these policies are to be implemented at the data source or as a disconnector filter.
Join Policy
Enter the policies for joining (if necessary), making it clear which metaverse attributes are required. Join policies are the most likely policies to have alternative requirements for the discovery and ongoing operational phases. Existing data must be joined through soft or manual joins, which in later stages, is unnecessary because of improved processes resulting in more reliable data.
You should also identify any needs for the ability to trace the origins of joined data.
Table 5 uses object-level policies from the Fabrikam scenario to demonstrate the join policy.
Table 5: Fabrikam Scenario: How a Join Policy Is Applied
| Object-Level Policy | Metadirectory Object Policies |
|---|---|
Join existing human resource records with Active Directory accounts. |
Attempt to match the FirstName, LastName, and DepartmentName from the connected data source to the givenName, sn, and department metaverse attributes. 1 |
Same as above |
Manually join the object polices that you cannot match perfectly. 1 Note: A log of join failures is required as a task list. |
Join existing human resource records with Active Directory accounts. Although these accounts are typically created automatically, if you decide to manually create them, you must join them by using the staff code. |
Attempt to match the FirstName, LastName, and DepartmentName from the connected data source to the*givenName, *sn, and *department metaverse attributes. 1 |
Same as above |
Manually join the object polices that you cannot match perfectly. 1 Note: A log of join failures is required as a task list. Note: You must set an operational attribute for the employeeID in case the data must be rebuilt. 2 |
Same as above |
Use employeeID for joining of any Active Directory User objects added externally. |
1. Only required during discovery
2. Use an operational attribute to provide a useful value for an object in a connected data source so that the object can be accessed or used when it is needed.
Project Policy
Enter policies for projecting. Note that in MIIS 2003, joining and projection policies are interlinked. Projection policies only apply if joining policies do not result in a join. Note that during discovery, join rules must be made to ensure that existing data is joined before any projection.
Table 6 uses object-level policies from the Fabrikam scenario to demonstrate the project policy.
Table 6: Fabrikam Scenario: How a Project Policy Is Applied
| Object-Level Policy | Metadirectory Object Policies |
|---|---|
Join existing human resource records with the Active Directory account. |
Do a manual projection on manual join failure. 1 |
Where joining fails or with all new records, create new metaverse objects. |
Do automatic projection on employeeID join failure. |
1. Only required during Discovery
Provision Policy
Enter the metadirectory object policies for provisioning new accounts. Note that provisioning is usually disabled until all existing objects are joined.
Table 7 uses object-level policies from the Fabrikam scenario to demonstrate the provision policy.
Table 7: Fabrikam Scenario: How a Provision Policy Is Applied
| Object-Level Policy | Metadirectory Object Policies |
|---|---|
Each new employee (subject to the filter requirement) causes the creation of Active Directory and Notes accounts. For example: Each new employee (subject to the filter requirement of permanent employees who are current, or left since 1/1/2000, or are summer-students) causes the creation of Active Directory and Notes accounts as follows:
|
New Active Directory User object created when new human resource employee object is imported that satisfies either of the following:
See also the filter policy. |
Deprovision Policy
Enter the metaverse object policies for deprovisioning new accounts, that is, for handling orphans created by deleting a metaverse object.
Table 8 uses object-level policies from the Fabrikam scenario to demonstrate the deprovision policy.
Table 8: Fabrikam Scenario: How a Deprovision Policy Is Applied
| Object-Level Policy | Metadirectory Object Policies |
|---|---|
If staff status changes to Terminated, apply the following policies:
|
Assuming you are using Active Directory, if employeeStatus changes to “Terminated,” apply the following policies 1:
|
After 90 days, all associated accounts are deleted unless the status changes from Terminated. |
Delete all accounts that are inactive for 90 days. 2 |
1. There will be logic to re-enable the Active Directory account should the status revert. There will also be policies for other object types resulting from this object-level policy. For simplicity these are not shown here).
2. Can be an external process.
Deletion Policy
Enter the (single) metaverse object deletion policy for this object type. Table 9 uses object-level policies from the Fabrikam scenario to demonstrate the object deletion policy.
Table 9: Fabrikam Scenario: How a Deletion Policy Is Applied
| Object-Level Policy | Metadirectory Object Policies |
|---|---|
If the staff status changes to Terminated, apply the following policies:
After 90 days, all associated accounts are deleted unless the status changes from Terminated. |
Objects are deleted from the metaverse 90 days after employeeStatus changes to “Terminated.” |
Step 4: Establish Outbound Flow
The Included Attributes worksheet for each connected data source object type contains a list of attributes, some of which are marked as outbound. For each connected data source, use data from the Included Attributes worksheet to populate four of the columns (Name, Validation, Validation Failure Action and May Be Overwritten with Null) in your Outbound Attribute Flow worksheet.
When you complete the Outbound Attribute Flow worksheet, it will contain a list of attributes with associated values in order for MIIS 2003 to correctly create or populate an object in the connected data source, that is, to meet the business objectives that you documented in the “Initiate Your Identity Integration Project”topic.
When creating this worksheet, include details from the Name, Requires validation, and May be overwritten with null attribute columns, which you can find on the Included Attributes worksheet. Also include Validation Failure Action details, which are included in the Inbound Attribute Flow worksheet.
Be sure to include any additional validation requirements that you notice. The metaverse and rules planners will add more validation requirements, such as testing for null values, during the detailed MIIS 2003 implementation.
Table 10 describes the information you need to gather to complete the Outbound Attribute Flow worksheet. For each connected data source that you are considering for your scenario, fill out one worksheet for each metaverse object. Note that in this step, you only complete the attribute information for each connected data source. In the next step, establish metaverse attributes, you complete the remaining columns of this worksheet.
Table 10: Outbound Attribute Flow Worksheet: Connected Data Source Attributes
| Connected Data Source Attribute Information | Explanation for Completing the Worksheet |
|---|---|
Name |
Names the outbound attributes for a connected data source in your solution. An example is FirstName. |
Validation |
Details the outbound validation policy that is applied to the named attribute. An example is “First name must be title caps.” |
Validation failure action |
Specifies what policy to apply if the attribute fails the validation test. An example is “Force title caps via value transformation.” |
Transformation |
Specifies the transformation policy that converts the content of the metaverse attributes to the connected data source attribute. For a constant value flow, place the constant here. An example is “new constant value.” |
May be overwritten with null Y/N |
Specifies whether a null value is allowed to replace the attribute value for the connected data source. Enter “Yes” if a null value is allowed. Otherwise, leave blank or enter “No.” |
Step 5: Establish Metaverse Attributes
For each attribute on each of your completed Outbound Attribute Flow worksheets, add attributes to the Metaverse Object Design worksheet (left side only — metaverse attribute columns) from which you can derive the value of the connector space object, and on the right side of the Outbound Attribute Flow worksheet.
You do not need an additional metaverse attribute for outbound flow if any of the following apply:
The attribute’s value can be provided by using a constant during outbound flow.
The attribute’s value is only populated during provisioning by using either a constant value or a non-metaverse data source (for example, from an XML file).
The attribute’s value can be derived from existing metaverse attributes.
In all other cases, you need to add a new attribute to the metaverse design unless a suitable one or combination already exists.
Some outbound attributes are readily identified as being composed of multiple real-world parts. For example, an employeeID might consist of a country/region code and a number: UK-1234567. When considering what metaverse attributes should be used to provide the outbound attributes of this type, you should break the problem down and use these sub-components, combining them with an export flow rule extension. There are two reasons for this:
The individual real-world components may not all come from the same management agent object, and hence they will never exist as a single metaverse attribute.
If other outbound attributes need to use the individual real-world parts, you do not have to add their required attributes to the metaverse design because they already exist.
In the preceding employeeID example, a telephone connected data source might flow the country/region code out to a telephone system.
You must also add any metaverse attributes that you need for joining the connected data source objects to their equivalent metaverse objects.
When You Need a Metaverse Attribute for Export Flow
For each attribute (or subcomponent, if you have decomposed the attribute) in the Outbound Attribute Flow worksheet, compare its content structure with that of the content structure of attributes already included in the Metaverse Object Design worksheet. If the content structure and data type is an exact match, document the metaverse attribute detail in the Outbound Attribute Flow worksheet and move to the next attribute (or subcomponent).
If you cannot find an exact match, consider whether you can transform an existing metaverse attribute to get the result you need. If you can, add the metaverse attribute and transformation rule to the Outbound Attribute Flow worksheet. For example, if the content structure for a LastName attribute required it to contain the last name of a person with all letters in upper case, you might use a metaverse attribute called personLastName with a “make upper case” transformation rule.
If you cannot perform a transformation to achieve a suitable match, is there a combination of metaverse attributes that you can use to provide the required value? If so, add the attributes and transformation rule to the Outbound Attribute Flow worksheet.
It may be that only part of the connected data source attribute’s value could be provided, or none at all — in which case you add the missing components or attribute to the Metaverse Object Design worksheet and then add the metaverse attributes and any transformation rule to the Outbound Attribute Flow worksheet. For example, you need an outbound attribute called InternationalWorkNumber that must contain the international dialing code for an employee’s desk phone plus their local number. Inspecting the Metaverse Object Design worksheet you can find the local number but not the international dialing code. You should add the missing nation-state attribute to the Metaverse Object Design worksheet and enter the attributes and transformation rule to the Outbound Attribute Flow worksheet.
You then move to the next outbound attribute (or subcomponent) and repeat this process.
When You Need a Metaverse Attribute for Joining
After you complete the analysis of all export attributes for this connected data source object, add any metaverse attributes that are needed for joining the connected data source objects to their equivalent metaverse objects.
You will already have documented your join policies in the Metadirectory Object Policies worksheets. You must now decide what attributes will be required, and you can then complete your join policies.
The process for designating that a metaverse attribute is used for the purpose of a join policy is similar to that described above for export flow; however, you need to perform the following additional steps:
Record whether you intend to use a metaverse attribute for the purpose of a join by entering Yes in the appropriate cell of the Joined column on the Metaverse Object Design worksheet.
Update the join policy in the Metadirectory Object Policies worksheet to use the metaverse attributes that you defined.
Important
For performance reasons and whenever possible, make joins to indexed data types. Although MIIS 2003 joins to non-indexed data types (for example, number or Boolean), it does not join non-indexable data types where an indexable version of that data type exists (for example, string or binary). Therefore, always use an indexable data type — if one is available and if there is any chance that you may need it for a future join.
Table 11 describes the information you need to gather to complete this step.
Table 11 Outbound Attribute Flow Worksheet: Metaverse Attributes
| Metaverse Attribute Information | Explanation for Completing the Worksheet |
|---|---|
Name |
Names the metaverse attributes from which the attributes flow. For outbound flows that require no metaverse attributes (for example, a constant value), leave this column blank. An example in our scenario is displayName. |
Considerations or policies needed |
Lists any notes or policies for this attribute flow. An example is “Only flow to the metaverse attribute if it is currently empty or if this management agent provided the last value.” |
Step 6: Establish Inbound Flow
This step requires two parts:
Identify which inbound attributes are required and then fill in the worksheets.
Determine attribute precedence for each metaverse attribute that has more than one inbound flow.
Identifying Inbound Attribute Requirements
For each metaverse attribute defined in the previous steps, identify the associated inbound connected data source attributes; then add them to the Inbound Attribute Flow worksheets and update the right side of the Metaverse Object Design worksheet. To facilitate precedence considerations, complete the connected data source and object details for the inbound attributes.
For each attribute on the Metaverse Object Design worksheet, make a list of inbound attributes that will provide the value of the metaverse attribute (you can find these on the appropriate Included Attributes worksheet). You create one Inbound Attribute Flow worksheet for each connected data source object.
For each of these inbound attributes, if the objects attribute of the connected data source is identical to the metaverse attribute in both data type and content, record this match as a direct import flow in the Inbound Attribute Flow worksheet. Then copy their attribute policies from the Included Attributes worksheet to the Inbound Attribute Flow worksheet.
If you do not find any direct mapping, determine if you can derive the metaverse attribute by using a transformation from one or more attributes. If you can, add these attributes and the transformation details to the Inbound Attribute Flow worksheet.
If no source for the metaverse attribute can be determined, then investigate other data sources for inclusion in the solution.
Note
You should always find a source for the metaverse attribute if you followed all the steps detailed in this topic and in “Designing Your System Dataflow for MIIS 2003,” that is, if you checked whether each export had at least one candidate import.
Determining Inbound Precedence
Determining attribute precedence is a critical step in the design of the metaverse. For each metaverse attribute that has more than one inbound flow — potentially supplying it with a value, you must determine the precedence that will apply. In some cases, you might have already done part of this research and recorded the findings as policies in the Included Attributes worksheet. However, because this is the earliest instance when you will have a complete list of the candidates for inbound attributes, it is unlikely that the previous research is complete.
You determine the final attribute precedence through discussion with the other members of the project team and the owners of the connected data source objects. As you determine the complete precedence policy for each metaverse attribute, add the details to the Metaverse Object Design worksheet.
Note
The precedence rules in the Metaverse Object Design worksheet are expressed in terms of what condition will stop the management agent (MA) from flowing an attribute value into the metaverse attribute. For example, a precedence rule for a Telephone MA that reads “When last supplied by Fabrikam Active Directory MA” would stop the Telephone MA flowing a value into the metaverse attribute when the current value for the attribute has been supplied by the Fabrikam Active Directory MA.
Table 12 describes the information you need to collect and record in order to identify inbound attribute requirements.
Table 12: Inbound Attribute Flow Worksheet: Connected Data Source and Metaverse Attributes
| Attribute Information | Explanation for Completing the Worksheet |
|---|---|
Name |
Names the Connected data source attribute. An example is FirstName, LastName. |
Validation |
Details the inbound validation policy that is applied to this attribute. At this stage, you have not decided if this validation rule will be applied with an MIIS 2003 synchronization rule or in the connected data sources. |
Validation failure action |
Specifies what policy to apply if the attribute fails the validation test. |
Transformation |
Specifies the transformation policy that converts the content of the connected data source attributes to the metaverse attribute. For constant or distinguished name subcomponent flows, place the value here and leave the metaverse entry blank. |
Manual precedence Y/N |
Specifies whether a manual precedence is required for this inbound attribute flow. If manual precedence is required, enter Yes and note any considerations or required policies. Otherwise, leave blank or enter No. |
Name |
Names the metaverse attributes to which the connected data source attributes flow. |
Notes |
Lists any notes or policies for this attribute flow. |
Reviewing and Refining Your Decisions
After you have refined your dataflow design by establishing the object-level policies for each object, establishing the outbound flows to the connected data sources, establishing metaverse attributes, and establishing the inbound flows from your connected data sources, your design process enters a review and refine phase. This phase includes:
Review all precedence policies for conflicts in precedence. Try to reduce rules complexity and simplify precedence.
Review and adjust all outbound transformations, evaluating whether outbound data transformation is the optimal arrangement.
Review and adjust the join attributes.
Consider storage limits.
Complete the Metaverse Attribute Design worksheet to determine the overall attribute requirement.
Step 7: Review All Precedence Policies
You should review each precedence policy to see if it falls into the “object collision” category. Object collision results from a conflict in precedence requirements. It can occur when an object from one connected data source has the potential of overwriting the metaverse object that was populated from a different data source.
For example, you might create duplicate objects for a highly symmetrical bidirectional synchronization scenario, such as synchronizing global address lists between two Active Directory forests, forest A and forest B. The logical design required that you use a single metaverse object type for contacts. For contacts originating in forest A, the precedence rule favors forest A; and for contacts originating in forest B, the precedence rule favors forest B. Hence, for different object instances of the same object type, you have conflicting precedence requirements, which suggests you have complicated rules extensions.
For ease of implementation, you might duplicate some of the object types. For example, you might create two object types (perhaps contactA and contactB) that allow you to apply simple precedence rules in favor of forest A for contactA and forest B for contactB. Do not hesitate to construct this kind of solution if you can reduce rules complexity as a result.
Where you decide to specify an additional object type, copy the existing object type that requires splitting up. Using this method, you can copy its associated worksheets for each new object type:
Metaverse Object Design
Metadirectory Object Policies
Outbound Attribute Flow
Inbound Attribute Flow
Both your new and existing worksheets need minor modification to show how you simplified the precedence policies.
Be sure to discuss your ideas with the project team because another team member, especially the rules designer, might offer valuable advice and insight.
Step 8: Review and Adjust Outbound Transformations
Your dataflow designer has provided you with a logical dataflow design that could be placed anywhere on a spectrum of design extremes:
Many complex import flow rules that create many attributes with the same base data in different forms, and for export flow, that require fewer, simpler flow rules to connected data sources.
Fewer and simpler import flow rules, generating few attributes that contain raw data and that require many complex export flow rules to correctly populate connected data sources.
The optimal design is probably somewhere between these two extremes: storage overhead versus the number and complexity of transformations. To find your optimal design, consider the following:
Processing overhead. Carefully consider how often each rule is likely to run while you also assess the complexity of the flow rules. Your optimal solution will likely be somewhere between the two extremes.
Storage limits. Estimate whether you are likely to reach (or come close to reaching) disk storage limits. If you might have storage issues, make your design more like the latter of the above extremes: your design should prefer simpler import flow rules and more complex export flow rules. Also consider data transformations, which are discussed earlier in “Attribute Flow Rules.”
Rule development complexity. Evaluate rule complexity with the rules planners. Typically, you do this once; however, you might need to offer ongoing support. If you have no issues with potential storage limits and you determine that your processing capabilities are sufficient, consider whether you can exchange complex rules with simpler rules or whether you can store more metaverse attributes.
Note
If your design will not be analyzed and reworked by rules planners before the operations team implements it, consider making simpler rules.
The logical design usually has fewer, simpler import flow rules, and many complex export flow rules. Review each outbound flow transformation in order, considering related import and export rules, and determining whether the current design is the optimal arrangement. You might change to an inbound flow transformation; however, changing from export flows to import flows is not always physically possible.
When reviewing your flow rules, remember the following characteristics of export flow rules:
All metaverse attributes that are inputs to the connector space object must come from a single metaverse object.
You cannot use an attribute of type Reference (DN) with rules extensions.
Each flow rule can only provide a value for a single connected data source attribute.
Also consider these characteristics of import attribute flow rules:
All the connected data source attributes that are inputs for a specific rule must come from a single connected data source object.
You cannot use an attribute of the type Reference (DN) with a rules extension.
Each flow rule can only provide a value for a single metaverse attribute.
Comparing the Logic of Import and Export Flow Rules
If you consider the minimal constraints for import (import staging) and export attribute flow rules extensions, you can always convert an import attribute flow rule to an export attribute flow rule by creating additional metaverse attributes; however, the reverse is not always possible. The logic is different because the set of metaverse attributes that are used by an export attribute flow rule might be flowed into the metaverse from different connected data source objects; however, the import attribute flow rule can only use attributes from a single connected data source object. A best practice is to give careful attention to this constraint when you attempt to optimize the logical design in order to reduce unnecessary processor use.
Developing Improved Rules Processing
Seek ways to improve the transformation rules that are detailed in the inbound and outbound worksheets. To illustrate, Tables 13 and 14 summarize information relating to certain attributes on the sample Inbound Attribute Flow and Outbound Attribute Flow worksheets.
Table 13: Scenario Data from Sample Inbound Attribute Flow Worksheet
| Inbound Attribute | Transformation | Metaverse Person Attribute |
|---|---|---|
Ma2.obj1.employeeID |
First two characters |
Employeecountry_region Code |
Ma2.obj1.employeeID |
Last seven characters |
EmployeeCode |
Ma1.obj1.DOB |
Last four digits |
DOB_Year |
Ma1.obj1.DOB |
|
DateOfBirth |
Ma3.obj1.DeptTelNo |
|
DepartmentTelephoneNo |
Ma2.obj1.EmployeeExtension |
|
EmployeeExtension |
Ma1.obj1.sn |
|
Sn |
Ma1.obj1.givenName |
|
givenName |
In the Table 19, the inbound table, two different rules extensions are specified for the Ma2.obj1 inbound attribute. These rules transform the employeeID attribute into either the first two-characters or the last seven characters, flowing the value of each to a Employeecountry_regionCode attribute or an EmployeeCode attribute, respectively.
In Table 14, the outbound table, these two metaverse attributes are used by three different rules extensions for export attribute flow and each transformation produces a string that is identical to the employeeID attribute value that originated from Ma2.obj1. If this were your scenario, you could improve efficiency by flowing the value of the employeeID attribute from Ma2.obj1 directly into the metaverse from where it would flow directly to the three management agent object attributes. Therefore, you would change the logical design to reflect the improved rules processing.
Table 14: Data from Sample Outbound Attribute Flow Worksheet
| Metaverse Person Attributes | Transformation | Outbound Attribute |
|---|---|---|
EmployeeCountry_RegionCode |
EmployeeCountry_RegionCode + |
Ma4.obj1.employeeID |
EmployeeCountry_RegionCode |
EmployeeCountry_RegionCode + |
Ma5.obj1.StaffCode |
EmployeeCountry_RegionCode |
EmployeeCountry_RegionCode + |
Ma4.obj1.AccociateNo |
DOB_Year |
|
Ma4.obj1.YearOfBirth |
DateOfBirth |
|
Ma5.obj1.DOB |
DepartmentTelephoneNo |
DepartmentTelephoneNo + |
Ma4.obj1.EmployeeTelNo |
DepartmentTelephoneNo |
DepartmentTelephoneNo + |
Ma5.obj1.TelNumb |
DepartmentTelephoneNo |
DepartmentTelephoneNo + |
Ma6.obj1.OfficeNumber |
Sn |
Sn + <space> + givenName |
Ma2.obj1.displayName |
Sn |
Sn + <space> + givenName |
Ma3.obj1.FullName |
Sn |
Sn + <space> + givenName |
Ma4.obj1.Name |
Transforming More Complex Scenarios
Other transformation issues might be more complex, but the same logic applies. In the scenario example, if the EmployeeRegionCode attribute were also mapped to a connector space object for another management agent, the following solutions are possible:
No change to the design.
Flow the employeeID attribute into the metaverse and out again and do either of the following:
Write an export attribute flow rules extension for the EmployeeCountry_RegionCode attribute.
Add an import attribute flow rules extension to flow the EmployeeCountry_RegionCode attribute into a suitable metaverse attribute.
From the perspective of the connected data sources, these changes are indistinguishable; however, they improve the efficiency of the solution by reducing the development effort or the size of the metaverse.
To generate the DOB_Year metaverse attribute, the DOB attribute is transformed and flowed into the metaverse. However, the DOB attribute also flows directly into the metaverse to generate the DateOfBirth metaverse attribute. DOB_Year is only exported once; so you might instead store the date of birth (DOB) in the metaverse, saving the development time of the import attribute flow rule and use an export attribute flow rule to generate DOB_Yearso that import attribute flow rule saving is negated. If all other elements remain the same, this change is probably unnecessary; however, it might be forced upon you if the number of metaverse attributes causes the design to exceed the maximum SQL Server 2000 row length. However, if multiple connector space sources could provide a date-of-birth figure, then this solution would become more pressing because you would have to define more complex precedence rules to manage the metaverse import flow.
In the outbound worksheet, you notice that an employee’s full name is created three times by using the same export attribute flow rule. The components of the full name (sn and givenName) are not used anywhere else, so you can improve the solution by creating a new metaverse attribute, such as displayName, and populating it by using an import attribute flow rule.
You cannot apply the same type of modification for the export transformation of the employee’s full telephone number (DepartmentTelephoneNo + EmployeeExtension) even though it is performed three times and appears to be better implemented as a single import attribute flow rule. This is because the components of the employee’s full telephone number are derived from different connector space objects; hence, you cannot improve the efficiency of the solution.
Finally, note that the optimal design for processing depends not only on the number of rules you use and their complexity, but also on how often they are run, which depends on the number of objects in each connected data source. If there are 100,000 objects in one source, and 10,000 in another, then transferring a processing overhead from one to the other may have to give a ten-fold benefit to be worthwhile (or may be very worthwhile even though the rule thus created is more complex than that saved).
Step 10: Consider Storage Limits
Check whether your database table is likely to reach or exceed the maximum row length for SQL Server 2000 or for any other storage limitations. Try these suggestions to reduce row length and overall storage requirements:
Understand transformation implications on performance and storage limits. Review “Attribute Flow Rules” earlier in this topic for more information about inbound (and outbound) transformations because some solutions involve more metaverse attributes than others.
Consider whether data transformations will help. Review “Attribute Properties” earlier in this topic for more information about attribute data types. .
Reuse attributes.
This final suggestion needs some explanation. The metaverse is primarily implemented as a single table in SQL Server — although other tables are involved, for example, to support multivalued attributes. Each row in the table represents an object; each attribute is represented by a column; and the table is logically partitioned into object types by using another single column.
For most designs, many of the table cells are empty because they are null (in mathematical terms, the metaverse is a sparse array). For example, a person object type might use the majority of the attributes that you define for the metaverse and these attributes are all populated with a non-null value. A group object type, however, might use only a small subset of the available attributes. Hence, person object rows in the metaverse contain values for most of the columns although locality object rows have many null values.
Table 15 is a sample metaverse table that represents a few objects, object types, and attributes.
Table 15: Metaverse Objects, Object Types, and Attributes
| Object Type | Sn | givenName | Location | ContactTel | member | WorkTel |
|---|---|---|---|---|---|---|
Person |
Baker |
Mary |
|
23465 |
|
|
Person |
Hesse |
Stefan |
|
88867 |
|
|
Group |
|
|
|
|
Mary Baker, Stefan Hesse |
|
Computer |
|
|
Office 007 |
|
|
|
Contact |
Ralls |
Kim |
|
|
|
23423 |
When you are designing the physical metaverse, you can use a similar table as a tool to evaluate where you might reuse an attribute. For example, if you need to eliminate one attribute in Table 12 because you are close to the row length limit in SQL Server, you might merge ContactTel and WorkTel into a single attribute because you can see that no object needs them both.
Consider reusing attributes to obtain the following benefits:
Reduced SQL Server 2000 row length.
Reduced overall storage requirements.
Performance improvement by merging two attributes that are indexed, resulting in one indexed column.
Because reusing an attribute means that one or both of the attribute names might not clearly represent the real-world value that was identified in the metadirectory design phase, only reuse attributes when you have no other option.
If you do merge attributes in this way, be sure to update all affected worksheets. In particular, update the following worksheets: Metaverse Attribute Design, Metaverse Object Design, Inbound Attribute Flow, and the Outbound Attribute Flow if the metaverse attribute flows to a connected data source.
Step 11: Complete the Metaverse Attribute Design worksheet
The Metaverse Attribute Design worksheet outlines the overall requirement for attributes, which is an aggregation of those required by each object type. Simply enter into this worksheet your final decisions for every attribute required (by all objects) along with their properties. You complete this worksheet by iteratively recording the results of your investigations. When it is completed, you will have done the following:
Identified and named all the metaverse attributes in your design.
For each metaverse attribute, identified the data type, which can be one of the following: binary, Boolean, string, number, or reference.
Decided whether to make each attribute indexable.
Decided whether to make each attribute multivalued.
Identified if an attribute that is indexable has been indexed.
Step 12: Document the Reasons for Your Changes
Finally review all documentation, adding notes to help explain your decisions. Your decisions and how you arrived at them will have the greatest impact on the synchronization rules planner, the rules extension builder, and consequently the day-to-day operations of MIIS 2003.
Summary
When you complete the process steps in this document, you will have added to and updated the worksheets started in the system dataflow design. As you planned your Metaverse, you chose names for the metaverse object types and attributes, reviewed all precedence policies stated earlier by the dataflow designer, reviewed and adjusted any outbound attribute transformations, reviewed and adjusted any join attributes, and analyzed your plan with regards to data storage issues for your particular environment.
You now have a substantial collection of information for your intended deployment:
The solution proposal, which includes a project charter, a vision, infrastructure analysis, and a list of candidate solutions.
A system dataflow design document, which includes many worksheets, some of which were refined during the current phase of the project.
A metaverse design specification, which includes additional worksheets as well as refinements to earlier worksheets.
Next, pass the documents and worksheets on to the rules designer and other members of the team.