DCS Destiny

specification

 

Modern Print Shops handle a wide variety of print data and print equipment. To compete effectively, Print Shops must now guarantee delivery of jobs, as well as provide audit trails to prove delivery.

 

Lead times and delivery expectations are constantly decreasing, while the number and complexity of applications is increasing.

DCS Destiny) is designed to enable effective production management in a digital print shop.  It automates the flow of data from receipt to printing, and provides controls for main process steps.

 

It is a very flexible system that can be tailored to meet a wide variety of possible requirements.  This new version of Destiny was completely redesigned to meets customers requirements in the future.  It is based on the new Microsoft .NET platform and it uses lots of modern techniques like multi-treading and remoting. The design was done very carefully which is the basis for all future developments on Destiny.

 

The system consists basically of the following components: 

Triggers

Jobs

Connections

User Interfaces

Processes

 

The structure of the system is quite easy to understand; all operations can be specified with only these entities.  The DPSM server itself runs as a service under any Windows operating system (Windows NT, 2000, XP, 2003, Linux) or any other operating platform supported by the Microsoft .net architecture.  IBM servers host DPSM to ensure the highest level of reliability, optimization, and support.

 

Trigger

A trigger essentially is an event that causes a job to start.  This can be the occurrence of a specified file (or search string) in a certain directory. A trigger also can be a control file that gives instructions, which job to start or it can even be an e-mail. Apart from that there are also time triggers that start a job at a specified time or in certain intervals.

 

This module is responsible for everything that has something to do with triggers.  It receives trigger data from the database and checks whether a trigger occurs. If necessary it fires a "Job Start" event that instructs Process Manager to start a new process.  It uses the Connection module to get access to remote hosts to watch for trigger events.

 

Jobs

A job is the container for tasks that should be performed by DPSM.  It contains a process chain that specifies the work flow within the job.  It is either started by a trigger or manually by an operator.  This process chain can consist of several tasks:

 

Fetch files:

Fetch files mean that this task can fetch any file into the working directory from a remote location.  That remote host can be connected to DPSM by using FTP or MAP.

Deliver files:

All files that are in the process-local file list can be delivered to any remote host.

Archive:

Archive means jobs can be stored (and compressed) to a directory tha can be archived e.g. on CD for later reprints.

Unachieved:

Get job from archive for reprint.

Sleep:

Wait for a specified amount of time. This can be useful if a job should be interrupted for a while.

Wait for trigger

 This means jobs wait to continue until another event occurred. This other event can for example be a file that appears somewhere or a time triggered event.

Print

 The task Print transfer specified files to a print server, whereas a job ticket can be defined.

Run PReS

 The RunPReS task communicates with a DPSM-PReS-Agent on a PReS server to create print output.  One PReS server can be used by several DPSM servers.

 

Connections

Connections provide information on how to access local or remote resources. At the moment the following types of connections exist in our system:

FTP connection

MAP connection

PReS connection

 

This module provides a connection interface. A list of available connections of a specified type (i.e. ftp, map) is received from the database. It then provides methods to access the data behind these connections.

 

DB Modules

The DB module is our interface to the SQL database.  It is thread-save which means that several threads can use it at the same time.  Besides, it has the ability to handle a fixed number of connections to a database.

 

User interfaces

Every part of DPSM that the User interacts with is regarded as a user interface.  If remotely plugs in and it does not matter on which machine the user interface is loaded.  One DPSM server can have several GUI's attached to it at the same time.  User interfaces can be:

Operator GUI

Administrator GUI

Console user interface

Accounting tool

Report generator

E-mail notification

SMS notification

Web monitoring tool

 

The concept of user interfaces provides a powerful and flexible way to do future enhancements because each user interface is its own application and it only has to implement a well defined interface to DPSM.

 

User Interface can for example trigger the following DPSM actions:

Manual start of a given job

Terminate the DPSM service

Suspend running processes

Resume process

Perform database operations like adding, deleting or modifying jobs, triggers, user, etc.

 

They are also able to receive events from the server.

 

All external user interfaces plug into the User Interface Module by using standard TCP socket connection. On a specified port the user interface manager is listening and serves queries.

 

Process

A process basically is a running job that has got a few additional properties like:

current file list (i.e. PReS output more than on files)

time started

current progress

...

 

The system can handle several simultaneously running processes. Processes can be suspended, resumed and terminated by the operator.

 

It actually performs everything a running process has to do, e.g. fetch files, deliver files etc. executes each in the process chain.