Boomi integration - Dynamically inject mapping information

Question

We are now in process of evaluating integration solutions and comparing Mule and Boomi.

Use case is to read an Excel file, map the columns to a pre-defined set of JSON attributes and then use the JSON to insert records into a database. The mapping may vary from one Excel template to another wherein the column names in an Excel may be different from others.

How do I inject mapping information (source vs target) from outside integration flow?

Note: In Mule, I'm able to do that using a mapping variable (value is JSON) that I inject using Mule DataWeave language.

Answer 1

Boomi's mapping component is static in terms of structure but more versatile solutions are certainly possible.

1. The data processor component opens up Groovy, JavaScript, and XSLT 3.0 as options. These are Turing-complete languages that can be used to bend Boomi to almost any outcome.
2. You could make the Boomi UI available to those who need to write the maps in JSON. It's a pretty simple interface to learn. By using a route component, there could be one "parent" process that governs the a process for each template/process and then a map for each template. Such a solution would be pretty easy to build and run; allowing the template-specific processes to be deployed independently of the "parent".
3. You could map to a generic columnar structure and then dynamically alter the target columns by writing a SQL procedure that would alter the target columns.

I've come across attempts to do what you're describing (not using either Boomi or Mulesoft) which were tragic failures: https://www.zdnet.com/article/uk-rural-payments-agency-rpa-it-failure-and-gross-incompetence-screws-farmers/ I draw your attention to the NAO's points:

ensure the system specifications retain a realistic level of flexibility

and

bespoke software is costly to develop, needs to be thoroughly tested, and takes more time to implement

The general goal for such a requirement like yours is usually to make transformation/ETL available to "non-programmers" which denies the reality that there are many more skills to delivering an outcome than "programming".