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.
End of Article
Prev. page
1
[2]
next page -->
