Configuration Portability
Configuration Portability enables you to copy selected configuration settings from one system to another system using a simple export and import mechanism.
Last updated
Configuration Portability enables you to copy selected configuration settings from one system to another system using a simple export and import mechanism.
Last updated
Configuration Portability enables you to:
Select the configuration settings you want to copy
Export the settings from the source system
Import them into the target system.
Further, you will also understand exactly:
How long each import will take
What manual changes you will still need to make (CMDB, Services, Service Actions, etc)
Configuration Portability, as a feature of ASM, allows you to move work packages from one system to another. Configuration Porting is not bi-directional. There can only ever be 1 source system.
While the process itself is actually simple, the underlying actions are complex and you may end up porting items you did not intend to port. For this reason, please review this section, and the following pages carefully to ensure you understand how Configuration Porting works before undertaking this task. It would be wise to see the assistance of Alemba for your first time. If you need to request support for these features, please contact Alemba Support
If you are a Cloud Customer, Config Port files can be created from your system, but the import must be done on the server. You will need Alemba Support to assist with this activity.
Create your export files and label them so that Support will know what order to bring them in. For example:
[Your Change#]-[File 1]-System Settings
[Your Change#]-[File 2]- Screens
[Your Change#]-[File 3]-Message Types
[Your Change#]-[File 4] - SSP Settings
An alternative to Configuration portability exists, please see:
Organizations often set up test systems when they implement major changes to an existing production system. The test system is analyzed to ensure that all changes have been applied correctly before updating the production environment. It is imperative for organizations to follow this procedure in order to reduce the likelihood of errors or failures when these changes are implemented on the production system.
ASM Systems are business-critical and require complex configuration and setup by administrators. As a result, it is typical to set up a test system for ASM Core, ensure the setup reflects the organization’s requirements, make changes if required, and then recreate the settings and data from the test system into the production system. Depending on the scale of an organization’s operations, this task can be time-consuming.
Configuration Portability enables you to copy selected configuration settings from one system to another system using a simple export and import mechanism. For on-premise customers, all this can be performed directly from the client application, which means that you do not need to have access to the ASM Core server to import and export configuration settings.
For example, if your organization has 3 environments then:
Once an organization has developed screens and configured settings on a development system (referred to as the source), the changes are imported and validated in the test system (referred to as the target ), and then the same source files are imported into the production system (referred to as the master target ).
For example, if your organization has 2 environments then:
Once an organization has developed screens and configured settings on a Test system (referred to as the source), the changes are exported as source files. The source files are imported into the production system (referred to as the master target ).
You can transfer Configurations - These are the administration settings pertaining to functional areas such as Service Desk, Workflow Management, Configuration Management and Service Level Management. The following data can be ported:
System Administration settings
Screens, forms, and message templates configured in ASM Designer
Data cannot be ported:
Call and Request Data
Person Records/Details
CMDB Items
AI Ops Rules
System default values (such as the default System Title defined in System Administration)
Templates (such as Workflow Templates and Call Templates) You must use the Workflow Port Utility
IPK Workflow Rules
CMDB Items and Services, Service Actions
Forum Management Rules
Activity Logs
SLM Agreements
Person records
Passwords and Email settings
System customizations, stored procedures, and integration settings. (These settings involve files which are not located within the database, such as SQL files, or HTML files.) They must be transferred manually between the source and the target systems.
Integration Platform settings
Workflow templates can be ported through the Workflow Management System Administration Menu ->Workflow Porting option.
Note the following requirements and recommendations.
You must only port from a single source system, that is, you cannot port from multiple systems into one target system. This means that you must use configuration portability in a serialized release environment. Refer to the Config Port Overview & Best Practices topic for more information.
Ensure the same version of the software is installed on both the source and target systems.
Back up your target system before porting data.
If your system has been customized, it is recommended Alemba® Professional Services assists you in porting data between systems.
Note the specific instructions for Config Portability with CSV Connectors (Upload option) below.
When Configuration Portability is used to make changes to a production environment, the production settings should not be changed manually. This is to prevent data mismatches and the potential for unexpected behavior.
Partition settings play a major role in determining how your ASM System functions. Importing to or exporting from a system that has partitioning enabled and subsequently disabled may result in random errors in the export and import process. In addition, partition names must be unique for the process to be successful.
Certain settings have specific rules applied to them when they are imported into the target system. The table below lists the rules for such options.
| Option or Setting to be Imported | Import Condition / Rule |
|---|---|
IPK and Workflow Management Groups | The recipient analyst and partition settings must match in the source and target systems. |
Stored Procedures | Only the settings for stored procedures are imported, not the stored procedures themselves. |
IPK Management Security Role | The Screen Sets tab appears on the IPK Management Security Role window when IPK statuses and streams are not enabled. If a call screen set does not exist on the target system, the corresponding role is created but will not have the screens linked to it. This action will be recorded in the import log. |
Call, Customer Survey, Request and Task Screen Sets | To export and import screens and data schema, the appropriate screen sets must be selected under the Screens, Forms and/or Message Templates tabs. This will process all screens for that screen set. Selecting the screen sets in the IPK Management or Workflow Management tabs will import the screen set names and all related screen sets parameters, fields, etc. As the config port has to factor in all of the relationships between all of the entities involved, what this setting exports is the following: 1. All of the Request Screen Sets 2. All of the custom extension fields associated with the Request Screen Sets 3. All of the screens/message templates for each of the selected Screen Sets (including their layout, rules, etc) Alternatively, you may select individual screens from Screens – Individual. If you need to only move a few screens, select the Screens – Individual tab, and add the single screen(s) that you wish to port. The Config Port Export will then export information regarding the screen, the Screen Set that it belongs to, and any extension fields that are associated with that screen set. When the file is imported, all of this information is compared to the destination system and, if that system does not have one or more entities in that port, they are created. |
Knowledge screens | When knowledge screens are copied, Knowledge Entry Types and Knowledge Base types are also copied because they are dependent settings. |
Data Transfer Steps
The data transfer between two systems is a two-step process. The data must first be exported from the source system (for example, the development environment), and then imported into the target system (for example, the test or pre-production environment) or the master target system (for example, the production environment).
Export Data from Source System: Begin by exporting data from your development or current live system. This will include all necessary configurations, data schema, and entries needed to replicate or update the target system.
Import Data into Target System: The exported data is then imported into the target or master target system, such as your test, pre-production, or production environment.
Matching Mechanism
Global Unique Identifier (GUID): ASM Core utilizes GUIDs as a key to match database entries across systems. This ensures that even renamed fields are correctly recognized and matched during the import process. Different GUIDs indicate distinct items.
Two items with different GUIDs are identified as different items.
Custom Schema Files
For additional customizations, schema files can be placed in the Config directory. These files are version-specific and should be handled by experienced developers only.
During the import, several rules ensure data integrity and prevent conflicts:
Matching Items: Items without a GUID in the target that match the entity and partition of an item in the source are considered the same and updated with the GUID from the source.
New Values: Active values in the source not found in the target are created in the target.
Workflow Groups: Missing workflow groups in the target, such as Finance, are added.
Existing Names: Items can be inserted into the target system even if they share names with existing items.
Retained Values: Values existing in the target but not in the source are kept.
Deleted Values: Deleted values in the source are imported into the target as deleted unless active in the source; then, they're marked active.
Name and Status Synchronization: Imported items retain their source's names and statuses unless a discrepancy is found, in which case, the target's item is updated accordingly.
Name Matching and Whitespace Rules: Names are matched disregarding the case. Unmatched whitespace in names is intelligently handled, ensuring accurate matches without duplications.
This framework ensures a smooth and consistent transfer of configurations and data between systems, maintaining integrity and functionality across different environments.
Before exporting the production database to the development system, it is recommended that you first run the Config Portability GUID Assignment.scp via the server console to allocate unique identifiers (GUIDs) to any fields missing a GUID so the system properties remain synchronized when using Configuration Portability.
When you import items into the target system, their relative order hierarchy matches that of their source items. Here's how it works:
Inserting New Items: If a new item is added to the target system, it is placed below any item that shares the same order hierarchy.
Reordering Items: If you reorder an item in the target system, it maintains its position below any item with an identical order hierarchy.
Unmatched Target Items: The order of items in the target system without corresponding source items remains unchanged.
This ensures a consistent and predictable organization of items following an import.\
If you are using the CSV connector, you are porting the settings, but not the CSV file itself. Therefore, when porting the settings for a CSV connector, take the following steps:
Export the CSV Connector Settings from the source system.
Import the CSV Connector Settings into the target system.
Open the CSV Connector Source in the target system.
Upload the CSV File.
Click to confirm that the target connector source system is working as expected.
Configure/review the Integration Resource, etc. as usual.
You can export individual Screens, Forms and Message Templates.
Only designable screens will be available for export. Non designer screens will have to be copied manually. The scope of the data is limited to the selected screen and directly related items.
The imported/exported information for these items is only displayed on the By Selection tab. These items are only a subset of the screen designer options, so are not relevant By Section.
Parent screen sets which are not found in the target systems will have some values set to defaults. These items include IMAGE_REF and REPORT_REF. To keep this information consistent, it is recommended to select the CMDB Item Types option as well.
Screen Set including parents
Security Profiles
Security Profile Access
Partitions
Extension Fields
When porting screens that reference extension fields on another screen, both screens need to be exported from the source system and then imported into the target system twice using the same configuration file. This ensures that any rules or filters that reference fields across screens are correctly linked and functional in the target system.
Export both screens from the source system.
Import the configuration file into the target system to create the fields.
Import the configuration file again to link the fields to their respective rules.
Screen Sets Selection: Selecting a screen set exports its entire contents. Individual selections within that set are ignored.
Linked Fields: Fields linked from one screen set to another are imported and linked correctly, but not back to the original screen if it exists.
Linked Extension Fields: Extension fields linked to another extension field are ignored during import.
Import Restrictions: Screens can only be imported if they were exported as individual items. It is not possible to selectively import screens from a broader set that was exported.
This process ensures that the imported screens work as expected with all rules and references intact, avoiding functionality issues in the target system.
| Case | Description |
|---|---|
Selecting an entire screen set and individual options | If a user selects a screen set under the Screens, Forms, and/or Message Templates tab, any individual Screens, Forms, and/or Message Templates selected for that screen set will be ignored. This is because the screen set and its associated types are already marked for export. |
Linked Fields on Individual Screens | If there are fields linked to a screen set from another screen set, these fields will be imported and linked to the screen. They will not be linked to the original screen, even if it exists. |
Linked Extension Field of another Extension field | These fields will be ignored and the field definition will be left untouched in the source html |
Importing Individual Screens | Screens will only be available for import if they were exported as individual screens. You cannot export Screens -> Call and then import only selected screen sets. |
