Whats the Data Importer activitys purpose if a change requires a deployment?

0
Being able to reference a specific import directly from a microflow, without relying on an association with a Template object or a configuration entity with a TemplateID integer attribute is great. That is what the Data Importer functionality, available onwards from 10.6, provides. However, it's very strict in terms of column names. Contrary to the existing marketplace module for xlsx/csv data imports, the column name has to match hwo it's configured within the Data Importer item in your project. If for any reason the user uploads a file with a different column name and you have not configured your error handling correctly, the user will not be able to import a file. The marketplace module simply states 'Column A maps to attribute X, column B maps to attribute Y, etc.'. In fact, during runtime you can even adjust the import, without relying on a new project revision and deployment.So other than a more direct method to reference an import functionality from a microflow, what's the goal of the Data Importer? I see more issues than advantages here.
asked
1 answers
1

Hi Sander,


I think the main benefit of the Data Importer is not only the fact that it can be called directly from a microflow.


It gives you a defined structure for the Excel/CSV file at design time, including the columns, data types and the target entity. This makes the import configuration part of the application model instead of having to maintain the mapping separately at runtime.

The strict column handling is indeed something to keep in mind. If the input files are controlled by your application, this is usually not a problem. If users can provide files with changing column names/structures, I would use Import Mapping instead, where you have more control over finding/creating objects, associations and committing the imported data.

Also, from Studio Pro 10.18 onwards, a Data Importer document can be used as the source for an Import Mapping, so these two approaches are not really competing solutions anymore. You can use Data Importer to define the Excel/CSV structure and then use Import Mapping when you need more flexibility.


So I would see it roughly like this:

Data Importer + Import data from file → simple, predefined Excel/CSV structure where the file format is known.

Data Importer + Import Mapping → same structured input, but with more control over mapping, associations and object handling.

For a completely user-defined Excel where columns can change frequently, I would probably not use the basic Data Importer activity alone. In that case, a more dynamic mapping approach is a better fit.

The fact that the configuration requires a deployment is also expected: the Data Importer document is part of the application model. Changing that model configuration is therefore a development-time change, rather than something intended to be edited freely by an end user at runtime.

answered