If you are embarking on a new development
project, or you are evaluating or writing a scope of works for an
application that you're going to ask another company to develop, there
are many different aspects to consider. Some of the Exchange APIs, such
as the Mailbox APIs MAPI and EWS, have overlapping functionality, while
some server-management tasks; for example, require the use of the
Exchange Management Shell cmdlets, which are the only method you can
use to provision mailboxes.
Choosing the correct API to use for
development requires that you map out the requirements of the
application that you wish to develop first. Then you can match those
requirements against the functionality that each API provides. To
demonstrate this, let's look at a few real-world scenarios and the
development choices available.
Real World Scenario: SCENARIO 1: LINE OF BUSINESS AUTOMATION APPLICATION THAT PROCESSES INCOMING MAIL
Customer A has a mailbox called Sales Orders.
Distributers send sales orders for their product to Customer A's
mailbox in the form of email attachments. Customer A requires an
application that will monitor this mailbox for new messages and then
process them on arrival. If a message has an attachment that is a sales
order, it will download the sales order, process the contents, and
upload the order into the company's enterprise resource planning (ERP)
system using a third-party API. After processing, the mail then needs
to be moved to a separate folder in the mailbox called Processed Sales
Orders. If the message isn't a sales order, the application should
forward the message to another mailbox for the sales staff to process.
In this scenario, all that
is required is an API that can access a mailbox. For this type of
application, Exchange Web Services is the best API to use in Exchange
2013. EWS can be used to poll the mailboxes on a timed interval. EWS
streaming notifications can also be used if real-time response to new
emails is required. EWS allows full access to the attachments, and it
also contains operations to move and forward messages. All of the code
that is written can run in a completely automated manner, without the
need for any user input.
Real World Scenario: SCENARIO 2: CLIENT-SIDE, USER-PRODUCTIVE ENHANCEMENT
Company B's sales department receives a lot of
inquires via email. To help them process these customer requests more
efficiently, they would like to have information from their customer
relationship management (CRM) system displayed in-line in any message
received. Users need this information for email that is accessed inside
shared mailboxes. Company B has users that use both Outlook Web Access
(OWA) and Outlook, and they require that the workflow be the same
across each client.
In this scenario, the application must interact
with the client that an end user is using, and it will also need access
to the shared mailbox. The primary functionality in this scenario can
be fulfilled by a mail app for Outlook and the Outlook web app that
uses the Office JavaScript API to access the mailbox and extend the
user interface in Outlook and OWA. Mail apps for Outlook must be hosted
on an IIS server.
This application is for internal company use
only. This means that it can be hosted on an internal system and then
published to selected users remotely as required. The company could
also choose to host their web apps using Azure if they are using a
cloud-based email system like Office 365.
Real World Scenario: SCENARIO 3: CUSTOM ROUTING APPLICATION IN THE OUTLOOK CLIENT
Company C has a requirement that all email sent
to a subset of email addresses in one particular domain be routed via a
particular SMTP smart host. They also require that the sender address
be rewritten to a single sender address when messages are marked in a
particular way.
In this scenario, the application must interact
with the messages when they are in the transport pipeline. Building a
transport agent using the Transport Agent SDK and the transport
pipeline's events and public objects fulfills this requirement. A
routing agent and the OnResolved Message event can be used to set a
routing override on a message so that it will be routed via a specific
SMTP smart host. The address rewriting can also be performed within the
transport agent events.
Transport agents
provide the ability to extend the functionality of the transport
pipeline by allowing you to build custom applications that execute at
different points in the transport pipeline. The transport pipeline is
the processing that happens on a message as part of the
message-transfer process. This starts at the beginning of the SMTP
conversation at the TCP connection and runs to the delivery of the
message to the Exchange store. Note that transport agents can't be
extended to the Mailbox store, so they can't be used to access messages
in a mailbox or route messages to particular mailbox folders (other
than the Junk Email folder). Some uses for transport agents are
gateways to external non-SMTP servers, such as fax or SMS gateways,
domain catchalls, enhanced mail routing, or antispam handling.
There are three different types of transport agents:
SMTP Receive Agents SMTP receive agents
are designed to respond to messages coming into and going out of an
organization. They can be used to respond to an event that happened
during an SMTP conversation or to perform Catch-All-type functionality
for incoming email.
Routing Agents Routing agents are
designed to allow you to catch a message just after submission or at a
different point in the transport pipeline. Some uses for routing agents
are to modify the message contents or perform custom routing functions
for a particular recipient.
Delivery Agents Delivery agents
allow you to deliver messages from your SMTP Exchange Server
environment to a system that doesn't use the SMTP protocol. They are
used for providing delivery messages to the foreign system and
providing acknowledgement for each successful message delivery.
The transport architecture has been
changed in Exchange 2013, and this affects the location and placement
of transport agents. The Transport service is now split into three
different services. Table 1 lists the new services that make up the transport architecture and the transport agents supported by each service.
TABLE 1: Exchange 2013 Transport service and transport agent support
For more information on developing
transport agents, you should download and read the Exchange 2013
Transport Agent SDK from MSDN.
Real World Scenario: SCENARIO 4: AUTOMATION OF MAILBOX PROVISIONING
Company D's HR department needs to be able to
provision mailboxes and contacts in the company's Exchange organization
when new employees are hired. After the mailbox is created, a specific
configuration should be applied to the mailbox and a welcome email,
personalized for the user, should be sent.
In this scenario, Exchange Management Shell (EMS)
commands need to be used to provision the mailboxes. The commands can
be run from managed code using remote PowerShell and the automation
class libraries. The personalized welcome message could also be sent
from the EMS, but EWS would be a better choice since it provides
greater formatting options.
While not strictly an API, the EMS cmdlets are
the primary mechanism for the automation of administrative tasks on
Exchange. These may include the provisioning of mailboxes,
adding/removing/changing email addresses on objects, and the
configuration of the default setting for mailboxes. Also, EMS cmdlets
are the primary mechanism used to access reporting information on
mailboxes, such as retrieving the size of mailboxes, the details of
quota usage, or message-tracking information.
Real World Scenario: SCENARIO 5: MIGRATION OF AN EXISTING APPLICATION THAT USES MAPI DURING A MIGRATION TO EXCHANGE 2013
Company E has been running Exchange since version
5.5. They are now seeking to migrate to Exchange 2013. Over the years,
they have purchased or developed a number of applications and scripts
that use MAPI over RPC to connect to Exchange. Some of these
applications are critical to the business and can't be offline for any
significant period of time.
In Exchange 2013, all MAPI connections need to be
encapsulated using RPC over HTTPS. This means that any existing
applications that use a direct RPC/TCP MAPI connection will need to be
rewritten to use RPC over HTTPS. For applications that use the
Collaboration Data Objects (CDO) version 1.2.1 library, which uses
RPC/TCP, Company E will need to get an updated version of this DLL that
supports RPC over HTTPS and make changes to their application to create
RPC over HTTPS profiles. Microsoft has deemphasized MAPI in 2013, and
it is recommending that all new development be done using Exchange Web
Services.
For Company E, any scripts that use CDO 1.2 can
easily be rewritten to use EWS and tested against their current
Exchange 2010 Servers before migration. For the applications that they
have developed themselves in the past, changing the source code to use
the new version of CDO 1.2 before the migration would be most prudent.
In the long term, however, moving these applications to EWS should be
planned. For any third-party applications, they will need to contact
the original vender to obtain a new version of the application that is
supported in Exchange 2013 before the migration can take place.
Other Exchange APIs
For the sake of completeness, you should be aware of one other development interface—the Exchange ActiveSync protocol. The Exchange ActiveSync protocol
is designed to allow mobile devices to synchronize email, calendar,
contacts, and tasks with Exchange Server. The XML structures used
within the Exchange ActiveSync protocol are tokenized, meaning that they are more compact, which reduces the size of the data transferred between the server and the client.
Other features included in Exchange
ActiveSync are policy mechanisms used to enforce standard configuration
settings on mobile devices. ActiveSync is the best protocol to use when
building a mobile device email client because of the policy and
tokenization features. Nevertheless, custom mobile applications that
need to access just one type of mailbox data may make better use of
EWS, which will reduce the overall development effort needed to build
and maintain an application.
NOTE You need a specific license from Microsoft to develop Exchange ActiveSync clients.
