2022.1

integrates into the workflow in general and what to keep in mind when doing an actual
implementation of such a process.
Considerations
l The workflow itself is a standalone system that does not interact with any third-party
systems, which of course does not correspond to real customer implementation. A client
will most likely need to communicate with both an ERP system that generates documents
as well as an archive software to store completed documents.
l The HTML, CSS and data file are generated whenever the process starts, in a specified
location, in order to avoid having to distribute multiple static files which would need to be
extracted and moved to a specific folder. In an actual implementation, these files would
probably be edited externally and loaded from a location on the hard drive. However, the
method of using a template to generate output is not so alien to PlanetPress Workflow so
it is not condemned to do so.
l The example doesn't use any advanced coding such as JavaScript, Ajax and caching. It's
easier to follow, but is less optimized in its use than a complex workflow that would use
such features.
Workflow processes in a Connect Send solution
OL Connect Send (see "OL Connect Send" on page765) needs one Workflow process to
handle the job transfer, and in licensed mode it needs at least one other process to interact with
the user. Reports about the use of OL Connect Send might be produced in yet another
Workflow process.
Each OL Connect Send solution will require the Workflow processes to be configured
differently, but certain plugins will always be part of the solution.
Job transfer process
The Workflow process that handles the job transfer starts with an HTTP Input task. The action
name of this HTTP Input task must match the last part of the URL for print job submission set in
the printer driver installer (by default: olcs_transfer).
The Job Processor plugin is the only other task in this Workflow process (see "Job Processor"
on page540).
Page 298