Kbase P54140: Dynamics. How Configuration File Import Works?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
14/11/2003 |
|
Status: Unverified
GOAL:
Dynamics. How Configuration File Import Works?
FACT(s) (Environment):
Dynamics 2.1A
FIX:
To import a configuration file a Configuration File Name must be entered and the Load XMLFile button chosen. Note that the Configuration File Name may point to an XML document on a Web server using a URL; it need not be a local file.
After loading the XML file, a list of all the session types is loaded into the Available Session Types list and the user can then select some or all of the session types to import and add them to the Selected Session Types list.
Choosing the Import Session Types button will begin the import process which may take a few minutes.
The Configuration File Import process creates a session type for each of the Selected Session Types. If an existing session type is encountered, the data in the imported configuration file will be added to the data in the repository. In other words, all properties, services, and values will be populated from the configuration file. Any existing properties, services, or values that do not
appear in the configuration file will remain in the repository.
As a result, choosing to import the entire configuration file, including the standard session types provided with Progress Dynamics could render certain session types invalid.
When a session type is created as a result of an import, it is created at the same level as the "Basic" session type discussed in Table 1 - Dynamics Session Types. This means that it does not inherit from anywhere and it is therefore necessary to change the "Extends Session Type" field on the Session Type Control screen for this session type.
As session types are imported, the import procedure looks for the Session properties, Manager Types, Service Types, Logical, and Physical Services (control data) in the repository and creates them if necessary. Anything that is changed as a result of the import in any of the tables will have the string "**(IMPORT)" added to the front of the description of the record being imported so that
it is easy to identify what has been imported.
In the case of Session Properties, Manager Types, Logical Services, Physical Services, and Service Types, selecting the maintenance of these tables from the session menu will produce a browser of all of the records in the table and sorting by the Description column will get the imported records together.
Any record that has the "**(Import)" string in the front should be verified to ensure that the data is still correct after the import. It is also suggested that "**(Import)" string be removed from the description once it has been updated.
How the import handles control data is determined by the three toggles on the Configuration File Import screen. The toggles determine whether Manager Types, Logical Services, and Physical Services are overwritten.
In the case of Manager Types and Logical Services, if the import encounters one that does not exist in the repository, it creates it. When it encounters one that does exist in the repository, it checks the value of this toggle. If the toggle is checked, the existing data in the repository is overwritten with the data from the configuration file. If the toggle is not checked, the data in the repository is left intact.
In the case of Physical Services, the issue is complicated by the fact that through manual editing of the configuration file, more than one physical service may exist with the same code but different connection parameters. For this reason, when a physical service is imported and the Overwrite Physical Service toggle is off, a new one is automatically created if the connection parameters do not match with the connection parameters of one already in the repository. If the toggle is on, the physical service is overwritten with values from the most recently read physical service in the XML file.