Beginners Guide to Configuring an Email Service Task With a Process Automation Manager
In this article, explore something that the author stumbled on while trying to use email notifications in his automation project.
Join the DZone community and get the full member experience.
Join For FreeRecently, I've been updating my free online workshops, specifically the series based on JBoss BPM Suite, so that you can get started with the newer Red Hat Process Automation Manager.
In this article, I'm sharing something that I've stumbled on while trying to use email notifications in my automation project.
I discovered while updating this project that the email service task, a task type that should allow you to send emails from a process, is not pre-configured out of the box. Not only that, but I'm unable to find the solution online for the Red Hat Process Automation Manager.
Let's fix that and take a look at what's needed to get our emails flowing in our processes.
Configuring Email Tasks
Many years ago, I published a few articles around automating email user tasks. This included details requiring adjusting the underlying JBoss Enterprise Application Server mail configuration, but with the current version, 7.2, we're using that's working for your local machine right out of the box.
<outbound-socket-binding name="mail-smtp"><remote-destination host="localhost port="25"></remote-destination></outbound-socket-binding>
As you can see, the localhost port 25 will be used for binding all email activity that our Red Hat Process Automation Manager generates, so all we need to do is configure our current project to process the email task correctly.
Figure 2: Project settings for WIH's.
There are a few concepts in using a service task like email in our project. First off, any service task requires a Work Item Handler (WIH) to be defined for handling the task. In our case, it's defining the email task to use a WIH that's included in the product, but not pre-configured for our projects.
The second item is that you'll need something to listen to port 25 and process the messages our email task generates. Normally, you'd set up some sort of SMTP or email server, but that's a bit much for just testing our process. We'll be using a simple Java solution to capture these messages and display them in a simple inbox.
Email Work Item Handler
First, let's look at configuring the project itself to make use of a specific handler specification. From the project assets view, shown in figure 2, select the settings tab. This provides all the project configuration options, and we'll start on the left side choosing deployments and then work item handlers.
Figure 3: Email work item handler.
From there, we add a new work item handler and fill in the details for the email handler, as shown in figure 3. For completeness, the details are included here so you can cut-and-paste them into your projects.
Name: Email
Value: new org.jbpm.process.workitem.email.EmailWorkItemHandler("localhost", "25", "", "", "true")
Save these settings, and you can now build and deploy this project with an email task sending emails on the localhost SMTP over port 25.
Figure 4: fakeSMTP helper application.
The final question is how can we capture these emails on port 25 without setting up our own SMTP server?
Capturing Email
Included in the Red Hat Process Automation Manager installation demo project (used in the online workshops) you'll find in the support directory a java helper application called fakeSMTP.
This project provides a simple java application you can run, as shown in figure 4, which once started, provides an SMTP server and inbox capture. Run this before executing any process that is configured, as shown in this article, and your emails are sent, processed, and captured in this application.
For more details on how that looks, you can see the free online workshop lab 7, which details it all for you step by step.
Happy automation integrating!
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments