Output Management WAS: [Re: How to implement bulk printing of documents?]

[Jacopo Cappellato <ti...@sastau.it>]

David E. Jones wrote:
> 
> On Feb 13, 2007, at 3:46 AM, Jacopo Cappellato wrote:
>>
>> What about implementing something more robust in this direction?
>> I'm thinking of implementing document processor and distribution 
>> features for the OFBiz framework.
>> The idea is this:
>>
>> * when a user submits a report creation request (e.g. an invoice), he 
>> has also to provide the distribution channel (file, mail, print, fax, 
>> etc...) and also the physical device options (to and cc email address, 
>> printer name, fax number etc...)
>> * the request is stored in a record somewhere (a new entity or 
>> something existing, in the Content component?, or just the JobSandbox 
>> entity) with the following information:
>>
>> jobId|status|screen path|input context(serialized?)|output channel 
>> (print/mail etc...)|output options (e.g. \\printserver\prt01, num of 
>> copies etc..)
>>
>> * an async service listens to this entity and process the report 
>> creation requests, then updates the status there
>>
>> For set of documents we could simply create many records in the above 
>> entity.
>>
>> Does it make sense?
> 
> Yeah, I think so. Sounds interesting.
> 
> As far as my thoughts on which to go: rather than having job management 
> just for this, it might be nice to use the service engine job management 
> for it and just store parameters in the persisted context and such. The 
> service engine job management is pretty feature rich on a low level, but 
> it needs some enhancements to the management UI. That is actually of the 
> areas that may see some work during the dev conference.
> 
> -David
> 

Ok, I will look into the details in this direction.

The next steps could be:

a) review the existing job scheduling services and entities (what is 
missing or should be enhanced to properly support output management?)
b) ui: enhancements to the webtools
c) ui: implement a new screen in WorkEffort for "My Submitted Jobs" 
where a user can see the job scheduled by him and maybe further filter 
the list to see the one of 'type' output (aka documents)
d) create a generic service (similar to the one used to send emails), 
that given a context, a printer name, and a screen name (the template 
for the document) can be put in the job queue (async, thus visible in #b 
and #c) and once executed will create a pdf and send it to the printer


Misc ideas:

A) if we store the persisted context in the JobSandbox, then the same 
job can be re-run to recreate the document: the contaxt is passed to the 
screen definition, the actions (minilang/bsh) are run and the context is 
filled with data, that is then shown on screen by the widgets/fo templates
B) as an alternative option to #A, we could also give the ability to 
store the persisted context AFTER the actions are run, so that, if we 
rerun the job (aka recreate the document) the context is immediately 
served to the widgets/fo templates: this would be a nice way to "store" 
the documents (like invoices etc...); do you think it is possible/useful 
something like this?

Anyone interested in this?
Ideas, remarks?

Jacopo