Email Task Exceptions

[conradi]

Hi,

The email task is a quite useful simple task - however, I think in it's current form it is hardly usable in a productive environment: any failure (be it a missing / invalid email address or a failure on the server side) is propagated as exception to the workflow, where it cannot be handled gracefully. <!–break–> It is possible to write a delegate for that or to write an own mail task - and we have done exactly that. More precisely, we have changed the activiti implementation by writing the error information into process variables: The workflow can then e.g. query for this process variables in a gateway.

I know the problem has been discussed here before (e.g. http://forums.activiti.org/content/how-can-i-manage-errors-generated-mailtask, in particular http://forums.activiti.org/comment/8887#comment-8887), but would nevertheless like to to ask again: How is the chance for an out of the box mail task implementation which offers more support for exception handling?

Heinz-Dieter

[jbarrez]

Well the answer is typical: when a jira is created we can follow up on it, weighted against other priorities. To be fair, expanding the mail task is not something that's currently high on that list.

You say that you have a custom delegate, one thing that would speed up tremendously is if you can share that through a pull request. That way, you're sure it's added quickly to the code. Of course we are here to assist with that and where everything should go etc.

[conradi]

I am aware, that the priorities have to be weighted.
And my post can be read as a question if it makes sense at all to send possible patches.

Unfortunately, I can't use github, but can of course give a patch which modifies the MailActivityBehavior in such a way, that no exception is thrown, but instead the error info is written into process variables (added as attachment, the patch is against 5.11, but should apply against 5.13)

[frederikherema1]

The patch uses the "set variable instead of fail" behavior always. Existing users can depend on the error occurring and might have other ways of retying/error-handling (e.g. Using async=true on email-activities and use job-mechanism for retrying/error-trapping). We can only accept this patch if the existing behavior is (by default) kept and the "new" behavior can be turned on using configuration on the XML…

[abentan]

Hi, in my opinion this problem is critical, simply the system crash in production environment if any problem with the mail server happens, or even more, if only one recipient of the email is not a current email address in the server. I had to change the MailActivityBehavior also, commenting:
[java]
throw new ActivitiException("Could not send e-mail", e);
[/java]
and adding:
[java]
     logger.warn("Could not send email:" + e.getMessage());
     logger.debug("", e);
[/java]

[trademak]

I would welcome an additional Activiti attribute where you define if you want the task to fail if the mail could not be sent. And based on this attribute you could change the exception throw to a logging statement like you did.

Best regards,

[conradi]

Coming back to an old topic.
We are currently upgrading our 5.11 codebase to use the current 5.15.1 release, and I would like to get rid of the mail patch.

When speaking of 'activiti attribute' do you mean something like:

<code>
  <serviceTask id="sendMail" activiti:type="mail" activiti:throwMailException="false">
</code>

or something like:

<code>
<extensionElements>
    <activiti:field name="throwException" expression="false" />
  </extensionElements>
</code>

But even more important, in my previous patch I wrote the information about the exception into a process variable, so that it can be used later in the workflow, e.g. by a gateway:

<java>
  private void handleException(ActivityExecution execution, String msg, Exception e) {
    log.log(Level.SEVERE, msg, e);
    execution.setVariable("EMAIL_ERROR", Boolean.TRUE);
    execution.setVariable("EMAIL_ERROR_MSG", msg);
  }
</java>

Would that be acceptable?

[conradi]

I created a new patch (including new tests) based on the assumption that the configuration is done with an extensionElement.
The old behavior is only changed when ignoreException is explicitly activated.

[trademak]

Thanks for the patch. Applied it with some small changes in the following commit:

https://github.com/Activiti/Activiti/commit/4b17821b1687ed671ee71f798099f48d8abe6efb

Best regards,

[conradi]

Thanks a lot!