Best Practices
Avoiding Duplicate Assets
Assets are imported into either:
the global domain specified on the command line (-d), or
the domain specified by the extension $.x-ep-application-domain-name, or
the global asset domain specified on the command line (-ad), or
the asset domain specified by the extension $.x-ep-assets-application-domain-name.
If you have the same Asset definied across multiple Apis that are imported into different domains, then these Assets are created in each domain.
Avoiding Asset Inconsistencies
The importer can only test for inconsistencies of Asset definitions within a single run, i.e. across the Apis imported in a run, before importing into the final target application domain.
When setting the environment variable CLI_TEST_SETUP_DOMAINS_FOR_APIS=true, any existing Event APIs and their referenced assets are copied from the target domain to their respective test domains before test pass 1.
This way, the importer can validate new imports against existing apis and assets.
However, if you do not use CLI_TEST_SETUP_DOMAINS_FOR_APIS, the importer does not check exisiting assets in the target application domain (generated by a previous run or manually), which may lead to WARNNGS when importing.
To resolve any inconsistencies, fix the underlying issue in the Api file(s) and import the same run again.