systemimport
usage: systemimport
[ -s|-skipexisting ]
[ -pp|-preservepermissions ]
[ -nameconflict re|an|sk|ask ]
[ -keyconflict re|an|sk|ask ]
[ -namekeyconflict rn|rk|an|sk|ask ]
[ -he|-holdexecution [ r|sr|sir|wr ] ]
[ -nr|-norollback ]
[ -no|-newowner]
[ -select <xml-selection file> [ -dryrun ] [ -onerror < ABORT | ASK | IGNORE > ] ]
[ -m|-message ]
[ -u|-upgrade ]
[ -eu|-enableusers ]
<export file|directory> [password]This command imports a ZIP file or a directory. If an import entry conflicts with an entry that already exists in the current system, the entry will not be imported. An example of such a conflict might be an identical entry name, but a different ID.
A workflow group that is scheduled to start while an import activity is happening will not start until the import is complete.
[-s|-skipexisting]
If you choose to set the skipexisting parameter, the imported data will not overwrite existing configurations that have the same key, name, type, and folder. This means that repeatedly importing a configuration, does not overwrite the data.
[-pp|-preservepermissions]
When user permissions are modified, set the preservepermissions parameter to prevent user permissions in the current system from being updated while importing a configuration.
This parameter enables you to identify an imported configuration with a name that is identical to the name of a configuration that already exists in your system. Using this parameter requires that you specify what you want to do with the imported configuration:
re(REplace): Overwrite the current configuration with the imported one.an(Add New): Add the imported configuration to your system. To resolve the name conflict, the new configuration's name is extended with_1at the end.
Note!
A name that already ends with _n is modified at the end to _n+1.
sk(SKip): Ignore the conflicting imported configuration.ask: Prompt when a conflict is detected.
Note!
If you do not set this parameter, the conflicting configuration is skipped and ignored.
[-keyconflict re | an | sk | ask]
This parameter enables you to identify an imported configuration with a key that is identical to the key of a configuration that already exists in your system. Using this parameter requires that you specify what you want to do with the imported configuration. For information about the keyconflict options, see [-nameconflict re | an | sk | ask].
Example - [-keyconflict re | an | sk | ask]
The command mzsh mzadmin/dr systemimport -keyconflict ask import.zip is applied with the ask option and detects a key conflict.
...
[Configuration/Event Notification]
- Importing Default.extraKey2...
Event Notification configuration with the same key
but with a different type, folder or name already exist!
Existing name is: Default.existingConfiguration
Imported name is: Default.importedConfiguration
What do you want to do?
1) Replace existing configuration
2) Import as a new configuration
3) Skip
> 1
Use this alternative for all configurations of this type?
1) Yes
2) No
> 2Note!
If you do not set this parameter, the conflicting configuration is skipped and ignored.
[-namekeyconflict rn | rk | an | sk | ask]
This parameter enables you to identify an imported configuration with a name as well as a key that are identical to a name and a key of two different configurations that already exist in your system. Using this parameter requires that you specify what you want to do with the imported configuration:rn (Replace Name conflict): Replace the configuration that name conflicts with the imported configuration.rk (Replace Key conflict): Replace the configuration that key conflicts with the imported configuration.an (Add New): Add the imported configuration to your system.sk (SKip): Ignore the conflicting imported configuration.ask: Prompt a message when a conflict is detected.
Note!
If you do not set this parameter, the conflicting configuration is skipped and ignored.
[ -he|-holdexecution [ r | sr | sir | wr ] ]
Example. Using the holdexecution parameter
$ systemimport -s -he r export.zip
$ systemimport -s -he sr export.zip
$ systemimport -s -he sir export.zip
$ systemimport -s -he wr export.zipUse the holdexecution parameter to prevent scheduled workflow groups from being started while importing configurations.
If a workflow or a workflow group does not stop within 5 minutes (300 seconds) when applying systemimport with either one of the following holdexecution parameters: sr, sir, and wr, a timeout will occur. You can change the timeout value by setting the Platform property mz.import.suppress.timeout.
When import is complete and a workflow group is still running, systemimport -holdexecution [ r | sr | sir | wr ] awaits the current running workflow member to come to a stop, and then restarts the whole group instead of continuing the execution of the member that follows.
If you do not specify any of the r, sr, sir or wr options:
A batch workflow or a workflow group will remain suppressed until all the workflows finish executing. Then, the workflow or the members of the workflow group, become idle.
A real-time workflow group will return to the running state.
systemimport -holdexecution generates events. To retrieve the events data, configure the Event Notification Editor to transfer it according to your preferences. For information about the Suppressed Event event type, see 4.3.7 Suppressed Event in the Desktop user's guide.
holdexecution Parameters
Select the action that should resolve held executions:
r(restart): When the import activity is done, and a workflow group is partly executed, specifying this option will restart that workflow group. Workflow groups that are fully executed, will not be restarted. A workflow that is started manually, will be restarted if it has been stopped.sr(stop and restart): Stops the workflows or workflow groups that are still running after an import is complete, waits for them to come to a stop or finish processing a batch, and then restarts synchronously all the workflow groups and all the manually started workflows that had not executed completely within the timeout boundaries.
Note!
A workflow that becomes Unreachable after a system import has begun, will be restarted only when and if the contact with the Execution Context that it runs on, is regained while still importing.
If a workflow is unreachable when system import is started, the import is aborted and the following error message is generated: Abort Import: At least one wf that is Unreachable.
For further information about the Unreachable state, see 3.1.11 Workflow Monitor in the Desktop User's Guide.