A community extension for Camunda Platform 7 to integrate emails in a process and interact with them. It was previously known as camunda-bpm-mail
.
- send mail
- poll mails
- delete mails
- react on incoming mails
Requirements:
- Camunda Platform 7 >= 7.20.0
- Java 17
Read these instructions.
Add camunda-bpm-mail-core
as dependency to your application. Using Maven, you have to add the following lines to your POM:
<dependency>
<groupId>org.camunda.bpm.extension</groupId>
<artifactId>camunda-bpm-mail-core</artifactId>
<version>1.5.1</version>
</dependency>
Add camunda-bpm-mail-core-1.5.1.jar
to your application server (e.g. apache-tomcat-8.0.24\lib
).
Also make sure that you included the following dependencies:
- camunda-connect-core >= 1.6.0
- JakartaMail >= 2.1.2
- Eclipse Angus Mail >= 2.0.2
- slf4j-api >= 2.0.11
If you use Wildfly, follow the special instructions.
The extension is build on top of the Connectors API and provide some connectors for interacting with emails. The connectors can be used inside a process as implementation of a service task and are referenced by id. Use the Camunda Modeler to configure it.
<serviceTask id="sendMail" name="Send Mail Task">
<extensionElements>
<camunda:connector>
<camunda:connectorId>mail-send</camunda:connectorId>
<!-- input / output mapping -->
</camunda:connector>
</extensionElements>
</serviceTask>
See the connectors user guide how to configure the process engine to use connectors.
Connector-Id: mail-send
Input parameter | Type | Required? |
---|---|---|
from | String | no (read from config) |
fromAlias | String | no (read from config) |
to | String | yes |
cc | String | no |
bcc | String | no |
subject | String | yes |
text | String | no |
html | String | no |
fileNames | List of String (path to files) | no |
files | Map of String to file process variable | no |
The text or html body can also be generated from a template (e.g. using FreeMarker). See the example.
Connector-Id: mail-poll
Input parameter | Type | Required? |
---|---|---|
folder | String (e.g. 'INBOX') | no (read from config) |
download-attachments | Boolean | no (read from config) |
Output parameter | Type |
---|---|
mails | List of Mail |
If download-attachments
is set to true
then it stores the attachments of the mails in the folder which is provided by the configuration. The path of the stored attachments can be gotten from the Attachments of the Mail.
By default, the polled mails are marked as read. If the property mail.imaps.peek
is set to true
then the mails are just polled and not marked as read.
Connector-Id: mail-delete
Input parameter | Type | Required? |
---|---|---|
folder | String (e.g. 'INBOX') | no (read from config) |
mails | List of Mail | no1 |
messageIds | List of String | no1 |
messageNumbers | List of Integer | no1 |
1 Either mails
, messageIds
or messageNumbers
have to be set.
The extension provide the MailNotificationService to react on incoming mails (e.g. start a process instance or correlate a message). You can register handlers / consumers which are invoked when a new mail is received.
MailNotificationService notificationService = new MailNotificationService(configuration);
notificationService.registerMailHandler(mail -> {
runtimeService.startProcessInstanceByKey("process",
Variables.createVariables().putValue("mail", mail));
});
notificationService.start();
// ...
notificationService.stop();
If you use a mail handler and enabled downloadAttachments
in the configuration then it stores the attachments of the mail before invoking the handler. Otherwise, you can also trigger the download manual by calling Mail.downloadAttachments().
By default, the extension loads the configuration from a properties file mail-config.properties
on classpath. You can change the lookup path using the environment variable MAIL_CONFIG
. If you want to look up a file on the classpath, use the classpath:
prefix (e.g. classpath:/my-application.config
).
An example configuration can look like:
# send mails via SMTP
mail.transport.protocol=smtp
mail.smtp.host=smtp.gmail.com
mail.smtp.port=465
mail.smtp.auth=true
mail.smtp.ssl.enable=true
mail.smtp.socketFactory.port=465
mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory
# poll mails via IMAPS
mail.store.protocol=imaps
mail.imaps.host=imap.gmail.com
mail.imaps.port=993
mail.imaps.timeout=10000
# if peek = false then the polled mails are marked as read
mail.imaps.peek=false
# additional config
mail.poll.folder=INBOX
mail.sender=USER@google.com
mail.sender.alias=User Inc
mail.attachment.download=true
mail.attachment.path=attachments
# credentials
mail.user=USER@gmail.com
mail.password=PASSWORD
You can find some sample configurations at extension/core/configs. If you use a mail provider which has no configuration yet, feel free to add one. You can verify your configuration with the integration tests.
if you are running camunda in the environment that supports Mail Service and Java Naming and Directory Interface (JNDI), you can configure mail session in the container and make it available through jndi. Provide the jndi-name of your bound mail session within properties file mail-config.properties
like this:
mail.session.jndi.name=java:jboss/mail/MyMailSessionName
Please refer you container documentation to configure mail service.
If you do not need other properties then session configuration, you can even skip property file mail-config.properties
and specify your mail session jndi-name directly via MAIL_CONFIG
environment variable like this:jndi:java:jboss/mail/MyMailSessionName
. Ensure it starts with jndi:
The following examples shows how to use the connectors and services.
- Pizza Order
- poll mails
- send mail with generated text body
- delete mail
- Print Service
- using the MailNotificationService
- send mail with attachment
The mail connector cannot directly support Helm values files since it cannot assume the deployment environment is Kubernetes.
This is why it is configured via the MAIL_CONFIG environment variable and a properties file.
However, supporting Helm deployment is easily done by following:
-
Accept the mail configuration in your Values.yaml, like this:
... mail: smtp: auth: true port: 465 ...
-
Render the mail.properties file with a Helm template
mail.smtp.auth={{ .Values.mail.smtp.auth }} mail.smtp.port={{ .Values.mail.smtp.port }}
-
Put the mail.properties file in a ConfigMap and mount it in your deployment on /config/mail.properties (or anywhere else you prefer)
-
Set the MAIL_CONFIG environment variable to "file:/config/mail.properties" in your deployment
Depends on the input of the community. Some ideas:
- provide element templates for camunda modeler (not supported yet)
- integration of file process variables
- spring-based configuration
Found a bug? Please report it using GitHub Issues.
Want to extend, improve or fix a bug in the extension? Pull Requests are very welcome.
Want to discuss something? The Camunda Forum might be the best place for it.
See also
It can be that Google blocks the requests because it estimates your application as unsafe. You may also receive an email from Google. To fix this go to https://www.google.com/settings/security/lesssecureapps and enable less secure apps.