Platform SDK: Exchange Server

Caching Sessions and Scripts

Your handler's design depends in part on the number of folders it will be used in and the workload (number, or volume, of events) it will carry within a folder. One affected design element is whether to cache a CDO session and a script. Consider the following cases:

In general, caching is more likely to help if high volume is involved.

In the case of the Microsoft Exchange Scripting Handler, if a new CDO session (which includes a logon to MAPI) had to be created every time a script fired, performance would suffer greatly. In this case, the session object (using the mailbox of the script author) is cached, which helps greatly. In other words, if a new script is run whose author also created another recently run script, that person's CDO session, having been cached, is reused. The script itself is also cached, to be used when the next event triggers it.

CDO Sessions and MAPI Sessions

The session that is passed to you in the EventSource objects Session property is a MAPI session from the service, not a CDO session. This precludes Microsoft Visual Basic and Java handlers from using it, because they can only use oleautomation types which MAPI does not support.

If your custom agent is written in Microsoft Visual Basic, it will need to perform its own CDO session logon. Although it is possible in principle to create a limited custom agent using Visual Basic or Java, it is recommended that you use C++.