Profiles are usually developed in the test or development environment and are transported to the production environment after thorough testing. We provide the following methods to transport profiles.

Automated transport of profiles using the Transport Manager.
Manual transport (export and import) of profiles. The respective systems should have the same release version. Importing profiles from a previous release version is possible, but all settings that do not exist in both versions are lost. Subsequent testing is strongly recommended.
Automated export of profiles with class ExportProfiles.

There are separate mechanisms for the explicit backup of profiles.

Guidelines for creating profiles in the test system for transporting to the productive system

The idea of a test system is that you create and test profiles (apart from general tests of all kinds) in a 'harmless' environment and then, once you have perfected them, transport them to the productive system. The harmlessness lies in the fact that one will usually not test with productive (partner) systems and databases and is therefore not in danger of corrupting important data through the necessary tests. But the use of non-productive systems creates pitfalls when transferring profiles. Following, therefore, are a few tips on how to avoid them. Important note: In principle, we only recommend transports from the test system to the productive system and not the other way around. This is to prevent test data from ending up in the productive system. If productive data ends up in the test system, that's not great either, but it's less dramatic.

The problem-free use of profiles from another system requires that no server addresses, names, passwords, etc. are hardwired in these profiles. Instead, the specific partner access data, for example, should be defined in partner channels. Furthermore, you can also use so-called system constants, which are defined in the system environment. These methods allow you to achieve that an unchanged profile connects to the test system of your partner on your test system, for example, but after having been transported to your productive system, it will connect to the productive system of your partner. When developing a profile, defined system constants can usually be selected easily in relevant fields.

Partner channels on target system

If you use partner channels in profiles, you have to transfer them separately. Either "manually" or with the corresponding function in the Transport Manager. In both cases, you also have to adjust their values after the transfer (productive access data). Note: If you create a channel with the same name for your profile on the target system (instead of transferring it), this is not sufficient. Channels are linked to profiles via their ID and a new channel gets a new ID. You would then have to manually assign the channel again in the profile. Note: The values for additional IDs in the partner channels refer to the central additional IDs (see details there). If such a central additional ID is not defined in the target system, a corresponding additional ID cannot be created successfully in the channel (when manually exporting/importing a partner and its channels). You will then find an additional ID in the channel, but without a name. If you manually create a central additional ID with the same ID on the target system (not the same name!), the name in the additional ID of the channel will be updated respectively. Alternatively, to work around this problem, you can use the Transport Manager.

System constants on target system

When transporting profiles, system constants are not transferred to the target system. They must therefore be created there again or transferred "manually" or by using the Transport Manager. In both cases, you also have to adjust their values after the transfer (productive access data).

Example: As you probably know, databases are handled via aliases, behind which the actual access data is hidden. You could set up an alias on the test system in such a way that it points to the test database and that same alias on the productive system could point to the productive database. However, this is not the cleanest solution, since there could be a mix-up, because the databases can no longer be distinguished by their alias names. It is better to use system constants in your profiles instead of directly working with aliases. Use a system constant XYZ_DB, for example, whose value (the alias name) is xyz_t on the test system (points to the test database) and xyz_p on the productive system (points to the productive database).

Manual export and import of profiles

You can export and import a profile together with the corresponding configuration files, macros (can be ignored, see there) and test files as a package (.pak). Configuration files are only taken into account if their file path starts with ./conf and has been entered as a fixed value. If the path of a configuration file uses variables, the file will not be taken into account. Replacement values for functions will also be part of export packages.

Export

See also section "Context Menu Profiles". When exporting a profile, you can choose between the following options.

(standard, importable) Profile and all configuration files as package file (.pak). Note: Configuration files in any subfolder named _exclude_ are not included in .pak files. This can be used to make sure that important files do not 'wander' from the test to the productive system, for example. Example:./conf/sub1/_exclude_/test.txt
(deprecated, importable) Only the profile without configuration files (.obj).
(importable) XML file (.xml). Can also be used for a profile comparison (diff).
(not importable) Gefeg.FX file (.xml). Only creates a tree structure.
(not importable) RESTful API Modeling Language (RAML). Only creates a tree structure. Note: Only works for profiles with event-driven Input Agent "HTTP" and set checkbox "HTTP interface or REST web service". In addition, the profile needs to have a source structure with a root node.

Import

See also section "Context Menu Profiles". Importing a profile will open another dialogue. Here you can import the formats ".pak" and ".obj", please always use format ".pak".

Following the possible settings:

(1) Upload file: You can either drag an export file directly into the field or use the button to search for one in the directory structure.

(2) Import as new profile: A new profile is created with this option. and all settings of the export file are applied.

(3) Overwrite selected profile, name, group & ID are retained: The selected profile (in the profile overview) will be overwritten with the content of the export file.

(4) Create new profile and overwrite structural information (mapping) only: A new profile is created. Only the source structure, the target structure and variables are imported. The settings for the Input Agent and the Responses are unchanged.

(5) Clone selected profile and overwrite structural information (mapping) only: The selected profile will be cloned. Only the source structure, the target structure and variables are imported. The settings for the Input Agent and the Responses are unchanged.

Note: When you import a package, you can decide which of the contained files you really want to import.

Note: Only when a new profile is saved after the import, it is permanently available. The same applies to other imported files.