Work Queue Classes
The Work Queue Class is a part of the model which defines how a work queue message looks (what fields it has), how it gets composed and what special operations (beyond some default ones) you can execute on it.
A Work Queue Class is always based on an Entity. If it is a database entity, you can use data events to automatically create messages based on data changes (e.g. creating a message when the record’s state changes). If you base your queue class on a virtual entity, you can only create messages using a sequential workflow or loading it from an external source (e.g. e-mails).
ORIGAM Root model already contains built-in work queue classes for:
- Text Files
- Binary Files
- E-mails
Messages to these queues can be loaded using built-in external loaders which help you to scan a folder with files and loading them for further processing or checking your POP3 or IMAP mailboxes.
When defining a new work queue class you need to:
- Right click on an entity
- Choose Actions > Create Work Queue Class…
- Select the fields you want to appear in the queue message list. You do not need to define a UI model (screens) for work queues. The GUI is generated automatically by the definition of the work queue class.
- Press OK.
This action will create the following model elements:
- New work queue class
- New data structure on which the queue class data storage is based. If you need to extend the queue class e.g. by adding new fields, you will have to extend this data structure, too.
New fields were added to WorkQueueEntry in the Root package in 2023.1. This entity is a base for concrete work queue entry data structures. If you have work queue data structures created in an earlier version and you want to run the project i 2023.1 or higher version of Origam you have to add these fieds into your data structures: InRetry, LastAttemptTime, NextAttemptTime, AttemptCount. See current version of the Root package for details.
The GUI of the queue is generated dynamically based on the information from the work queue class data structure. All fields (except of the IAsapEntity2 fields) will be displayed. All uniqueidentifier fields need to have a lookup specified otherwise they will not appear in the GUI.
Attributes
These are the attributes of a work queue class:
| Notification | |
| NotificationFilterPkParameter | A name of a parameter (resulting from the selected NotificationLoadMethod) to which a value in the refId column will be passed. That means e.g. if your work queue class is based on a Project entity it will pass the project’s Id to your parameter. |
| NotificationLoadMethod | A method that will load the notification record. This will typically be a filter which will load a record by its primary key. |
| NotificationStructure | A structure that will contain all the information needed to construct a notification using a Notification Template (defined by a user through ORIGAM GUI). |
| Other | |
| ConditionFilter | In case the class is based on an entity you can optionally provide a filter which will pass only some of the records (e.g. only outgoing invoices). |
| Entity | A work queue class can be based on an entity. In that case you can use data events and configure that a message is created e.g. on a state change. If it is not based on an entity the only way how to create messages is programmatically (using a Work Queue Service Add Method in a sequential workflow or using an External Loader). |
| EntityStructure | In case the class is based on an entity you need to provide a structure through which the entity’s record will be retrieved. |
| EntityStructurePrimaryKeyMethod | A method using which a single record for an entity will be retrieved. A single parameter is expected. |
| RelatedEntity1 (-7) | In case the class is based on an entity and some of the fields are not just a copy from the original entity but are looked up (e.g. you store a text version of customer’s name for a Project based work queue) you can specify which entities this record depends on (in this example the Project’s queue would depend on BusinessPartner entity from where the name was looked up). So when you change a customer’s name all the related records in the queue will get updated with the new name. |
| WorkQueueItemCountLookup | A lookup which will return a number of messages in the queue. You can provide your own in case you have a custom ListMethod that provides only a subset of messages to the user in order to also provide a correct message count. |
| WorkQueueStructure | A structure which defines the message’s fields and their links to the internal storage (WorkQueueEntry entity). |
| WorkQueueStructureSortSet | Optional sort set if you need the data in the queue sorted (e.g. newest e-mails first). |
| WorkQueueStructureUserListMethod | A method which will get a list of queue messages when a user displays the queue’s contents. You can use this to customize the filter e.g. to filter out some entries by date (display only invoices due) or by row level security (display only my own projects). |
| UI | |
| DefaultPanelConfiguration | Here you can preset the default look of the grid (column widths etc.). |
See Also
Work Queues
Work queues allow a user (admin) to create instances of work queue classes using ORIGAM GUI.
Extending Work Queue Notifications With a New Contact Type
It comes handy when you want to send notifications to recipients that are to be computed dynamically based on the data.