Command-line options for exporting objects

Use the wstool exportObjects command to export objects from the command line tool.

Command syntax:
wstool exportObjects -username <username> -password <password> [options] <output_file>

The following tables describe the parameters available for wstool exportObjects.

Mandatory parameters

ParameterDescription
<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

ParameterDescription
-rExport any specified objects recursively; that is, export the specified objects and find and export their referenced objects as well.
-forceAllow the export code to overwrite an existing output file. You can only write to an existing file if you specify this.
-previewPreview objects to be exported.

Objects to export

ParameterDescription
-allExport 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 Management > Linguistic Tools Setup > File Types 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

ParameterDescription
<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

To export all the linkage and workflows:
wstool exportObjects -username <username> -password <password> 
–link all –workflow all data.xml
To export all the users and the Translate & Save workflow:
wstool exportObjects -username <username> -password <password> 
–user all –workflow “Translate & Save” data.xml

Object list file format

You can use an .xml file to provide the list of objects to export. The .xml file can contain the following elements (which are equivalent to the command-line arguments):
<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

Example 1 – Export all the linkage and workflows and all their dependencies:
<object_list>
   <workflow include=”all” recursive=”true”/>
 	 <link include=”all” recursive=”true”/>
</object_list>
Example 2 – Export all the users (but not their groups and their users) and the Translate & Save workflow, along with its dependencies.
<object_list>
   <user include=”all” recursive=”false”/>
   <workflow include=”Translate & Save” recursive=”true”/>
</object_list>
Example 3 – Export the following objects:
  • Workflow1
  • Workflow2
  • Linkage from /XML/en_US to /XML/fr_FR
  • Linkage from /XML/en_US to /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).

You can use the following ObjectList to accomplish these goals:
<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.

The deployment tool does not export disabled objects. The behavior of export when it encounters a disabled object depends on the situation:
  • 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.