Like the tortoise and the hare, Microsoft Exchange Server and Lotus Notes are seemingly mismatched contenders in the race for market share in the messaging and groupware products industry. Lotus Notes' groupware and document-routing capabilities have given it an edge in this race. Although Microsoft had intended Exchange Server to be a platform for more than just email, it hadn't delivered on those good intentions. Exchange 4.0 and 5.0 never quite provided an extendible base for application development.
But the race for market share is far from over, and Microsoft is making an all-out effort to win with the release of Exchange 5.5. Microsoft believes that Exchange 5.5's Scripting Agent will close the gap between Exchange and Lotus Notes. Based on my early experience with the Scripting Agent, I think Microsoft might be right.
Exchange 5.5's Scripting Agent triggers the execution of server-side application code when certain actions occur in folders. With this code, you can build real groupware applications and automate business processes.
Server-side execution is not a foreign concept in Exchange installations. Outlook Web Access 8.03 uses the same approach to execute code in active pages. And like Outlook Web Access, the Scripting Agent is built using Collaborative Data Objects (CDO), a reusable set of messaging and calendaring objects that lets code written in Visual Basic Script (VBScript) or JScript (Microsoft's implementation of the ECMAScript scripting language, formerly known as JavaScript) access components within Exchange.
Introducing the Scripting Agent
In the past, Microsoft positioned the combination of public folders and custom electronic forms as the cornerstone of Exchange's groupware applications. However, once people began using these applications, the difficulties with this approach became apparent. Public folders are excellent repositories for static information, but they don't intelligently manage that information. In other words, public folders store items generated from document management and workflow applications, but the folders don't let the ap-plications know when conditions change in those folders. For example, a public folder stores items generated from a document management application, but the folder doesn't let the application know when a user drags a Word document from Explorer and drops it into the folder. Similarly, a public folder stores items that a workflow application generates, but the folder doesn't let the application know when a manager approves a purchase order that's in the folder.
Although users can manually monitor folder contents and take appropriate actions to invoke document management and workflow applications, this method isn't an integrated solution and doesn't leverage folders' storage capabilities. Creating a server process that constantly monitors folder contents is a more automated solution, but why have every application designer reinvent the wheel? Although developers can use notification mechanisms that interfaces such as Messaging API (MAPI) provide, these mechanisms require a substantial amount of application-specific code.
What you need is a standard method to notify applications when an action occurs in a folder--and Exchange developers have provided this method in version 5.5. The advantage is obvious. Programmers who know VB can write applications that use data held in folders without having to resort to C++ code or writing a Windows NT service.
Understanding How It Works
You can use the Scripting Agent to notify server-side applications about what is occurring in public or private folders. Any of three actions (i.e., events) occurring in a folder can trigger applications to run: creating an item (a Folder_
OnMessageCreated event), changing an item (a Message_OnChanged event), and deleting an item (a Folder_OnMessageDeleted event). You can also arrange to trigger a server-side application according to a predetermined schedule (a Folder_OnTimer event). Here is how these four events trigger a server-side application, or script, to run.
A new NT service--the Exchange Event Service (events.exe), which re-sides on the Exchange server--dynamically monitors public and private folders for the four events. When an event occurs in a folder, the Event Service uses the IExchangeEventHandler interface to pass on important information (such as the identity of the folder in which the event happened and the identity of the message that triggered the event) to the Exchange Scripting Handler. This ActiveX scripting engine then processes the appropriate script for that event.
The Scripting Handler runs interpreted VBScript code, interpreted JScript code, and code in other programming languages that support Component Object Model (COM) objects. (A new COM object, ss.dll, provides Exchange-specific script processing.) You can even use any COM-compatible language to create a script handler. The Microsoft Platform Software Development Kit (SDK) includes documentation and sample scripts that are useful starting points for projects (see the Microsoft Platform SDK at http://www.microsoft.com/msdn/sdk/platform.htm).
You can use the Scripting Agent to create scripts that fire when events occur in public folders that your document management and workflow applications use. For example, suppose you store customer addresses in both a public folder and a separate, external database. Rather than have employees update two lists when address changes occur, you can use the Scripting Agent to fire Message_On-Changed event code that tells Word to update the external database. You can also use Folder_OnMessageCreated event code and Folder_OnMessageDeleted event code to tell Word to update the external database as employees add customer addresses to and delete customer addresses from the public folder.
For your workflow application, suppose you have an electronic purchasing system. After a manager approves a purchase order, you can use the Message_OnChanged event code to prompt the application to validate the approval. (The person approving the item might not have the correct authorization.) If the authorization is valid, you can then use the Message_OnChanged event code to route the purchase order to the next step in the electronic purchasing cycle.
Users do not have to be online to fire events. For example, an Outlook client might post a new item to a folder when the user is working offline. The next time the client connects to its home server and synchronizes the contents of the folder, the new item goes into the server-based folder, causing the Folder_OnMessageCreated event code to fire. Conceivably, offline posting might result in a series of transactions within a workflow or document management application, all occurring under the control of the code linked to the Folder_OnMessageCreated event.
Setting Up the Scripting Agent
Although Microsoft includes the Event Service in all Exchange 5.5 installations, you decide whether to use it. To take advantage of the Event Service, you need to specify it as a subcomponent of Exchange Server during upgrade installations. As Screen 1 shows, the Event Service operates under the control of the Exchange service account in the same way as other Exchange services, such as the Mail Transfer Agent and System Attendant.
The installation of the Event Service creates a new branch--the Events Root folder--in the System Folders hierarchy. (System Folders, which aren't visible to users, hold items such as the Offline Address Book and Free/Busy schedule.) Each server that runs Event Service will have a separate folder, EventConfig_ServerName. Screen 2 shows a System Folder hierarchy with one configured server (EventConfig_RUCKS).
The EventConfig folder serves two purposes. First, it holds details of script bindings (i.e., the registration list of scripts) for a particular server. Second, its properties include an access control list (ACL), just like any other folder's. The ACL defines who can run scripts on a server. By default, no one can run scripts, so you must use Client Permissions in the EventConfig folder to specify which users have this right. Users must have at least Author permission.
Similarly, not every user can write and bind code. To write code for a particular folder, you must be the folder's owner. You must also be on the ACL of an EventConfig folder on at least one server at the site. For example, if you have three servers at a site and you have permission in the EventConfig folder for one of those servers, you can write scripts for the folder but only execute the code on the server that you have permission for. To bind a script to a folder, you must be the folder's owner. You must also be on the EventConfig folder's ACL on that server. For example, if you have three servers at a site and you have permission on the EventConfig folder for only one server, you can register scripts only on that server.
If users need to write or bind code for folders they do not own, you must first grant them owner permission for the folder. The users will then be able to see the Agents tab when they view the folder's properties. (Without permission, users cannot see this tab.) By clicking Agents, they can view existing code or add new code for folder events.
These controls are strict, but they make sense. Because the Scripting Agent runs on the Exchange service account, those users who have access to the Event Service also have access to other Exchange services. As a result, you must limit access to as few people as possible--or use Microsoft Transaction Server (MTS).
You won't find many references to these controls in user documentation. Exchange 5.5's release notes, What's New, and Administration Guide briefly mention how to grant permission to run scripts on a server, but nothing more. Anyone needing more information must consult the Platform SDK. You can also register for the Microsoft Developer Network (MSDN) and access programmer documentation for the Scripting Agent at http://www.microsoft.com/msdn.
Creating Scripts
If you're running Outlook 8.03, the latest version of the Outlook client that ships with Exchange 5.5, you can use Notepad to write script code. You use Outlook to create and manage scripts. However, the interaction of any client (e.g., MAPI, Internet Mail Access ProtocolIMAP4, or Post Office ProtocolPOP3) with a folder that has associated scripts will trigger an event. In this respect, Outlook is no better or worse than any other client that you can connect to Exchange.
Outlook 8.03 displays scripts through the Agents tab in a folder's Properties dialog box. You will see the Agents tab if you're the folder owner and have the necessary permission on the EventConfig folder on one or more servers. Screen 3, page 201, shows what you might see when you click the Agents tab. This folder has one script.
Clicking Edit reveals the dialog box in Screen 4. You can associate the selected script with each of the four potential events (created, changed, deleted, and timer) that might occur in a folder. Clicking Edit Script reveals the code, as Screen 5 shows.
Although Outlook 8.03 uses Notepad as the default editor for creating or editing code, you can use a more sophisticated script editor, DevStudio (the IDE component of Visual Studio). If the Outlook 8.03 setup program detects that you have Visual Studio on your computer, Outlook will copy the necessary extension to access Exchange on your hard disk. (This extension lets you browse, edit, and save VBScript or JScript programs into Exchange folders.) Then you must use the Tools.Macro option in Visual Studio to load the macro file for Exchange.
With Visual Studio, Exchange generates prototype VBScript code when you create a script. Exchange divides the code into a set of four procedures (one procedure for each event that the script might handle). You insert the code into the appropriate dialog boxes in Outlook 8.03. The Exchange CD-ROM includes several sample scripts that you can use to develop applications.
Debugging Scripts
In some respects, scripts execute in a void. No user interface is available to flash progress messages as the code runs. You can insert Script.Response statements into a script so that, when the script runs, Outlook writes feedback information into a log. Although this technique is crude, Script.Response statements provide a useful starting point on the debug trail. You insert Script.Response statements much in the same way you insert Print statements in BASIC or COBOL.
The Outlook client is the only way to view script logs. To access a script's log file, you need to go into the folder's Properties dialog box, click the Agents tab, and then click Edit. The resulting dialog box will contain a Logs button, like the one in Screen 4. If you click Logs, the log file will open.
The amount of information in a log depends on how many Script.Response statements you incorporate into a script. If you don't insert any Script.Response statements, the log file will be blank (unless the script encounters a fatal runtime error, in which case, Outlook will log the error details). If you insert many Script.Response statements, you run the risk of overwriting statements because a script's log entry has a 32KB limit. The type of information in a log depends on the type of errors that occur.
To debug scripts, you can use the Script Debugger, which Microsoft provides as part of Internet Information Server (IIS) 4.0 and Internet Explorer (IE) 4.0. If the Script Debugger is active, you can insert stop statements (for VBScript) or debugger statements (for JScript) into a script to halt its execution. In this respect, these statements act as simple breakpoints; the Script Debugger will interrupt script processing and let you examine what's going on.
The Script Debugger's usefulness, however, is limited because you must run it on the server where the script is executing. In other words, you can't perform remote debugging. Also, when the Script Debugger halts a script, the processing of all other scripts pauses, too.
Because of these limitations, you must thoroughly test the script on a trial server before you install it on an operational server. You don't want to get into a situation in which a script encounters an error, falls through to a section of code, and proceeds to execute that code with unforeseen consequences.
Executing Scripts
As you can see from the drop-down list at the bottom of Screen 3, the Event Service lets you assign scripts to run on specific servers. However, the Event Service doesn't have automatic load balancing. Thus, if you want to spread the load across multiple servers, you have to modify each folder's properties to define where you want to run the scripts. You can direct all scripts to a specific server and minimally configure that server, with no mailboxes, connectors, or public folders. This setup is a good way to use a low-end server.
Because the Event Service runs on the Exchange service account, scripts run under the same NT security context as the service account. If this situation poses problems, you can use MTS to specify which NT account will run the script engine.
The Event Service uses Incremental Change Synchronization (ICS) to track successful completion of scripts. ICS assigns each folder a master counter (i.e., a change number). If a script encounters a fatal error (e.g., the Event Service crashes), ICS will not increment the folder's change number. The next time the Event Service examines folders (examinations take place each time a create, change, delete, or timer event occurs), the Event Service will notice this discrepancy, associate the missing number with the folder, and then execute the script. The Event Service executes scripts according to the folders' change-number order, so there's no danger that the service will execute scripts out of sequence.
Because the server interprets a script's code, the code will not run as fast as compiled code. The time needed to interpret the code and the inevitable delay in interprocess communications mean that the Event Service doesn't process events synchronously with Exchange's Information Store. In other words, the Information Store doesn't wait for the Event Service to process an event before the information store carries out its tasks. For example, if a user creates a new file and then deletes it shortly thereafter, the Information Store will not wait for the Event Service to execute the script for a Folder_OnMessageCreated event before the Information Store deletes the folder.
Applying the Scripting Agent
Although the Scripting Agent is in its infancy, Microsoft is already suggesting how you can use it. For example, Microsoft suggests using the Scripting Agent for routing documents for review or approval, automating lists (e.g., sending everyone on a distribution list updates from a public folder once a day), processing newsfeeds (possibly with an Network News Transfer Protocol NNTPfeed into a public folder), and automating common administration tasks (e.g., letting users post requests to join or leave a distribution list in a public folder). Exchange 5.5's CD-ROM contains four sample scripts, including an interesting example that demonstrates how the Inbox folder for a resource mailbox (such as a conference room) can automatically accept or reject meeting requests.
Microsoft is also specifying what the Scripting Agent is not well suited for. Because events are asynchronous with Information Store contents, you can run into trouble using this tool for high-volume applications. For example, if a script tries to process every piece of outgoing mail, you'll experience a drastic reduction in performance. Essentially, you're reducing the performance of your Exchange Server to the execution speed of VBScript.
The Scripting Agent is also not well suited for wide-scale applications (such as creating scripts for a certain folder in everyone's mailbox in a large enterprise) because you must install scripts individually into folders. No utility exists to distribute scripts to multiple folders within a site.
A Close Race Ahead
The Scripting Agent promises to become the base for a wide variety of groupware applications, such as simple serial-step workflow and basic document management. If you want to write applications that you can integrate with Exchange, consider using the Scripting Agent. It delivers the same types of automation and routing capabilities that application developers have used to build many solutions on top of Lotus Notes. The combination of folder events, Event Service, and CDO greatly simplify writing groupware applications for Exchange.
With the Scripting Agent, Microsoft is closing the gap between Exchange and Lotus Notes. This new method will make Microsoft a viable contender in the race for market share, so now is definitely not a good time for Lotus to stop and rest. Otherwise, Lotus might share the hare's fate and watch the tortoise take the lead.
