Imports and Import Data Sources as Production Data
This article explains the different scenarios and the implications of marking imports and import data sources as production data.
Before we begin, let's define production data. In the simplest terms, production data is data or artifacts that can be changed directly in a production environment without pushing the change via the development environment.
In order for the production environment to remain up to date, it is extremely important that it is connected to the source system. Since all the transactional data and metadata have to get loaded into the production environment directly, all the lists storing this data have to be marked as production data lists. In contrast to production data, there is structural data that doesn’t get changed directly in the production environment, and any change has to be pushed via the development environment through revision tags. On the other hand, imports and import data sources don’t necessarily have to be marked as production data. By default, they are marked as non- production data or structural data. Here are a few scenarios that this article will explain in detail, along with their pros and cons.
Imports marked as productiondata and import data source marked as non-production data.
Imports marked as non-production data and import data source as production data.
Both import and import data source marked as production data.
Both import and import data source marked as non-production data.
I - Imports marked as production data and import data source marked as non-production or data
In this scenario, import mappings and other import-related options can be changed from the production environment directly.
Let’s say we want to import from source module to target module. Both have similar dimensions. We take the following steps.
Step 1: Create a saved view in source module.
Step 2: Create an import, select mappings, and run it.
Step 3: Mark the import as production data.
Step 4: Push this change to the production environment. All is good until now.
Come back to the development model and change the saved view of the source module – in this case, “Sales” line item has been renamed to “Revenue”.
Run the same import action that you created in Step 2. You will notice that the import will run with failures; that is because Anaplan has not mapped renamed line item automatically.
Here is the mapping that is thrown off due to the above change.
In order to correct this, you edit the Import action in the development environment and re-select the mappings manually. Once done, you re-run the import action, and it will complete successfully.
Since this import action had been marked as production data earlier, whatever change you made in the dev environment will not flow to the production environment. Hence, there is a need to change the mappings in the production environment as well.
Admins can reorder the positioning of an import directly in the production model.
Admins can upload the new import data source file, provided the naming convention of the file doesn’t change. However, admins can’t save if they wish to edit import data source.
Sometimes clients want additional control over the import mappings for debugging the import mappings.
Your client might not want to do this change directly in the production environment.
This particular change can be made in production after the revision tag has been pushed from development, so there is a dependency on the development model.
Due to segregation of duties, you might not be able to access the production environment, and therefore, you may need to ask production wwners to make that change for you—hence the dependency.
You can’t test the change in test environment without pushing the revision tag to test.
It is repetitive, meaning whatever you are doing in development has to be done in test and production separately.
II - Imports marked as non-production data or structural and import data source as production data
Import data source, as the name suggests, is the data source for any import. This data source can be in the form of a flat-file or model-to-model import.
When the import data source is a flat-file: In this scenario, admins will be able to edit the file and change the file options of an import. All the starred options can be changed in the import data source of production environment.
When the import data source is a saved view: In this scenario, admins can change the import data source from one saved view to another saved view directly in the production environment.
File options of import data source can be changed directly in the production environment.
Saved views of import data source can be changed directly in the production environment.
Admins of the prod environment can reorder the positioning of import data sources directly in the production environment.
Imports will fail if the import data source is not structurally the same.
Again, it is repetitive, meaning whatever you are doing in dev has to be done in test and prod separately.
III - Both imports and import data sources marked as production data
This scenario is the combination of scenario 1 and scenario 2 described above. This scenario gives more control to the admin users of the production environment. For example, if some of the parameters of the source file, like text encoding, column separators, delimiters, etc. have changed along with the column headers, admins can load the updated file directly and change the file options. After this, they can go to the imports and correct the mappings. This also applies when the source data comes from any saved view.
Greater control with production admins and better position to be in than the first two scenarios.
Don’t have to wait for the development team to push the change.
Both imports and import data sources marked as production data can be reordered.
1. Changes go untested and unchecked directly in the production environment.
IV- Both imports and import data sources marked as non-production data
This is the default selection of any model. All the imports and import data sources are non-production data. Most of the use cases follow this approach and do not change the settings.
More control over how the data comes into the model.
It goes through multiple rounds of testing before making its way to the production environment.
Every change has to come from the development environment (blessing in disguise).
The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.