Custom importer

There are a few things that need to be decided before you begin building your custom importer:

• What type of data will you be including in your new import?
• Which SOA data contracts support the data you will be importing?
• What file format do you want to use to get the data you need for constructing the data contracts? For example, tab-delimited or XML?

Once those questions are decided, you need to decide how you are going to execute this change:

• You can replace the File Importer completely:

This approach requires more code because you need to manually do the work the File Importer does for you, but it does give you more control over how the import process works. For example, you can name your import batches as you like. The example given in the tutorial is simple and could be executed in many different ways. Depending on how you perform your implementation, you must create an app.config file allowing you to use SOA. This approach is cloud-friendly, as you could run your program anywhere as long as you can communicate with the SOA service.

• You can extend the File Importer:

This approach allows any number of importer modules you write to be supported together within the File Importer, and you don’t have to write the code to submit import batches. The example given in the Custom Templates tutorial for this approach is more code than the Import Donations example, but that is because the custom templates does more. However, this approach is not cloud-friendly, as it requires an update to the web.config file and making your library available to iMIS.