In the world that is constantly running on high pace, people have less and less time to interact with software via sophisticated user interfaces. Especially in situations when there is a need to make a decision or provide quick feedback.
It's no different when it comes to business automation, where number of processes, rules and cases interact with each other to fulfil particular business goal. But at some point there is a need to have human participation one way or another.
Regardless of the information human actor needs to provide, they need to be put in context to make a proper decision or answer given query. Obviously tailored UI and forms can achieve this but that will usually require people to be notified about awaiting task and then switch to some other application to know more about the task and the work that is expected from them.
But what if they are no online or simply overlooked the notification... hmm and the notification itself how is that handled....
To provide an alternative approach (well know and constantly in use) email messaging can be used. In most of the cases notification is already send over email. Then a logical choice would be to use the same mechanism to respond to that notification over email too. And this is exactly what this article is about - interacting with processes over email.
What does it cover?
It's no different when it comes to business automation, where number of processes, rules and cases interact with each other to fulfil particular business goal. But at some point there is a need to have human participation one way or another.
Regardless of the information human actor needs to provide, they need to be put in context to make a proper decision or answer given query. Obviously tailored UI and forms can achieve this but that will usually require people to be notified about awaiting task and then switch to some other application to know more about the task and the work that is expected from them.
But what if they are no online or simply overlooked the notification... hmm and the notification itself how is that handled....
To provide an alternative approach (well know and constantly in use) email messaging can be used. In most of the cases notification is already send over email. Then a logical choice would be to use the same mechanism to respond to that notification over email too. And this is exactly what this article is about - interacting with processes over email.
What does it cover?
- first and foremost - notification and completion of user tasks - users can be directly notified over email that there is a task waiting for their action, users can simply reply to that email to complete their tasks
- start process instance by email
- start case instance by email
- upload documents to your processes (as part of task completion for instance)
Implementation
Let's have a look what is included in the email integration:
- KIE Server extension that allows to simply make use of it with KIE Server
- task event listener that sends email notification when task is created
- message extractor with default implementations (for plain text and text with attachments)
- handlers to react to received messages (after they are extracted)
- two default implementations - complete task and start process
jBPM notification uses IMAP to listen on given folder for new messages and process them immediately once they are available. To do that, it uses IDLE command so it can be notified by the mail server without of any poll based mechanism. The only poll is done once it starts to look up if there are any (unread) messages in the folder and if so process them.
Mechanism is as follows
Message extractors are responsible for parsing source message and extracting relevant information, this can be based on various criteria such as "from" email address, "to" email address, subject, MIME type and more. Based on that information, only one can actually be used to process message and thus MessageExtractor has priority that allows to control in what order extractors will be tried. Moreover, extractors usually deal with only one MIME type so they can be nicely written (and tested).
On the other side, all handlers are always invoked for single message that was extracted. Since handlers actually bring the logic what to do with message, they should also include logic to ignore message if not applicable for it. For instance it does not make sense to start process instance for a reply message - as this is most likely referring to existing user task. So it's up to handler implementation to deal with these situations.
For instance a CompleteTaskHandler will only react to message that have In-Reply-To header and it's in expected format (containing container id and task id). All other messages will simply be skipped. StartProcessHandler will actually ignore all messages that do have In-Reply-To header present.
Default implementations
CompleteTaskHandler
jBPM notifications comes with complete support for handing user tasks - it integrates easily with sending email notifications and handling replies. So there is not much you need to do if you want to take advantage of it. Maybe just provide your custom email templates to send emails with your brand, or extract information relevant to your domain.
StartProcessHandler
you can send email to jBPM and it will automatically create new process instance for it. How does it do it?
- it expects that the subject of the email to be ContainerId:ProcessId
- message content will be set as process instance variable called "messageContent"
- "from" email address will be used to find the user in jBPM and set it as "sender" process instance variable
This is the basic way to integrate email with process engine, you can provide your custom handlers that will do whatever else is needed. maybe include some email markup in the message that will make it simple to parse and find relevant data. All in your hands.
TextEmailMessageExtractor
capable of extracting plain text from email that uses "text/plain" as content type.
MultiPartTextEmailMessageExtractor
capable of extracting both text and attachments from email that uses "multipart/alternative", "multipart/mixed"as content type
More message extractors can be added, no limitations there, they are always invoked based on their priority (that is defined as part of the implementation).
Sample use case
To illustrate how it actually works and what it can do, let's take a look at very simple personal assistant build with jBPM and drools. So it has a single process as shown below:
It then uses business rules to match question with best answer if possible, if it cannot find any answer it delegates that to human so someone from the staff could reply. This could be later on enhanced with "learning capabilities" so whatever human actor replied is put into the system and next time such question would be asked, then system can reply directly.
Watch this short screen cast to see it actually in action.
Simple but shows how little effort is needed to make this a useful feature, and who knows maybe that kind of functionality is needed in some domain....
This is not yet integrated with jBPM but if you think that it makes a good candidate then reach out to us via mailing list.
