There are ten sample rules provided, which are automatically installed into the OPS Sample Rule Sets group. Each rule set is explained in its Info, which can be accessed from the Get Info item on the rule set's context menu, or the Get Info option in the File menu in Rule Set Manager.
The design intent is to have one master rule set which receives all orders from OPS (usually OPSReceiveOrder), one rule set for processing each type of order, and one rule set to post status updates back to the OPS web site for all orders (usually OPSPostStatus.)
Five order type sample rule sets are supplied, named OPSProcessXxxx. Typically you would create a rule set for each different type of item in the OPS Product Catalog.
- OPSFlushOrdersSilently: This rule set will process incoming orders but do nothing with them. This is useful if you want to turn off order processing in Prinergy without queuing the orders at the OPS end. (Under normal circumstances, the Prinergy system and OPS site cooperate to ensure that orders are never lost. If you disable the rule set that receives orders, then orders will be queued at your OPS site and resubmitted to Prinergy when you re-enable the rule set.)
- OPSReceiveOrder: This rule set is an example 'master' rule set, designed to be enabled at the system level to receive all orders from OPS. When an order is received, a Prinergy job is created for each item that was in the customer's shopping cart when the order was checked out. The jobs are created using a table of values to choose the appropriate template job in the "Create Job, select template based on order information" rule. Some information is saved in the job, and the job status is then set to In Prepress to start processing. The created job is named OPS-order-<cart-number>-item-<itemnumber> where the <cart-number> and <item-number> are unique numbers assigned by OPS to each shopping cart and item ordered on your instance. They may have some alphabetic characters before the numeric portion. You may change the names of the jobs created to match your naming conventions.
By default, this rule creates all of its jobs in the OPS group. If this is not desired, you could use the type of order and/or the customer information to select a group, for example.
CAUTION: If your OPS storefront includes stock items that are not meant to be processed through Prinergy, then this rule set must be updated to ignore such items because the OPS site will send all items to Prinergy. One way to ignore them is to add a branch that checks if there are any (PDF) file URLs in the item. If there are none, then the item is not for Prinergy. As of OPS version 12.1, you can have stock items which contain a high-resolution PDF and that PDF will be sent to Prinergy. - OPSHotFolderOrder: This rule set is a duplicate of the OPSReceiveOrder rule set, intended for debugging order processing rules. It is intended to be enabled on a Prinergy hot folder into which you would drop XML orders, instead of listening for orders directly from the OPS server. This allows you to test order processing without having to submit a new order on your OPS site.
CAUTION: This particular sample rule set requires that you rename or destroy the job created previously (if any) for the same order (because the RBA action to create a job will find the old job rather than creating a new one if a job of the same name already exists). - OPSProcessUpload: This rule set is one of two sample rule sets which process order items. It processes items where the user has uploaded a file to be printed. When you create Product Catalog items, you can specify custom fields that the user can or must fill in when placing the order. These customer-specific fields show up in the XML order file as "Extrinsic" elements which have a "type" attribute which is the title of the field presented to the user and a value which is what the customer input. These elements are a bit awkward to process in RBA, as you have to select the correct Extrinsic element using a Select One action and then pick up the value. See the "Get Contact Email"-"Save in Custom Field OPS_CustomerEmail" and "Get Contact Phone"-"Save in Custom Field OPS_Customer phone #" rules in the sample. You do not need to copy the extrinsic values to Prinergy custom fields; you can just process the values immediately. Note that the actual processing steps (Refine Input File, Publish File, and Create Document) are examples only.
- OPSProcess2SidedBusinessCard: This rule set processes a two-sided business card item. The example product item used for this sample had no extrinsic fields, so there is no processing of them in the rule set. For products similar to this business card sample, OPS provides a pair of plain PDFs for front and back, and imposed PDFs for front and back. This sample downloads the imposed PDFs. If you want the unimposed ones for your workflow, change the "Transfer order item files from OPS" rule accordingly.
This sample collects the front and back of the business card image from the OPS server and renames each of them to<itemnumber>_<front-or-back>.pdfso that they have a predictable name for later processing. This rule set is typical of the processing you would want to do if you need to rename the files coming from the OPS server. - OPSProcessKodakBC: This rule set assumes that you have a Kodak Nexpress digital press, and prints a two-sided business card using the imposing capability of the Nexpress. If you do not have a Nexpress digital press, the second to last action in the rule chain will be an unknown action, but the earlier part of the rule chain is still useful to examine. The final CreateDocument action has its Print Quantity parameter filled in with "Quantity * UnitSize / 20 + 1". In this example, the 20 is the number of business cards per sheet. This is a typical computation to determine the quantity to print.
Note: No attempt is made to determine which file is the front and which is the back of the business card. This is because the imposition we are using on the Nexpress will work with either the front first or the back first. See the OPSProcess2SidedBusinessCard sample for details on how to handle front/back issues when that is required. - OPSProcessProject: The purpose of this rule set is to suggest a way to begin processing a project item by breaking up the project pages and transferring each one from the OPS server. It is not necessarily indicative of the actual processing you would do for an OPS project order item.
Important: It is important that you give your project a real name which can also be used as a folder name, because it is used as one in this sample. - OPSProcessVPrint: VPrint items from OPS are actually sent to Prinergy twice. The first time the item has not been processed through the OPS scheduler so there is no processed file available. There is a test in the OPSReceiveOrder rule set which checks this and simply ignores items which are waiting for the scheduler. Once the item has been through the scheduler, it is passed to the OPSProcessVPrint sample rule. Note that you will almost certainly want to differentiate VPrint items according to the template used. This sample rule merely shows you how to pick up the VPrint output file and suggests that the quantity to print would be in the UnitSize order property (usual value is 1), not the Quantity property. This is because for a VPrint item, the Quantity property tells you how many items were in the VPrint input file.
- OPSPostStatus: This rule set posts status to OPS so your customer can see how their order is progressing. You can define various statuses to be posted to OPS—see the Configuration section above. The sample assumes that the order has been printed when the Prinergy job is marked as Complete.
- OPSTestReceiveCart: This rule set is intended for installation and configuration verification only. Do not forget to disable this rule after you have completed connectivity testing.