Patent Application
20090281862
1. Related Patents
This patent is related to commonly owned, co-pending United States Patent Application Serial Number (RSID 1-560) filed herewith and entitled MULTI-LAYER WORKFLOW ARCHITECTURE which is hereby incorporated by reference and hereinafter referred to as the “Architecture patent”.
2. Field of the Invention
The invention relates to the field of print shops and, in particular, to a graphical editor for creating jobs based on device capabilities operable as a standalone editor or in a workflow architecture for a print shop having a multi-layer platform for handling workflows in the print shop.
3. Discussion of Related Art
A print shop generally refers to a workplace where printing is performed, typically to provide commercial printing services. Customers use print shops to print catalogs, manuals, books, magazines, brochures, etc. Print shops may be large production print shops that implement large inline printers (i.e., continuous feed printers) to print long run-length jobs for a few customers. For example, a large production print shop may print customer bills for a credit card company. Most print shops are smaller shops that print short run-length jobs for many different customers. For example, a small print shop may print magazines, catalogs, books, brochures, etc, for a variety of different customers.
Because most small print shops service many different customers, the small print shops have to be able to change their workflow and system configuration to handle different jobs. A workflow generally refers to some organization of resources, devices, and roles in a print shop for providing printing services. For example, a small print shop may include a black and white printer, a color printer, a cutting device, and a binding device. For a workflow of one customer, the print shop may use the color printer and the cutting device to generate brochures for this customer. For a workflow of another customer, the print shop may use the color printer, the black and white printer, the cutting device, and the binding device to generate books for this customer. Due to the needed flexibility of the small print shops and the cost of new, large inline devices, many of the devices in the print shop are either offline devices (requiring human configuration and control) or near-line devices (accepting electronic configuration, but still requiring human control) as opposed to inline devices (which can be both configured and controlled electronically). Thus, to switch configurations quickly to handle different types of jobs, the small print shop does not need to re-configure an inline system, but may instead use the offline devices or near-line devices.
Many print shops, but not all, use software to help manage the flow of work throughout the shop. Some shops have a single software system that is capable of representing every activity, situation, and device in the shop, and use the software for that purpose; other shops use separate software systems to represent different parts of their shops; and some shops have no software at all, managing their devices and activities physically, or via printed instructions. For those shops which have devices or activities which can be and are in fact controlled by software, we can consider the workflow architecture of a print shop to be the platform upon which a job is created or generated, and then subsequently executed on the devices in the print shop. Among such shops, the typical workflow architecture as presently practiced comprises software that is run on one or more computers in the print shop. Such software is customized for each print shop based on the particular devices used in the print shop and the type of jobs that will be handled in the print shop. For instance, if a print shop has two printers from two different vendors and a cutting device from another vendor, then the customized software for that print shop is programmed based on those specific devices being used.
The customized software allows a print shop operator to create one or more jobs, manage the jobs, schedule the jobs, etc. To provide such functionality, the operating parameters, capabilities, and other information for each of the devices (i.e., the printers, cutting devices, binding devices, etc) in the print shop are defined in the customized software. The customized software may provide a job editor that displays the devices in the print shop and their associated capabilities to the print shop operator. The print shop operator may then create a job by selecting one or more devices in the print shop, and by defining the activities to be executed by each of the devices for the job. For instance, the print shop operator may first select a color printer to print a particular printable file (e.g., a PDF file) to generate printed pages. The print shop operator may then select a cutting device to put one or more creases in the printed pages to generate brochures.
When the job is created through the job editor, the customized software transmits messages to the devices selected for the job. The messages indicate what printable files are needed for the job (if any), and what activity or activities should be executed on that particular device. Messages such as these are often referred to as job tickets.
It is an ongoing challenge to create jobs based on a simple, intuitive graphical user interface and also to create jobs that are assured to be capable of being processed in the particular workflow processing application. For example, some present job editors in workflow architectures for print shops or as standalone job editors are difficult to use. They may, for example, define jobs in terms of relatively cryptic or obscure, textual interface oriented, command language syntax. Further, for example, some present job editors in workflow architectures do not account for changes in the capabilities of devices as they may change based on the activity in the workflow environment or based on the particular job's sequences of activities/devices selected by the user. For example, a user may define a sequence of devices/activities in a job such that the output of a particular device/activity renders the output material or information unusable as input to the next device/activity. Present job editors may not detect such erroneous configurations of a job. Thus the user of present job editors may generate a job that is not capable of being processed in the print shop in its present state of operation with a particular selected sequence of devices/activities.
Embodiments of the present invention solve the above and other related problems by providing a graphical job editor. The graphical job editor also provides dynamically updated information regarding the devices and activities available for defining a job with the graphical editor. The graphical job editor may be operable in a workflow architecture such as described in the Architecture patent and as described herein. Such a workflow architecture includes a workflow front end as one layer, a service bus as another layer, and service providers as another layer. The workflow front end represents the layer that provides the interface to print shop operators or other users. The workflow front end may provide the graphical job editor features and aspects hereof for creating jobs as well as a workflow controller for managing the execution of jobs, etc. The editor uses a description of device capabilities of each device to interact with the user to create a job. Device capabilities for an identified device describe a set of activities that the device can perform; each activity describes a set of resources it requires and resources it produces. Each resource can have an internal, hierarchical structure, every element of which is defined and described by a set of named attributes (numbers, text, and so on). The editor also includes a user interface operable to display a graphical representation of each identified device and operable to receive user input defining a job comprising a plurality of activities from the displayed devices. The editor further includes a linking module coupled to the user interface to receive the job and operable to verify that the output resource of a device activity comports with the input resource of the next device activity in the defined order. The editor enables the user to organize any number of activities into a sequence by connecting the output(s) from one or more activities to the input(s) of one or more other activities; an input can be connected to an output as long as the two items are of the same type. For example, a stack of paper output from one activity may be used as input to another activity if that second activity also expects to receive a stack of paper as an input; a file output from one activity may be used as input to another activity if that second activity also expects to receive a file as an input. In this way, all activities in a job can be arranged into an order of execution, described by the activities' dependencies on each others' resources. A job generator associated with the editor then generates and outputs a job ticket by arranging the activities into a well-defined format.
The invention may include other exemplary embodiments described below.
The same reference number represents the same element or same type of element on all drawings.
Embodiments provided herein describe systems and methods for creating jobs to be processed, such as in a print shop, using a graphical job editor that presents near real-time capabilities of each device/activity in the print shop. The systems and methods may be implemented in a specific workflow architecture used in the print shop. Thus, the workflow architecture is described below and in
Workflow architecture 100 is implemented as a multi-layer platform in this embodiment. The first layer (Layer 1) is the device-level layer. Layer 1 is comprised of one or more service providers 111-114. Service providers 111-114 are each associated with a device 101-104 in the print shop. A service provider comprises any system, software, or module that is operable to store and/or report capabilities of the devices 101-104. Device capabilities comprise any data or information that describes or indicates the ability of a device to perform actions or services in the print shop. The device capabilities may define the input for a device (i.e., an input device capability), an output for a device (i.e., an output device capability), and/or any operating parameters or device configuration used to perform an action or a service. A service provider may also be operable to perform one or more activities using its associated device. For example, if a service provider is associated with a printer, then the service provider may be operable to execute a printing activity on the printer.
A service provider may also be operable to execute one or more activities using its associated device. For example, if a service provider is associated with a printer, then the service provider may be operable to execute a printing activity on the printer.
The second layer (Layer 2) of the architecture 100 is a service bus 122. A service bus comprises any system, software, or module that is operable to store or integrate device capabilities for a print shop, and execute (manage) jobs in the print shop. A job comprises any task that defines one or more activities to be performed in a print shop. For example, a job may define a printing activity, a cutting activity, a binding activity, etc.
The third layer (Layer 3) of the architecture 100 is a workflow front end 132. A workflow front end comprises any system, software, or module that is operable to provide a user interface that allows a print shop operator or another user to create a job. The workflow front end is further operable to provide a user interface that allows a print shop operator or another user to view the status of jobs being executed in service bus 122, and/or to manage the jobs in service bus 122. Although one workflow front end 132 is illustrated in
One type of job ticket that may be used is a Job Definition Format (JDF) job ticket. A JDF job ticket is in XML format, and describes a job ticket, a message description, and message interchange. A JDF job ticket includes information that enables a device to determine what files are needed as input (if any), where the files are located, and what activities the device should perform. Other messages may be communicated in the workflow architecture 100 as Job Messaging Format (JMF) messages. JMF is part of the JDF specification. A JMF message is in XML format, and allows for communication of events (start, stop, error), status (available, offline, stalled, etc.), results (count, waste, etc.), and other details. The well known JDF standards are created and maintained by The International Cooperation for the Integration of Processes in Prepress, Press and Postpress Organization (CIP4) and are publicly available at www.cip4.org.
Workflow controller 204 provides user interface functions for service bus 122. When a job operator creates jobs through job editor 202, the jobs are transmitted to service bus 122 for execution. Service bus 122 schedules the jobs for execution, and executes the jobs as scheduled. Workflow controller 204 provides a user interface that displays the schedule of jobs to the print shop operator, and also allows the print shop operator to change the schedule of jobs. When a job is executed in service bus 122, workflow controller 204 provides a user interface that displays the status of the job. The print shop operator may also manage the jobs that are being queued or executed in service bus 122.
Integrated device capability database 302 may be further operable to register or unregister service providers 111-114 as needed or desired. For example, if a device 101-104 (see also
Job scheduler 304 comprises any system, software, or module adapted to receive and store job tickets from workflow front end 132, and schedule the stored job tickets for execution. For example, the received job tickets may be JDF job tickets. Job scheduler 304 may schedule the jobs according to an algorithm (e.g., first in first out), according to instructions from the print shop operator, or according to some other method.
Job controller 306 comprises any system, software, or module adapted to execute a job ticket (or a job defined by the job ticket). When job controller 306 receives a job for execution, job controller 306 is adapted to identify the activities defined in the job, and identify the service providers 111-114 to perform the activities defined in the job. Job controller 306 is also operable to generate process messages that request the identified activities be executed. A process message comprises any type of message that request or instructs a device to perform or execute one or more activities. In one example, the process message is a JDF job ticket. Job controller 306 is further operable to transmit the process messages to the identified service providers 111-114 so that the activities requested in the process messages may be executed.
Job controller 306 is also operable to receive the status of activities of a job. Job controller 306 may modify a job based on the status of one or more of the activities, such as by substituting one activity on a device 101-104 (see also
The device capabilities for a device 101-104 may be defined in a service provider 111-114 in a variety of ways. For example, the device manufacturer may define the device capabilities for a device according to a format set forth for workflow architecture 100. In another example, the manufacturer or provider of the workflow architecture may define service providers or device capabilities for multiple devices that may be part of a print shop. The appropriate service providers may then be activated if a new device is added to the print shop. In another example, a print shop operator may dynamically define the device capabilities of a device, such as through workflow front end 132.
Process controller 404 comprises any system, software, or module operable to execute one or more activities (e.g., job step activities) on a device 101-104. When process controller 404 receives a process message from service bus 122, process controller 404 is operable to identify the activity or activities to be executed in the process message, and execute the activity or activities using its associated device 101-104. For example, if the process message comprises a JDF job ticket, then process controller 404 processes the JDF job ticket to identify what files are needed as input (if any), where the files are located, and what activities the device should perform. Process controller 404 may then convert the JDF job ticket into device-specific operational commands in the format compatible with its associated device 101-104, and transmit the device-specific operational commands to its associated device 101-104 to execute the activity identified in the JDF job ticket.
Process controller 404 is also operable to monitor the status of activities being performed on its associated device 101-104. Process controller 404 is also operable to report the status of the activities to service bus 122. Process controller 404 may use a JMF message to report the status of the activities to service bus 122.
This multi-layer workflow architecture 100 (see
To illustrate how workflow architecture 100 operates in the print shop,
As previously stated, service providers 111-114 store device capabilities for their associated devices 101-104, such as in device capabilities database 402 (see also
In step 504, service bus 122 receives the device capabilities from service providers 111-114. Integrated device capabilities database 302 (see also
In step 506, workflow front end 132 receives the device capabilities from service bus 122, such as in job editor 202 (see also
In one alternative, workflow front end 132 may generate a web page that indicates the device capabilities of devices 101-104 in the print shop. The web page generated by workflow front end 132 may be part of an online store provided by the print shop. A customer may then view the web page, and select one or more of the devices 101-104 and one or more of the activities to be performed by the devices 101-104 as a subset of the device capabilities. A job may then be generated at the customer end, or may be generated in job editor 202 based on the selections by the customer. If the job is generated at the customer end, then workflow front end 132 receives the generated job from the customer over a network, such as the internet.
Service bus 122 receives the job, such as in job scheduler 304 (see also
One or more of the service providers 111-114 receive a process message from service bus 122. Through process controller 404 (see also
Service providers 111-114 are each able to identify the status of the activity executed using its associated device 101-104. Service providers 111-114 then transmit the status of the activity to service bus 122. Service bus 122 transmits the status of the activities of the job to workflow front end 132. The status of the activity may be transmitted in workflow architecture 100 in a JMF message. Workflow front end 132, such as through workflow controller 204, then indicates the status of the activities to the print shop operator. The print shop operator may then monitor the status of the entire job.
The print shop operator may manage or modify the job that is being executed in service bus 122. For instance, if one of the devices 101-104 encounters an error or becomes unavailable, then the print shop operator may modify the job to define a new device 101-104 or a new activity. Similarly, service bus 122 may automatically modify the job based on the status of the activities. If one of the devices 101-104 encounters an error or becomes unavailable, then service bus 122 is able to modify the job to replace this device with another device in the print shop to perform the activity.
As with workflow architecture 100 shown in
At some point during operation, each service provider 611-617 reports the device capabilities for its associated device 601-607 to service bus 122 so that service bus 122 has real-time information on the device capabilities of each of the devices. The device capabilities may be provided in a declarative language, such as Extensible Markup Language (XML). An exemplary device capability definition relating to a printer is discussed below in conjunction with discussion of the graphical job editor.
Service bus 122 receives the device capabilities from the service providers 611-617, and integrates the device capabilities into an integrated device capabilities database. The device capability database represents the entirety of the activities and devices available in the print shop. Service bus 122 then provides an integrated device capabilities file to workflow front end 132, such as responsive to a request from workflow front end 132.
Workflow front end 132, responsive to receiving the integrated workflow capabilities file, provides a user interface that displays or otherwise indicates activities that may be performed using devices 601-607 based on the device capabilities indicated in the integrated device capabilities file. Because the device capabilities indicate the devices 601-607 that are available and the activities that are available, the print shop operator may select one or more of the devices 601-607 and one or more of the activities performed by the devices 601-607 as a subset of the device capabilities. Assume for this embodiment that the print shop operator wants to create a bound instruction book.
To create the instruction book, the print shop operator may first select one of the printers 601-603 to print the instruction book, and may also indicate the printable file to be printed on the selected printer, such as a PDF file. Because the interior pages of the instruction book are in black and white, assume for this example that the print shop operator selects black and white printer 602 through the user interface to print the pages of the instruction book. The instruction book is also to be bound in some manner, so the print shop operator may next select binder 604 or bookmaker 605 through the user interface to bind the pages of the manual. Assume for this example that the print shop operator selects binder 604 through the user interface to bind the printed pages of the instruction book. The desired size of the instruction book may be smaller than the paper stock available in black and white printer 602, so the print shop operator may next select one of the cutters 606-607 to cut or trim the printed pages down to the correct size. Assume for this example that the print shop operator selects guillotine cutter 607 through the user interface to cut the bound, printed pages.
In addition to selecting the black and white printer 602, binder 604, and cutter 607 to perform particular activities, the print shop operator may view the operating parameters (e.g., resources) for these selected activities on the selected devices, and set or change the operating parameters (resources) as desired. For example, the print shop operator may select a particular type of paper stock from black and white printer 602. The print shop operator may set the cutting parameters for cutter 607. The adjustable parameters for each of the activities for each of the devices will be displayed by workflow front end 132 through the user interface.
Responsive to the input from the print shop operator, workflow front end 132 generates a job ticket (e.g., using graphical job editor 202). Because the job is created based on the device capabilities of black and white printer 602, binder 604, and cutter 607, the job is virtually guaranteed to be executable on service bus 122. In this example, the job ticket comprises a JDF job ticket. The JDF job ticket describes the activities that are to be performed by black and white printer 602, binder 604, and cutter 607. The JDF job ticket also includes a location of the PDF file for the instruction book. Workflow front end 132 then transmits the JDF job ticket to service bus 122.
Service bus 122 receives the JDF job ticket, and processes the JDF job ticket to identify the activities defined for the job. Service bus 122 also identifies the service providers 611-617 operable to perform the activities, which are service providers 612, 614, and 617. Service bus 122 then generates another JDF job ticket or re-uses the JDF job ticket for each of the service providers 612, 614, and 617. The JDF job tickets each indicate what files are needed as input (if any), where the files are located, and what activity (or activities) should be performed, and provide any additional information (e.g., resources or parameters) specified either by the user or as default values in the capability description. Service bus 122 then routes a JDF job ticket to service provider 612 (which is associated with black and white printer 602).
Service provider 612 receives the JDF job ticket from service bus 122. The JDF job ticket is written in XML format. For example, the following illustrates an example portion of a JDF job ticket transmitted to service provider 612 which indicates the type of finishing to perform:
Service provider 612 also monitors the status of the printing activity on black and white printer 602. To report the status to service bus 122, service provider 612 transmits a JMF message back to service bus 122 indicating the status so that service bus 122 may monitor the overall status of the job. For example, service provider 612 may transmit a JMF message indicating when the printing activity has ended.
After the printing activity has been completed, the output from black and white printer 602 comprises printed pages for the instruction book. The next step in the workflow is to bind the printed pages. Because binder 604 is an offline device, the output from black and white printer 602 is not automatically sent to binder 604 as input. Thus, service bus 122 instructs the print shop operator to manually insert the printed pages in binder 604—in other words, the human operator (a device) is instructed to execute the activity of inserting printed sheets into binder 604 to bind them. Service bus 122 also routes a JDF job ticket to service provider 614 (which is associated with binder 604).
Service provider 614 also monitors the status of the binding activity on binder 604. Service provider 614 may rely on input from the print shop operator as the status of the binding activity (e.g., completed or not completed). Service provider 614 then transmits a JMF message back to service bus 122 indicating the status so that service bus 122 may monitor the overall status of the job. For example, service provider 614 may transmit a JMF message indicating when the binding activity has been completed.
After the binding activity has been completed, the output from binder 604 comprises bound, printed pages for the instruction book that have to be cut to the appropriate size. The next step in the workflow is to cut the bound, printed pages down to the desired size. Because cutter 607 is a near-line device, the output from binder 604 is not automatically sent to cutter 607 as input. Thus, service bus 122 instructs the print shop operator to manually insert the bound, printed pages in cutter 607. Service bus 122 also routes a JDF job ticket to service provider 617 (which is associated with cutter 607).
Service provider 617 also monitors the status of the cutting activity on cutter 607. Service provider 617 transmits a JMF message back to service bus 122 indicating the status so that service bus 122 may monitor the overall status of the job. For example, service provider 617 may transmit a JMF message indicating when the cutting activity has been completed.
After the cutting activity has been completed, the output from cutter 607 comprises a completed, bound instruction book. Service bus 122 may then execute the job again to generate another copy of the instruction book as desired.
The print shop operator may manage or modify the job that is being executed in service bus 122. For instance, if black and white printer 602 encounters an error or becomes unavailable, then the print shop operator may modify the job to utilize black and white printer 603 instead. Service bus 122 then stores the modified job as a modified job ticket.
Graphical job editor 202 interacts with a user through a suitable interactive user device 1102. Device 1102 may be, for example, a standard personal computer or workstation or any other suitable display device with interactive input devices associated therewith. Exemplary of such input devices are: a keyboard, a pointer device, voice recognition capabilities, and touch screen input capabilities, etc. Where the device 1102 is a computer system (e.g., personal computer or workstation) job editor 202 may operate on the same device and utilize the display and user input devices of that computer system for its user interaction.
Based on the device information and device capability information received by graphical job editor 202 and based on user interaction through device 1102, graphical job editor 202 generates a job ticket 1116 describing a job to be processed in the associated environment. In one exemplary embodiment, graphical job editor 202 may be utilized in a print shop to define a JDF job ticket. In other embodiments, the job ticket may define a job for processing in a generalized workflow processing system—i.e., for print shop operations or any other workflow.
Graphical job editor 202 may include device information interface 1104 for receiving information regarding devices and device capabilities from source 1101. As noted above when embodied within a workflow processing system architecture, interface 1104 may interact with the service bus to receive device information and associated device capabilities. Job editor 202 may also include user interface 1106 to interact with a user through device 1102. User interface 1106 generally presents each of the devices identified in the received device information on a display screen of device 1102. In addition, interface 1106 presents on the user's display screen the one or more activities that each device is capable of executing. Interface 1106 then interacts with a user to select activities of one or more selected devices in a defined order to thereby define a desired job. In addition, user interface 1106 interacts with a user through input devices associated with device 1102 to permit the user to select or define values for the various resources defined by the device capabilities (i.e., received information) associated with the selected devices defining the job.
As generally noted herein above, device capabilities for each device may include at least an input resource defining desired input for the selected activity of a selected, associated device and an output resource defining output generated by the selected activity when performed on the selected device. Linking module 1110 verifies that the job defined by the user as a sequence of activities to be performed by identified selected devices is valid and operable in the present environment. In particular, linking module 1110 verifies that the input resource of each selected activity comports with the output resource of the preceding activity in the sequence of activities that define the job. Thus linking module 1110 and user interface module 1106 cooperate to assure that the user defines a job that may be performed within the present environment. By contrast, prior job editor systems and processes permit a user to generate a job that may be impossible to perform in the present environment because particular activities of selected devices cannot practically be combined with other activities for requirements of a particular job. Graphical job editor 202 provides the user (through user interface 1106) only those devices and corresponding activities known to be available in the present environment and verifies that the input resources and output resources of the various selected activities comport with one another in the defined order.
Job generator 1112 receives the defined job following verification by linking module 1110 and generates a job ticket 1116 based on the defined order of activities defined by the user input through user interface 1106. The generated job ticket 1116 may then be utilized for processing the job represented therein. In the context of a print shop, the job ticket may represent a job to be processed within the print shop by utilization of the selected activities of the selected devices in the defined order within the print shop.
Further features of the job editor 202 include device capabilities update 1108 operable to modify a local copy 1114 of the device presently available and device capability information retrieved through device information interface 1104. Actual capabilities (e.g., permissible values to be associated with resources of particular activities of selected devices) may change dynamically based on the particular definition of a job. For example, the output from one activity of a selected device in a defined job may restrict an otherwise broader range of potential input resource values to a next activity in the defined job. Device capabilities update 1108 is operable in cooperation with user interface 1106, linking module 1110, and the local copy of the device and capability information 1114 to dynamically update information in the local copy 1114 based on the particular defined order of activities and devices selected by the user to define a new job.
For example, in the context of a print shop, job editor 202 could allow a user to select a folding activity on a folding machine device. The input resource to the folding activity may specify printed paper and the output resource of the folding activity may specify folded printed paper. A next device in a defined job could be a cutting device where a cutting activity is selected. The device may be capable of accepting paper (an input resource) in a particular weight range suitable for cutting. However, the paper generated as output from the folding activity of the folding device may have an effective weight of twice that of the input to the folding machine (i.e., if folded in half). Thus, the cutting device may be incapable of cutting the full range of paper weights it is normally capable of processing since each sheet of paper may be folded and thus have an effective weight of two or more times the nominal (unfolded) weight of the sheet of paper. Device capabilities update 1108 therefore serves to monitor the particular sequence of activities and devices in the defined job to update any device capabilities of an activity based on its particular ordering relative to other activities in the job.
Device capabilities update 1108 may be invoked to perform its update after a user has defined a complete job. In such a scenario, device capabilities update 1108 may further validate the defined job based on an update of the local copy of the device capabilities 1114 for the particular defined order of the selected activities. In addition or in the alternative, device capabilities update 1108 may be invoked in conjunction with user interface 1106 as a user interacts to add or remove an activity from a job being defined. For example, as user interface 1106 processes user input to add a new activity to the job, device capabilities update 1108 may then be invoked to modify any device capabilities that may be affected by the new combination of activities in the defined order of the job. In like manner, removal of an activity previously added to the job may be cause for device capabilities update 1108 to be invoked to restore or otherwise update capabilities based on the new defined order of the remaining selected activities in the job. Device capabilities update 1108 may thus validate or invalidate the particular selection based on these updated device capabilities.
Those of ordinary skill in the art will readily recognize that the modifications or updates performed on device capabilities are based on a local copy (e.g., a working copy) of the device capabilities 1114 as utilized by the bob editor in defining this particular job. An original or archival version of the normal device capabilities provided by source 1101 will remain unchanged such that this or other job editors may utilize the same initial device capability information when commencing construction of their respective jobs. In particular, in the context of the earlier described workflow processing architecture, the service bus retains the original device capabilities regardless of how the job editor 202 updates its local copy 1114 to define a job.
As noted above, device capability information may be provided as textual information such as may be encoded in a markup language including, for example, Extensible Markup Language (XML). In general, device capability information includes: a name of a device, the name of one or more activities provided by the named device, and resources associated with one or more of the activities provided by the device. A device may provide only a single named activity. For example, in the context of a print shop, a cutter device may be capable of providing only a single activity—namely cutting. A folding device may provide a single activity—namely folding. By contrast, a multifunction device in the context of a print shop may be capable of providing multiple activities including, for example, printing, copying, scanning, etc.
For each activity provided by a device a plurality of resources may be defined. For example, an input resource and an output resource should be defined for each activity provided by a device to define the input(s) required for the activity and the output(s) generated by the activity. Various other resources may be defined to characterize other operating parameters or features of the device. The input resource(s) defines the parameters of the input utilized for processing by this activity of this device while the output resource(s) defines parameters of the output generated by processing of this activity of this device.
In the context of a print shop operation, the exemplary XML device capability description below defines a “Print” activity of a printing device named “Printer #2”.
Those of ordinary skill in the art will readily recognize the hierarchical nature of the exemplary XML listing where a “device” includes an “activity” which, in turn, includes “input” and “output” resources. Lines 0003 through 0016 in the exemplary device capability listing above define input resources for the “Print” activity of device “Printer #2”. Lines 0017 through 0019 define output resources for the same activity of the same device. The lists of input and output resources for this Print activity on this exemplary Printer #2 both describe a resource named “Paper”. In other words, this activity on this device receives paper as input and generates paper as output. In addition, various other input resources are listed. For example, “FileToPrint” is a named resource of the input device capability as is “NumberOfCopies”. Both are resources that may be defined in the list of input resources of the Print activity of device Printer #2. Still further, the “Paper” resource has three attributes that may be assigned values by a user. A “Size” attribute shown as having three potential LegalValues (“Letter”, “11×14”, and “11×17”) as well as a DefaultValue of “Letter”. A “Weight” attribute having six potential LegalValues (20, 40, 80, 120, 140, and 250) and an associated default value of 20. A “Glossy” attribute having two potential LegalValues (On or Off) and an identified default value (Off).
This exemplary device capability description presents one exemplary activity for one exemplary device such as may be found in a print shop. Any number of activities may be defined within each of any number of devices for a particular environment. The graphical job editor may receive device capability descriptions for all devices, activities, and resources defined in the present environment (e.g., in the print shop). The graphical job editor may then present all identified devices and their respective activities and resources to the user through the interactive user interface and receive user input to select the desired activities in a defined order to thus define the desired job to be performed.
Any of several well-known graphical interface and techniques may be utilized for selecting activities to be added to a new job, for removing activities previously added to a new job, and for re-ordering the activities in a newly defined job. For example, in addition to the depicted “Add” and “Remove” buttons (1206 and 1208), a user may “drag and drop” a new activity from the list 1202 of available activities and devices onto the ordered list of selected activities defining a new job 1204. Similar “drag and drop” techniques may be used to remove a previously added activity from the new job 1204 or to re-order activities previously added to the newly defined job 1204. Numerous such graphical user interface techniques will be readily apparent to those of ordinary skill in the art.
For each activity added to a newly defined job, values may be defined for one or more device capabilities associated with a particular selected activity of a selected device. Again, in the context of a print shop, a printer device may provide numerous device capabilities (attributes) useful to define operation of the printing device. As noted, every device preferably includes at least an input device capability and an output device capability defining attributes of the input to be applied to the selected activity of the device and the output generated by processing of a selected activity of the device. The user may utilize well-known graphical interface techniques to define device capabilities of the selected devices. For example, a selected device in the list of the newly defined job 1204 may be “double clicked” or “right clicked” to provide a screen suitable for user input to define attributes of the various device capabilities for the selected device.
As shown in
Referring again to the device capabilities update features discussed above, a range or plurality of otherwise legal values for a device capability may be reduced due to the affect of another activity in the defined order. For example, the number or range of permissible values for an input resource of a cutter device may be reduced because a particular job adds the cutting activity to a job after a folding activity. With reference to
Still further, a wide variety of types of data may be presented based on the definitions for resources and attributes in the device capabilities information for a selected device. For example, a default resource value to be used as the resource or attribute value in the absence of user input specifying the resource or attribute value. Legal values may be specified as an enumerated list of permitted values such that the user input selects the resource or attribute value from among the permitted values. Or, a range of permitted values may be specified wherein the user input defines the resource or attribute value from the range. Still further a regular expression mask defining permitted character strings to be assigned as the resource or attribute value may be specified wherein the user input defines the value as a character string matching the regular expression mask. Still further the data values may be any of several basic data types including, for example, a numeric value field; a numeric range field; a date value field; a date range field; a plain text field; enumerated lists of potentially legal values; etc.
In one exemplary embodiment of the invention, step 1408 optionally updates a stored local (“working”) copy of the device capability information for the selected devices and activities based on other activities in the defined order of the job. As noted above, input or output resources of an activity may be modified based on other activities that provide input to a newly selected activity or utilize the output of a newly selected activity. Thus step 1408 modifies the working copy of device capabilities for the devices and activities selected for the job to reflect such dynamic changes resulting from a particular combination or ordering of activities in the job.
Step 1410 then links the selected devices in the defined order by verifying that the input of each activity of the job comports with the output of any preceding activity. In other words, the inputs and outputs of each activity in the defined order of the job as selected by the user must be determined to be compatible such that the job will be operable to provide the desired output of the job. Step 1412 then determines whether the linking step 1410 detected an error in the compatibility of inputs and outputs of sequential activities of the job as defined by the user. If step 1412 detects an error, processing returns to step 1406 to receive further user input to further define the job or to redefine the job. If step 1412 detects no error in the sequence of activities and compatibility of their corresponding input and output device capabilities, step 1414 generates a job ticket describing the job to be performed as the ordered sequence of activities each with its respective defined device capability values. Those of ordinary skill in the art will also recognize that the error checking of steps 1410 and 1412 may be performed as a part of the user input processing of step 1406. In other words, as a user selects activities in a defined order, the job editor may validate that the inputs and outputs of the newly re-ordered activities remains compatible. An invalid attempt to add a new activity to the job may thereby be detected and rejected earlier in the process as the method interacts with the user.
To add a new activity to a job, step 1504 updates a local, working copy of the device capabilities for the selected activity based on the particular activity that precedes this new activity and based on the updated device capabilities of that preceding device and activity. Step 1506 then receives user input defining values for resources and attributes of the selected activity to be added. Step 1508 then updates the local, working copy of device capabilities for the activity (if any) the follows the newly added activity in the defined order of the job based on the updated capabilities of the newly added (inserted) activity. In particular, processing of step 1504 may be further operable to update the local copy of the device capabilities of all activities and devices that precede the inserted activity to whatever extent such updates may “ripple upstream” to other preceding activities and/or devices already defined in the job. In like manner, step 1508 is further operable to update the local, working copy of device capabilities of all activities (if any) that follow the inserted activity to whatever extent such updates may ripple downstream from one updated activity to the next. Step 1512 determines whether the user indicates completion in defining the new job. If the user input indicates a completed definition of all activities in the job, step 1514 completes the definition of the job returning the selected activities in the defined order with all device capabilities updated (in the local, working copy thereof). If step 1512 determines that the user is not yet done defining a job, processing continues looping back to step 1500 to receive further user input selecting yet more activities for the job or removing other activities therefrom.
Responsive to detecting a request to remove a device at step 1502, step 1510 updates the local, working copy of the device capabilities for all activities affected (upstream or downstream in the defined order of the job). Processing then continues at step 1512 as discussed above to determine if the job has been completely defined.
Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, embodiments of the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 1012 providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A computer system 1000 suitable for storing and/or executing program code will include at least one processor 1002 coupled directly or indirectly to memory elements 1004 through a system bus 1050. The memory elements 1004 can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices 1006 (including but not limited to keyboards, displays, pointing devices, etc) can be coupled to the system either directly or through intervening I/O controllers. Network adapter interfaces 1008 may also be coupled to the system to enable the computer system 1000 to become coupled to other data processing systems or storage devices through intervening private or public networks. Modems, cable modems, IBM Channel attachments, SCSI, Fibre Channel, and Ethernet cards are just a few of the currently available types of network or host interface adapters. Presentation device interface 1010 may be coupled to the system to interface to one or more presentation device such as printing systems and displays for presentation of presentation data generated by processor 1002.
Although specific embodiments were described herein, the scope of the invention is not limited to those specific embodiments. The scope of the invention is defined by the following claims and any equivalents thereof.
