Work queues define user managed flows where different items wait for user’s interaction. The user actions can be also automated so the queue system can be also used for automating tasks.
Each work queue contains messages which can be processed using commands. Some commands are presented as buttons so the user can decide which command to use (e.g. Approve or Cancel) or they can be processed automatically (e.g. incoming e-mails can be automatically stored into the system).
Work queues are visualized in the ORIGAM GUI where the user can see all the queues he has access to. By opening a queue all the items in the queue show together with the commands that can be applied to each item.
Why using queues?
In most of the systems there will come a requirement to display some kind of a list:
- List of postponed projects
- List of active tasks
- List of unpaid invoices
- List of orders to manufacturing
Typically these requirements are implemented just like that: as a list. Items in the list might get some context menu or buttons where the user could be even able to process the items further: opening the task, invoice, confirming order… Sometimes you can even predefine filters and columns visible in each list or you create reports. Those normally are not able to invoke any further activities.
So in reality, the list is not just a table listing different items, it is actually a materialization of a workflow. Items invoke actions and an item will appear in different lists in different times (new orders -> orders to bill -> orders with complaints). The same item would probably have different activities in a different list.
But there is much more you would expect when you start to imagine a workflow instead of a simple list.
- Showing different data at different times for the same item
- Showing different actions at different times and to different users based on security settings
- Automated processing using rules (all orders below $100 confirmed automatically)
- Notifications when new items appear
- Loading data from external systems for further processing (e.g. reading an e-mail inbox for importing into a CRM application)
Work Queue Message Sources
There are 3 ways on how a message get into the queue:
- From an entity when a configured data-event is triggered
- By composing it programatically in a sequential workflow
- Using an external loader (e.g. reading a list of e-mails from a POP3 mailbox)
Defining Work Queues
Work queue definition has two phases.
In the model
- Defining the work queue class
- Defining special processing actions (more complex than just changing a state or a value)
- Defining a special data loader
By the user
- Creating a queue based on the modeled work queue class
- Defining when item will appear and when it disappears automatically from the queue
- Defining available commands for this particular queue
- The Work Queue configuration screen is present in your ORIGAM application.
- A proper Work Queue Class has been prepared for your items
Work Queue Creation
A work queue is defined by a user (admin) using ORIGAM client application. Opening the Work Queues screen will allow you to define all the work queue parameters and define its behavior.
|Code||Abbreviated name of work queue.|
|Name||Name of work queue. Will be shown in the list of work queues in side menu.|
Work Queue Class used to parse and store messages. There is already several prepared classes, ready to use: BinaryFile, Mail, TextFile. For more classes and their documentation please contact your vendor.
|Roles||Semicolon separated list of application roles. Users having any role listed will be able to see and manage the queue in side menu Work Queue.|
|Active||Work queue processing (fetching new messages) can be disabled by this checkbox.|
|ErrorQueue||Mark queue as an error queue. Will be then listed in 'Error Queue' dropdown field in 'Commands' tab.|
|Lookup Field Values||Determine whether lookuped or plain values will be used in OldValue and NewValue filelds in tab Creation (State/Value Change).|
|Display Number of Messages||The number is displayed in side menu Work Queue next to work queue name.|
|Queue Processor||Specifies instance, which is supposed to process the queue. If empty, any instance will try to process the queue. If specified, only instance with the same name (configured in AsapSettings file by parameter Name) will process the queue.|
External loader can fill a work queue with messages based on an external data source, e.g. by loading e-mails, files or data from web services.
A command is an action that can be executed on a work queue message.
Notifications allow you to send an e-mail, SMS or any kind of a notification whenever a message appears in the queue.