3.8 Setable Variables

Setable variables can be set within script or used within a CGI string. For example, the variable "ScriptDebugTrace" can be used as a parameter to a service call to display debug trace information on a page. Setting one of these variables can change the content of the page.

The following is a list of Idoc Script setable variables:


"ClientControlled"
"coreContentOnly"
"getCookie"
"HasLocalCopy"
"IsJava"
"IsSavedQuery"
"IsSoap"
"IsXml"
"isZoneSearchField"
"ScriptDebugTrace"
"ScriptErrorTrace"
"setCookie"

3.8.1 Workflows

Idoc Script includes predefined functions and variables that are used specifically for workflows.

For a detailed description of how workflows are implemented in Content Server, see details the Oracle Fusion Middleware Application Administrator's Guide for Content Server.

The following points summarize the use of Idoc Script in workflows:

  • Workflow jumps are initiated through the evaluation of Idoc Script that is defined for a particular step event (entry, update, or exit).

  • As a revision moves from step to step, the system creates a companion file that maintains information about the state of the revision in the workflow. Along with user-defined options, the system also maintains the history of what steps the revision has been to, the last entry time, and the number of times a revision has entered a particular workflow step.

    • Global state information is maintained as the revision moves from step to step.

    • Localized state information is stored with the step and becomes available when a revision is at that step.

  • The companion file uses keys to keep track of workflow state information. The syntax for a key is:

    step_name@workflow_name.variable=value
    

    For example, the following keys define the value of the entry count and last entry variables for the Editor step of a workflow called Marketing:

    Editor@Marketing.entryCount=1
    Editor@Marketing.lastEntryTs={ts '2002-05-28 16:57:00'}
    
  • All workflow script evaluation occurs inside a database transaction. The result is that any serious errors or aborts that are encountered cause no change to either the database or the companion file. This also means that no Idoc Script workflow function should take more than a negligible amount of time. Consequently, to trigger an external process, an Idoc Script function should be written to execute in a separate thread.

    Caution:

    If you are using Idoc Script or custom components to load workflow information into the local data, keep in mind that there is a risk of data pollution. This is particularly important if you are loading information for a different revision than the current one.