Support multiple mappings accessed through route

In real case scenarios, especially when using atlasmap standalone, it is more practical to have multiple “Atlasmapping.json” for working on different transformations simultaneously without re-running the app. The different AtlasMappings can be accessed through route, example : url:port/id/{{atlas_mapping_id}}

Afaik the application currently does not support this functionality right?

[igarashitm]

Thinking about the browser memory usage, maybe your route&reset approach is better as opposed to having multiple mapping definitions in a single ConfigModel at once. So to switch between mapping definitions, UI would just retrieve a list of mapping definitions ID and show them in a dropdown, then once one of them is selected, it would be forwarded to the route and re-initialize with that mapping definition. What I’m mentioning is basically for standalone usage BTW, Syndesis ATM stores a mapping definition in their own store. Just like we disable import/export, we’ll have to disable switch mapping definition feature in Syndesis.

On the other hand, backend still should be aware of all available mapping definitions, and better to be stored in a logical structure. I think we can create sub directories for each mapping definitions with having mapping definition ID as a directory name. It could be just a sequence number, so that we can assume 0 is always a default mapping definition. REST API would accept mapping definition sequence number to refer specific mapping definition, and 0 is assumed if not specified.

Supporting multiple import/export mapping definitions at once could be a separate feature so that it could come later. We can export current active mapping definition for now. Import might have to overwrite active mapping definition until we provide switch mapping definition feature in standalone UI. So for the 1st step, all of catalog GZ file, mapping JSON file, ADM file would be placed in each mapping definition sub directories, so that all imported schemas are isolated for each mapping definitions. However, lib/ directory is better to stay at the top directory, otherwise we’d have to switch classpath for every backend invocation.

React migration shouldn’t be that hard for this one… maybe think about it when we arrive there.

[igarashitm]

Sounds good, right now busy with fixing bugs though, I’ll try jumping on it soon.