The Web Project Properties dialog now allows you to define settings for a 'Work Queue' table. The 'work queue' table is used when you want to perform some time consuming task.
Instead of performing the task immediately, you insert an entry into the 'work queue'. Another process (could be an Alpha Anywhere process, or another process - e.g. PHP, ASP.Net) is responsible for actually performing the work in the work queue. A common use for a 'work queue' is sending email. In a web app, if you want to send email, sending it immediately is often not a good idea because it can be slow connecting to a SMTP server. Instead a new entry is made to the 'work queue' table. Adding an entry to a 'work queue' is very fast. Another common use for a 'work queue' is printing reports. Printing reports can be quite slow, and you might prefer to have some other process (other than your App Server), handle the task of printing reports. There are new options in the 'Send e-mail' actions and the 'Print report' action to expose the 'work queue'.
Basically the primary motivation for adding the Work Queue (WQ) functionality is to allow you to offload work from the App Server so that the App Server does not get bogged down doing tasks that are not time critical. In that respect, the WQ is a really simple concept. So for example, when an application needs to send an email, it does not have to be done immediately. It will probably be OK, if the email is sent (say) in 2 or 3 seconds time, or perhaps in 5 seconds time, rather than immediately. Therefore, this task can be added to the Work Queue for later processing. At this point our focus has been on setting up the Work Queue infrastructure, i.e. writing an API for adding tasks to the Work Queue and reading data from the Work Queue. But we have not written a Work Queue Processor. At some point we are likely to write a Work Queue Processor, but there is no pressing need for us to do this because a developer could quite easily write his or her own custom WQ processor. A Work Queue Processor is just an Xbasic script (or other process) that reads a table, finds the next record that has not been processed, marks that record as locked, then does the work specified, and then finally marks the record as having been handled. When the WQ processor had no more work, it would either sleep for a minute, or schedule a new instance to run later and then exit. The beauty of this is that the Work Queue Processor does not have to be an Alpha Five process. For example, you might have a PHP or ASP.NET application that can handle certain kinds of tasks more efficiently than Alpha Five, and you could point your PHP application at the Work Queue table and let it process some of the tasks that it is well suited to handle. Since one of the fields in the Work Queue is the scheduled start time of a task, you could insert items in the Work Queue with a scheduled start time at some future point in time. By default, when you add a new item to the WQ, its scheduled start time is now. But it would be just as easy to add a task with a scheduled start time set to the future, for example sometime in the lightly-loaded nighttime hours. However, scheduling tasks is merely a by-product of the WQ. The WQ is not inherently a task scheduler. Another really attractive aspect of the WQ is that you can have multiple Alpha Five instances that are running simultaneously handling the load in the WQ. They would have to be careful to lock tasks in the queue before processing them, but this is not a terribly difficult problem.