Export Command Line Options
To export objects, use the wstool exportObjects command.
wstool exportObjects -username <username> -password <password> [options] <output_file>
The following tables describe the parameters available for wstool exportObjects:
| Parameter | Description |
|---|---|
<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. |
| 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. If this is not specified, attempting to write to an existing file will result in an error. |
-preview | Preview objects to be exported. |
| 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 | <filter-name>:<config-name>} | Export all configurations or a specific file type configuration. <filter-name> should come from the 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. |
| 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.) |
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.
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
wstool, you must do the following:
- 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.
- Make sure that the
wstoolscript 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 variableWS_APP_HOMEto the directory location of your expanded WAR file.
Examples of Using the Command Line
> wstool exportObjects -username <username> -password <password>
–link all –workflow all data.xml
Translate & Save:
> 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 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
<object_list>
<workflow include=”all” recursive=”true”/>
<link include=”all” recursive=”true”/>
</object_list>
Translate & Save, along with its dependencies.
<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 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).
<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.
- 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.