{"id":2572,"date":"2013-03-23T02:31:14","date_gmt":"2013-03-23T02:31:14","guid":{"rendered":"https:\/\/www.wapshere.com\/missmiis\/?p=2572"},"modified":"2013-03-23T02:31:14","modified_gmt":"2013-03-23T02:31:14","slug":"some-housekeeping-xpath-queries","status":"publish","type":"post","link":"https:\/\/www.wapshere.com\/missmiis\/some-housekeeping-xpath-queries","title":{"rendered":"Some Housekeeping XPath Queries"},"content":{"rendered":"

I’ve been thinking a lot lately about maintaining data quality in the FIM Portal. When you’re working with a lot of referenced objects (and it really is the best way to go in the Portal) you find yourself copying string data around a lot. So, for example, a person selects a business unit object<\/em> from an Identity Picker, but I also want to copy the business unit name<\/em> to their Department field, for sync’ing to AD and other such purposes. How do we protect ourselves from unexpected failures in these processes, leading to inconsistencies in the data we’re trying to maintain?<\/p>\n

<\/p>\n

As is often the case, my colleague Bob was well ahead of me on this one<\/a> and\u00c2\u00a0has given me some good advice about targeting my queries so I find just the data inconsistencies, without unnecessarily re-running workflows against the majority\u00c2\u00a0of objects which are actually fine.<\/p>\n

There are a few things I’ve learnt while developing my housekeeping queries.<\/p>\n

You can’t generalise for different values<\/h3>\n

Starting with the example above where I copy\u00c2\u00a0the name of the linked business unit object to the department field, there is no query that says “show me all people who’s Department does not equal Unit\/DisplayName”. However we can do this:<\/p>\n

\/Person[Unit='c1391740-4e40-46b9-9d18-9ae39659f153' and not(Department='Accounts')]<\/pre>\n
the GUID there belonging to the “Accounts” business unit object which is linked to the person’s “Unit” attribute.<\/p>\n
So essentially we need a query for each case. We start by exporting all the business unit objects:<\/p>\n
$Units= Export-FIMConfig -OnlyBaseResources -CustomConfig \"\/Unit\"<\/pre>\n
and then loop through them, adjusting the filter for each unit object, and fixing any errors we find:<\/p>\n
foreach ($Unit in $Units)\r\n{\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0$ObjID = ($Unit.ResourceManagementObject.ObjectIdentifier).replace(\"urn:uuid:\",\"\")\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0$ObjName= ($Unit.ResourceManagementObject.ResourceManagementAttributes | where {$_.AttributeName -eq \"DisplayName\").Value\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0$Filter = \"\/Person[Unit='{0}' and not(Department=\"\"{1}\"\")]\" -f $ObjID,$ObjName\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0$ErrorObjs = Export-FIMConfig -OnlyBaseResources -CustomConfig $Filter\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0if ($ErrorObjs)\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0{\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 foreach ($obj in $ErrorObjs)\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 {\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 $ImportObject = ModifyImportObject -TargetIdentifier $obj.ResourceManagementObject.ObjectIdentifier -ObjectType \"Person\"\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 SetSingleValue -ImportObject $ImportObject -AttributeName \"Department\" -NewAttributeValue $ObjName\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 $ImportObject | Import-FIMConfig\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 }\r\n\u00c2\u00a0\u00c2\u00a0\u00c2\u00a0 }\r\n}<\/pre>\n
Note: the doubled double quotes around {1} are to account for names which may have a single quote character in them.<\/p><\/blockquote>\n
Multivalued Attributes<\/h3>\n
You may also need to check multivalued string attributes have the right values. Here again I found it more efficient to focus on the individual possible values rather than checking through a person’s whole list. But now I need two filters – one that shows missing values that should be added, and one that shows extra values that should be removed.<\/p>\n
In this example I have a multivalued reference field called “Applications” which links to another object type. I also copy the names of the application objects to the multivalued string attribute “ApplicationNames”, as strings are easier to use in the Sync Service. I want to check that everyone with a particular linked application also has the application name, and that no one has the application name without also having a link to the application object.<\/p>\n
$AddStringFilter = \"\/Person[Applications='{0}' and not(ApplicationNames=\"\"{1}\"\")]\" -f $ObjID,$ObjName\r\n$RemoveStringFilter = \"\/Person[not(Applications='{0}') and ApplicationNames=\"\"{1}\"\"]\" -f $ObjID,$ObjName<\/pre>\n
Comparison with a third object type<\/h3>\n
In the design I’m working on, people get applications and other services via “entitlement” objects. Once the entitlement is in an active state, a role object is directly linked to the person. So I need to be checking that people’s linked roles match their active entitlements, and also that they don’t have any linked roles where an active entitlement does not exist.<\/p>\n
$AddRoleFilter = \"\/Person[ (ObjectID = \/Entitlement[Status = 'Active' and RoleLink = '{0}']\/PersonLink) and not (Applications = '{0}') ]\" -f $ObjID\r\n$RemoveRoleFilter = \"\/Person[ (Applications = '{0}') and not(ObjectID = \/Entitlement[Status = 'Active' and RoleLink = '{0}']\/PersonLink) ]\" -f $ObjID<\/pre>\n
Comparison with a Set<\/h3>\n
The final query uses a set membership. Perhaps you have a TransitionIn Set MPR that triggers a workflow, and you want to periodically check that everyone in the Set does indeed have whatever that MPR should have given them.<\/p>\n
You could<\/em> set the associated workflow to “Run on Policy Update” and periodically disable\/enable the MPR, however for a large set this can have a catastrophic impact on Portal performance, tying up FIM Service resources until every single member of the set has been processed, and you can’t stop those jobs once they start<\/span>.<\/p>\n
So again we’re better off targeting queries to look for discrepancies, and again we’ll have to be specific – looking at individual sets and specific expected values. In this example filter I expect all members of the specified set to have an entitlement with a particular linked role:<\/p>\n
$Filter = \"\/Person[ (ObjectID = \/Set[ObjectID = '{0}']\/ComputedMember) and not(ObjectID = \/Entitlement[RoleLink = '{1}']\/PersonLink)]\" -f $SetID,$RoleID<\/pre>\n
Summary<\/h3>\n
Data quality is everything in identity management. The Sync Service\u00c2\u00a0is great at enforcing\u00c2\u00a0rules and we can re-sync the same data set as often as we need to – but the Portal operates quite differently. By putting in some extra effort with scheduled housekeeping operations we can maintain data quality – but we always need to keep performance in mind, and keep any queries and updates as efficient as possible.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve been thinking a lot lately about maintaining data quality in the FIM Portal. When you’re working with a lot of referenced objects (and it really is the best way to go in the Portal) you find yourself copying string data around a lot. So, for example, a person selects a business unit object from…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[42,60,23],"tags":[],"class_list":["post-2572","post","type-post","status-publish","format-standard","hentry","category-fim-2010","category-fim-2010-r2","category-powershell"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pkp1o-Fu","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/2572","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/comments?post=2572"}],"version-history":[{"count":12,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/2572\/revisions"}],"predecessor-version":[{"id":2584,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/2572\/revisions\/2584"}],"wp:attachment":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/media?parent=2572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/categories?post=2572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/tags?post=2572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}