The patent application is a continuation of a co-pending U.S. patent application having the Ser. No. 11/279,052, and filed on Apr. 7, 2006, which is incorporated by reference herein.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to the field of workflow systems and in particular to a workflow system design tool that enables significant customer configurability while allowing for definition of feature rich, complex workflow processes.
2. Statement of the Problem
A wide variety of systems entail processes that process information through a sequence of steps. In general, many such systems may be modeled and controlled as a workflow system wherein each step receives input, processes that input in some manner and forwards generated output to one or more next steps in the process. A complete process of such steps may be referred to as a process or a job. Workflow systems often allow for modeling of a complex sequence of steps including conditional evaluation for alternative paths or options through the entire workflow process.
Such workflow systems are frequently applied to a wide variety of workflows to model processes associated with a particular application area. In particular, workflow systems are frequently utilized to model workflows of data processing systems where input data is received by a step in the process, manipulated in various manners, and resulting data is applied to a next step in the process. Workflow systems may also be applied to model numerous other systems in a variety other application areas including, for example, process control systems such as may be common in manufacturing environments.
Workflow systems are sometimes created as customized programs designed and coded by system analysts and programmers designing and coding customized computer programs for a particular workflow processing application. Such a customized computer program may very closely model the underlying process but the development and maintenance costs are prohibitive in most environments. Other workflow modeling systems provide tools for more typical users to create new process models—e.g., without the need for skilled staff to create custom computer programs. These process modeling design tools aid an end user in creating a model for a new process and in maintaining the generated process models thus reducing or eliminating the need for skilled computer programmers and systems analysts. A number of workflow systems are available as commercial products that allow some degree of customization by a sophisticated end user. For example, IBM provides a product referred to as Infoprint Workflow (“IPW”) for such workflow process modeling in the context of printing systems management. IPW is widely known to those of ordinary skill in the art and information regarding IPW is readily available at www.ibm.com.
Some present day commercial workflow modeling design tool products are simple to use and thus obviate the need for costly, trained computer programming professionals. But most such systems are so simplistic that they cannot model complex processes. Other commercially available workflow modeling design tools are so complex that they entail such design complexity that most users still require the services of a highly trained professional to perform required setup, configuration, and customization. Further, such systems are sufficiently complex that any maintenance to the workflow definitions may also require services of a costly, highly trained computer professional.
It is evident from the above discussion that a need exists for an improved workflow system that provides both a high degree of flexibility in modeling even complex workflow systems and also provides a simple, easy to use architecture that allows a less sophisticated end user to easily define and maintain workflow systems utilizing the workflow system design tools.
SUMMARY OF THE SOLUTION
The invention solves the above and other related problems with methods and associated systems and apparatus operable to flexibly configure a workflow system to execute jobs. Features and aspects hereof provide for generating workflow models from configurable templates. The workflow models may include one or more phases, each comprising one or more processes, each process comprising one or more steps. The phases, processes, and steps may all be defined by configuring parameters of corresponding templates. Information defining the workflow models and all job information for jobs to be executed are entries in an integrated database such that creation and update of workflow model information and job information is performed as simple database queries and updates.
One feature hereof provides a method for managing a workflow processing system. The method includes storing job information in a database. The job information relates to one or more jobs to be processed by the workflow processing system. The method also includes generating a workflow model to process one or more jobs relating to the job information in the database. The generated workflow model is stored in the database and the workflow model is generated from configurable templates. The method also includes processing one or more jobs using the workflow model in the database and using the job information in the database.
Another feature hereof provides a system for workflow processing. The system includes a database for storing one or more workflow models and for storing job information relating to jobs to be processed in accordance with a corresponding workflow model. The system also includes a computing node coupled to the database and adapted to execute jobs using the job information and the workflow model in the database. The computing node is further adapted to generate and modify workflow models stored in the database. The computing node is also adapted to generate the workflow models from templates.
Another feature hereof provides a method for workflow processing. The method includes configuring a workflow model based on configurable templates. The method also includes storing the configured workflow model in a database. Still further the method includes generating job information about a job wherein the job is associated with the generated workflow model and storing the job information in the database. The method then includes executing the job using the job information in the database and using the workflow model in the database.
The invention may include other exemplary embodiments described below.
DESCRIPTION OF THE DRAWINGS
The same reference number represents the same element on all drawings.
FIG. 1 is a block diagram of an exemplary workflow system in accordance with features and aspects hereof.
FIGS. 2 through 4 are flowcharts describing exemplary methods for workflow configuration and execution in accordance with features and aspects hereof.
FIG. 5 is a diagram depicting exemplary phases of an exemplary workflow for print job processing in accordance with features and aspects hereof.
FIG. 6 is a diagram describing a particular example of two exemplary jobs processed in corresponding exemplary workflow models in accordance with features and aspects hereof.
FIG. 7 is an exemplary display screen for presentation of status information relating to jobs and devices in a workflow system in accordance with features and aspects hereof.
DETAILED DESCRIPTION OF THE INVENTION
FIGS. 1 through 7 and the following description depict specific exemplary embodiments of the present invention to teach those skilled in the art how to make and use the invention. For the purpose of this teaching, some conventional aspects of the invention have been simplified or omitted. Those skilled in the art will appreciate variations from these embodiments that fall within the scope of the present invention. Those skilled in the art will appreciate that the features described below can be combined in various ways to form multiple variations of the present invention. As a result, the invention is not limited to the specific embodiments described below, but only by the claims and their equivalents.
FIG. 1 is a block diagram of a system 100 providing flexible generation and configuration of workflow processing systems in accordance with features and aspects hereof. In particular, system 100 depicts a workflow processing system particularly as applied to a printing environment in which print jobs are performed or executed utilizing a variety of printing system objects 110 and in accordance with workflow models defined by elements of system 100. Primary workflow server 102 is a computing node used to generate workflow models in accordance with user input. A user may generally define a workflow model as comprising one or more phases, each phase including one or more processes, and each process comprising one or more steps that may in turn include conditional Boolean logic. Templates 104 are used by primary workflow server 102 to permit flexible configuration of a new workflow process by configuring attributes of standardized templates 104. In particular, templates 104 may include phase templates useful for defining new phases in a newly defined workflow model, process templates useful for defining each of the one or more processes within a newly configured phase, and step templates useful for configuring one or more steps in each newly defined process of each newly defined phase.
Flow is divided into phases, such as Receive or Prepare, and processes within those phases. A process is a sequence of steps that perform a logical set of actions on the jobs they process. Any particular job will flow through a particular set of phases, selecting a single set of processes in each phase. The ordered set of steps, grouped by the processes and phases that contain them, determine the workflow processing for a job.
Features and aspects hereof define how phases, processes, and states are represented in the system and how their interfaces are defined. Users of the workflow system, over time, build a set of reusable phases and processes that may be applicable to several offerings. For example, the Receive phase and its processes will likely be used in almost every application to receive an input job for processing. Exemplary embodiments described herein below discuss the phases, processes and steps needed for a printing enterprise application. The examples below are not intended to describe the complete set of functionality that can be supported, but rather suggest one concrete example of how the architecture can be applied in a specific case—print job workflows in printing enterprises.
Primary workflow server 102 stores the newly defined, configured workflow models as information in workflow database 108. In particular, the workflow models are stored in tables that define the relationships between the configured phases, configured processes, and configured steps as well as transition conditions for moving from step to step, from process to process, and from phase to phase in the workflow model. The configured phases, processes, and steps may be configured by appropriately setting attribute values and parameter values associated with the newly created entries in database 108. The templates 104 therefore provide a starting point for such configuration and the various attributes and parameters allow for significant flexibility in defining the ultimate workflow model for a particular type of job to be performed.
In addition to configured workflow model information, primary workflow server 102 also manages information relating to current jobs to be processed by system 100. A current job is associated with a particular configured workflow model to direct the processing of the job. A job type attribute may be used to associate a particular job with a particular workflow model—both stored in the workflow database 108. Primary workflow server 102 preferably includes a workflow engine processing element (not shown) that retrieves current job information for a particular job to be performed and retrieves information for the associated workflow model information and performs the phases, processes, and steps configured in the workflow model for the associated job.
One or more secondary workflow servers 106 may be provided to enhance the performance of the workflow processing system 100. Each secondary workflow server 106 may also include a workflow processing engine (not shown) to provide additional computational power for performing other workflows associated with other jobs or portions of a particular workflow for a particular job. Such distribution may include distributing different jobs to be performed to the various servers (and their associated workflow processing engines) or may include distributing individual steps, processes, or phases from a single workflow over the multiple servers 102 and 106.
To simplify coordination of such multiple servers accessing the common, shared workflow database 108, secondary workflow servers 106 may access workflow database 108 only through coordinated processing with primary workflow server 102. Those of ordinary skill in the art will readily recognize other mutual exclusion techniques and processing coordination approaches to help assure coordinated processing of one or more secondary workflow servers 106 and processing of primary workflow server 102 in concurrently accessing workflow database 108. In addition, the workflow database 108, per se, may be distributed using network storage architectures and other distributed storage and processing paradigms. Such distribution versus centralization techniques are well known matters of design choice for those of ordinary skill in the art.
As thus far described, workflow system 100 may be applied to processing of any jobs that may be described by a workflow model comprising one or more phases, each phase comprising one or more processes, each process comprising one or more steps. By way of example, system 100 includes printing system objects 110 accessed by the primary workflow server 102 and the optional additional secondary workflow servers 106 to perform workflow job processing for print jobs. The workflow servers (102 and 106) may access any of the various print system objects 110 as required to execute a particular print job in accordance with an associated workflow model. Print system objects 110 may include any number of print objects useful to execute print jobs including, for example, print engines 112, print servers 114, post processing elements 116, software or automated steps 118, and manual steps 122. In addition, print system objects 110 may include the actual print job data as it is manipulated and transformed through the workflow job processing. Print job data 120 therefore represents data associated with one or more print jobs in raw form as well as various translations and transformations thereof. For example, print job data 120 may be implemented as a print spool feature for spooling raw print data as well as rasterized or ripped print data as generally known to those of ordinary skill in the art. Other print related data may be stored with the print spool data. For example, control files describing configuration and operation of post-processing equipment may be specified in files associated with print data 120.
As applied to such print job workflow management, system 100 may, in accordance with the phases, processes, and steps of a corresponding workflow model, access the print engines, print servers, post processing element, software/automated and manual steps all for purposes of processing print job data 120 to effectuate eventual printing of the data on appropriate printable medium.
Those of ordinary skill in the art will readily recognize that workflow processing system 100 may be adapted to couple to any application specific objects associated with workflow processing of an associated job. Thus, print system printing system objects 110 are merely intended as one exemplary application of structures and methods of system 100. Further details of the exemplary application of system 100 to a printing environment such as shown in FIG. 1 are discussed further herein below.
FIG. 2 is a flowchart broadly describing a method in accordance with features and aspects hereof to generate and execute workflow models to process jobs in accordance with a configured workflow model. Element 200 is first operable to generate a workflow model from configurable templates. As noted above, the configurable templates may include phase templates, process templates, and step templates all useful for customizing and configuring a particular workflow model for a particular application. Unlike prior techniques, generation of a workflow model from flexibly configurable templates requires little professional engineering expertise such as is required for generating fully customized program instructions to implement a particular workflow model for processing of a job. Further, by contrast with other prior techniques, the configurable templates supplied in accordance with features and aspects hereof permit a high degree of flexibility in customizing or configuring particular phases, processes, and steps for a particular workflow processing application. Prior simpler workflow processing systems provided little or no configurability thus forcing the user to adapt the workflow processing application to the particular static model already defined by the workflow processing system. Users had little or no capability to easily customize or reconfigure the workflow system for particular desired workflow processing of particular job applications.
As noted above, a configured workflow model stored in the workflow database may then be executed by a workflow processing engine. The workflow engine (not shown) may be integrated with each workflow server and manages the processing steps required to produce the desired printed product by using information in the workflow database. These steps can be automatic or manual. The list of steps and the transitions between them are maintained in the database so that changing a process or creating a new process is a simple matter of configuring the appropriate database tables. Steps are modular and perform units of work with clearly defined interfaces. Steps may interface with system resources, such as a PostScript transform or an IBM PSF printer driver. Steps may interface with third-party software, such as address cleansing or inventory control. Steps may perform work directly on the database or the files associated with a job.
Element 202 is then operable to store the generated workflow model as information in the workflow database of the workflow system. A job type attribute or other suitable indicia may be used to identify the particular types of jobs for which the newly configured model may be applied. The database entries representing the workflow model information may be easily reconfigured by simple database query and update operations (such as the SQL query language) again utilizing the configurable templates provided in accordance with features and aspects hereof. As noted above, each database entry for the model generated from a template may include a wide variety of configurable attributes and parameter values to allow each phase, process, or step to be reconfigured for a particular new job or application.
Element 204 represents further processing to create a new job and store job related information in the workflow database. As noted above, the integrated database includes both the workflow model information and the job information for individual jobs. Thus the workflow database integrates all data for jobs being processed as well as the workflow model information describing the workflow processing to be performed for each of multiple types of jobs to be processed. The database tables contain entries for each job in the system, including all job metadata such as job originator, current processing step, number of pages, number of copies, desired paper stock(s), finishing needs, and so on. The database also is the repository for real-time data monitoring the print shop floor. Such printer characteristics as pages printed, currently-printing job, toner status, etc. can be kept in the database (assuming the printers are capable of reporting these items). Similar information can be kept on any print shop equipment, including inserters, finishers, etc. The database also maintains the history of jobs and devices and when the status of each job and/or device changed. This allows the system to report relevant statistics that might identify a device that needs service or an operator who is unusually efficient.
Job metadata may be any information associated with the job including, for example, billing or charge-back information, the desired delivery date, and any other information needed to produce the job. This information is often referred to a job ticket. Because the job ticket is in the database, any step that needs to access ticket information can easily do so. New metadata items simply add a new entry in the database and flow through the system without requiring system changes.
Having so generated and stored information regarding one or more jobs to be performed and one or more associated workflow models, elements 206 and 208 are then operable substantially concurrently. Element 206 is generally operable to execute the job using the job information and the generated workflow model information in the workflow database. Execution of the job generally entails retrieving information from the database for a next phase to be processed and for the next process and steps within that phase. The execution engine then retrieves associated job information and performs appropriate next steps in accordance with the customized, configured workflow model. Eventually, when all steps, processes, and phases for processing of a job have completed, execution of the job is thus completed and desired results obtained.
Substantially in parallel with operation of element 206 to execute jobs, element 208 may be operable to monitor status information regarding the jobs and the various workflow models associated with the various jobs. The status information so monitored may be presented to a user to provide near real time feedback as to the progress in processing each of the one or more jobs being executed within the workflow system. Status information regarding the various jobs and currently executing workflow models may also be stored within the database. Thus, element 208 is generally operable to retrieve current status information regarding the execution of each of one or more jobs within the workflow system and to present that retrieved status information to a user in near real time.
Those of ordinary skill in the art will readily recognize a wide variety of graphical user interface techniques for presenting such status information. Further, the status information may include information regarding each job presently executing or queued for execution within the workflow system, as well as status information regarding the various devices, components, modules and other elements used by the workflow system to execute each job known to the system. For example, as applied to printing systems as described above, status information may include status of each print engine known to the system, each print server known to the system, each post processing element known to the system, etc. Thus, in a single integrated database, all status information regarding the performance of the workflow system may be stored and retrieved for presentation to a user in accordance with operation of element 208.
FIG. 7 depicts an exemplary display screen useful for presenting such status information and for interacting with a user to control the state of devices and/or print jobs. A “System Summary” portion of the display screen summarizes the count of the number of print jobs in each phase of processing (e.g., Receive, Prepare, Print, Complete) and the count of print jobs in each state of each phase (e.g., Preprocessing, Active, Manual, Error). A “Printers” portion of the exemplary display screen shows a user the known printers and the status of each known printer. In addition, this portion of the screen may permit user interaction (e.g., through “click” buttons on the screen) such as to Enable or Disable a selected printer. Still another portion of the display screen presents detailed status regarding “Active Jobs In Print Phase”—in other words details regarding all print jobs presently printing in the Print phase of the respective workflow model. As above, this portion of the screen may provide “click” buttons for user interaction to change the state of a selected print job such as to Stop or Continue the printing thereof or to Process Again where a job needs to be reprinted. Those of ordinary skill in the art will readily recognize a variety of equivalent display and interaction techniques that may be employed to present status information regarding printers and print job or more generally any jobs and devices of a workflow system in accordance with features and aspects hereof. In particular, presentation of information regarding the present phase, process, step, and state of any job and the present state of any device in the system may be presented by retrieving corresponding information from the workflow database.
FIG. 3 is a flowchart providing additional exemplary detail of the operation of element 200 of FIG. 2. As noted above, element 200 of FIG. 2 is generally operable to generate a new workflow model based on configurable templates provided in accordance with features and aspects hereof. Element 300 of FIG. 3 is therefore first operable to add a new entry to the workflow database describing a new workflow model useful for processing an associated job type. Element 302 then adds an entry to the workflow database for a first or next newly created phase configured utilizing a selected phase template. As noted above, a user is provided with a rich collection of useful phase templates that may be easily configured to adapt to a particular desired workflow processing application or type of job. Thus, element 302 represents processing for a user to identify a preferred phase for adding to the workflow model by selecting the corresponding template. The newly created database entry for the phase is then customized or configured by operation of element 304 by configuring or setting attribute or parameter values associated with the selected phase template.
Element 306 is then operable to define and enforce any constraint rules associated with the newly created and configured phase. Such constraints are useful for helping to assure that the user does not improperly configure new phases or steps contrary to the user's own rules for the intended applications. Such rules may be defined as simple Boolean predicates testing, for example, whether a particular phase may occur first or must occur last, etc. The database entry for the newly defined phase is appropriately annotated to reflect the additional constraints or validation rules defined for the newly configured phase of the new workflow model. In addition, the defined rules are applied as the user continues to configure the new workflow model. Thus, element 306 represents processing not only to define the rules but to apply the rules to validate the current design. Other exemplary constraints are discussed in additional detail herein below.
Elements 308 through 312 are similarly operable to add one or more new database entries for new steps associated with the newly defined and configured phase. Each step to be added to the newly configured phase is configured by selecting a desired step template from the step templates provided by the workflow system. The selected template is then used to create a new database entry for the new step and the new step database entry is associated with the new phase currently being defined. In addition, element 310 represents further processing to define any appropriate transitions from the newly defined a step to other previously defined steps (if any) in this currently defined phase.
Transitions from step to step or from phase to phase are defined and provided as annotations to the various entries or may be defined as a separate table in the workflow database. Thus, a user may configure complex workflow processes by configuring any number of phases each including any number of steps and by specifically defining desired transition conditions from step to step and from phase to phase.
Element 314 is operable to determine whether more steps are desired to be defined in the new phase currently being configured. If so, processing continues to iterate through elements 308 and through 314 until no further steps need be configured in the new phase currently being defined. Processing then continues at element 316 to determine whether the user wishes to configure additional new phases in the new workflow model being defined. If so, processing continues looping back to element 302 until all desired phases have been defined in the new workflow model.
As noted above, in accordance with features and aspects hereof, phases may also include multiple processes such that each process within a phase may include one or more steps. Although not shown in FIG. 3, those of ordinary skill in the art will readily understand that the method may be simply modified to incorporate the definition of additional processes within a phase each of which then includes one or more steps.
FIG. 4 is a flowchart providing additional exemplary details of processing by element 206 of FIG. 2 above. As noted above with reference to FIG. 2, element 206 is generally operable to execute a job using job information stored in the workflow database and using generated workflow model information stored in the workflow database. Element 400 of FIG. 4 is operable to retrieve information from the workflow database relating to a selected workflow model. The selected workflow model is the workflow model customized and configured to process a job type matching that of the particular job to be executed.
As noted above a workflow model includes one or more phases of operation. Element 402 then determines whether more phases remain to be executed for the job presently executing in accordance with the present workflow model. If not, processing by element 206 is completed. If so, element 404 next determines whether a stop processing event or action has been encountered. A stop or pause in the processing of the job may be requested by detection of particular events such as by operator interaction or by any other suitable mechanism. In general, processing may stop upon completion of a phase or upon commencement of processing for a next phase.
If processing has been stopped due to detecting an appropriate event, element 406 is operable to await resumption of processing. Resumption may be requested in response to detection of another event such as by operator input or by other suitable mechanisms. When processing resumes, element 408 is operable to retrieve a next phase from the current model information retrieved from the database. Element 410 then determines whether any steps remain to be executed in the presently executing phase of the workflow model. If not, processing continues looping back to element 402 to continue processing additional phases of the workflow model (if any). If more steps remain to be executed in the present phase, element 412 is next operable to retrieve a next step from the model information in the workflow database. Element 414 then executes the retrieved next step and loops back to element 410 until all steps have been retrieved for the present phase and executed.
As noted above with regard to generation and configuration of the workflow model, each phase may comprise one or more processes which may, in turn, each comprise one or more steps. For simplicity and brevity of this description, discussion of processing of multiple processes within a phase has been removed. Those of ordinary skill in the art will readily recognize appropriate modifications to the method of FIG. 4 to incorporate processing of one or more processes within each phase of a work model.
Phases, Processes, and Steps
A job is executed in accordance with the phases, processes and steps configured as a workflow model and stored in the workflow database. Features and aspects hereof are therefore largely driven by a workflow engine that, in turn, retrieves its process flow information from workflow database tables. Changing the system processes is a simple task of configuration: i.e., changing the database table content. The only custom coding requirements are those needed for any new processing steps not previously anticipated by an earlier defined phase, process, or step template. Rearranging or eliminating steps in an existing process or phase requires no coding, only configuration.
A feature hereof that makes the system configurable is its use of SQL. For example, the list of jobs in a certain queue is simply an SQL query that lists the database entries with a specific queue name. To add a new queue, a user need only create a query that selects the jobs with attribute values related to particular attribute values of interest. Job metadata is simply attributes and values in a database table. To add a new item, a row is simply added to the metadata table. Such simple database transactions are well known to those of ordinary skill in the art and require little or no costly programming expertise.
In accordance with features and aspects hereof, workflow is divided into phases, such as Receive or Prepare, and processes within those phases. A process is a sequence of steps that perform a logical set of actions on the jobs they process. Any particular job will flow through a particular set of phases, selecting a single set of processes in each phase. The ordered set of steps, grouped by the processes and phases that contain them, determine the workflow processing for a job.
Features hereof define how phases, processes, and states are represented in the system and define their interfaces. As users use the system creating new workflow models and new templates, they will build up a set of reusable phases and processes that may be applicable to several workflow processing applications. For example, the Receive phase and its processes will likely be used in almost every workflow process to receive a new job for processing.
The descriptions herein above present features and aspects as broadly applicable to any general workflow application. Features and aspects hereof may also be readily understood with reference to a particular application, namely: workflow processing for print jobs in a printing environment. In large scale printing facilities for data processing enterprises, large numbers of print jobs may be generated and distributed over a similarly large number of printers, print servers, post processing devices, etc. One particularly useful application of features and aspects hereof is to management of workflow associated with processing print jobs in such a large scale printing environment.
Jobs and workflow models in the database may each be associated with a job type. The value assigned to a JobType attribute of a job determines the particular workflow processing a job receives when moving through the system. The JobType determines the choice and order of the phases within the workflow for each job. It also chooses the process within each of the selected phases. This is realized by the Job.Process.After.phase_name attributes and the Transitions table entries.
The workflow engine does not determine the transitions between processes and phases; that is left to the Transitions database table. When each step completes, the workflow engine invokes its ChangeJobState method to set the job to its output state and then to set the job to the input state of the next step according to the Transitions table.
Exemplary phase and steps templates are discussed herein below that are readily configurable for application to such large scale printing environment workflow processing systems. FIG. 5 is a block diagram broadly describing exemplary phases useful in processing print jobs in such a printing environment. Table 1 below more fully describes these exemplary phases, the inputs associated with each phase, the output generated by each phase, and a description of the purpose and operation of each phase.
Exemplary Phases for Print Job Workflow Processing