Dependent Workflow Tickets

Dependent workflow job tickets are those that allow the input of one business service to be dependent on the output of a previous business service. Obviously, the value of business service output parameters can only be known at execution time. Workflow job tickets solve this problem by allowing a parameter to reference another parameter value in the job ticket using XML XPath queries.

The following is a more realistic example that retrieves a copy of a source document from Documentum, renders the copy to PDF, and then adds the rendition back to the source document. This is accomplished by calling the “retrieve”, “render”, and “distribute” business services.

Without getting into details of how these services work, “retrieve” has an output parameter called “local-path” that will contain the full path of the copy of the source document. “Render” has an input parameter that is the path of the file to be rendered. Similarly, “distribute” has a “local-path” input parameter that is the file to be added as a rendition. At the time of writing the ticket, these paths are not known. However, as highlighted in bold below, you can specify the “from” attribute on a parameter.

The attribute value can be any valid XPath query that can be used by the workflow service to resolve the parameter value. The XPath query should uniquely identify another node in the job ticket whose text value will be copied. As mentioned earlier, the workflow business service sequentially executes the subordinate business services. Prior to the execution of each business service, workflow will resolve any parameters having the “from” attribute.

<workflow job-name="Test Workflow" submitter="John" product="Vista">
<retrieve>
<request tag="request1" name="retrieve-document">
<URL type="string">dms://dctm/borg/09015bda800081db?label=CURRENT</URL>
<content-type type="string">doc</content-type>
</request>
</retrieve>
<render>
<request tag="request2" name="render-pdf">
<document-name
type="string">dms://dctm/borg/09015bda800081db?label=CURRENT
</document-name>
<local-path type="string"
from="retrieve/request[@tag='request1']/local-path">
</local-path>
<force-rendition type="bool">1</force-rendition>
<content-type type="string">doc</content-type>
<rendition-found type="bool">0</rendition-found>
</request>
</render>
<distribute>
<request tag="request3" name="distribute-rendition">
<URL type="string">dms://dctm/borg/09015bda800081db?label=CURRENT</URL>
<local-path type="string"
from="render/request[@tag='request2']/local-rendition-path">
</local-path>
<format type="string">pdf</format>
</request>
</distribute>
</workflow>

After “retrieve” is executed, its portion of the ticket will appear as follows. Notice that the “localpath” output parameter has been added:

<retrieve>
<request tag="request1" name="retrieve-document">
<URL type="string">dms://dctm/borg/09015bda800081db?label=CURRENT</URL>
<content-type type="string">doc</content-type>
<local-path type="string">c:\Temp\aa123.tmp.doc</local-path>
</request>
</retrieve>

Before executing “render”, workflow will modify the ticket to resolve the renders “local-path” parameter by copying the value of the retrieve “local-path” parameter. The render portion of the ticket then looks as follows:

<render>
<request tag="request2" name="render-pdf">
<document-name
type="string">dms://dctm/borg/09015bda800081db?label=CURRENT
</document-name>
<local-path type="string" from="retrieve/request[@tag='request1']/localpath">
c:\Temp\aa123.tmp.doc</local-path>
<force-rendition type="bool">1</force-rendition>
<content-type>doc</content-type>
<rendition-found type="bool">0</rendition-found>
</request>
</render>

Note in the above example that the “local-path” parameters for ‘retrieve’ and ‘render’ are both type “string”. If the parameters are not the same type then the “from” option will fail. If no type is specified on a parameter then “string” is assumed.

The author of the job ticket is allowed to use whatever XPath query works. In the above examples, “request” nodes were qualified with a “tag” attribute and the XPath queries used the tag as follows:

retrieve/request[@tag='request1']/local-path

This approach is merely a convention and not required.

A variation on the above involves parameters whose values are XML. You can specify the “from” attribute on any node within the parameter value. However, the parameter node must have the “resolve-from” attribute specified and set to “1” (true). Prior to executing the business service, workflow will look for parameters that are type “xml”. If “resolve from” is true for the parameter, then all nodes in the XML will be examined for “from” attributes. In the following, the “someparam” parameter value is XML and a node in the XML has an XPath reference to the retrieve “localpath” parameter.

<workflow name="Test" submitter="Test App" product="Xtent">
<retrieve>
<request tag="request1" name="retrieve-document">
<URL type="string">file://c:/Dev/Vista/MyDoc1.doc</URL>
<content-type type="string">doc</content-type>
</request>
</retrieve>
<some-business-service>
<request tag="request1" name="do-something">
<some-param type="xml" resolve-from="1">
<document>
<local-path from="retrieve/request[@tag='request1']/local-path"/>
</document >
</some-param>
</request>
</some-business-service>
</workflow>