Import in the Admin Console
The Import section controls the importing of an entire KB or a single table. Regular imports or exports are controlled through the power user interface. For more information, see Importing Record Data. To access this section, navigate to KB Management > Import.
Though similar to the Import tab in the power user interface, the Admin Console Import section has some important distinctions.
When importing a knowledgebase, you have two possible approaches:
- Create a new KB
- Overwrite an existing KB of the same name
Data Source Tab
Select the data source of the KB to be imported in this tab.
If the import file is stored locally, select the “Local hard drive” option.
If the import file is stored on the server, the file is located in the TMP directory or the Home directory. For the TMP directory, the file is stored in /
usr/local/EnterpriseWizard/tmp on the server.
For the Home directory, the file is stored in
/usr/local/EnterpriseWizard/data/backups/admin on the server.
Choose the import file in this tab. Attempts to import an invalid file type prompts an error informing the admin that the file format is not supported.
Once an file is chosen and upload begins, navigating away from the Import tab kills the upload process.
Enter the name of the KB that will be created from the import file. If a KB with the same name already exists, it becomes overwritten by the import.
As with the KB Creation tab, a KB label and KB description are required to proceed.
Select the items to import in the Options tab.
Choosing “All” imports all data, scripts, escalation rules, and inbound email definitions. To select a subset of the options, choose “Tables definitions plus:”.
Depending on the selections made, imported data may overwrite existing objects in the target KB.
An additional option is available to retain a KB even if the import fails. This is helpful for investigation of issues. The failed KB is made inaccessible by default, but it can be turned on in the Setup/Patches tab of the Admin Console. A failed KB should never be put into production until the issue has been resolved.
KBs are automatically backed up upon import, as well as at defined intervals thereafter. Unless your organization has a specific need, consider disabling subsequent backups to prevent unnecessary strain on the system.
To disable KB backups:
- Log in to the admin console.
- Go to KB Management > Backup > [Edit KB] > Frequency.
- In the Frequency section, select Never.
- Click Next and then click Finish.
Disable KB on Import
If this is selected, the knowledgebase state becomes 'Disabled' upon import. This is useful in cases where a copied KB has existing rules/inbound mail accounts/external integration, and enabling them after import would cause them to become active and create conflicts with the existing live KB.
A disabled KB will have no active mail accounts, rules, or other background processes. This KB can only be logged into by admin level users in the power user interface. The admin will then need to evaluate all the processes which should be inactive and disable them to prevent conflicts with the live KB, before enabling the whole KB.
Note: The option to disable a KB has also been added to the Options tab of the Export wizard. This will disable the KB state before export, which will have the same effect as disabling it upon import.
Importing the Admin KB
Since it is possible to manually export an Admin KB at any time, the system’s control structure checks for KB restrictions during the import process. A flag marking a particular KB as the Admin KB is stored in the
swdescmeta.xml file of each
Agiloft export. The system reads the flag and prevents certain actions from executing.
Changing the flag on an Admin KB to “spoof” the system allows import of a file that would otherwise be denied. In this particular case, we examine an Admin KB.
After a successful import, the flag may be changed back to indicate a KB is an Admin KB through BeanShell. Two concurrent instances of an Admin KB will not cause the server or system to crash, however nearly all Agiloft functionality will be lost, rendering the system completely unusable.
Import Table allows the import of a specific table from any KB on the same server. In order for the import action to occur, both KBs must exist and be active on the server. There is no option to import a table from a KB that exists only as a backup file.
This tab specifies the KB and the table to be imported. Only knowledgebases with a Status of “Active” appear in the drop-down selection. The default source KB is the Demo KB.
The target tab specifies the destination KB of the imported table. Only KBs with a status of “Active” show up in the drop-down menu.
To import the skeleton structure of the table without the record data, check the box next to “Import structure only”.
Below, the tab asks for a table label to be set. If a table with the same name already exists in the target KB, the console throws an error. There is no way to rename tables at the system level.
To import and overwrite an existing table, the sync capability controlled at the KB level through the power user interface must be used. This sync capability is different from the sync capability described for the admin console below.
Refer to Import Export for more information on KB-to-KB sync capabilities.
This tab controls the table-wide and field level permissions for the imported table in the target KB. This is done by mapping groups in the source KB to groups in the destination KB, rather than setting permissions for fields directly.
Any groups in the target KB that are not mapped to will have no access to the imported table as a default. Permissions can be refined after import via the staff administrator interface by changing Group settings.
If identical group names to the source KB are desired in the target KB, the groups must be set up in the target KB prior to import.