Global Exports/Imports

As described in previous chapters there are exports for parts of the configuration, like domain definition or selected parameters. If the need to transfer configuration between environments appears or when saving a copy of the current configuration is needed - global exports are most helpful. In the Hyperon Module, there are two kinds of export: Superpack and Snapshot.

Snapshot is a file containing full parametrization from application or only parts of parametrization accordingly to set requirements, it is an alternative for Superpack file. What is the most important about snapshot export: it is less complicated than building a Superpack (batch). User only have to decide from which profile (or profiles) he would like to make an export and basically, thats it. Next step is to decide if all elements in profile should be exported, one may decide to export only selected functions and parameters, or not export functions and parameters at all. Furthermore SNAPSHOT will generate zip file, in which parameterization is described by tree structure, user may check what is within every region and version just by going through folders which are simulating tree structure.

To check xml file from snapshot open snapshot.zip (downloaded file) and go to @domains, file with selected profile name and subfolder @def there you should find xml file named after profile name (profile_name.xml). This xml-file is the same xml-file you can export from Domain Configuration.

Batch/Superpack export allows to:

• Save XML - allows you to save configuration of Superpack export and reuse it later, just by using LoadXML
• Load XML - loads XML file from given path with definition of Superpack export
• Show XML - displays XML file with configuration of Superpack export
• Create pack - creates pack with XML file (Superpack definition) and all exported data and, then allows to download zip file.
  

Batch/Superpack export - rules

There are few simple rules you should follow while creating Superpack:

-

‍

Check export environment and target environment :

• to what profile do you want import data?
• to what region and version do you want import data?
• do you need to create profile, region or version?
• are all data (that you want to export) assigned to one version of every region or are they distributed between different versions of one region

- every step available while creating Superpack might be used multiple times

- order of steps defined for export, will be kept during import process

- import of Superpack overwrites configuration in target environment - if any changes were found, if no changes were made - step is skipped, if any element is in superpack zip and not in target environment - then such element is created.

- never create or import Superpack if user have an open session, first publish changes or discard them, then create a batch

Batch/Superpack export - steps

Every step might produce Business Error or System error. Business errors are those which are caused by invalid configuration within Hyperon while import on target environment - examples of those errors are listed in every step description. System Error are unexpected exceptions in application code.

To control how import reacts on any of those errors in steps are attributes :

• OnSystemError
• OnBusinessError

Depending on settings import might stop or continue when such problem occurs. If that happens, even if import did not stop after error, information about error will be displayed on report sheet, when import ends.

Superpack export is build step by step. User have to design export process and import process, what includes :

• preparation of source environment for export
• specifying data for export
• specifying data to delete
• preparation of target environment for import Those are superpack capabilities which might be used when appropriate steps are added. Nevertheless, not always full potential of Superpack is needed.

What are those steps, then? Steps are settings of export. Since the is no scheme of export, every Superpack is customised plan of data export.

Superpack steps have attributes. They describe, in detail, how each step should be executed. Below is a screen of attributes for one of available steps :

When by the name of attribute symbol of asterisk is visible (1) - then it is obligatory to set value for that attribute. When field for value is greyed out (2) then value will be set automatically. There are attributes with default value (4), those are not marked with asterisk or grayed out. That default value might be overwritten by setting value for such attribute. For selected attributes there are additional guidelines, visible after clicking on question mark icon (3).

Property

It is intended to characterise value, which will be declared during import. This step also provides validation while value is given. When step Property is added to Superpack, it also needs to be linked in other steps. This step by itself have no influence on import or export. It is setup for other attributes values (in other steps).

Attributes:

• code - name of Property which will be used every time to execute set property
• label - will be displayed, when pack import is started, meaningful name, helps identify property during import
• type - value type expected in validation process, available are (string, number, date)
• format - regex expression which control if entered value is correct
• formatValidationMsg - message, that will be displayed, if value doesn't match set regex expression in field 'format'
• min - minimal value, only for date and number type
• max - maximal value, only for date and number type
• propertyValue - default value displayed as suggested value, for every step where property is in use, during import

If Property step is in Superpack export configuration, then while import popup will show:

Settings in example (numbers in brackets are numbers from pictures):

• code (3) : selectedVersion
• label (1) : select version to set :
• type: Number
• format: \d
• formatValidationMsg (5) : singleCharacter
• min: 1
• max: 3
• propertyValue (2): 1

If user tries to insert incorrect value, then appropriate message will occur next to wrongly filled property.

In this case maximum value was set: 20 (4), but regex expression allows only for single character value.

SetVersion

It sets version on target environment

Attributes:

• region - region from which version will be selected
• version - version which must be set as visible version before executing other steps
• onBusinessError
• onSystemError

Possible Business Errors:

• Region does not exist in set Profile on target environment
• Version does not exist in set Profile on target environment

SetProfile

It sets profile on target environment

Attributes:

• profile - profile name, which must be set, before executing next steps of Superpack import. Selected profile should be the one, on which you want to upload changes.
• onBusinessError
• onSystemError

Possible Business Errors:

• Profile does not exist on target environment

SetOnSystemErrorOnPack‍

It sets new default value on OnSystemError attribute for all steps added to Superpack.

Attributes:

• defaultValue - default value to set for all following steps of Superpack import, describing what action should be taken, if any system error occurs, while setting continue wouldn't block import process.
• onSystemError

SetOnBusinessErrorOnPack

It sets new default value on OnBusinessError attribute for all steps added to Superpack

Attributes:

• defaultValue - default value to set for all following steps of Superpack import, describing what action should be taken, if any business error occurs, while setting continue wouldn't block import process.
• onSystemError

ScheduleVersion

It adds selected version to Timeline

Attributes:

• region - region code from which version should be added to timeline (schedule)
• version - version code which should be added to timeline
• fromDate - start date from which selected version will be set as system version (read more in User Guide: Versioning > My view)
• onBusinessError
• onSystemError

Possible Business Errors:

• Region does not exist in set Profile on target environment
• Version does not exist in set Profile on target environment

RollBackSession- discards opened session on current user account (all changes from session are reverted to last published state)

There is a rule to never create or import Superpack if user have an open session.

Attributes:

• onBusinessError
• onSystemError
• description - added while rejecting all changes in current session, is visible to all users on sessions list

ResetVersions

It sets system versions (those active by settings in Timeline) as visible versions, resets versions on whole target environment (in every profile). On profiles, where are no regions or versions, this step will not cause any changes or errors.

Attributes:

• onSystemError

MultiLoadParams‍

It allows to transfer parameter between versions (only if parameter is assigned to region)

This step is divided into three sections: first are basic attributes, next are filter settings and last is multiload configuration table.

Attributes:

• files - name of .zip file including list of filtered elements (if no filter is defined all elements fitting to criterions are exported)
• region - to which region filtered parameters should be imported,
• versions - filled automatically when table (in the bottom of attribute section is filled)
• onBusinessError
• onSystemError
• Name - simple filter, allows to search through parameters by code (name) or part of code. If necessary you may use Full filter - read more in the end of this chapter
• Region - choose region from which export will be made (only regions from current - set as visible - profile are available)
• Add Versions - available when Region is chosen. When button is pressed, popup appears, where versions from selected region are listed. You may choose one or more versions. All selected versions will be visible in table in the third section as Versions from. By default Version to is version with the same code as Version from, but those may be changed.

Possible Business Errors:

• Profile does not exist on target environment
• Region does not exist in set Profile on target environment
• Version does not exist in set Profile on target environment

MultiLoadFunctions

It allows to transfer function between versions (only if function is assigned to region)

This step is divided into three sections (just like MultiLoadParams): first are basic attributes, next is filter settings and last is multiload configuration table.

Attributes:

• files - name of .zip file including list of filtered elements (if no filter is defined all elements fitting to criterions are exported)
• region - to which region, filtered functions, should be imported,
• versions - filled automatically when table (in the bottom of attribute section is filled)
• onBusinessError
• onSystemError
• Name - simple filter, allows to search through functions by name or part of name. If necessary you may use Full filter - read more in the end of this chapter
• Region - choose region from which export will be made (only regions from current - set as visible - profile are available)
• Add Versions - available when Region is chosen. When button is pressed, popup appears, where versions from selected region are listed. You may choose one or more versions. All selected versions will be visible in table in the third section as Versions from. By default Version to is version with the same code as Version from, but those may be changed.

Possible Business Errors:

• Profile does not exist on target environment
• Region does not exist in set Profile on target environment
• Version does not exist in set Profile on target environment

MultiLoadDomain

It allows to transfer domain elements between versions (only if domain element have business role : PRODUCT and is assigned to region)

This step is divided in two sections : first are basic attributes, second is multiload configuration table.

Attributes:

• removeNotInFile - if 'true' then every element assign to selected version (on source environment) is exported to target environment, and all elements on target environment which are assign to 'version to' and where not included in batch from source version will be deleted. If false all changes from source version are added to target version. By default: false.
• files - name of .zip file including list of filtered elements (if no filter is defined all elements fitting to criterions are exported)
• region - to which region domain elements should be imported,
• versions - to which version domain elements should be imported,
• onBusinessError
• onSystemError
• Region - choose region from which export will be made (only regions from current - set as visible - profile are available)
• Add Versions - available when Region is chosen. When button is pressed, popup appears, where versions from selected region are listed. You may choose one or more versions. All selected versions will be visible in table in the third section as Versions from. By default Version to is version with the same code as Version from, but those may be changed.

Possible Business Errors:

• Profile does not exist on target environment
• Region does not exist in set Profile on target environment
• Version does not exist in set Profile on target environment
• incorrect data type defined in domain
• incorrect value type, not consistent with defined data type for attribute

LoadUsers

It loads list of users (all user information with: login and password) with roles assigned, from export environment. This step does not include information about set roles, only names of those roles. To export roles and grants assigned to them select step LoadRolesAndRights.

Attributes:

• file - name of .zip file including list of users
• onBusinessError
• onSystemError

Possible Business Errors:

• user role does not exist on target environment
• incorrect user status

LoadTags

It loads all tags from export environment but does not contain list of parameters or functions with exported tags. To export parameters and functions information, like: tags assigned, add steps LoadParameters / LoadFunctions.

Attributes:

• file - name of .zip file including list of tags
• onBusinessError
• onSystemError

LoadSandbox / LoadContext‍

It creates xml file with full configuration of context from selected Profile.

Attributes:

• file - name of .zip file including list of tags
• removeNotInFile - if true removes all Context elements not included in file, if false all elements from file are added to current state on target environment. By default: false.
• onBusinessError
• onSystemError

Possible Business Errors:

• incorrect type
• incorrect GMO Persistent value

LoadRolesAndRights / LoadRolesAndGrants

It loads all roles and grants from export environment

Attributes:

• file - name of .zip file including list of roles and grants
• onBusinessError
• onSystemError

LoadRegions

It loads all regions from export environment only for selected profile

Attributes:

• file - name of .zip file including list of regions, versions and schedule
• dontOverrideRegions - If 'true' all regions on target environment will be overwritten by regions from source environment. It means that only regions from .zip file will exist on target environment after import. If false, all regions from .zip file will be added to those already existing on target environment. By default: false.
• dontOverrideVersions - If 'true' all versions on target environment will be overwritten by regions from source environment. It means that only versions from .zip file will exist on target environment after import. If false, all versions from .zip file will be added to those already existing on target environment. By default: false.
• onBusinessError
• onSystemError
• sourceProfile - profile on source environment (export environment) from which all regions will be packed to zip file‍

LoadParams

It loads all parameters, which in moment of export are visible:

• assigned to version of region set as visible, in My View, in moment of export
• all global parameters - not assigned to any region

Attributes:

• file - name of .zip file including .xlsx file with parameters
• onBusinessError
• onSystemError
• Name - simple filter, allows to search through parameters by code (name) or part of code. If necessary you may use Full filter - read more in the end of this chapter

Possible Business Errors:

• non existing tag assigned
• assigned to non existing region
• assigned to non existing version
• parent does not exist on target environment (only if parameter is an alias)

LoadFunctions

It loads all functions which in moment of export are visible (assigned to version of region set as visible, in Timeline, in moment of export and all global functions - not assigned to any region)

Attributes:

• file -name of .zip file including .xlsx file and .js files with functions
• onBusinessError
• onSystemError
• Name - simple filter, allows to search through functions by name or part of name. If necessary you may use Full filter - read more in the end of this chapter

Possible Business Errors:

• non existing tag assigned
• assigned to non existing region
• assigned to non existing version

LoadDomain‍

It loads domain elements which in moment of export is visible (assigned to version of region set as visible, in Timeline, in moment of export and all global elements of domain - not assigned to any region)

Attributes:

• file - name of .zip file including list of domain elements from current view
• removeNotInFile - after import, on target environment current view, only elements from zip file will exist - everything, what was not included in export file, will be deleted. By default: false.
• onBusinessError
• onSystemError
• sourceProfile - profile on source environment from which export should be made

Possible Business Errors:

• assigned to non existing region
• assigned to non existing version

DeleteParams - allows to delete parameters from current view (assigned to version of region set as visible, in Timeline, in moment of export). Creates list of parameter codes (names) and exports it as txt file. That list is used to search through target environment, then elements from the list:

- will be deleted (if 'leftSelected' step is set: false) or

- will not be deleted (if 'leftSelected' step is set: true) but every element, not named in file, will be deleted.

This step is vulnerable to versioning. Before executing this step make sure both export environment and target environment are set on the right view.

Attributes:

• file - name of .zip file including list of filtered parameters from current view
• leftSelected - works similar to removeNotInFile, if 'true' all parameters from list, those matching filters, will be left and every other parameter from current view - deleted, if 'false' (by default) only selected parameters will be deleted.
• onBusinessError
• onSystemError
• Name - simple filter, allows to search through parameters by code (name) or part of code. If necessary you may use Full filter - read more in the end of this chapter

DeleteFunctions‍

It allows to delete parameters from current view (assigned to version of region set as visible, in Timeline, in moment of export). Creates list of parameter codes (names) and exports it as txt file. That list is used to search through target environment, then elements from the list:

• will be deleted (if 'leftSelected' step is set: false) or
• will not be deleted (if 'leftSelected' step is set: true) but every element, not named in file, will be deleted.

This step is vulnerable to versioning. Before executing this step make sure both export environment and target environment are set on the right view.

Attributes:

• file - name of .zip file including list of filtered functions from current view
• leftSelected - works similar to removeNotInFile, if 'true' all parameters from list, those matching filters, will be left and every other parameter from current view - deleted, if 'false' (by default) only selected parameters will be deleted.
• onBusinessError
• onSystemError
• Name - simple filter, allows to search through functions by name or part of name. If necessary you may use Full filter - read more in the end of this chapter.

CreateVersion

It creates a new version on target environment based on existing version from export environment. Creating new version does not influence 'visible version' settings but may change 'system version' settings in My View

Attributes:

• region - name of new region in which new version will be created (on target environment, in current profile)
• srcVersion - code of version (on source environment) which will be cloned as foundation of new version
• dstVersion - name of new version on target environment
• onBusinessError
• onSystemError

Possible Business Errors:

• Region with given code does not exist in set Profile on source environment
• Version with given code does not exist in set Profile on source environment (relates to srcVersion)
• Version with given code already exist in set Profile on target environment (relates to dstVersion)

CreateRegion

It creates a new region on target environment (on Profile set on target environment) and first version in that region - in Hyperon, region cannot exist without version. Creating region will not cause assigning any elements to new region. If exported elements are assigned to region named the same as new region, then Hyperon will interpret it as the same region.

Attributes:

• code - name of new region which will be created on target environment on current profile
• initialVersionCode - code of first version, which must be created since no Region may exist without Version.
• onBusinessError
• onSystemError

Possible Business Errors:

• region with given code already exist in set Profile on target environment

CreateProfile‍

It creates a new profile on target environment. Creating new profile will not cause setting it as visible profile on target environment.

Attributes:

• code - name of new profile which will be created on target environment
• onBusinessError
• onSystemError

Possible Business Errors:

• Profile with given name already exist on target environment

CommitSession

It causes publication of active session. That step may be used at the begging of export (to publish any changes in current user session) or at the end (as autocommit). Commit session may cause Business Error, if during publishing conflict with another user's session will appear. If that happens, Cohesion analysis will be necessary.

Attributes:

• onBusinessError
• onSystemError
• description - short information about changes included in published session. That information is available for every user on target environment in sessions list view.

Possible Business Errors:

• conflict during publishing - user needs to execute cohesion analysis

CheckNoActiveSession‍

It checks if on target environment, on current user profile is active (open) session. Returns set description if open session is found.

Attributes:

• message - information displayed on report sheet when open session is found on target environment.
• onBusinessError
• onSystemError

Possible Business Errors:

• Active session found

Full Filter

Basic filter allows to select those elements (functions or parameters) which name contains stated phrase. Not always that is a sufficient criterion. In Full Filter you may create additional conditions for your search. Including:

• Levels - (only for parameters) - names/codes of parameter levels (INs and OUTs), add as many as needed, every level must be selected from dropdown list (levels list might be scrolled) and add to filters by pressing + or - button, both of those buttons add filter.
• If filter is added by + button, then filter includes every element with added phrase.
• If filter is added by - button, then filter excludes every element with added phrase.
• Type - (only for functions) might be groovy or rhino - depending in which language functions where defined
• Tags - add as many as needed. Every tag must be selected from dropdown list and added to filters by pressing + button
• Region - add as many as needed. Every region must be selected from dropdown list and added to filters by pressing + button
• Modified by - login of user who last made changes, you may add as many as you need but remember to do it one by one

Additionally you may add time frame for last made (and published) modifications of the element:

• Modify from
• Modify to

Remember that search goes with logical conjunction. Which means that all filters must apply at once.‍

Batch export - order of steps‍

Suggested order :

Those two are not necessary if you know that there is no active session (on current user account) in the moment of import

1. CheckNoActiveSession
2. CommitSession or RollBackSession - depending on the expected result
3. SetOnSystemErrorOnPack - worth adding if you want default value be different than 'stop' (which is set by default even without this step)
4. SetOnBusinessErrorOnPack - worth adding if you want default value be different than 'stop' (which is set by default even without this step)
5. Property - should be added to export before the step relating to it
6. CreateProfile
7. SetProfile
8. LoadSandbox / LoadContext
9. LoadRegions
10. CreateRegion
11. CreateVersion
12. SetVersion or ResetVersions* - depending on the expected result
13. LoadTags*
14. LoadRolesAndRights / LoadRolesAndGrants*
15. LoadUsers*
16. DeleteParams
17. DeleteFunctions
18. LoadParams or MultiLoadParams - depending on the expected result
19. LoadFunctions or MultiLoadFunctions - depending on the expected result
20. LoadDomain or MultiLoadDomain - depending on the expected result
21. ScheduleVersion
22. CommitSession - if you want autocommit changes

Following steps don't need any settings on target environment (no chosen profile, region etc.):

• LoadRolesAndRights / LoadRolesAndGrants*
• LoadTags*
• LoadUsers*
• CommitSession*
• CheckNoActiveSession*
• RollBackSession*
• SetOnSystemErrorOnPack
• SetOnBusinessErrorOnPack
• Property
• ResetVersions*

* - steps global for the environment

It is safer way to export your data from one environment to another. User doesn't have to export all data, regarding structure, from Hyperon application.

To export snapshot click Tools and Snapshot export on main Toolbar, following view will appear:

As you may see in the picture there is a choice connected to creating a snapshot file. You may export data about Domain (definition, configuration, attributes, values), Functions, Parameters, Profiles and Tags but to avoid errors you should follow few rules. When you want to export Domain, you need to export Profiles as well because in Hyperon application every Domain Configuration is connected to profile and one can not exist without the other. To export Tags it is recommended to export all : Functions and Parameters. Because Tag is kind of a label, which supposed to make search easier, or allow to group you parameters. And if you only export Tags, not Parameters and Functions, you will have a label but in your snapshot there will be no elements with that label even if in profile from which you are exporting data were. If what you want is to export only functions and parameters you also need to export Profile if you want Regionazing and Versioning to work after importing snapshot.

Then you may chose your export settings. To create snapshot file first select source Profile (from which you would like to export data):

Next step is selecting types of objects for export: Domain, Functions, Parameters, Profile with or without Context and Tags. User may choose all or only few of them - as discussed earlier. For every one of those types there is a functionality that may be used:

1. From session - if selected: inside snapshot file user will have only elements influenced by changes in current session. Usually (if not selected) snapshot will consider structure already existing in application after users modifications even if they have not been published yet.
2. Filter by name - from all elements like for example parameters will select only those starting with given name. When as filter is typed : "group." then all parameters starting with "group." will be exported in file. To apply filter remember to click on plus button on the right side of the filter cell.
3. Remove elements not included in file - this action considers filters but may be applied even if filters are not defined.
4. With context - export Profile with context content.

Those functionalities have influence on data within snapshot file, so be aware which checkboxes are needed for the result you expect.

Snapshot Export - file

Here we are going to focus on how to read and edit snapshot file. As previously mentioned it is a zip file containing tree structured parameterization. Depending on what where the settings during export this file may look differently. Here we are going to look into a case of full parameterization export (including: Profile, Tags, Domain, Functions and Parameters) - where we can find domain elements, functions and parameters assign to regions and versions.

When export is made and file is saved (downloaded) user may see what is included in zip file, first layer is general division between Profile, Tags, Domain, Functions and Parameters:

The last file : config.json will be described in the end of this chapter.

Domain

Inside file @domain user will find files named by exported profiles, since Domain is assign to profile and cannot exist without it. Then, inside every of those files will find @conf and @def file which are equivalent of Domain Configuration and Domain Definition parameterization.

File @conf is structured in accordance with Domain Definition types, their Components and Business attributes. It is made analogically to navigation, which user can see on Domain Configuration screen, where he can create objects defined by types from Domain Definition.

File @def contains .xml file - the same which may be made in Domain Definition section by using "Export to xml" button.

If type is defined in Domain Definition but in Domain Configuration no element of that type was created then file for that type will not be included in @conf file. Nevertheless that type will be considered while creating @def file.

Profiles

Let's look into profiles. Inside file @profiles user will find files named after all selected profiles to export. In this case only one profile has been exported and that is profile GROUP. While going further user will find file @regions and context.def (if in export check 'with context' was selected). In @regions file are all regions created in structure. Inside every one of those is catalog @versions where user will find files containing definitions of versions inside selected region- number.ver where number = 1,2,3.. is name of version given by system. What's more in region named file user may check: schedule schedule_regionName.csv (which is responsible for when which version is active) and region definition regionName.info

Functions and Parameters

Structure for parameters and functions is similar only difference is in how function and parameters are defined. for every exported parameter is defined by two depending files : \*.mat and \*.def. First one describes the matrix in parameter and second one parameter definition. Definition of functions is stacked into one \*.js file containing information about function arguments and function code.

Path to parameter files may look like on the picture below:

Path depends from the name (code) of parameter/function and region to which selected parameter is ascribed.

For example in that snapshot file under number 1 is parameter that have no region ascribed (it is a global parameter, that is why it can be find under @global file ) named: group.deviationPerSelectedRider every ' . ' (dot) in name of the element (parameter or function) is interpreted as another file in the structure. If we want to know full name of the second parameter (2) we would have to take every folder name, starting with first folder inside @global: 'group' then add ' . ' (since every dot means going one folder further), next is 'business' another ' . ' and 'activity', so full name of this parameter is : group.business.activity

If instead of going into @global user will check @profiles he would find all the parameters that are ascribed to regions and versions (element that is ascribed to region is always ascribed to version).

What if function is ascribed to region? Then file structure will change, because there will be few additional catalogues (for region and version to which element was added).

If we have functions ascribed to region in file structure it will be placed inside: profile named catalogue, then ascribed to region catalogue, next to version catalogue. In structure of snapshot .zip file in @functions catalogue, that kind of function is placed in @profiles file then inside profileNamed catalogue (1), @region (2) and inside that in regionNamed file, further inside is versionNumber catalogue and then file structure of function like: group.distribution.normal.groovy where functionName.groovy may also be functionName.rhino (depending on the language applied in function definition).

Tags

When it goes to @tags: inside this file there always are two other ones, @basic and @access, in both of those user will find files like tagName.tag containing selected Tag definition. Tags are divided between those catalogues because some of those were created with access control and those will be in file @access.

config.json file

On config.json file influence have only three actions, two may be find on the Snapshot export screen:

Those are responsible for filtering elements during export and import, narrowing or expanding the range of imported changes. The third one may be find in the config.json file: searchWithinParameterMatrix. This action is only used by import if 'Remove elements not included in snapshot' was selected during export, or set on 'true' in config.json file . This action, while set on: 'true' verifies if element, which should be deleted, is called in parametr matrix (is used in parameter matrix), but by default it is set on : 'false'. What means that if user doesn't apply any changes in config.json file parameters matrix won't be checked.

For example, if export is configured like:

Then config.json file:

{

"exportTime":"2019-03-08 14:14",

"profiles":["GROUP"],

"functions":{"nameStartsWith":["group.util"],
    "removeNotInSnapshot":false},
    
"parameters":{"nameStartsWith":["group.product"],
    "removeNotInSnapshot":true},
"searchWithinParameterMatrix":false

}

Generally we can say that config.json file is divided into four sections:

Export information

"exportTime":"2019-03-08 14:14"
"searchWithinParameterMatrix":false

Profile settings

"profiles":"GROUP"

Function export/import configuration

"functions":{"nameStartsWith":["group.util"],
    "removeNotInSnapshot":false}

Parameter export/import configuration

"parameters":{"nameStartsWith":["group.product"],
    "removeNotInSnapshot":true}

It is not advised to change filters in config.json file because it may cause errors during import. Filters are defined for functions and parameters like: "nameStartsWith":["filter\_1","filter\_2"].

Editing config.json file is advised when user wants to change settings of removeNotInSnapshot (for parameter or function) and searchWithinParameterMatrix (verify usages of element prepared for deletion) which is disabled by default.

Special cases:

1. After export user deletes filters from config.json file, removeNotInSnapshot is set on 'true' and starts import. Then, while import, filters are not applied and everything what is not in snapshot file will be deleted.
2. If in parameterization exist function and parameter with the same name ('A'), then searching in parameter matrix won't be able to see the difference between cascade call to function named 'A' and parameter named 'A'. (In nearest future giving the same name to parameter and function will not be possible, but for now it still is possible.)
   

When you want to import file just select Import snapshot from toolbar Tools/Import snapshot.

Then window will popup and one will have to select snapshot zip file for import.

Here user may chose from two non-obligatory options:

• Publish session after import -
• Should consider configuration file during import : config.json - which carries information about used filters and if elements are not included in file, they should be removed from configuration.

If snapshot export screen was set like on the picture below:

Then config.json file:

{

"exportTime":"2019-03-08 14:14",

"profiles":["GROUP"],

"searchWithinParameterMatrix":false,

"functions":{"nameStartsWith":["group.util"],
    "removeNotInSnapshot":false},
    
"parameters":{"nameStartsWith":["group.product"],
    "removeNotInSnapshot":true}

}

Since we applied filter on functions, now only those which name starts with : "group.util" will be included in SNAPSHOT file. Because second checkbox was not selected none functions should be deleted while import.

When it goes to parameters only those with name starting with: "group.product" should be included in snapshot file. What's more since that filter was set in export configuration and checkbox "Remove elements not included in snapshot" was selected while import only parameters which name starts with words "group.product" will be considered while deleting those not in exported file.

For example:

If in environment (A), from which export is made, following functions exist:

• group.util.offer.calculateBenefit
• authentication.user.getLeadingRole
• group.util.offer.calculateSumLimit

Only group.util.offer.calculateBenefit and group.util.offer.calculateSumLimit will be packed in snapshot.

If in environment, from which export is made, following parameters exist:

• group.product.availability
• group.business.activity
• group.rider.tolerance

Then only group.product.availability is accurate by applied filter.

Then in Snapshot:

Let's assume that on the second environment (B), where import is made, exist functions:

• group.distribution.gamma
• group.product.calculate.commissionToPay

and parameters:

• authentication.user.definition
• group.dictionary.pkd
• group.product.default

After import: functions from environment B will still be there and those in snapshot file will add to the structure. But when it comes to parameters, after import, all those in environment B which name does start with "group.product" and are not in file, will be deleted (like: group.product.default). Because group.dictionary.pkd and group.product.availability do not start with "group.product", while import, their presence in file is not even checked. In other words, filter is applied not only when exporting structure but also while import, that being said : import may change only those elements which meet the requirements of the filter (if filter is applied).

After Import state of environment B:

Snapshot Import - report

Result window will pop up, when process is finished - this import summary is called Import report.

Status

Informs if import went without problems

• OK -if changes were correctly applied

• SKIPPED - file were skipped because no changes were detected in comparison to parametrization on the environment

• ERROR - import of selected file was not possible (for more information click on eye icon). Such situation may occur when function/parameter file is not correctly formed. Import will not check body of the function but it will check if a file is properly formatted.

• WARNING

Warning status may show this icon may show in few cases (in every one of those cases user may click on eye icon to check with which one user is dealing with):

• for element that should be deleted by import but is currently in use in parameterization
• if parameter folder contains files with wrong file extension (expected are: *.def and *.mat), parameter is associated with more then two obligatory files (or one obligatory file for alias)
• if function was imported but there were some issues to report. Example situation: there was more than one file associated with the function. Function was successfully imported from one of the files. Import from the other files was not done because either the function was already imported or there were some processing errors or simply if function folder contains files with wrong file extension
• if tags folder contains files with incorrect extension or unexpected files

Element

What kind of element was checked during import, influenced by changes

Imported files

Number of files imported from snapshot file. All elements of selected type included in snapshot export file.

Deleted

How many files were deleted during import (that is the result of config.json file)

Errors

Number of errors that occurred

Skipped

How many files were skipped, happens when element is contained in snapshot file but it is exactly the same as in environment on which import is made.

Unpublished

Only if option autocommit was selected

Message

Clicking on icon Eye icon opens information window, where user may check message for every element influenced by import.