Central to a Business Support System, with Sales Order, Accounting, and Logistics is the ability to run tasks in the background. Some time ago, I wrote Job::Machine
, a module for Job queue handling using PostgreSQL. Now I needed it for my own little system, and decided to have a place where I can see the status and result of the tasks - certainly better than using SQL all the time.
So no I have a Djet page listing all the tasks, with their status and results, and it can even link to any file returned from Job::Machine, provided the mime_type is set properly. Forgive me for not including a screenshot, but it looks
basic, and my web design department is, erh, still on vacation.
Technically, it requres a new basetype, one (and only one) node entry and the JobMachine Engine. Of course Job::Machine also has to be installed. The Job::Machine process will hand off the task to a handler in the ::Jobmachine namespace. This handler sets up the necessary environment and performs the necessary methods.
While working on this specific problem, and the Sales Order System in general, I realized that Djet really needed a place for the business logic. It's really separate from the Engine, and not a DBIx::Class thing. The M
part of MVC, if you like.
So I began stuffing all the code for handling orders, invoices, jobs, importing and exporting into the ::Model namespace. It's really more of a convention than an embedded system construct, but it works. The code is available from the Engine, and also from the Job::Machine tasks.
That means that ::Engine and ::Jobmachine namespaces call the functionality in the ::Model namespace, making it simple to spin off heavy tasks to background processes.
So, finally I feel that the architecture is in place. Every bit sits happily at its own little desk and does what it's supposed to do, and nothing more.