Typical Steps in Event Processing

The following steps illustrate folder event processing and refer to elements in the diagram in Event Handling Architecture. In this example, "Folder 3" is one of several folders configured to have events monitored. Agents are registered for this folder to link certain events that occur to user-defined scripts contained in Folder 3.

1. A message is posted to Folder 3, a folder being monitored by the Microsoft Exchange Event Service.
2. A notification of the posting is sent to the Event Service.
3. The Event Service calls an Incremental Change Synchronization (ICS) method to request all the changes that have occurred in Folder 3 since the last time an event occurred in that folder. The Event Service translates the notification into an event.
4. The Event Service keeps track of the agents registered for every type of folder event. Because an agent called "Microsoft Exchange Agent Scripting" has been registered to handle events for this folder, the Event Service creates an agent of this type.
5. The Event Service calls the ExecuteEvent method on the IExchangeEventHandler interface on the agent. In doing so, it passes the folder identifier of Folder 3, the message identifier of the newly posted message, and the session object of the logged-in CDO session.
6. The scripting agent obtains the script from the folder being monitored.
7. The scripting agent creates a CDO 1.21 session object (MAPI.Session) with the Microsoft Exchange identity of the person who saved the script in Folder 3 and passes it to the script. Now, when performing actions within the system, the script has the same rights as its author. See Scripts, Agents, and Security.
8. The scripting agent runs the script for the event that occurred.

Note – Synchronous versus Asynchronous Event Handling  The Microsoft Exchange Event Service fires events asynchronously with respect to the Microsoft Exchange information store. This means that the store does not block your event script, or wait for it to run, before letting other processes access the folder or message. Other processes (Inbox Assistant rules, or even a fast user) could move, copy, delete, or modify the message before your script has a chance to complete or even run. 

The Microsoft Exchange Scripting Agent is therefore suitable for typical, medium-volume workflow or administrative applications. It is not suitable for applications that would, for example, scan every piece of mail in or out of the system for viruses, or archive every message for government record-keeping purposes, because there is no guarantee that your scripts will see every message. A good example is trying to use OnMessageCreated events in your Outbox folder to process all outgoing mail. By the time your script runs, the message will already have been delivered and deleted from your Outbox.

Additionally, some of these types of scripting applications could face problems of scale. Depending on the application's purpose, you would either have to manually install a script in every folder for every user, or the volume would simply be too high to process with an interpreted scripting language like VBScript.