Hi Guys,
I want to use a freemarker template to generate some HTML content for sending to a printer. Hence the content will include inline base64 encoded images rather then URL links. Hence the output is quite large, larger than the largest String process variable allows.
Hence this is my problem, Id like to use a freemarker script task to create the content, however by default it seems to get associated with a String process variable which is too large to persist. Even if I remove the variable before a flush, the history insert throws a too large exception.
Hence question, is it possible to force a freemarker script to use an Object variable type such that the process variable is stored as a Bytearray rather than a String?
regards
Rob
Why should the whole template be persisted as a variable in the engine?
Hi,
Its not that I need the template content persisted as a process variable, however thats the default behaviour of the engine… Hence in my process model, I have two tasks;
Render Content -> Print Content
Hence render content uses the freemarker template to merge with variables to produce a large HTML blob with inline base64 encoded images. Thus the next task, just takes this content and using say the java print service, sends the content to a printer.
Thus out of the box, the engine wants to assign the output of the freemarker task to a process variable in order that the next task can use it. I thought I may be able to outsmart the engine by calling removeVariable(…) before the engine flushes to the DB and thus avoid inserting a large HTML CLOB into the variable table. However, this did not go to plan and I still got an SQL too large exception.
My alternate is to use a service task and persist the large HTML file in a temporary file store, but I was hoping to do less coding and use more of the engines features if I could…
regards
Rob
Hi Rob,
The script task sets that object as a variable which is returned by the scripting engine. So in order to change the value type, you could implement a scripting engine (e.g. named freemarker-typed-value) that delegates to the Freemarker engine and wraps the result in an object value. That is certainly not a very nice solution but should work.
Regarding your solution idea with removeVariable, you could implement a custom history level and drop those history events that are related to the transient variables. That could be done by prepending a prefix to the variable name and deciding based on the name. Not a clean solution either.
The clean solution would probably be transient variables, i.e. variables that are never inserted into the runtime or history database. That is something we have discussed in the team on various occasions but not yet seen the necessity to implement.
Cheers,
Thorben
Thanks Thorben,
I like the idea of transient variables!
R