Typical Steps in Event Processing

The following steps illustrate folder event processing and refer to elements in the diagram in Scripting Architecture. In this example, "Folder 3" is one of several folders configured to monitor events. The creation of the agents for this folder linked certain events that occur in Folder 3 to a script placed 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 the agent called Microsoft Exchange Agent Scripting has been registered for events in this folder, the Event Service instantiates an agent of this type.
5. The Event Service calls the Run 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 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 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 language like VBScript.