MAPI SPOOLERMAPI spooler is a function of the Microsoft Office Outlook process that is responsible for sending messages to and receiving messages from a messaging system. MAPI spooler plays a vital role in message receipt and delivery. When a messaging system is unavailable, MAPI spooler stores the messages and automatically forwards them at a later time. This ability to hold on to or send data when necessary is known asstore and forward, a critical feature in environments where remote connections are common and network traffic is high. MAPI spooler runs as a background thread within Outlook.MAPI spooler has additional responsibilities related to message distribution. These extra duties include the following: Keeping track of the recipient types that are handled by specific transport providers. Informing a client application when a new message has been delivered. Invoking message preprocessing and postprocessing. Generating reports that indicate that message delivery has occurred. Maintaining status on processed recipients.The following illustration shows at a high level how a message flows from a client to the messaging system.Outgoing message flow

The user of a client application sends a message to one or more recipients. The message store provider initiates the sending process, formatting the message with additional information needed for transmission.MAPI spooler receives the message to process if any of the following conditions occur: The message store provider is not tightly coupled with a transport provider. The message requires preprocessing. The message store and transport provider are tightly coupled, but they cannot handle all the recipients to whom the message is addressed.If MAPI spooler receives the message, it performs any required preprocessing and delivers the message to the appropriate transport provider. The transport provider gives the message to its messaging system, which sends it to its intended recipient.With incoming messages, the flow is reversed. The transport provider receives a message from its messaging system and notifies MAPI spooler. Spooler performs any necessary postprocessing and informs the message store provider that a new message has arrived. This notification causes the client to refresh its message display, enabling the user to read the new message.

MAPI Service Provider Between the MAPI subsystem and the messaging systems are the various service providers. Service providers are like drivers that connect MAPI client applications to an underlying messaging system. There are three types of providers: message store providers, address book or directory providers, and message transport providers. MAPI supports each type of service independently, enabling a vendor to offer one or more custom service providers. For example, a vendor might want to create an address book provider that uses a corporate telephone book directory of employees or to create a message store provider that uses an existing database.Service providers are typically written for specific messaging systems by software developers who have specialized knowledge or experience with a particular system. For example, the Microsoft Outlook 2013 and Microsoft Outlook 2010 Mobile Services use an address book provider to expose a mobile address book in Outlook.MAPI presents client applications with a unified view of address book and transport provider information. This integrated approach prevents the client application from having to map data to the appropriate provider. It also prevents the user from having to negotiate among multiple address book and transport provider addressing schemes. Message store provider information, however, is not unified, and clients that use multiple message store providers are responsible for handling them individually.The service providers work with MAPI to create and send messages in the following way: messages are created by using a form that is appropriate for the specific type, or class, of message. Many messages are made with the standard note form that comes with the MAPI subsystem, either by the user of a client application or programmatically without user interaction. The completed message is addressed to one or more recipients a user or group of users designated to receive the message. A recipient might or might not have an entry in a directory that one of the installed address book providers owns. Recipients that are not associated with an installed address book provider are calledcustom recipientsorone-off addresses. A one-off address can be temporary, lasting only until the message is submitted.When the client application sends the message, the message store provider checks that each recipient has a unique and valid address and that the message has all of the information necessary for transmission. If there is a question about a recipient (for example, when there are multiple recipients with the same name), an address book provider takes care of resolving the ambiguity. The message is then placed in the outbound queue.

MAPI Address Book Provider Address book providers handle access to directory information. Directory information consists of data for two types of message recipients: individual messaging users and groups of messaging users who are commonly addressed together in distribution lists. Depending on the type of recipient and the address book provider, there is a wide range of information that can be made available. For example, all address book providers store a recipient's name, address, and address type.Each address book provider organizes this data by using one or more containers. The number and structure of the containers depends on the address book provider's implementation. For example, one address book provider might use a single container to hold all of the information, another might use one top-level container that holds subcontainers, and a third might use several top-level containers, each holding subcontainers. An address book container hierarchy can be quite deep; there is no limit to the number of subcontainers that can be used.The following illustration shows a typical MAPI address book organization.Address book organization

MAPI integrates all the information supplied by the installed address book providers into a single address book, presenting a unified view to the client application. The integrated list shows the top-level containers displayed by each of the installed address book providers. Most address book providers expose only a few containers (typically one to three) at the top level for inclusion in the top level of the MAPI integrated address book. For example, an address book provider might make available "All Users" and "Local Users" as two containers at the top level.The users of client applications can view the contents of address book containers and, in some cases, modify the contents. Address book containers can be created with different access levels, depending on the address book provider.

MAPI Message Store Provider Message store providers handle the storage and retrieval of messages and other information for the users of client applications. The message information is organized by using a hierarchical system known as a message store. The message store is implemented in multiple levels, with containers called folders holding messages of different types. There is no limit to the number of levels in a message store; folders can contain many subfolders.The following illustration shows the hierarchical message store architecture.Message store architecture

The figure shows two folders, one with a subfolder. Client application users can access a summary view of the messages contained in each folder or view them individually with a form. Whether the client displays a standard form that MAPI supplies or a custom form that a form developer supplies depends on the type, or class, of the message. The first folder contains note messages and uses the MAPI standard note form. The second folder contains inventory request messages and uses a custom inventory form. The information on both forms represents the properties of the message.You can use message store data in a variety of ways. In addition to using data for traditional electronic mail, you can use folders as a forum for public discussion, as a repository for reference documents, or as a container for voice mail, calendar, contacts, or tasks, for example. A single message store can hold many types of information. Multiple clients can install the same message store. This makes the sharing of data easy and fast.Message store folders enable you to sort and filter messages and to customize the message display in a user interface. Links to filtered messages are held in special folders called search-results folders. The user of a client application enters filtering criteria, which MAPI refers to as a restriction, and the criteria is applied to the messages stored in one or more folders. For example, a user might want to view only those messages that deal with a particular subject and have arrival dates that are more recent than last week. References to the messages that match the criteria are listed in the search folder, and the real messages remain in their regular folders.Messages are the units of data that are transferred from one user or application to another user or application. Every message contains some message text, with simple or complex formatting, and message envelope information that is used for transmission. Some messages include one or more attachments, or additional data related to and transported with a message in the form of a file, another message, or an OLE object.Depending on the message store provider, a user can save a new message currently being written in addition to messages that have been sent or received. Messages can be copied or moved from one folder to another with each copy becoming a separate message that can be copied, deleted, or modified individually. Another feature that some message store providers enable is the ability to change a message after it has been received and to store it back in its folder. A user might take advantage of this feature for rotating a fax message that arrived upside down. The user can store the correct view in the folder for later viewing.

MAPI Transport Provider Transport providers handle message transmission and reception and implement security, if necessary. They also take care of any necessary preprocessing and postprocessing tasks. There is typically one transport provider for every active messaging system.Client applications communicate with the transport provider through a message store provider.Transport providers register with MAPI to handle one or more particular types of recipient entries. When a message is ready to be sent, MAPI must determine which transport provider should handle the transmission. Depending on the type of recipient, MAPI can even call upon more than one transport provider. If an unavailable transport provider is the only one that can handle the recipient, the message transmission will be postponed until a connection with that provider can be reestablished.Some messaging systems are secure systems; all potential users are required to enter a set of valid credentials before access is permitted. MAPI prevents unauthorized access to such secure messaging systems by having the transport provider validate credentials at logon time.

MAPI Message Service A message service defines a group of related service providers, typically service providers that work with the same messaging system. Whereas service providers perform the work of communicating between messaging systems and the MAPI subsystem, message services perform the work of interfacing between the user and service providers that work with a common messaging system. Message services exist to make the installation and configuration of service providers easier for users. Users never directly install or configure a service provider; the message service completely handles the installation and configuration of each of the service providers that belong to the service. Because of this feature, users do not need to be familiar with specific service provider configuration requirements.The following figure shows the relationship between a messaging-based client application and two message services.Message service installation and configuration

The user invokes the installation code of each message service to add the service and its service providers to a profile. In one of the message services shown in the figure, there are three service providers; in the other message service, there are two service providers. At some later time after installation is complete, typically at logon time, the service providers in each message service are configured. The configuration code in each message service handles the configuration of the providers in the service.When a message service is installed, its installation program copies necessary files from the installation source to the user's local disk and updates a configuration file, Mapisvc.inf. The Mapisvc.inf file contains configuration settings for all of the message services and service providers that can be installed on the computer. It is organized in hierarchical sections, with links between each section at each level. The section at the top level contains information that is relevant for the MAPI subsystem, such as a list of all available message services, and for the online Help installation. The next level has sections for each message service, with information such as the DLL file name of the message service and the name of its configuration entry point function. The third level has sections with configuration data for each service provider in the message service.To handle configuration, a message service implements an entry point function that complies with a prototype defined by MAPI, and a tabbed dialog box known as a property sheet. MAPI calls the entry point function to service client requests that relate to profile management and the management of service providers in the message service. Property sheets are used for viewing and changing message service and service provider configuration properties.

MAPI Forms A MAPI form is a viewer for a message. Every message has a message class that dictates the particular form that is used as its viewer. MAPI defines several message classes and has implemented the forms for viewing messages of these classes. Client software developers can create new message classes and custom forms for viewing messages created by using the new classes.Every custom form implements a set of standard menu commands, such asOpen,Create,Delete, andReply, and a set of commands that are specific to the particular form. Some of the form commands are integrated with the user interface of the client application when the form is active; other form commands completely replace the client commands.The following illustration shows the relationship between the MAPI components involved in using forms.MAPI form architecture

In the diagram, notice that the form manager plays a role that is similar to other MAPI service providers, although it is not a service provider itself. The form manager is a replaceable DLL that implements some of the MAPI interfaces. Although developers can implement their own form manager, most environments will use the form manager provided by Microsoft due to the form manager's complexity.The following list describes the components in the diagram and their relationship to other components: Messaging client: An application that can use form objects. The messaging client uses the MAPI form interfaces to communicate with the form manager to load messages into form objects. MAPI form interfaces: A defined standard for communication between MAPI components that are related to forms. Form manager: The DLL that messaging clients use to handle installation of forms in form libraries, loading of form servers, and initial communication between messaging clients and form servers. Form libraries: Permanent storage for the executable files associated with form servers. Form servers: Executable files that implement a form. Form servers create form objects and user interfaces to deal with specific messages. This executable is also an OLE server and adheres to the usual OLE conventions. Form objects: Run-time objects created by form servers that correspond to specific messages. Form objects run in the same process context as their form server.