IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Services and service-related functions > Access external services with adapters > Configure and using adapters > IBM WebSphere Adapters > Email > Overview of WebSphere Adapter for Email > Technical overview of the WebSphere Adapter for Email
Inbound processing
WebSphere Adapter for Email supports inbound processing of email events. Inbound event processing means that the adapter polls the mail server at specified intervals for new emails that are ready for processing. When the adapter detects an event that is ready to be processed, it converts the event data into a business object and sends it to the consuming service.
During inbound processing, the adapter polls the mail server for new emails, which are called events. When the adapter detects a new event, it reads the email and creates a business object to represent the email content. The adapter then forwards the business object to the export which is an exposed interface from a service component architecture (SCA) module that offers a business service to the outside world. Business objects carry the information the adapter takes from an email. By converting emails to business objects and forwarding them to a service, the services using your adapter module do not have to deal directly with the mail server. It is the adapter that polls for events, changes them to a format the consuming services can understand (business objects), and then forwards them to the export for delivery to the services that consume them.
The following illustration shows at a high level how the adapter functions as part of an inbound service in a service-oriented architecture (SOA) implementation. The adapter polls the mail server for incoming events, converts them into business objects, and then the adapter sends them to a consuming service.
Figure 1. Adapter as part of an inbound SOA implementation
Each inbound module contains components that form a service, including an export. An export is a component, but without an implementation. Exports allow components in a module to provide their services to external clients. Exports require an EIS binding, which specifies the means of transporting the data from the modules. The assembly editor in IBM Integration Designer sets up the export, lists the supported bindings, and simplifies its creation. For inbound requests, business objects are essentially the logical graphical representation of the content of an incoming email, that appears as output from the export that represents the module in the assembly diagram.
The following illustration shows a more detailed view of the module in an inbound implementation. The I and R symbols within the illustration represent interfaces and references. Interface is a specification of the operations performed by a component. For inbound communication, it is limited to the Read operation. The interface dictates to the users of a service component, in this case the export, how the component can be used. A reference declares the interface that your service component is going to call. Each component in your module has one or more references. When you write the implementation for your service component using the assembly editor in IBM Integration Designer, you call a reference instead of directly calling the component. This implementation allows you to reassemble components in the future because you have not built dependencies into the code.
Figure 2. Inbound communication showing the export
Supported inbound protocols
The adapter supports two different inbound email protocols: POP3 and IMAP. With each, the adapter polls the mail server at a specified interval for inbound events (emails) and when an email is detected on the mail server, the adapter converts it to a business object. The adapter considers any email in the specified inbox folder on the mail server that is ready for processing an event.
Depending on your mail server, you might be able to choose the inbound email protocol that the adapter can use. Differences between the protocols and a description of how the adapter works with each protocol are noted in Table 1 and the sections that follow.
| IMAP | POP3 |
|---|---|
| Supports the existence of multiple mail folders on a mailbox. | Supports only one mailbox (named Inbox) per user. |
| Allows a copy of the email to remain on the mail server after the client receives the email. | Supports a view-once-only feature on the server. The mail is deleted from the mail server after the client receives a copy of it. |
Inbound communications with IMAP
If you use the IMAP protocol for your inbound communication, the following steps are performed:
- The adapter polls the mail folders at regular intervals and logs
any unread emails as events in the event store. You can use the activation
specification PollFolders property to customize the list of folders
that are searched by the adapter.
If you specify multiple mail server folders for the mail server account in the PollFolders property, the adapter polls all mail server folders sequentially.
- Search criteria determines which events are picked up from the mail server. The adapter picks up all events that match the search criteria. If no search criteria is specified, the adapter picks up all unread emails.
- The adapter writes all polled events to the staging directory. After an event is written to the staging directory, it is deleted from the mail server.
- The adapter transforms each event into an email business object. The headers, email body content, and mail attachments are recorded within the business object.
- The email business object is sent to the export.
- After it has been processed, the adapter deletes processed emails
from the staging directory and archives them (if archiving is selected).
If the archive file naming pattern activation specification property is specified, the file names conform to the pattern.
Inbound communications with POP3
If you use the POP3 protocol for your inbound communication, the adapter performs the following steps during inbound operations (from the mail server to the service):
- Polls the Inbox folder on the mail server for inbound events (new emails). When it finds an email, it logs it as a new event in the event table.
If you specify search criteria, all unread emails that fit the search criteria are picked up by the adapter. If no search criteria are specified, the adapter picks up all unread emails.
- Writes new events to the staging directory as files and then deletes them from the mail server.
- Converts the email into a business object. Headers, email body content, and mail attachments are recorded within the business object.
- Sends the business object to the export.
- Deletes all processed email from the staging directory and archives
them if the archiving property is configured.
If the archive file naming pattern property is specified, the file names conform to the pattern.
If it is not specified, the name remains the same as it is in the staging directory.
- Inbound data transformation
During inbound communication, the adapter transforms multipart MIME email messages into business objects. - Event store
The event store is a persistent cache where event records are saved until the polling adapter can process them.
Technical overview of WebSphere Adapter for Email
Related tasks:
Setting deployment and runtime properties for inbound processing
Related reference:
Activation specification properties