Documentation Center

Export Command Line Options

To export objects, use the wstool exportObjects command.

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

The following tables describe the parameters available for wstool exportObjects:

Table 1. Mandatory parameters
ParameterDescription
<output_file>The file into which to write exported data. Because this is an XML file, you might give it the extension .xml. (Or you can use another extension, or none at all.)
-username <username>Your user name.
-password <password>Your password.
Table 2. 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. If this is not specified, attempting to write to an existing file will result in an error.
-previewPreview objects to be exported.
Table 3. 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 | <filter-name>:<config-name>}Export all configurations or a specific file type configuration. <filter-name> should come from the Management > Linguistic Tools Setup > File Types list, and <config-name> should come from the name on the <Selected File Types>: Available Configurations page. For example, this might be DOC File Type:Default.
-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 groups.
-tm {all | <id>}Export all or specific TMs.
-tmGroup {all | <id>}Export all or specific TM groups.
-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>XML file containing a list of objects to export.
Table 4. 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.)

When you specify an object to export, the <name> parameter must match exactly. Wildcard matching is not supported. Use quotes around names that have spaces.

If you want to export more than one—but not all—objects of a particular type, you can use the parameter multiple times in a command. For example, if you wanted to export Workflow1 and Workflow2, but not your other workflows, you could use the following syntax (adding your username and password):
> wstool exportObjects -username <username> -password <password> –workflow Workflow1 –workflow Workflow2 data.xml

Setting Up to Run wstool

Before running wstool, you must do the following:
  1. Make sure that <install-dir>/bin is in your path, where <install-dir> is the WorldServer installation directory; for example, C:\Program Files\Idiom\WorldServer. If you installed using the WorldServer installer, this should already be set.
  2. Make sure that the wstool script knows how to find your expanded WAR file. The script looks automatically in <install-dir>/tomcat/webapps/ws-legacy/, which is the default location for an installation under Tomcat. If you have a different configuration, you need to set the environment variable WS_APP_HOME to the directory location of your expanded WAR file.

Examples of Using the Command Line

To export all the linkages and workflows:
> wstool exportObjects -username <username> -password <password> 
–link all –workflow all data.xml
To export all the users and the workflow Translate & Save:
> 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 besides true, it is treated 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 linkages 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 workflow Translate & Save, 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 on the command line, there is just one -r flag that is either present or not. However, in the XML ObjectList, it is possible to specify recursiveness for each object individually. This feature allows you more control over which objects to export.

For instance, suppose you have a workflow with a step assigned to user 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 whole 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) would not be exported. On import, jdoe would just be hooked up to the Reviewers workgroup that already exists in the target server, without changing the workgroup's other memberships.

Export and Disabled Objects

To prevent WorldServer processes (like 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 view. Essentially, the object has been disabled from further use, but is still available to running (or scheduled) processes.

For example, suppose you have a task assigned to a user. If the administrator tries to delete the user, it 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, export fails. For example, if user Bob is disabled, and you try to export Bob specifically, the export fails.
  • If WorldServer encounters 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 the disabled object is omitted from the export. For example, suppose the locale "French" has a disabled user "Pierre" as a member. The locale would still be valid without Pierre, so 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 will fail. For example, if a workflow has a step assigned to a disabled user, attempting to export that workflow fails until the step is reassigned.