Built-In Information Management Tools

Managing information when building applications can be one of the most tedious tasks for a developer. But public folders, with their built-in and configurable services, handle these tasks automatically for you. They allow you to set the expiration time for information, which prevents public folders from becoming inundated with megabytes of outdated and useless information. Their conflict management features prevent two users from unintentionally saving two versions of the same document. If two users edit the same document stored in a public folder and then try to save their changes, Exchange Server sends a conflict message to both users and to any folder contacts defined on the public folder. The users then have the choice to keep one of the two items or both. Figure 3-20 shows the Conflict Message dialog box.

Rules

To manage the massive amount of information received by an organization, Exchange Server supports rules. Although many other collaborative systems also have this functionality in some form, in most cases a user must be logged on to the system before the rules can be processed. Also, other systems don't allow rules in folders other than a user's personal folders. With Exchange Server, rules are supported for both personal folders such as an Inbox and for public folders.

By setting rules in your public folder application, you can to some extent control the flow of information into and out of it. Public folder rules are configurable by the owner of the public folder and are server-based, which means no client has to be logged on for the rules to fire. Instead, the server fires the rules.

Figure 3-20 Exchange Server automatically detects when conflicts of information occur in your applications. The server will then send a notification to the folder owner and to the users who generated the conflict.

The types of rules you can create range from simple rules, such as "send a thank you e-mail to anyone who sends a message to the public folder," to very complex rules. Complex rules can entail checking multiple fields on an item and taking a specific action based on those fields.

Event Scripting Agent

Sometimes rules are not the best strategy for controlling the flow of information in your application—for example, they might be too constrictive. In these situations, a feature in Microsoft Exchange Server version 5.5, called the Microsoft Exchange Event Scripting Agent, will help you greatly. The Event Scripting Agent (discussed in more detail in Chapter 12) allows you to write custom event handlers for the most common Exchange Server folder events by using standard development tools that support COM. For example, you can write a script event handler that calls COM objects that you create. Plus, as its name implies, the Event Scripting Agent ships with a scripting engine that understands any ActiveX scripting language, so you can write your custom agents using a scripting language such as VBScript or JScript. You choose which development tool you use to write these agents.

Once you write your custom agent, you can place it in an Exchange Server folder, such as your server-based Inbox or a public folder. Your agent can handle four distinct events:

• OnMessageCreated. This event fires when any type of new item is posted to the folder, such as an e-mail message, a calendar appointment, or a Microsoft Word document. This event can be generated from any type of client, such as Outlook or a web browser client. An expense report agent might use this event to look up the manager of a person who submits an expense report and then route the report to the manager for approval.
• OnChanged. This event fires when any type of item is edited and saved back into the folder. An example agent for this type of event is a resource scheduling agent, which monitors a public folder calendar for conference rooms. When a meeting time is changed, the agent notifies all the attendees and any catering services.
• OnMessageDeleted. This event fires whenever an item is deleted from the folder. It's useful when you want to synchronize the contents of a folder with another data source. By writing a custom agent for this event, you could delete from other folders or databases items that are related to the deleted item.
• OnTimer. This event fires based on a time limit you specify, which can be weekly, daily, hourly, or on a more granular time. For example, you can customize an event so that it fires every 15 minutes starting at 6:00 p.m. and ending at 3:00 a.m., or set the event to fire only on certain days. An example of an agent using this event is another expense report agent that works in conjunction with the sample expense report agent we just discussed. Suppose the manager does not approve the expense report forwarded by the first expense agent in the specified amount of time—an hour, let's say. A scheduled event, created to check pending expense reports every hour, determines that the expense report needs to be escalated to the manager's manager. The agent could look up that individual using the Exchange Server directory and route the expense report to her.

As you can see, by creating custom agents, you can implement custom functionality that would otherwise be unavailable in public folder rules.