Processes, Chains, and History
Processes lie at the core of Redwood Server. Processes can be submitted by users, as the result of a particular event (for instance the arrival of a file, or a trigger in a remote system), or based on a business schedule. A chain can be as short and simple as a line of ABAP code that runs on a single system, or as complex as a multi-day mass activity that runs across dozens of machines.
Chains and Process Definitions
Redwood Server not only allows you to submit simple chains, it allows you to create chains with complex parameters. Custom process definitions with complex parameters can be written that are re-used for different tasks. Consider file transfer as an example; when there are only one or two files to be transferred, then writing a chain for each file transfer that contains all the commands to transfer the file (including the file name) might be sufficient. When there are dozens (or even hundreds of files), a better approach is needed.
In Redwood Server, this could be handled by creating a process definition called Transfer File that has four parameters: System to transfer from, Directory to transfer from, System to transfer to, Directory to transfer to. This would allow operators to easily add new file transfers to the schedule, and clearly see the files being transferred (and the systems involved) in the processes monitor. If some improvement was made to the transfer process, for example, using secure FTP instead of FTP, then this change can easily be made by changing the process definition. If a mistake is made, this can be fixed by changing the parameters of the process (through the chains monitor), rather than editing the process definition itself.
note
FTP support requires the Platform Module, which allows you to schedule programs on remote UNIX, HP OpenVMS, and Windows servers.
Submitting a process definition allows you to specify values for the parameters, creating a process. Each process can then be monitored throughout its life-cycle: from being submitted, to running, to finishing (either in a COMPLETED or ERROR state) to finally being deleted. The process definition approach means that you can have as many processes running as you need, rather than having to create new processes as business needs change.
Chain processes are process definitions of a specific type. They are made of one or more calls to process definitions, named chain definitions, and are comparable to multi-step SAP jobs. Complex process definition dependencies can be met with chain definitions, steps and processes can be restarted when a process fails, for example.
History
Processes are saved in the system according to the keep clause. The keep clause is set on a process definition or chain definition basis. The default is to keep process definitions forever; if you really want to keep specific process definitions indefinitely, you should select the corresponding keep clause. The keep clause can be expressed in number of process definitions to keep, or time to keep process definitions. For example, you would like to keep process definitions from a specific process definition for 12 months; the system keeps all process definitions of this process definition for a year and will, after the anniversary date of the oldest process definition, delete it. The System_ProcessKeepClauses maintenance process definition runs regularly; it checks for old process definitions that need to be deleted and deletes them.
The Active Archive module is also used to manage process definition history by offloading process definition metadata and output to an external archive system; the module can be set up to delete archived process definitions in Redwood Server.
You can also choose to manually handle process definition history, the context-menus of process definitions and chain definitions have an action Delete final state process definitions. The output of deleted process definitions is regularly deleted by the system process definition System_DeleteJobFiles.