Ideas
MIM Sync Adapter integration usability improvement suggestion
At the UNIFYBroker site I am presently working on there are now 7 Broker-driven management agents for MIM, most of which interact with multiple adapters. I have found that it starts to get unwieldy when it a single schema change in a single connector requires a schema/interface refresh of all 7 management agents. Furthermore, when deploying MIM sync configuration and using the schema matching dialog, there is a need to deselect all of the adapters (LDAP partitions) which are not relevant to each particular MA, complicating the deployment process.
It would be great if there was a way to limit visibility of the UNIFYBroker adapter set on a per-management agent basis - and the most obvious way I could think of achieving this would be by using multiple LDAP user accounts, and extending the Settings page to support mutli-selection of adapters per LDAP user. In this way, adapters visible to any given MIM MA would be determined by the use of an appropriate user account - rather than the current practice of using the same LDAP user for every MA.
This would address both of my above scenarios as follows:
- A single connector schema change would potentially limit the need for schema refreshes to a single MA; and
- Partitions not visible to the LDAP account would no longer appear on the partition matching dialog, and in most cases this would reduce the number of partitions requiring deselection (and in many cases eliminate the partition matching dialog being displayed altogether) when importing MIM sync server config XML.
Customer support service by UserEcho
Hey Bob,
Thanks for the feedback. I've been thinking about this one since you opened it, and have a few points for discussion/clarification.
The idea of being able to restrict user accounts to a subset of adapters is a good idea - it would also further enhance the security model of the product, specifically allowing consuming downstream systems to only interact with the data that they are required to. This would appear to solve your second problem too - where an MA would only be able to see the adapters that it has access to, so would negate the need to deselect other partitions.
However, i'm not sure it would do anything for your first scenario. Consider this:
We have LDAP partitions Partition1, Partition2 and Partition3. MA1 consumes Partition1 and Partition2, while MA2 consumes Partition2 and Partition3.
If you were to update the schema in either Partition1 or Partition3, then you would only need to update the schema in the corresponding MA. However, if you were to update Partition2, then you would need to update the schema in both MA's. Having the account restricted to consuming MA's wouldn't resolve that problem.
You also mention that "a single schema change in a single connector requires a schema/interface refresh of all 7 management agents". I may be forgetting some nuances of MIM, but I would imagine that you would only need to refresh the schema of the MA's which relate to the partitions containing the schema change, unless Broker is running in Single Schema mode. Is there a detail I'm missing here which would require a constant update of all management agents?
Thanks for getting back, Matt.
In your 2xMA / 3xAdapter scenario, I would be happy to work with that constraint - knowing that if I wanted to avoid it I would either A. not share partition 2 (i.e. clone the adapter with a different DN structure), B. use the same creds for both MAs (like we do now), or C. use separate creds and deal with the refresh scenario.
In the second scenario, I have run into this issue multiple times in the last few weeks - and can confirm that a schema change for a single attribute of a single connector caused a schema refresh on all 7 MAs to detect and apply schema changes - which in turn leads to the need of the "refresh interfaces/refresh partitions" steps you need to then perform on each MA (over and above the refresh itself).
Matt - just confirming this morning that after making a change to a single adapter transform on just one of 18 adapters in my configuration, each of the 7 MIM ECMA2 management agents reported schema changes on refresh.
Thanks Bob,
That seems a bit strange to me - but may be a nuance of Broker or MIM that i'm forgetting. We'll look into it to see whether that's intended behaviour or whether there's something we can do to avoid it happening.