SQL Server Magazine

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.

   Prev. page   [1] 2     next page