Transport system
This section describes the concept and use of the transport system. This system is also known as the Changeset Import. It provides procedural steps and best practice recommendations from Omada.
Some parts of this page are only relevant for the on-premises version of Omada Identity. They start with an on-prem badge. The rest of the sections are relevant for both cloud and on-prem customers.
Changesets are saved as XML-files. If you are familiar with XML files, you can inspect the content of a changeset file and change them if you need to.
The purpose of the transport system is to move all configuration changes made and approved in the development and test environment over to the quality assurance and production environment.
All the configuration changes are logged and collected while you work in the configuration/development environment. Once you have completed the changes to the configuration that you required, you must transfer these changes to the test, quality assurance and production environment.
Use logging to log configuration changes and group them in a changeset. You can then export this changeset to a file, which you can import into a target system.
You can export the changeset to an XML file. After you have prepared the XML file, you can import it into a target system. An import of a changeset file can be done instead of making all the changes included in the changeset file manually.
The import of a single change can fail if the change relies on the presence of data that is not present in the target system, for example, if a change states that a data object should refer to a specific user in a specific reference property, and that the user is not present in the target system, the import fails. Import errors are reported to the importing user.
Before you make any changes, the best practice is to run the import of the changeset files in test mode. Test mode does not make any changes to the database but allows you to discover possible errors without causing any errors to system configuration.
When you import a changeset, you can set up the system to log the result of each imported change to a file. Each imported change also generates a new change, if you have enabled logging into the target system. Customer and master settings dictate whether changes to the master data are logged. It is described below on this page, especially in sections Logging of configuration changes and Logging of configuration changes.
on-prem Use a command-line utility to run an import. This utility also supports automatic deployment and scheduling. For more information, contact your Omada representative.
Prerequisites
There are several issues to consider when you plan your configuration changes strategy.
To perform changes to the configuration and to create changesets, you must be a member of the Administrators User Group.
on-prem It depends on you where you prefer to store the changeset xml file. Below you'll find an example that you can follow:
- Create a folder on a Windows fileserver and share it as, for example, Omada Identity Transports.
- Ensure that the appropriate resources have access to the folder (developers, application consultants, configuration manager). Consult with your Active Directory system administrator to ensure the proper permissions and setup.
- Make sure that all changesets are downloaded to this folder as it makes it easier to support deployment.
Binary code
The transport system does not cover binary code, such as code assemblies and other .Net assemblies. You must move such components between systems manually.
Changes not logged
The transport system does not log these changes:
- Process instances
- Master settings
- Read info for data objects
- Log data in general: code method log, email log, system log, object log
- Customer settings
- Files
Running processes and logging changes
An import of a changeset can impact processes that are already running.
When a changeset contains changes to a process template, these changes can impact processes that are already running. This is not different from when you change something manually. You must consider the possible impacts when you plan your transport process.
Running processes have their own set of process-specific data including:
- The process object itself
- Activities
- Overridden form field states
- Transitions
- Control elements
- Graph layout
Processes also rely on certain global data which include:
- The target data object type
- The properties used on the target data object type
- Event definitions
If a changeset contains changes to the global data, the running process instances are affected. To avoid affecting running processes, do one of the following:
- Ensure that all running processes are completed before changing the process template.
- Do not change or delete properties and/or remove properties from the data object type. Also, do not change or delete event definitions used by the process template.
Activating the transport system
Omada recommends that your first activity on a newly installed configuration/development system is to activate the Transport system, so that configuration changes are logged.
To ensure consistency across all systems in the system landscape, Omada recommends that you only activate logging of configuration changes in the configuration/development system.
Logging of configuration changes is not enabled by default. You must enable this setting under Customer Settings.
Logging of configuration changes
The transport system includes a logging functionality where you can log changes to master data and data objects.
You can specify to log changes by enabling the customer setting called Enable configuration logging.
This setting should be set to True in a configuration/development environment and to False in the test/quality assurance/production environments.
on-prem After enabling that setting, do the following:
-
Restart the system’s Internet Information Server (IIS) on the server that hosts the web application and close all browser windows. Make sure there is no activity on the web server before you run IISReset.
-
After the IISReset has been completed, open Omada Identity again. The active changeset is now displayed in the top menu to the left of the search icon. By default, the active changeset is set to None.
-
In the top menu, click the blue Active Changeset link to open the Choose changeset dialog box. You can now use the transport system.
When you create changes to the configuration and/or Master Data after configuration change logging is activated, the system logs all changes to configuration and master data, even when you do not select a changeset.
Omada recommends that you always create a new changeset, and never leave it as None. After you have created a changeset and selected it as the active one, the changeset information in the top menu bar changes its color to black and displays the name of the selected changeset.
The logging mechanism always ignores changes made to process instances. The changeset functionality groups change together for easier management.
If you always want to have an active changeset when you make changes, you can add the customer setting RequireChangeSet to your system. You must add this customer setting to your system manually.
For information about how to add non-default customer settings, refer to the Configuration guide.
Proceed to the Changesets section to learn how to use and import changesets.