Good template practices for mailtask notifications?
Many users are complaining about the bulk notifications using the WorkflowMail and prefer to get just-in-time notification with nicely formatted message subject field, etc.
But using the flowable mailtask makes every mailtask separate from the others.
Are there any good practices for managing templates with the flowable mailtask?
As far as I understand, the html mailtask supports JUEL ( Java Unified Expression Language (sourceforge.net)) instead of the velocity templating available through WorkflowMail.
This makes it difficult to use functions and repeated elements, for example to display the datetime, the url of the instance, etc.
Any good ideas on how to manage notifications?
arthurburkhardt
Posted 4 years ago · Edited 1 year ago·Last reply 3 years ago
10 comments
arthurburkhardt
OP4 years ago · EditedIf someone is interested, I created an idea to request the extension of the
mailbean to allow for non-grouped emails to be sentIdeation Platform – Collibra | Product Resource Center
arthurburkhardt
OP4 years ago · EditedI just had a very nice coaching session with @shiroshana.tissera who provided very nice advice on how to solve it.
Instead of defining mailTasks, I created a sub workflow that can be called either within a script task or a subprocess task.
Benefit 1: the message creation and notification stay together, offering better visibility
Benefit 2: Less boxes running around, I can manage everything by code
Benefit 3: The template is managed within the subprocess, which means I don’t have to play around with groovy-lib or any other resources.
There does not seem to be too much of a performance impact vs using a mailtask.
Now, I just don’t know whether I should use the
workflowInstanceApi.startWorkflowInstancesor theworkflowInstanceApi.startWorkflowInstancesInJobmethod.I guess the only difference is blocking vs asynchronous call, so only the behavior varies…
arthurburkhardt
OP4 years ago · EditedI just had a very nice coaching session with @shiroshana.tissera who provided very nice advice on how to solve it.
Instead of defining mailTasks, I created a sub workflow that can be called either within a script task or a subprocess task.
Benefit 1: the message creation and notification stay together, offering better visibility
Benefit 2: Less boxes running around, I can manage everything by code
Benefit 3: The template is managed within the subprocess, which means I don’t have to play around with groovy-lib or any other resources.
There does not seem to be too much of a performance impact vs using a mailtask.
Now, I just don’t know whether I should use the
workflowInstanceApi.startWorkflowInstancesor theworkflowInstanceApi.startWorkflowInstancesInJobmethod.I guess the only difference is blocking vs asynchronous call, so only the behavior varies…
Lakhbir Singh
·4 years ago · Edited@arthur.burkhardt - I have been doing this in my workflows. Today, I have run into an issue where I am also changing the email body. I am expecting to send emails to multiple users with different email body. I am updating the email body in ‘format Email’ script and using execution.setVariable() to set the variable. Trying to use that variable in the MailTask HTML section. It’s not picking up that variable. Emails are going to all users but content stays the same. In the subprocess, I am trying to figure out the way to include the person name in the body so it’s personalized. Let me know if anyone know how to do that.
arthurburkhardt
OP4 years ago · EditedYou have to be mindful about variable scopes.
In this case, the function is only aware of “subject” and “body”. If you try to add names without passing the variable to the function, it will not work.
Is this what you are trying to do?
Former User
·3 years ago · EditedTry and turn on the Sequential flag to true (in multi-instance) on the Transaction where you put the loop for the mail task.
Sequential flag on the transcation and not on the mail task i mean.
This would solve your problem.
Former User
·4 years ago · EditedHey Arthur,
It would be nice indeed to have better templating available.
With your IDE setup though, potentially you can make your own conventions and have your deployment scripts appropriately place them where they need to go?
Even if it did simple things like adding in a comment in the final mail task to tell you which script box / template was used that you can look directly within your project similar to what you have done with scripts.
It might save you a click or two!
Former User
·4 years ago · EditedHey Arthur,
I’m not sure if this is what you are asking for / is the problem you are describing, but for me when I use a mailtask, I have a script task just before it which holds all of the logic required (e.g. generating the HTML with variables substituted in) and then just use these as the final variables to go into the mail task. This way I can simply copy the script task and plonk it before any mail task if I want to reuse the same sort of template.
A clunky way of having more “tempalated” outputs would be to have multiple script tasks which just progressively add to the same output variable (e.g. htmlTemplate), so you could easily chain them together to create various template outputs.
Again, not sure if this is what you were looking to achieve or not, but thought I’d give my 2 cents
Former User
·4 years ago · EditedHey Arthur,
I’m not sure if this is what you are asking for / is the problem you are describing, but for me when I use a mailtask, I have a script task just before it which holds all of the logic required (e.g. generating the HTML with variables substituted in) and then just use these as the final variables to go into the mail task. This way I can simply copy the script task and plonk it before any mail task if I want to reuse the same sort of template.
A clunky way of having more “tempalated” outputs would be to have multiple script tasks which just progressively add to the same output variable (e.g. htmlTemplate), so you could easily chain them together to create various template outputs.
Again, not sure if this is what you were looking to achieve or not, but thought I’d give my 2 cents
arthurburkhardt
OP4 years ago · EditedThanks for pitching in!
Yes, at this time I’m using a similar approach which looks like this:
def formatEmail(subject, body) { return "<some html>${subject}[...]${body}</some html>" } def subject = "${asset.name}: Meaningful notification" def body = "The asset ${assetLink} bla bla bla" execution.setVariable("email", [to: userExpression, subject: subject, body: formatEmail(subject, body)])And I’ll configure the mailtask like so
Problems and next steps
Reusing functions
Apparently, it is not possible to store functions in the execution process context. So I need to redefine myformatEmailfunction in each script task In this case I'll upload theformatEmailfunction to the groovy-lib folder so that I can reuse it without redefining it.MailTask readability
Just seing${email.body}does not meaningfully describe the content of the email. So each time I have to figure out what script is responsible for generating the message (ok, ok, it's really easy, but still, couple more clicks :smile:). I would love that we could use something like a velocity template in here.