In order to work with Print Data in the Workflow, all data must first be transferred to the Workflow. We offer a number of options for this, which are described below.
1. Data Storage in practice
Instead of storing the Print Data locally on workstations as is the case with non-server-based work environments, the required files are transferred to the server on the Workflow and stored with the preferred hierarchal structure familiar to most people who have experience managing data and files.
Figure 1: Example of a typical folder structure:
The figure above shows a theoretical file structure representing customer/print data on a (Macintosh) file system.
- The first entry in this hierarchy example is represented by the customers [1] (Client_A to Client_X, in reality probably customer name or customer number or a combination thereof), of which there are (hopefully!) many.
- In each customer folder "order folders" [2] are created, named here for the purpose of our example with a numbering system, but in reality are often labeled with a combination of short descriptions and/or order number(s).
- The actual Print Data (yellow background) [3], which exists in different formats (PDF, InDesign, Photoshop, Illustrator, LaTex, etc.) and may possibly contain several versions (see the PDF-based jobs 0001 and 0002 above), are now located within an Order Folder. Highly likely but not shown, are additional documents/files such as the fonts used and the images assets, which must be managed in addition to the graphic/layout documents.
This Production Data model structure - whether on a workstation or a shared server - only works if all people involved adhere to "rules", which - often unspoken - are cultivated in the company. If an error occurs, it is possible that documents can no longer be found or - worse - can be deleted or overwritten. In the latter case, you must approach the customer again and ask for a copy of the order data, which can have very unpleasant consequences, especially under time constraints...
2. Structured Data Storage on the Workflow server
In contrast to manual storage in the file system, Print Data is stored in the Workflow in one of the following forms / data structures:
- as an Order
- as a Production Job
- as an Article
These data structures are organized in the Workflow in Lists, which are essentially configurable views of database entries and were designed around the searchable topics and organization of many Print Jobs/Items. The uploaded documents are of course stored on the server in the background in a traditional file system, which, cannot be viewed by the Workflow users but is exclusively managed by the Workflow. This ensures that documents in the system cannot be mistakenly moved, deleted or overwritten. Documents can always be deleted and moved, etc. but not without explicit consent from the user side.
3. Uploading Documents
The transfer of print data can be either manually completed or automated. The user is completely free to choose which process is used, depending on the organization of the company.
- +New – Create a new Article, Production Job or Order.
- Drag and Drop Upload – Upload Print Items or Articles using the drag and drop zone.
- Force Print – Use Force Print to create a new Production Job or send them directly to the Printer.
- Additional Data – Quickly save additional files which are not directly related to the Production Job.
The automated transfer of print data is done either directly in the Workflow by upstream systems or by moving print data to monitored directories. The following options are available:
- Hotfolder – Print data is copied into defined directories (defined by the user), and then processed automatically by the Workflow using settings defined in the Hotfolder dialog.
- RestAPI – Print data is transferred directly from a leading system (i.e., an ERP or MIS ) to the Workflow by sending a Request or Rest Calls to the Workflow.
- Integrate – Print data is transferred to the Workflow by processing descriptions such as: XML, CSV, JDF, etc., via the Integrate Server.
It may be that there are context-dependent and/or process-dependent operations happening here. The following articles describe all variants and their advantages and limitations or the consequences resulting from their use.