This is regarding the development of FIM 2010 management agents for applications, which are not provided OOTB. I want to develop an Import and Export management agent.The export mode should be Call Based export. Hence the interfaces to be implemented are IMAExtensibleFileImport and IMAExtensibleCallExportIn the function GenerateImportFile I have written the logic to connect to the application/data-source, and import and write the data in a text file. This is executed when I execute the Full Import run profile on the custom MA.However, I am not clear on how the application identity data which is now written in the text file, will be imported in the connector space of custom MA. Do I have to use the Delimited File based MA for importing this data? If yes, then what is the purpose of using the ECMA as an intermediate MA when the same thing could have been achieved by using rules extension of Delimited File based MA. Please advice Mayank Vaish

FIM / ILM will import the data automatically as part of the MA run. e.g., Launch ECMA "SomeECMA" with "import" run stepFIM calls MyExtensionMA.GenerateImportFile("import.txt", ....)ECMA creates file "...MAData\SomeECMA\import.txt"FIM reads contents of "import.txt" The ECMA also gives you the ability to perform call-based exports, whereas a simple delimited file MA using the built-in template has little or no meaningful export ability. There is not much upside to writing an ECMA if you only want to import data from a delimited / AVP / LDIF file. (Although there is still the benefit of getting the MA to generate the file on demand.)

When you create a custom MA, you have to feed it a template file that is of the same format that your code-generated file will be in. That tells FIM how to read in the data. You specify the name of the import file in the run profile, and that name is passed to your code through the "filename" string parameter in GenerateImportFile(). You wouldn't create a separate File MA to read the file your ECMA generates. For starters, the File MA would look in its own folder under MaData for the import file, not in the folder for the custom MA. The rules extension of a file MA (or any other MA type) only affects the import flows of individual records after they are already imported into the connector space. The rules extension cannot do anything to create the import file itself. Chris

The best analogy I've heard is to think of the ECMA as a frontend to a Delimited file MA. You write the code to fill up the file and FIM takes it from there. Similar for a file based export (call-based is a little more sophisticated) Even when you have a file thats already in the right format, you can use the code capability of the ECMA methods to copy a file from some other place - i.e. get it off a file share or FTP site and copy it to the MaData folder so you don't have to schedule an external process, you can do everything in one place - and have it launched from the profile run. I know its more than that - but it gets the idea across.Frank C. Drewes III - Architect - Oxford Computer Group

When you create a custom MA, you have to feed it a template file that is of the same format that your code-generated file will be in. That tells FIM how to read in the data. You specify the name of the import file in the run profile, and that name is passed to your code through the "filename" string parameter in GenerateImportFile(). You wouldn't create a separate File MA to read the file your ECMA generates. For starters, the File MA would look in its own folder under MaData for the import file, not in the folder for the custom MA. The rules extension of a file MA (or any other MA type) only affects the import flows of individual records after they are already imported into the connector space. The rules extension cannot do anything to create the import file itself. Chris

The best analogy I've heard is to think of the ECMA as a frontend to a Delimited file MA. You write the code to fill up the file and FIM takes it from there. Similar for a file based export (call-based is a little more sophisticated) Even when you have a file thats already in the right format, you can use the code capability of the ECMA methods to copy a file from some other place - i.e. get it off a file share or FTP site and copy it to the MaData folder so you don't have to schedule an external process, you can do everything in one place - and have it launched from the profile run. I know its more than that - but it gets the idea across.Frank C. Drewes III - Architect - Oxford Computer Group

In addition to what you've got here already (alot of good info), two things come to mind: I usually use an LDIF file in lieu of delimited text files for flexibilityIf you opt to implement an ECMA2 XMA, you won't need the import MAMy Book - Active Directory, 4th Edition My Blog - www.briandesmond.com