This section describes little-used features of the process support that have been superceded.
Sub processes
Each process can also be called as a script. In this case, it looks for the action in the config attribute for an initial action to run, rather than the request attribute. (It uses the presence of the data attribute to determine whether to look in the requests attribute or the config attribute.)
The sub process may change the data. The state and return values from the last script in the sub process will be the state and return value from the sub process.
A task script may invoke an action on its own process using the following:
application.put('config',{action:requiredAction});
application.call(application.get('process'));Application attributes, such as data and request, will be available to the action.
The same convention can be used to invoke a process through application call() or execute(), for example the following code executes the process associated with a node and runs the display action.
application.put('config',{action:'display'});
application.execute(context); Data persistence
Of itself, a process does not persist data, though the tasks are free to write data as required. However, standard tasks are available to assist with data persistence.
| Save data | Save the data attribute, either to the context node or to a temporary node. |
| Load data | Load previously saved data into the "data" attribute. |
| Delete data node | Delete the data node identified by application attribute "dataNode". |
The data persistence tasks are useful when the process supports user interaction. In outline, to interact with the user:
- Use Save data to save the data.
- Run a task that creates a response with content. The links or forms with which the user restarts the process should pass the reference of the data node in the request parameter "data".
- When restarting the process, use Load data to reload the saved data.
Process instance
The Process Instance can be used to create instances of processes. The process is run when the instance is executed. They provide a Data member for the process to save data.
Other types can be created based on Process Instance.
Progress indicator
More complex processes may benefit from a progress indicator to entertain and inform the user while the process is in progress.
See the Progress Indicator Script for general introduction to the progress indicator. Task scripts are available to support the progress indicator process.
| Start progress | Start or restart a progress indicator, and set a redirect to the progress indicator node. |
| Show progress | Write a message to the progress indicator. |
| End progress | End the progress indicator, optionally redirecting to a URL. |
| Progress error | End the progress indicator with an error read from the application error fields, optionally redirecting to a URL |
| Render progress | Standard script to render the progress indicator. This must be present in the process with an action name of "renderProgress". |
| Check for progress indicator | Test whether a progress indicator should be shown. |
| Execute in background | Re-execute the current context in the background. This is used to continue the process in the background after starting a progress indicator. |
| End progress with execute | End the progress indicator, redirecting to an execute of the current context. |
Response handling
Task scripts can output a response to the user in the standard way, setting the title, head and content of the response.
However, it is sometimes useful to bulid a response in one script and then output it in another. For example, it can be useful to build a response in a background script, and then end a progress indicator with a redirect to an action that shows the response. You can achieve this by saving the response to the data area, and then rebuliding the response from the data area later in the process.
Two tasks scripts are available.
| Copy response to data | Copy a response to the data attribute. |
| Copy data to response | Recreate a response that has previously been copied to the data area. |
Copy data to response can also be used to output a response built up by previous scripts in the data.response object. This can be useful if a process uses multiple tasks to build a page to send to the user.
Authority
Of itself, a process does nothing about authority. All the tasks run under the authority of whichever user called the process.
For executed scripts, it can be useful to run the process under the node owner's authority. You can achieve this by calling the process as a script from a wrapper script, and preceding the call with application.runAsOwner().
In many cases, the process will want to know about the original caller, and may want to call services using the original caller's credentials. In this case, the wrapper script can use the Caller Credentials Script. This provides two methods:
- store() – store the current user as a Script User object in the application attribute "user" and their credentials as a Service Credentials object in application attribute "credentials".
- remove() – cancel the credentials and remove the "user" and "credentials" application attributes.
The wrapper script below will run the process bound to 'process' as the node owner, but with access to the caller in the "user" and "credentials" attributes.
application.include(application.getBinding('scriptCallerCredentials')); // bind to Caller Credentials Script
CallerCredentials.store();
application.runAsOwner();
application.call(application.getBinding('process'));
CallerCredentials.remove();Caller Credentials Script also provides more granular methods for storing and removing just the user or just the credentials.
Looking up processes using dynamic bindings
In complex solutions, processes and status rules (see below) may be identified by dynamic bindings.
Derive Process And Status Rules is a specialised type for creating a derivation field that will look up a process and status rules using dynamic bindings, and write them to Process and Status rules (library.process.StatusRulesLink, not library.process.StatusRules) respectively, taking defaults specified on the derivation field. Add this to the types in a solution so that the instances of those types will have Process and Status rules populated.