Command-line options for exporting objects
Use the wstool exportObjects command to export objects from the command line tool.
wstool exportObjects -username <username> -password <password> [options] <output_file>
The following tables describe the parameters available for wstool exportObjects.
Mandatory parameters
| Parameter | Description |
|---|---|
<output_file> | The file in which to write exported data. Give it the .xml extension or no extension at all. |
-username <username> | Your WorldServer user name. |
-password <password> | Your WorldServer password. |
Export mode parameters
| Parameter | Description |
|---|---|
-r | Export any specified objects recursively; that is, export the specified objects and find and export their referenced objects as well.
|
-force | Allow the export code to overwrite an existing output file. You can only write to an existing file if you specify this. |
-preview | Preview objects to be exported. |
Objects to export
| Parameter | Description |
|---|---|
-all | Export all the supported objects from the system. |
-attribute {all | <object-type>:<api-name>} | Export all attributes or a specific attribute. |
-costModel {all | <id>} | Export all or specific cost models. |
-costModelRule {all | <id>} | Export all or specific cost model rules. |
-filterConfig {all | <filetype-name>:<config-name>} | Export all configurations or a specific file type configuration. You can find the <filetype-name> and the <config-name> on the page. |
-humanAction {all | <id>} | Export all human actions or a specific human action. |
-link {all | <source>:<target>} | Export all linkage or a specific linkage. The source and target must include the full AIS path. |
-locale {all | <name>} | Export all locales or a specific locale. |
-mount {all | <name>} | Export all mounts or a specific mount. |
-recurrence {all | <name>} | Export all recurrences or a specific recurrence. |
-role {all | <name>} | Export all workflow roles or a specific role. |
-scopingConfiguration {all | <id>} | Export all or specific scoping configurations. |
-td {all | <id>} | Export all or specific TDs. |
-tdGroup {all | <id>} | Export all or specific TD sequences. |
-tm {all | <id>} | Export all or specific TMs. |
-tmGroup {all | <id>} | Export all or specific TM sequences. |
-usertype {all | <name>} | Export all user types or a specific user type. |
-user {all | <name>} | Export all users or a specific user. |
-vendor {all | <name>} | Export all vendors or a specific vendor. |
-workflow {all | <name>} | Export all workflows or a specific workflow. |
-workgroup {all | <name>} | Export all workgroups or a specific workgroup. |
-objectList <objectListFile.xml> | An .xml file containing a list of objects to export. |
Getting help
| Parameter | Description |
|---|---|
<no parameters> | Print a Help message including a parameter overview and supported objects list. (This is the equivalent of a -h or -help option.) |
Examples of using the command-line tool
wstool exportObjects -username <username> -password <password>
–link all –workflow all data.xml
wstool exportObjects -username <username> -password <password>
–user all –workflow “Translate & Save” data.xml
Object list file format
<attribute>
<costModel>
<costModelRule>
<filterConfig>
<humanAction>
<link>
<locale>
<mount>
<recurrence>
<role>
<scopingConfiguration>
<td>
<tdGroup>
<tm>
<tmGroup>
<user>
<usertype>
<vendor>
<workflow>
<workgroup>
All elements must have the include attribute set to either all or an object name. Elements may also have the recursive attribute set. If this attribute is missing or is set to anything other than true, the tool treats it as false.
The root element of the .xml file should be <object_list>.
Examples of using an object list file
<object_list>
<workflow include=”all” recursive=”true”/>
<link include=”all” recursive=”true”/>
</object_list>
<object_list>
<user include=”all” recursive=”false”/>
<workflow include=”Translate & Save” recursive=”true”/>
</object_list>
- Workflow1
- Workflow2
- Linkage from /XML/en_US to
/XML/fr_FR - Linkage from
/XML/en_USto /XML/ko_KR
<object_list>
<workflow include="Workflow1"/>
<workflow include="Workflow2"/>
<link include="/XML/en_US:/XML/fr_FR"/>
<link include="/XML/en_US:/XML/ko_KR"/>
</object_list>
Example 4 – Perform an export that includes some dependencies, but excludes others.
If you specify arguments at the command prompt, there is just one -r flag that is either present or not. However, in the XML ObjectList, you can specify recursiveness for each object individually. This gives you more control over which objects to export.
For example, you have a workflow with a step assigned to John Doe (jdoe). John Doe is a member of the Reviewers workgroup, which in your test system includes some users that were created just for testing. You want to export the workflow along with its immediate dependencies (for example, the human actions it uses and direct assignees), but you do not want to pick up the entire tree of dependencies related to John Doe (like the other members of the Reviewers group that exist for testing).
<object_list>
<user include="jdoe" recursive="false"/>
<workflow include="wf1" recursive="true"/>
</object_list>
The file effectively exports the workflow and most of its dependencies, but causes the recursion to stop at user jdoe—his dependencies (like the Reviewers workgroup) are not exported. On import, jdoe is attached to the Reviewers workgroup that already exists in the target server, without changing the other members of the workgroup.
Exporting disabled objects
To prevent WorldServer processes such as workflow tasks from getting into an invalid state when one of the objects it is processing is deleted, WorldServer keeps the object in the database, but removes it from the user interface. Essentially, the object has been disabled from further use, but is still available to running (or scheduled) processes.
For example, you have a task assigned to a user. If the administrator tries to delete the user, the user is actually disabled instead (to avoid putting the task in an invalid state). However, the user no longer appears in the main user management page. There are also ways of disabling certain types of objects—users and linkages, for example—in the interface.
- If a disabled object is listed explicitly in a list of things to export, the export is unsuccessful. For example, if user Jane is disabled and you try to export Jane, the export is unsuccessful.
- If WorldServer finds a disabled object as a reference and the reference to the disabled object can be removed without creating an inconsistent state, the export succeeds, but WorldServer omits the disabled object from the export. For example, the locale French has a disabled user called Pierre as a member. The locale would still be valid without Pierre; therefore, when you export the locale, Pierre is omitted from the list of users in the locale.
- If WorldServer encounters a disabled object as a reference and the original object is dependent on the referenced object, the export is unsuccessful. For example, if a workflow has a step assigned to a disabled user, attempting to export that workflow does not succeed until you reassign the step.