Exchange 2000 Server supports a powerful set of authoring tools to allow developers to quickly get started with Web Storage System applications. Microsoft Web Storage System Forms for Exchange 2000 Server, for instance, enables you to build HTML-based electronic forms in Microsoft FrontPage 2000 without the need for any programming. Microsoft Visual InterDev can be used to implement advanced collaboration solutions based on ASPs. With Visual Basic and Visual C++, on the other hand, you can develop COM components derived from OLE DB and ADO, which you may then reuse in other applications.
This lesson explains how to utilize the Web Storage System for customized collaboration solutions. It addresses how to extend the user interface of OWA and covers how to process items automatically based on Web Storage System events.
At the end of this lesson, you will be able to:
Estimated time to complete this lesson: 45 minutes
The Web Storage System is capable of handling electronic forms similar to Outlook 2000. Instead of Outlook forms, HTML- or ASP-based forms are launched when the user opens an item in a Web browser. A DLL called WMTEMPLATES.DLL defines the default templates used by OWA to render standard HTML forms for e-mail messages, contacts, and calendar objects. You can extend OWA by implementing a custom user interface based on Web Storage System forms. Web Storage System forms must be registered in the Web Storage System Forms Registry.
It is a good idea to install the Web Storage System Forms SDK on your Exchange 2000 server and the FrontPage Extensions for Web Storage System Forms on your workstation if you are planning to design Web Storage System forms. The server component integrates a custom forms engine (EXWFORM.DLL) into Exchange 2000 Server, which is used to render HTML forms with information from Web Storage System folders and items (see Figure 23.4).
Figure 23.4 Web Storage System forms processing through a custom forms engine
Using FrontPage 2000 with extensions for Web Storage System Forms, you can build Web-based applications directly in the Web Storage System. This has several advantages. For instance, programming know-how is not required, custom properties can be defined conveniently, and HTML forms can be registered in the Web Storage System automatically. Knowledge about Web Storage System internals is not required. Using FrontPage, you can open Web pages directly in the Web Storage System to edit them. The functionality is similar to the FrontPage Extensions Web on a standard file system. Detailed information on how to design HTML-based Web Storage System forms is available in the Web Storage System Forms SDK documentation.
It is very easy to develop frame-based Web pages using FrontPage. When you set each frame to use a particular Web page, you may specify URLs that point to Web Storage System folders or individual items. OWA will then be used to render the contents in these frames. For instance, you can build a page that displays both the Calendar and the Inbox folder.
The Web Storage System is capable of launching ASP-based forms directly and without the need for a custom forms engine. EXWFORM.DLL is not required to fill the Web page because ASPs can retrieve item properties themselves. However, it is convenient to design the forms using FrontPage 2000 first, and then extending the functionality through ASPs developed in Visual InterDev. Visual InterDev does not allow you to manage the forms registry or schema definitions automatically. If you do not want to use FrontPage 2000 for this purpose, you need to create the form registration items and property definitions manually.
To use custom Web pages in the Web Storage System, you need to reference them in registration items. Every Web Storage System folder provides access to an urn:schemas-microsoft-com:exch-data:schema-collection-ref property, which identifies the default URL of the folder in which to look for schema definition items and forms registries. If this property is not set, the default location is non_ipm_subtree/Schema in the folder's mailbox or public store.
The forms registration is based on items with a DAV:contentclass of urn:schemas-microsoft-com:office:forms#registration. Various properties can be set for this item type to control how the referenced Web page is used. For instance, one Web page may represent the default view for a folder, and another may be launched when an item of a particular content class is opened. Data and forms must reside on the same server. Remote access to forms over the network is not supported.
Based on the information obtained from the browser (that is, requested URL and HTTP header information), the Web Storage System looks for a form definition that matches the requested item, the browser capabilities, and other information. Through a best-fit comparison the appropriate form is determined for the rendering process.
Important information retrieved from forms definitions includes the following:
NOTE
For ASPs, both executeurl and formurl must be set to the ASP page. ASPs do not require the help of a forms rendering engine to generate Web pages.
The forms registry has a great influence in the behavior of customized Web Storage System applications. Each registration item maps a certain set of circumstances through its properties to a specific form. For instance, you may implement one form for Internet Explorer 5.0 in English and another form for Microsoft Mobile Explorer in French to render the data in the best way possible according to the user's browser capabilities and language (see Figure 23.5). The user does not need to be concerned about this process. Based on the browser, the requested item, and forms registration information, the Web Storage System determines the appropriate form automatically. You may track message and content states, browser capabilities and version, and parse the browser's language. You can implement different forms for specific URL actions performed on an object (CMD=).
Figure 23.5 Accessing the same item from different Web browsers
To determine which version of a form to use, the Web Storage System checks the following information in subsequent order: HTTP request, URL query string (CMD=), message state, content state, browser capability, browser version, browser platform, major version number, minor version number, and browser language.
Every form registration item must contain the following basic properties:
In this exercise you will create a public folder and register a custom ASP page in the Web Storage System. You will use a simple yet very illustrative sample form from the Microsoft Exchange 2000 Server Platform SDK.
To view a multimedia demonstration that displays how to perform this procedure, run the EX1CH23*.AVI files from the \Exercise_Information\Chapter23 folder on the Supplemental Course Materials CD.
To implement a custom Web interface for a contact management solution
Install Sub Install 'Get the folder sFolder = InputBox("Please enter the URL to the folder" _ & ": example http://serverName/public/foldername" _ ,"Setup Instructions") If Trim(sFolder) = "" Then Exit Sub End If 'Create the app folder, ' pointing its SCR to the BIN subfolder Set oDest = CreateObject("CDO.Folder") oDest.Fields("urn:schemas-microsoft-com:" _ & "exch-data:schema-collection-ref") = _ sFolder + "\bin" odest.Fields("DAV:contentclass") = "urn:content-classes:folder" oDest.Fields.Update oDest.DataSource.SaveTo sFolder 'Create the BIN folder and make it invisible Set oDest = CreateObject("CDO.Folder") oDest.Fields("DAV:ishidden") = True oDest.Fields.Update oDest.DataSource.SaveTo sFolder + "/bin" 'Fill the BIN folder with form registrations Set oCon = CreateObject("ADODB.Connection") oCon.ConnectionString = sFolder + "/bin" oCon.Provider = "ExOledb.Datasource" oCon.Open '————————————————————————— 'Register the default page for the folder Set oRec = CreateObject("ADODB.Record") oRec.Open "default.reg", oCon, 3, 0 oRec.Fields("DAV:contentclass") = _ "urn:schemas-microsoft-com:office:forms#registration" oRec.Fields("urn:schemas-microsoft-com:office:forms#contentclass") = _ "urn:content-classes:message" oRec.Fields("urn:schemas-microsoft-com:office:forms#cmd") = "open" oRec.Fields("urn:schemas-microsoft-com:office:forms#formurl") = _ "CustomMessage.asp" oRec.Fields("urn:schemas-microsoft-com:office:forms#executeurl") = _ "CustomMessage.asp" oRec.Fields.Update oRec.Close 'Further instructions MsgBox "Copy CustomMessage.ASP into the BIN directory." _ & " Enable script execution on the directory.", _ 64, "Further Instructions" End Sub
Figure 23.6 Preparing a customized Web Storage System form
<%@Language=VBScript%> <html> <body> <% dataurl = request.querystring("dataurl") Set c = Server.CreateObject("ADODB.Connection") c.ConnectionString = dataurl c.Provider = "ExOledb.Datasource" c.Open Set r = Server.CreateObject("ADODB.Record") r.Open dataurl, c, 3 %> <form class="form" method="post" action="<%=request.querystring("dataurl")%>?Cmd=save"> <h3> Message</h3> Subject:<input type="text" name="urn:schemas:mailheader:subject" value="<%=r("urn:schemas:mailheader:subject")%>" <input type="submit" value="Save"> </form> <% r.Close c.Close %> </body> </html>
IMPORTANT
If anonymous access is enabled for the Public virtual directory, INSTALLMESSAGE.VBS will run in the context of the anonymous IIS account. In this case, you may not have the required permissions to modify items in the CustomMsg or Bin public folder. Use Exchange System Manager to adjust the client permissions and propagate the changes to all subfolders. The configuration of folder permissions was illustrated in Exercise 2 of Chapter 17, "Public Folder Management."
Figure 23.7 Opening items in a custom Web page in Outlook 2000
The Web Storage System supports custom HTML forms based on ASP scripts or ISAPI filters. Any form must be registered in a forms registration item. This exercise used an item called DEFAULT.REG to specify the CUSTOMMESSAGE.ASP file for the Open command, oRec.Fields("urn:schemas-microsoft-com:office:forms#cmd") = "open". Based on the registration properties of the DEFAULT.REG item, the Web Storage System is able to locate the desired custom form, retrieve it, and use it to render the data. Custom forms can be stored in the information store along with the actual user items. For ASP pages, you need to ensure that Script and Execute permissions are granted. ISAPI filters, such as EXWFORM.DLL, require Script and Executable permissions for the virtual directory. You do not access the forms renderer, such as an ASP page, directly. Instead, the Web Storage System launches the form automatically when you work with items in the Web Storage System.
The event model of Exchange 2000 Server allows you to work with two general types of events: transport events and Web Storage System events. Both can be asynchronous or synchronous. While transport events allow you to customize the behavior of the Simple Mail Transfer Protocol (SMTP) or Network News Transfer Protocol (NNTP) service, Web Storage System events, based on OLE DB, enable you to implement workflow and process-tracking logic. Web Storage System events are the basis of workflow, which is a topic of Chapter 24, "Workgroup and Workflow Technologies."
Web Storage System events are useful in many scenarios. For example, a vacation planner application could initiate an approval process when a user submits a new vacation request. Through an asynchronous event, you can notify the user's manager that a new request is now awaiting approval in the Web Storage System folder. Likewise, another asynchronous event may inform the user when the manager approves (changes) the request item or denies (deletes) it. Synchronous events, on the other hand, enable you to check data before it is saved. You may use a synchronous event, for instance, to prevent the transmission of incomplete vacation requests (see Figure 23.8).
Synchronous events occur before, and asynchronous events occur after, any changes are committed to the store. Synchronous events are called OnSyncSave and OnSyncDelete. Similarly, asynchronous events are called OnSave and OnDelete. When a user saves an item in the Web Storage System, OnSyncSave is fired before the changes are committed, followed by OnSave. Likewise, OnSyncDelete occurs before an item is deleted, followed by OnDelete when the deletion is committed. In addition, Exchange 2000 Server supports three system events: OnTimer (timer events), OnMDBStartUp (a store is mounted), and OnMDBShutdown (a store is dismounted).
Figure 23.8 Automatic data processing based on Web Storage System events
Synchronous event sinks fire first, followed by folder rules (if defined), and asynchronous event sinks. Synchronous events support priority values, which can be registered for each event sink. Asynchronous events do not support priorities and fire in an arbitrary order. Unlike synchronous events, asynchronous events do not block the event source and cannot obtain exclusive control over the item that triggered the event. An item may be deleted before an asynchronous event is fired.
Event sinks are the entities that receive and process Web Storage System events. They can be custom COM classes or scripts that the Web Storage System calls according to the properties specified in an event registration. Only when the event meets the event registration criteria is the appropriate event method called in the event sink. To register events, you can use a VBScript file called REGEVENT.VBS, which you can find on the Exchange 2000 Server CD. You can use REGEVENT.VBS to register, enumerate, and delete event registrations. For parameter definitions and examples of how to use REGEVENT.VBS, see the Exchange 2000 Server SDK documentation.
NOTE
Web Storage System event sinks are registered in the IIS metabase via Server Extension Objects (SEO). The ExOLEDB provider reads the event registration and calls the appropriate bound event sinks.