Sunday, July 14, 2013

Outbound System Scoping Filter: "Contains" doesn't work on multi-valued attributes (and why no "Is Present"?)

I was excited to finally have a scenario in which I could use the new Outbound System Scoping Filter, but sadly its limitations put the kibosh on that idea.  I was surprised to discover (empirically, of course) that you cannot use a "contains" operator on a multi-valued attribute.  What's more, there is no "is present" operator at all.  Anyone else frustrated by FIM's lack of consistency? </rant>

Anyway, here are the tests that I ran, in case you're interested:


Test
Scoping filter
Result
Single-valued attribute equals
employeeID EQUAL 100000
OK
Multi-valued attribute contains string
Roles CONTAINS MyRoleName
FAIL
(Not Applied)
Attempt at multi-valued attribute contains string
Roles STARTSWITH MyRoleName
FAIL
(Not Applied)
Another attempt at multi-valued attribute contains string
Roles EQUAL MyRoleName
FAIL
(Not Applied)
Desperate attempt at multi-valued attribute contains string
Roles STARTSWITH %MyRoleName%
FAIL
(Not Applied)
Attempt at "Is Present"
employeeID NOTEQUAL NO SUCH EMPID
FAIL
(Applied when employeeID is not present)
Another attempt at "Is Present"
employeeID STARTSWITH %
FAIL
(Not Applied)
Desperate attempt at "Is Present"
employeeID GREATERTHAN 0
SUCCESS
100000: Applied
A100000: Applied
<empty>: Not Applied

And here's the explanation from Andreas on the forum:

"That is not supposed to work. The scoping filter is only intended for string values. It isn't documented because I didn't think of documenting it."

Posted by at

3 comments:

  1. AnonymousMay 25, 2015 at 1:20 AM

    Joe - I can report that I am having success with an "Is present" test which looks like this: "employeeID NOTEQUAL ''", i.e. in the XML we would have this:
    <scope>
    <csAttribute>employeeID</csAttribute>
    <csOperator>NOTEQUAL</csOperator>
    <csValue />
    </scope>

    This seems to work fine, but apart from being a tad intuitive, has one other downside to be wary of ... if you are migrating the above XML and you end up with <csValue></csValue> instead of <csValue /> your sync rule will not work at all. This is because (I expect) <csValue /> is effectively a test for null.

    Hope that helps - I've actually built an entire FIM solution (9-connectors, reasonable degree of complexity) using 100% scoped declarative rules, and plan to blog about this in the near future.

    ReplyDelete
    Replies
    1. Joe ZamoraMay 30, 2015 at 4:11 AM

      Great work Bob, and thanks for the feedback!

      Delete
  2. AnonymousJune 24, 2015 at 7:27 AM

    Joe - part 1 of the promised blog series is here: https://bobbradley1967.wordpress.com/2015/06/24/fim2010-r2-scoped-sync-rules-part-1-the-vision/

    ReplyDelete

Subscribe to: Post Comments (Atom)