Request: better support for Extensible Connectivity Management Agents development RRS feed

  • General discussion

  • Hi all,

    After I updated to FIM 2010 R2, I discovered that my custom ECMA1 MAs were broken, while in theory they should just be deprecated but continue to work regularly, and this is forcing me to migrate all my existing MAs to ECMA2.

    Therfore, I would like to start a discussion about the development of Extensible Connectivity Management Agents, because I think that there's room for some serious improvements.

    Problem: ECMA2 Management Agents are hard to develop and debug

    Every time I modify something in the MA, I have to manually refresh the interfaces from the Synchronization Service console.
    This is very annoying, for example, if I just fixed a bug, without adding/removing interfaces or changing configuration paramaters.

    Since the MA dll is loaded only when the MA is being executed, it's impossible to attach a debugger.
    This forces me to insert Debugger.Launch() statements in the code.

    I recently discovered that the GetCapabilitiesEx method of the IMAExtensible2GetCapabilitiesEx interface is called only when the Management Agent is created, and not when the dll of the MA is updated.
    This implies that if I'm developing a new MA, I must get the capabilities right at the first attempt, otherwise I'll have to delete the MA and create a new one, which also means that I'll have to reconfigure everything.

    Proposal: it would be nice to have a "development mode" option for Management Agents, which could make the MA work differently than in "production mode". For example, in "development mode" the MA could reload the capabilities on demand, ignore dll changes (it will be my responsibility to refresh the interfaces if I know it is needed), and we could have an option to run a profile (or refresh the schema) attaching a debugger at the same time.

    Problem: Documentation for ECMA2 Management Agents could be improved and is scattered around

    The documentation for many interfaces or methods seems to be automatically generated, and is not very helpful.
    This is the case, for example, of the IMAExtensible2GetCapabilitiesEx.GetCapabilitiesEx Method.
    The relevant information for that method is instead at a generic "What's New in ECMA 2.2" page, which states that the capabilities page will not appear when editing an existing ECMA 2.2 connector: this information should be in the documentation of the method itself.

    Several pages, like IMAExtensible2CallImport.GetImportEntries and IMAExtensible2GetSchema.GetSchema provide a link to a generic page for "Return values, Errors, and Exceptions" instead of specifying what the method should return.

    Proposal: I think that the documentation would be greatly improved if

    • all the relevant information for each topic was in a single place
    • it was stated clearly when the methods of each interface are called by the system
    • it was clearly specified what each method is expected to return, which exceptions it is expected to throw and how the system will react to them.

    Please comment

    If you have experience developing custom management agents, please share your opinions here.
    I think that this situation should definitely be improved, and maybe some of these remarks could be taken into consideration for future developments.
    Extensibility is, in my opinion, the most important feature of FIM, and having a better support for development would allow creating better quality custom Management Agents.

    Paolo Tedesco -

    Tuesday, June 16, 2015 7:46 AM

All replies