Job::Machine integration

Integrating Job::Machine into Djet, and the birth of the Djet::Model namespace
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 horriblebasic, 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.


Fields in bold are mandatory
Email Address