Common Transformation Scenarios

Given the breadth of transformations available in UNIFYBroker, a number of different use cases may be accommodated for when it comes to data modelling. Different connected systems have different structures, and as a result may require variant forms of adaption for presentation for identity management.

Below are some common scenarios that can be addressed adequately through the use of transformations

Name Overrides

Some target systems may not contain suitable data for display in downstream systems. This can be true when HR systems contain abbreviated names for position titles or other information that would not be appropriate in public-facing systems.

A CSV, database, or alternate file may be created to contain the primary key and new name of the item. Using the primary key of the connector pointing to this data, configure a Join transformation to replace the name with the overridden name.

Manager Relationships

Several HR systems do not directly contain a user's manager reference. Internally, the application may infer who the manager is based on the position, but this is not presented to external systems. Using UNIFYBroker, this inferred relationship can be calculated.

Consider a HR system which contains three tables:

• Employees
• Positions
• Reports To

The Employees table may only contain information about employees, the Positions table only about the positions that employees currently hold, and the Reports To table containing relationships between one position to another (for example, Position B reports to Position A). The following combination of transformations can be used to get managerial information in a flattened format on a single employee object:

• Use the Employees table as the base of the adapter
• Use a Join transformation with a sliding date relationship on the user's employee ID to map between a user and their position in the Positions table. The date relationship will allow for a variety of selections, either their last held position, their current position, or their future position.
• Use a Join transformation using the position number against the Reports To table to check the position that the manager holds
• Use a Join transformation with a sliding date relationship against the Positions table to get the employee ID of the employee who currently holds that position
• Use a Join transformation against the Employees table to grab the employee details of the manager

Group Management

An increasingly important requirement for identity management, especially as it pertains to access management, is the management of groups. UNIFYBroker makes group management fairly straight forward.

• Ensure that two adapters are created - one containing the members, and one containing the high level group definitions. The second must contain the criteria required for members to fall into groups, whether it be based on position numbers, classes, subjects, schools or otherwise
• Use a Group transformation to generate the membership field against the Group adapter using the criteria that is relevant.

Transformation Combinations

When the complex manipulation of entity data is required which falls beyond the capability of a single transformation, a chain of transformations can be configured that results in the desired changes. When designing transformations in this situation it is important to keep in mind that each transformation operates on the entity state provided by prior transformations.

Take, for example, a scenario where a User entity contains the id of a OrgUnit to which it belongs and the desired end state is for the entity to contain a flattened OrgUnit hierarchy that also maintains the level at which each OrgUnit exists in. The OrgUnit hierarchy has a maximum, known height and the level at which an OrgUnits parent OrgUnit exists can be greater than one (ie OrgUnit A at level 2 can be the parent of OrgUnit B at level 4).  OrgUnit data is provided with an Id, name, level and parent OrgUnit id. To achieve this results with all requirements met the following solution could be implemented:

Join Transformation

JOIN ON
     OrgUnits
WHERE
    [orgId] == [orgId]
SELECT
     Priority
ON [level] ( 3 ) MAP                        // Exclude other values
    [orgId] -> [levelThreeOrgId]
    [orgName] -> [levelThreeOrgName]
    [parentId] -> [levelThreeParentId]

The lowest level (3, in this example) OrgUnit information is joined onto the base entity based on the value in orgId prioritising OrgUnits with a level of 3 and excluding all others. As the join condition is on a unique identifier this means if the matching OrgUnit is not of level 3, no change is made.

[Optional] Copy Transformation

[levelThreeParentId] -> [level2OrgIdTemp]

This copied field will be used by the following PowerShell transformation and will be assigned the correct organization id. This transformation is required to enable reflection when the organization connector context is updated, otherwise this field can be created by the PowerShell transformation itself. 

PowerShell Transformation

foreach ($entity in $entities)
{
    if (($entity['levelThreeParentId'] -ne $null) -and ($entity['levelThreeParentId'].Value -ne $null))
    {
        $entity['level2OrgIdTemp'] = $entity['levelThreeParentId'];
    }
    else 
    {
        $entity['level2OrgIdTemp'] = $entity['orgId'];
    }
}

Copies the id of the next OrgUnit in the hierarchy to the temp field. This is either the level 3 OrgUnits parent or, if no level 3 OrgUnit was set, the OrgUnit defined by base entity.

Join Transformation

JOIN ON
     OrgUnits
WHERE
    [level2OrgIdTemp] == [orgId]
SELECT
     Priority
ON [level] ( 2 ) MAP                        // Exclude other values
    [orgId] -> [levelTwoOrgId]
    [orgName] -> [levelTwoOrgName]
    [parentId] -> [levelTwoParentId]

As before, the level 2 OrgUnit information is joined onto the base entity based on the value in level2OrgIdTemp, prioritising OrgUnits with a level of 2 and excluding all others.

[Optional] Copy Transformation

[levelTwoParentId] -> [level1OrgIdTemp]

As above, but for the level 1 organization id.

PowerShell Transformation

foreach ($entity in $entities)
{
    if (($entity['levelTwoParentId'] -ne $null) -and ($entity['levelTwoParentId'].Value -ne $null))
    {
        $entity['level1OrgIdTemp'] = $entity['levelTwoParentId'];
    }
    elseif (($entity['levelThreeParentId'] -ne $null) -and ($entity['levelThreeParentId'].Value -ne $null))
    {
        $entity['level1OrgIdTemp'] = $entity['levelThreeParentId'];        
    }
    else 
    {
        $entity['level1OrgIdTemp'] = $entity['orgId'];
    }
}

Copies the id of the next OrgUnit in the hierarchy to the temp field. This time resulting value of level1OrgIdTemp will be either the level 2 parent id, level 3 parent id or the orgId defined on be base entity, depending on the success of the previous join transformations.

Join Transformation

JOIN ON
     OrgUnits
WHERE
    [level1OrgIdTemp] == [orgId]
SELECT
     Priority
ON [level] ( 1 ) MAP                        // Exclude other values
    [orgId] -> [levelOneOrgId]
    [orgName] -> [levelOneOrgName]
    [parentId] -> [levelOneParentId]

The final join transformation, joining where the level is 1.

With these transformations in place, each level of the OrgUnit hierarchy is populated correctly, but only where appropriate to do so.