Here are the situations where you may find this feature useful:

1.  You are creating a new Management Policy Rule (MPR), such as one to provision all users an AD account, and you want one or more of the action workflows in your new MPR to be applied, upon creation of the MPR, to all the members of the MPR's Resource Final Set (also referred to as "Target Resource Definition After Request" in the portal's MPR wizard).  For example, you may be creating a new MPR to apply a new Synchronization Rule to all users.  You may want to retroactively enforce this new policy by applying the Synchronization Rule workflow to all users that already exist.

2. You are enabling a previously disabled MPR, and you want one or more of the action workflows in the MPR to be applied, upon enabling of the MPR, to all the members of the MPR's Resource Final Set.

3. You are adding a new action workflow to an existing MPR, and you want the new workflow to be applied to all the members of the MPR's Resource Final Set, immediately upon adding the workflow to the MPR.

4. You are modifying the Resource Final Set of an existing MPR to reference a new set, and you want one or more of the MPR's action workflows to be applied to all the members of the new Resource Final Set, immediately upon modification of the MPR.

5. You are manually modifying the membership of the Resource Final Set of an MPR, either by modifying the set's Filter or ExplictMember attribute, and you want one or more of the MPR's action workflows to be applied to all the *new* members of the new Resource Final Set, immediately upon modification of the set.

The "Run on Policy Update" feature is an option that lives on action workflow definitions, as an attribute labeled "RunOnPolicyUpdate" bound to the WorkflowDefinition resource type.  When this boolean attribute is set to "true" for a given action workflow, if any of the 5 scenarios above are encountered with an MPR that uses this workflow, the workflow will be automatically applied to the members of the Resource Final Set of the MPR.

Following is a table that summarizes the cases where a "Run on Policy Update" enabled action workflow is applied, in addition to the normal cases where a new Request satisfies all the criteria of an MPR that uses the workflow.

User Request	Resulting Action by the FIM Service
Create new MPR	Apply each "Run on Policy Update" enabled action workflow referenced by the new MPR to all members of the MPR's ResourceFinalSet.
Enable an existing MPR	Apply each "Run on Policy Update" enabled action workflow referenced by the enabled MPR to all members of the MPR's ResourceFinalSet.
Select a new ResourceFinalSet for an existing MPR	Apply each "Run on Policy Update" enabled action workflow referenced by the MPR, to all members of the new set referenced by the ResourceFinalSet attribute.
Add a new "Run on Policy Update" enabled action workflow to an existing MPR	Apply the newly added action workflow to all members of the MPR’s ResourceFinalSet.
Modify the filter of a set	For all MPRs whose ResourceFinalSet references the set being modified, apply each "Run on Policy Update" enabled action workflow  mapped to the MPR to each resource that transitions into the set because of the filter update.
Update explicit membership of a set	For all MPRs whose ResourceFinalSet references the set being modified, apply each "Run on Policy Update" enabled action workflow  mapped to the MPR to each resource that that is added to the set.

Nima

 If I have one hope is it that you have found this blog, along with the talks, webcasts and reports I have done to be useful in helping to digest the seemingly endless new concepts coming out with FIM 2010. It can be a lot to take in one shot for sure, as sometimes I even find myself scratching my head as to how something works and even more so when I attempt to describe it,

 To all of my colleagues and friends I have made in my time on the MIIS/ILM/FIM teams, I wish you all the best going forward. As for me, its back to the student life for the time being.

 Going forward, I'll still be available to help people with FIM (as much as my new student life permits of course!) if you want to reach me, you can email me at bobby.gill (at) gmail.com and you can always find me on facebook at www.facebook.com/jasjeet

 Ill be at TechReady tomorrow morning and I should be at the FOX Sports Grill event in the evening, so come grab me if you see me.

 In the meantime, I leave this blog in the more than capable hands of my colleague Nima.

 Thanks

Bobby

From:
Sent: Tuesday, July 14, 2009 11:06 AM
To: Bobby Gill
Subject: (Bobby and Nima's Forefront Identity Manager Blog) : Question about FIM/Outlook
Importance: High

Good afternoon Bobby and Nima's.

I read your blog often as I await the release of MMS...I mean MIIS...I mean ILM...I mean FIM :)

I keep seeing things about how nice it is to request to be added to groups or distribution groups through Microsoft outlook. Are all of the features available from inside Outlook available from the web interface?

The reason I'm asking is that a lot of clients may have a need to use identity management to synchronize their Microsoft world with their HR world...and their email world ! (*cough Lotus Notes*). I understand that the level of integration (especially for distribution lists) is probably not the same, but are most other features of the Outlook FIM client available on the web console ?

------

The simple answer to the question above is that the Outlook plug in for FIM 2010 contains a proper subset of functionality available within the web portal. That is everything that is possible through the Outlook interface is available within the web portal.

However the opposite is not true. While the Outlook plug in allows you to manage group memberships and approvals/requests, it does not nearly provide the same level of functionality as the web portal. For instance the creation of groups (both static and dynamic), deletion and modification (outside of membership) can only be done through the FIM portal.

Further, the Outlook plugin requires both Outlook 2007 as well as Exchange 2007 running on the backend. However, if you are using an email client which is not Outlook 2007, or a email server that is not Exchange 2007, you can still send notifications and approvals to email clients via any SMTP server. To perform any operations on said messages will require you to go to the portal and perform .

Much like my box of Frosted Miniwheats, FIM 2010 has a few hidden surprises of it’s own that lurk underneath the covers and are often ignored. One of these features is Hierarchical Provisioning. Much like the name would imply, Hierarchical Provisioning allows objects, and more importantly, any missing parent containers, to be provisioned into the connector spaces of LDAP MAs . Previously in MMS, MIIS, and ILM 2007, if one wanted to provision a user into a container in Active Directory, one would need to ensure that they created the container in Active Directory prior to provisioning the user with MMS/MIIS/ILM. However, with Hierarchical Provisioning, you do not need to do this anymore. With some settings configured in the Management Agent (MA), the missing container can be created automatically by the Active Directory Management Agent, and then the object provisioned within it.

The steps to configure this feature are relatively straight forward. Assume that you want to provision the following user into Active Directory: “cn=Bobby Gill, ou=Redmond, ou=Users, dc=fabrikam, dc=com”. In this case, the Redmond OU does not exist in the Active Directory domain. Before the ILM AD MA can provision this new user into the OU specified,  the OU needs to be created in Active Directory. This is where Hierarchical Provisioning comes into play.

 As an ILM Admin, to enable Hierarchical Provisioning on a LDAP MA, you need to configure a mapping within the MA such that anytime upon export the MA detects that a parent of a object doesn’t exist, it knows what object to create in the connected directory for that parent. This configuration is done within  the LDAP MA screens  by mapping valid DN components to object classes in the connected directory. In this case, you would set up a mapping between the “OU” DN component to the object class “organizationalUnit”. Thus in the above scenario, when the MA is exporting the object to AD and realizes that the “OU=Redmond” parent is missing, it will look up the mapping for the “OU” component and first create a new organizationalUnit object named “Redmond” and then export the new user  into the container.

 Steps to configure Hierarchical Provisioning: 

1. Create a new instance of your favorite LDAP Management Agent. Personally, I’m a Microsoft guy, so obviously I always choose Active Directory Domain Services.
2. You’ll notice a new page on the left tab titled ‘Configure Provisioning Hierarchy’.
3. Map DN components to Object Classes. The DN Component list box lists all known valid DN components for the given directory, this is inferred by analyzing the LDAP schema of the directory. To the right is the list of available object classes in the directory, again taken from the LDAP schema.

4.)    Mappings are created by selecting a DN component in the left list box, and a object class in the right list box, and then clicking “new”. You can only create 1 mapping per DN component.

 Once setup, Hierarchical Provisioning is transparent to the actual provisioning mechanism. Thus, if you are using Synchronization Rules or even a traditional scripted Metaverse Extension, these settings will be applied to both at export time.  Hierarchical Provisioning further reduces the burden on IT Pros by allowing much more flexibility in terms of provisioning decisions made in the FIM Workflows and eliminates an often tedious manual step whenever a new business unit comes online and an associated container or OU needs to be created.

The feature is available to all LDAP Management Agents and is available in the ILM "2" RC0.

Whoa, new product name! For those of you who have been chasing butterflies for the past month, what was once known to us as Identity Lifecycle Manager "2" is now called Forefront Identity Manager.  I know, it's not the sexiest name in the world and is probably the 5th different name the product has had since it's conception, but it reflects the combination of Microsoft's security and identity product lines into the Forefront brand announced last year.

Personally, I wanted to name the product "Black Thunder II", but then again there are a myriad of reasons why I am not allowed to name Microsoft products.

 But back onto the topic at hand...

Synchronization Rule Dependency

I decided to take some time off today to briefly talk about Synchronization Rule Dependencies, a powerful yet not well understood part of ILM FIM's synchronization capabilities. In brief, a Synchronization Rule Dependency allows one to construct and apply a series of outbound Synchronization Rules ontop of each other. The scenarios that spring to mind whereupon this functionality is useful are things such as adding/removing Exchange mailbox provisioning, or adding/removing VPN access upon a user's Active Directory account (with the former 2 being dependent on the latter).

If an Outbound Synchronization Rule (the dependent) is marked as having a dependency on another Synchronization Rule (the root), the dependent rule will apply itself ontop of the connector that the root Synchronzation Rule is applied on. At run time, when a FIM Action Workflow attempts to add an Expected Rule Entry (ERE) object for the dependent Synchronization Rule onto a FIM Resource's Expected Rules List (ERL) , there needs to also exist an ERE-Add object for the root Synchronization Rule on the ERL.  (I am just going to take a minute here and say I don't think there has been that many acronyms stuffed into one sentence since the merger between the wrestling giants WWF and WCW was announced). Conversely, if an Action Workflow adds a ERE-Remove entry for a root Synchronization Rule, all EREs that correspond to Synchronization Rules further up the dependency tree will be removed.

Its important to note that when you design an Action Workflow to add or remove a series of EREs that correspond to a Synchronization Rule dependency chain, the root rule must be added to the workflow surface prior to any other dependent rules.

Multiple levels of dependency can be created, with more than one Synchronization Rule being made to depend on a single Synchronization Rule.

In the Synchronization Rule Designer, to create a Synchronization Rule Dependency is relatively straightforward. The first page of the designer allows you to select another outbound Synchronization Rule to make a new Synchronization Rule depend on. When selected, the Scope and Relationship pages are automatically greyed out. Once a Synchronization Rule is made to depend on another rule, the only settings that are adjustable on that rule are the workflow parameters and the outbound attribute flows. Conceptually, this falls cleanly from the fact that a dependent Synchronization Rule is being applied "on top" of another rule.

I wish I could paste some screenshots of what this looks like, but the FIM UI has changed markedly since the RC 0 release and I dont want to ruin the surprise just yet :)

The canonical scenario in which Synchronization Rule Dependency's are used are around creating business processes to manage the provisioning/deprovisioning of capabilities that stem from attributes set on a Active Directory user account. In a typical provisioning scenario, one would construct a base "Active Directory User Synchronization Rule" which, as the name implies, would create a new AD User object, flow the necessary base DN, samAccountName and name information. On top of that, you could then model a dependent Synchronization Rule for granting an Exchange mailbox. This Synchronization Rule would be dependent on the Active Directory User Synchronization Rule, and as a consequence would only have a single flow to the homeMDB attribute. Modelling the user account provisioning seperately from the mailbox provisioning, through the use of Synchronization Rule dependency, allows you to define independent business processes around the lifecycle management of the two through Management Policy Rules and workflow.

 As always, feel free to email me any questions you might have and I will do my best to get back to them.

Bobby

While many of the common questions and areas of concern are fresh in my memory, I’ll proceed to share some guidance where I can. 

Let’s start with some examples that demonstrate the use of the XPath Filter Dialect addressing common queries (for reporting and other scenarios).  I’d recommend first reading the previous post on the xpath fundamentals.

Note: The XPath Filter Dialect is case sensitive.  Keep this in mind when writing your xpath filters.  For example, /Person[displayname = ‘value’]  is NOT the same as /Person[DisplayName = ‘value’].

Example 1:  A User’s Pending Approvals

You’ll need the following xpath if you want to build a report or page that lists all the approvals that are pending a response from a specific user.

Let’s assume the user, for which you want to see the pending approvals, has an Account Name of ‘mmeyers’ and an ObjectID of  ‘11111111-1111-1111-1111-111111111111’.

This first filter demonstrates how to identify the pending approvals based on the user’s ObjectID:

/Approval[ApprovalStatus = ‘Pending’ and Approver = ‘11111111-1111-1111-1111-111111111111’]

This second filter demonstrates how to identify the pending approvals based on the user’s Account Name:

/Approval[ApprovalStatus = ‘Pending’ and Approver = /Person[AccountName = ‘mmeyers’]]

Notice that in the second example we make use of a location path expression, /Person[AccountName = ‘mmeyers’], inside the predicate in order to identify approvals where the Approver is a user with the specified Account Name.

Note that the ApprovalStatus represents the status of an approval and can have one of the following values:

·          Pending

·          Approved

·          Rejected

·          Expired

A status of ‘Pending’ means the approval is currently awaiting a response from one of the users listed in the Approvers attribute of the approval.

A status of ‘Approved’ means the Request associated with the approval has been approved by the required number of approvers.  After an approval has been created it will only be marked as ‘Approved’ if the minimum number of responses, as specified by the ApprovalThreshold  attribute of the approval, is met.

A status of ‘Rejected’ means a user designated as an approver for the approval have rejected the approval.  At any point in time if a valid approver rejects an approval, that approval is immediately rejected and the workflow and associated Request is terminated.

A status of ‘Expired’ means the approval has reached the time indicated by the ApprovalDuration attribute on the Approval object as no response to the approval has been submitted.

Example 2:  All Security Groups expiring within the next 7 days.

/Group[Type= ‘Security’ and ExpirationTime <= op:add-dayTimeDuration-to-dateTime(fn:current-dateTime(), xs:dayTimeDuration(\"P7D\"))]

Example 3:  All Orphaned Security Groups

An ‘orphaned’ security group here refers to a group with no owner.  The following is the xpath to identify such groups:

/Group[Type = ‘Security’ and Owner != /Person]

Example 4:  People who are members of both the "Interns" group and the "Full Time Employees" group:

While my example here may not be a very compelling one, the goal is to demonstrate how we can identify users that are in sets or groups producing conflicting roles or permissions.

/Person[ObjectID = /Group[DisplayName = ‘Interns’]/ComputedMember  and  ObjectID = /Group[DisplayName = ‘Full Time Employees’]/ComputedMember ]

Note that I used the DisplayName attribute to identify the groups of interest, but the better practice would be to use a unique identifier to identify the groups, such as their ObjectID attribute.

Example 5:  People who were EVER members of both the "Interns" group and the "Full Time Employees" group at the same time:

The previous example identified people who are currently members of two conflicting groups.  The following example identifies people who were ever members of these conflicting groups at the same time.   This example makes use of the historical querying feature of ILM to scope the query to a time in the past.

allTime(/Person[ObjectID = /Group[DisplayName = ‘Interns’]/ComputedMember and ObjectID = /Group[DisplayName = ‘Full Time Employees’]/ComputedMember ])

Example 6:  All permissions that Kim Abercombie had in the month of January, 2009.

Again, here we see the use of historical query to check for a condition that was met at some time in the past.  This time we are checking for permissions that existed for a user between a specified time period.

betweenTime(/ManagementPolicyRule[GrantRight = 'True' and PrincipalSet = /Set[ComputedMember = /Person[ DisplayName = ‘Kim Ambercrombie’]]] , ‘2009-01-01T00:00’, ‘2009-01-31T00:00’)

Notice that the filter above is looking for any Management Policy Rule, of the type that grants permissions, which granted permissions to a set that contained Kim Ambercrombie in its membership

Example 7:  Changes to security groups in the last 10 days

/Request[Target = /Group[Type = 'Security'] and Operation = 'Put' and CreatedTime >= op:subtract-dayTimeDuration-from-dateTime(fn:current-dateTime(), xs:dayTimeDuration('P10D'))]

The above filter is returning all Requests that were created, within the last 10 days, to modify a security group.  If you want to find only the Requests that were actually ‘completed’, or the ones that were ‘rejected’ or still pending, simply add an additional condition based on the status of the request.

Example 8:  All full time employees that were ever contractors (ie. transitioned from one job to another).

/Person[EmployeeType=’Full Time Employee’ and ObjectId = allTime(/Person[EmployeeType=’Contractor’])]

Each of these examples is related to a question I've recieved in the past.  As more common scenarios become apparent, I will post examples addressing them. 

 - Nima

This blog focuses on the XPath Filter Dialect, which you can use to create the queries to submit through the ILM Web Services.  XPath Filter Dialect is a subset of the XML Path Language (XPath) 2.0, with some additional functions.

Client applications can send WS-Enumeration Enumerate messages to the ILM Service to identify a of resources and attributes.  The subsets resources to return are identified by expressions in the XPath Filter Dialect (from here on usually referred to simply as an ‘xpath filter’ in this blog). 

If you are developing your own custom client for ILM, or submitting queries to ILM through a custom activity, you will need to use the xpath filter as your query language.  In the ILM portal, xpath is the language in which you express the queries for Search Scopes that can be created.  Xpath is also used to express the membership conditions of calculated groups and sets.

The following is an example of an xpath filter that identifies all people whose Job Title is ‘Engineer’: /Person[JobTitle = ‘Engineer’]

Rather than continue listing examples of xpath filters you may find useful, I’m going to use this blog post to describe the fundamentals of the ILM Xpath Filter Dialect so that you can understand the expression language and construct any filter you need.  I will follow up this blog with another post of some sample filters for commonly requested queries and reports.

Much of the content I include here is probably covered by the ILM “2” SDK in much more detail, but hopefully you’ll also find some of the guidance here conveniently available and useful J.  I will build on this topic with examples as people request them, so feel free to make suggestions!

Let’s start by looking at the data types the ILM xpath filters support.

Data Types

The ILM XPath Filter Dialect supports the four data types defined for XPath 1.0, plus the dateTime type that is defined in the XML Schema specification. These types are defined in the following table.

Now that we know what types of data we can filter on in our expressions, let’s take a look at what types of expressions we can actually define.

Types of Expressions

ILM “2” supports the following types of xpath expressions:

1. Location path expressions
2. Boolean expressions
3. Equality expressions
4. Relational expressions
5. Function calls

1.    Location Path Expressions

A location path expression identifies a node-set (collection of resources). A location path expression consists of one or more location steps. Location step expressions are delimited by a forward slash (/).  A location path expression must refer to an object type in ILM, or an attribute of type reference which refers to a resource.  Location path expressions have the following form:   /step/step/… | step/step/…

A forward slash at the beginning of an expression indicates an absolute location path expression as distinct from a relative location path expression. A relative location path expression identifies a node-set relative to the context node-set. The context node-set is the set of nodes that have already been identified.

Example: /Group/ComputedMember is a location path expression that consists of two location steps: Group and ComputedMember.  The result of this filter is all resources that are the ComputedMember of any Group.

Example: /Person[AccountName = ‘nima’]/Manager returns the resource referenced by the Manager attribute of the Person with an Account Name of ‘nima’.

Example: /Person[AccountName = ‘nima’]/DisplayName is not a valid xpath filter because DisplayName is not a reference type attribute.

            Union of location path expressions

The union of one or more location path expressions can be obtained by linking the location path expressions with the union operator, which is denoted by the vertical bar character, |.

Example:  /Person | /Group returns all people and groups. 

Predicates

Predicates are expressions that appear enclosed in brackets at the end of location steps. In the XPath Filter Dialect, predicate expressions must be Boolean expressions, equality expressions, function expressions or relational expressions.

Predicates filter the current node-set to produce a subset. A predicate is evaluated for each node in the current node-set. If the result of the predicate is true for a node, that node is included in the subset yielded by the predicate; otherwise, it is excluded.

Example:  /Person/Manager[JobTitle = ‘VP’] returns all people whose Manager’s Job Tile is ‘VP’.  The location step here are Person and Manager[JobTitle = ‘VP’] .  The second location step consists of a node name, Manager, and a predicate, JobTitle = ‘VP’.  

You can even have location path expressions nested inside predicates.

For example, the filter /Person[Manager = /Person[JobTitle = ‘VP’]] returns all people whose Manager is a person with a Job Title of ‘VP’.  Note that this returns us the same result as a previous example: /Person/Manager[JobTitle = ‘VP’].

2.    Equality Expressions

Equality expressions test the equality of terms. They have the following form: left_hand_term operator right_hand_term

The valid equality operators are as follows:

The left-hand term of an equality expression must be the name of an attribute in the ILM schema.

The right-hand term of an equality expression can be one of the following:

·         A function call.

·         A Boolean value.

·         A dateTime value.

·         A number.

·         A string.

·         A reference value.

If the left-hand term is a reference type attribute, the right-hand term can be a location path expression (ie. a filter representing a sub-condition).

Multi-Valued Equality Expressions

When the = operator is used in an equality expression where the left-hand term is a multi-valued attribute and the right-hand term is a literal value, the expression evaluates to true if the value of the right-hand term is any of the values contained in the left_hand_term.

Example:  /Group[ComputedMember = ’11111111-1111-1111-1111-111111111111’] returns all groups whose ComputedMember attribute contains the resource with the ObjectID ’11111111-1111-1111-1111-111111111111’. 

When the = operator is used in an equality expression where the left-hand term is a reference attribute (multivalued or single valued) and the right-hand term is a location path expression, the expression evaluates to true if the value of the attribute on the left-hand term is any of the values contained in the node-set returned by the right_hand_term. 

Example:  /Group[Owner = /Person[EmployeeType = ‘Contractor’] returns all groups whose Owner is a Contractor. In other words, this filter returns all groups where any of the values of their Owner attribute is among the set of people whose Employee Type is ‘Contractor’.

3.    Relational Expressions

Relational expressions compare the values of two terms. They have the following form: left_hand_term operator right_hand_term

Valid relational operators are: <=, <, >=, >, which are pretty self explanitory.

4.    Boolean Expressions

Boolean expressions evaluate the validity of two expressions in a predicate using ‘or’, and ‘and’.

When ‘or’ is used, the predicate evaluates to true if either expression is true.

Example: /Person[JobTitle = ‘VP’ or ‘Senior VP’] returns people whose Job Title is ‘VP’ or ‘Senior VP’.

When ‘and’ is used, the predicate evaluates to true only if both expression are true.

Example: /Person[JobTitle = ‘VP’ and Department = ‘Sales’] returns people who are VPs and are in the Sales department.

5.    Function Calls

The ILM XPath Filter Dialect provides the following functions that can be used in location path expressions:

Hopefully this blog helps you understand the structure of the XPath Filter Dialect expression language.  Trust me when I say this knowledge will come in extremely handy if you will be performing any of the following:

·          Creating search scopes for the portal.   Search scopes are pre-canned searches you can use in the portal.

·          Creating advanced calculated sets and groups that cannot be created using the Filter Builder control in the ILM portal.  One example of such a set is the set of all resources that contain an Expected Rule Entry for a particular Synchronization Rule in their Expected Rules List.

·          Creating custom activities that will query the ILM Service database.

·          Creating a WS client that will submit queries to the ILM Web Service.  Such clients can be used for purposes such as reporting.

Stay tuned as I will be following up with some xpath ‘tips and tricks’ and sample filters for commonly requested queries.

Cheers,

Nima Ganjeh

Of course.

At a basic level, with ILM "2" RC, you can take an existing ILM 2007 deployment and migrate it's synchronization engine component straight into ILM "2" RC. You can do this by copying the IdentityIntegrationServer DB to a ILM "2" server, and upon installing ILM "2" point to this database instance during the setup of the synchronization component. The installer will then migrate that data forward such that all existing MA and MV configurations are ready to use right away, including rules extensions.

But if you want to go beyond this, its important to note how Codeless Provisioning works side-by-side with existing ILM synchronizaiton concepts. That is, while Codeless Provisioning bubbles up a business process driven approach to synchronization it is inherently underpinned by the same basic mechanics which power the ILM synchronization engine. As such, the adding of this functionality should not in any way change the behaviour of how MA's work, how rules extensions are called or how traditional metaverse provisioning is done.

This side-by-side coexistence is collectively referred to as a hybrid deployment.

Metaverse Provisioning 

In fact, it is supported to run Codeless Provisioning based provisioning logic side by side with traditional metaverse extensions. Codeless Provisioning is driven through the processing of Expected Rule Entry (ERE) objects, these determine which MV objects are provisioned a connector and how flows are applied on top. For a MV object being sync'ed, this processing is done prior to the calling of the Metaverse rules extension. Hence if for any reason the ERE's attached to a MV object do not achieve a desired outcome in a CS, you can use a Metaverse extension to provision additional connectors, apply initial flows and deprovision existing connectors just you would have done with ILM 2007.

Custom Functions = Rules Extensions 

Metaverse extensions are just one aspect of a hybrid scenario. A more common use case is for scripted flow. ILM "2" RC contains around 20 built in functions, which for the most part should satisfy most basic needs. However if this is not true, then you can always use an traditional Rules Extension to apply a transformation on a outbound flow. Using an MA, you can defined an advanced flow like before. This flow will be applied after any Sync Rule flows have been pushed onto an object, thus allowing you to append or overwrite attribute flow data that was provided by a Sync Rule.

Join / Projection Rules

On the inbound side, the traditional Join/Projection concepts live on as you remember them in ILM 2007. Just like the extension points, you can use traditional declared/advanced join projection rules along side Synchronization Rule concepts. In this case, if you have defined a Inbound Synchronization Rule on an MA that also has traditional join/projection rules defined the Synchronization Rule will be evaluated first. So if a disconnector exists within this MA such that it matches a Synchronization Rule's connected scoping filter, than this disconnector will be attempted to be joined/projected to the MV based on that Synchronization Rule definition. If the evaluation of that disconnector against the Synchronization Rule results in the CS object remaining a disconnector, then the existing declared join/projection rules will be executed against it.