The Mysteries of the ILM Management Agent Uncovered:

 

One of the many changes we made across the ILM to support the new declarative synchronization and provisioning concepts (aka 'codeless provisioning') was with the ILM Management Agent (hence forth referred to as ILM MA)  configuration experience. 

 

While at first glance the ILM MA may walk like, look like and act like any one of the many management agents that we have all come to know and love from the MIIS/ILM days, this resemblance is, at best, superficial. In fact the ILM MA is not your typical Management Agent, and has a unique design experience tailored to fit within the broader conceptual relationship between the ILM Application Store and the ILM Metaverse. While the two stores co-exist as independent stores in ILM "2", the relationship between the two should not be thought of  in the same vein as the typical relationship between a connected system and the Metaverse. Instead, it is envisioned that the ILM Application Store is in fact conceptually equivalent to the ILM Metaverse. Taking this notion one step further you should view the Metaverse serving as a transient storage mechanism on the road to and from the ILM Application Store, the ultimate  location for any data being synchronized into ILM. Seeing this,  we can then very easily imagine data moving from Active Directory or another third party system into the ILM realm and immediately coming under the control of the policy and process framework which applies to all data within the ILM Application Store and is at the conceptual heart of ILM application. (In order for this statement to be valid is for all data to make it to the Application Store)

 

With this view in mind, when we looked at the ILM MA, we wanted to make the experience of setting up the Management Agent between the Metaverse and Application Store to both provide a simple and "replication" like experience as possible. Thus, when you configure the ILM MA, you do not set up join and projection rules, nor do you need to write provisioning code or use Synchronization Rules to move data between the ILM MA connector space and the ILM Metaverse. Instead, you simply map object types from the Metaverse to object types in the Application Store, and then setup the attribute flow relationships between the two. After this point in time the ILM MA will automatically make sure that any new objects which are created in the ILM Application Store of the type specified in the mapping  are replicated to the ILM Metaverse as an instance of the second type specified in the aforementioned mapping (and vice versa).  The ILM MA thus allows customers the flexibility to connect newly defined ILM Application Store types to existing schema elements that they have created with their existing ILM Metaverse deployments.

 

Some of you may wonder if you are able to use scripted attribute flow and other extension mechanisms within  the ILM MA. The answer to this is no. The reason for this is that transforming data as it flows between the ILM Metaverse and the Application Store would violate the conceptual tenant that the two are logically equivalent. Instead, any desired data transformation should be done either upon inbound flow from a connected system into the Metaverse (via a Synchronization Rule or scripted flow) or in the ILM Application Store (as part of a workflow or through a web service call).

 

If we look at Nima's example of setting up the flowing of Computers, his configuration of the ILM MA demonstrates the new mapping functionality. You will notice in the ILM MA that the projection and join screens have been replaced by a Object Type Mapping screen. It is in this screen in which you map a Application Store type to its associated Metaverse type. (a known issue in Beta 3 is that your Metaverse type must be pre-fixed with "managed:" to be visible in the object type selection).

 

On the next page, you will then need to configure the attribute flows between the two types. ILM does not attempt to automatically map the attributes themselves and leaves it up to the user to determine how the attributes should be flowed. (Note: only direct flows are supported). The ILM MA also automatically adds a set of built in flows needed to support the replication functionality of the ILM MA, do not delete these!