Auto Reply ServiceAuto Reply Service
Creating a simple email processing service
Home > Books > Tutorials and Training Guides > Email > Auto Reply Service

Rate this page:
Really useful
Satisfactory
Not helpful
Confusing
Incorrect
Unsure
Extra comments:


Introduction

NetKernel is transport independent. It can process messages received by any application protocol. Here we demonstrate how to configure NetKernel with the MailTransport to process email messages.

Service Specification

We will describe a service which auto replies to every email arriving in a mailbox. We will provide a web interface to manage the autoreply service - this will allow the service to be initially configured, started, stopped and for the autoreply message to be customized. We shall generate the auto-reply message by making a further service request which may be written to serve either static or dynamic content thus demonstrating service-oriented mail processing.

The completed module "trailmap email autoreply" is available for installation through the install wizard. The module should be installed into the front-end fulcrum so that the web-interface is exposed. The module JAR file will be placed in your [install]/modules directory. You should unzip the JAR to view and modify the source.

After you've installed the module the service can be initialised and managed here.

Fulcrum Module MailTransport Configuration

The MailTransport is dynamically configurable but it must be registered in a host module. If you inspect the module.xml configuration you will find that the mail transport is registered with the following entry...

<transports>
  <transport>org.ten60.mail.traccessor.MailTransport</transport>
</transports>

The MailTransport requires a minimal configuration to be provided at ffcpl:/etc/MailTransportConfig.xml. You will see that the module has an /etc directory containing the MailTransportConfig.xml which is...

<mailTransportConfig>
  <id>urn:org:ten60:netkernel:mail:service:autoreply:transport</id>
</mailTransportConfig>

In addition the /etc directory provides an SMTPConfig.xml file which provides the configuration for the SMTPServer accessor, which is used to send emails via SMTP.

Finally the module imports the mod:smtp module, this is the library module containing the MailTransport classes, it's configuration services and the SMTPServer.

<import>
  <uri>urn:org:ten60:netkernel:mod:smtp</uri>
</import>

Service Structure

The module is partitioned into 4 distinct parts. The /resources/ directory holds the primary DPML idocs which provide the web-interface of the service. The /services/ directory holds the main services for servicing an autoreply message from the transport, generating a message and processing updated transport configuration. Lastly /content/ and /transforms/ hold static content and stylesheets used by the web-interface.

Initialisation

The init.idoc serves a dynamically generated form containing the current configuration for the mail processor and the SMTP server. This form is submitted to the services/process-config.idoc which uses mailproc-register to register the new MailProcessor with the MailTransport, mailproc-start to start the newly registered processor. Finally it also stores the SMTPServer config. After initialisation the browser is redirected to the main status.idoc.

Initialisation can be performed repeatedly - if new config is provided the old mailprocessor will be stopped and removed before the configuring the MailTransport with the new MailProcessor.

Status

The status.idoc uses the mailproc-status accessor to request the current status of the autoreply mailprocessor from the MailTransport which it styles to produce the main management view.

Stop

The stop.idoc uses mailproc-stop accessor to stop the autoreply mailprocessor in the MailTransport.

Start

The start.idoc uses mailproc-start accessor to start the autoreply mailprocessor in the MailTransport.

Target Service

A MailProcessor registered with the MailTransport periodically polls a pop or imap mailbox for new mail messages. For each new message received it invokes the service URI specified in the MailProcessor config. In this demo the default service is active:dpml+operand@ffcpl:/resources/services/autoreply.idoc which is the active URI to execute the DPML autoreply.idoc. The MailTransport appends to the active target URI the message header and body part arguments.

In the autoreply.idoc the header argument is transformed to create a reply header (it simply swaps the contents of the "from" and "to" tags). The autoreply.idoc next requests the reply message from the message.idoc service. By default this is a static greeting (the comments explain how this could be modified to a dynamically generated greeting or to serve useful information, such as the current new headlines). Finally the autoreply.idoc issues the message as an email reply using the SMTPServer.

You will note that the MailTransport and SMTPServer are asymetric - that is, MailTransport only ever receives messsages, SMTPServer only sends messages. This is because email is intrinsically asnychronous and asymetric - email can be received by a number of different means (pop3, imap, maildir, mbox) but is generally always sent via an SMTP server.

© 2003-2007, 1060 Research Limited. 1060 registered trademark, NetKernel trademark of 1060 Research Limited.