This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.
.gif)
Exchange 2000: Web Storage System, Workflow Tools, and CDO Turbocharge Collaboration Apps |
||||
| Sean McCormick | ||||
|
||||
icrosoft® Exchange 2000 provides a rich development platform for creating Web-based applications and was designed with the developer in mindâ€"enabling you to build powerful collaborative applications. Web Storage SystemsThe new Web Storage System in Exchange 2000 is conceptually the same as an Exchange-based information store. Instead of holding only Exchange-based data, however, a Web Storage System can store all sorts of documents and data types and is accessible via a number of methods. A Web Storage System is a hierarchical folder system, much like a file system, that can hold Office documents, e-mail messages, Web pages, multimedia files, and so on. It can be accessed via Web browser (HTTP), Exchange public folders, file system drive mapping, Data Access Objects (such as ADO 2.5), wireless protocols, and the like. Web Storage Systems act like a potluck dinner for corporate data. Bring whatever data you want and the Web Storage System services manage storage, indexing, and searching. For example, you could access your Exchange environment via HTTP with this URL: |
.gif){kind=small}
https://ServerName/Exchange/MBX/smccormick/calendar/
You could use an OLE DB connection string like this:
file://./backofficestorage/example.com/MBX/smccormick/calendar/
Or you could use a drive mapping like this:
M:\ example.com\MBX\smccormick\calendar\
Unlike previous versions of the Exchange information store, Web Storage Systems can be broken out into multiple parts, and those parts can be administrated separately. For instance, you can have two Web Storage Systems providing mailboxes to your users. One Web Storage System can be backed up offline while the other is still online providing mailbox access on the same server.
Figure 1 shows how to access an inbox using ADO. This code first creates the URL string that represents the path to the inbox and uses it to open the Record object. Next, the code creates an ADO Recordset object that represents the contents of the Record object (which points to your inbox) and traverses that recordset, printing out the display names of its contents.
Once your data is within a Web Storage System, it can be converted and rendered into HTML using the Web Storage System engine. The Web Storage System engine creates a Web Storage System form to represent your document in a browser. The engine detects your browser automatically and can provide compatible code back to HTML 3.2. Because the Web Storage System engine can utilize XML, WebDAV, and HTML, using Microsoft Internet Explorer 5.0 will give your users an interactive experience similar to using Outlook 2000 over the Internet. If you simply use an HTML 3.2-compliant browser, the data will be displayed in a static environment that requires round-trips to the server.
The Web Storage System provides multiclient access to events that fire when certain tasks occur within the Web Storage System. Document creation, deletion, changing, and timer-based functions are all events you can script to accomplish tasks. Both synchronous and asynchronous events are supported. Synchronous events allow tasks to complete before the particular event finishes. For instance, the event sink may validate that all of the fields in a document are correct before committing the item to the store. Asynchronous events fire off tasks that are not guaranteed to finish before the particular event finishes. For example, you may want to notify others via e-mail that a new document has been posted to the folder. The event is fired and finishes at its own pace without holding up other processes.
The Workflow Engine
One exciting new feature in Exchange 2000 is the workflow engine. Previous versions of Exchange provided separate tools and services to help developers create workflow applications: routing objects, event services, scriptable folders, and so on. Exchange 2000 provides a comprehensive set of services, COM objects, and design-based tools that comprise the workflow engine. This module's sole purpose is to help developers create and maintain workflow applications. The workflow engine and the workflow designer allow you to take full advantage of the Web Storage System features while creating robust workflow applications.
One example of a workflow application is a program that automates an existing paper-intensive task. For instance, if you have to fill out 10 requisitions and get nine approvals on each requisition to get a new stapler, you're doing a paper-intensive chore that begs to be automated with a workflow application. Any business task that is time-consuming, tedious, and takes time away from real work is a good candidate.
Most workflow applications have a few services in common: routing, state management, audit tracking, and so on. The workflow engine takes care of those duties for you. The workflow engine also includes a workflow designer that helps you map out your business process and acts as the skeleton for your application. The workflow engine provides COM interfaces that allow programmers to access events, routing, and audit trailing services straight from their C++ or Visual Basic®-based applications.
The Workflow Designer
The workflow designer helps you create a functional workflow application quickly. It allows you to specify workflow states, which represent the milestones that occur during workflow. The different states are connected by actions that change the workflow state. For instance, a workflow application for business trip approval might have the following states: request, approval, planning, completion, and cancellation.
Actions cause workflow to move from state to state. For instance, when you get approval for your travel request, you move on to the planning state. After the trip is planned, you move on to the completion state. If your trip gets cancelled or disapproved at any point in the application, you move directly to the cancellation state.
The workflow designer provides a graphical tool for creating states and the actions that join them. It also provides a Visual Basic-based scripting environment that allows you to accomplish tasks programmatically when an action or event is fired within your designed workflow.
Seven basic actions can occur to your data, moving the workflow to a different state. The Create action marks the point when the data first enters the workflow, and the Delete action occurs when your data exits. Enter and Exit actions can be assigned to any state and fire when data either enters or exits that particular state. The Change action occurs when your data is updated. The Receive action fires when your data/document receives mail. The workflow engine also lets you time-expire your data with the Expiry action, so you can clean up forgotten or abandoned requests.
When creating your workflow, you have three execution locations where you can manipulate data programmatically, accomplish tasks, create and commit transactions, and so on. These locations are executed in order, and their execution depends on the previous result. The conditional expression fires first, followed by the action script (if the conditional expression evaluates to True), and then the compensation script (if the action script doesn't commit a transaction). The entire workflow has a shared script, which acts like a script library. This allows you to create subroutines and functions that your different execution locations can call. Figure 2 shows the workflow designer environment and the three execution locations.
A Workflow Application Example
Let's take a look at how to install and execute a sample workflow. (The sample is included with the source code at the link at the top of this article.) This workflow will run on a public folder. Users can post questions using a custom Outlook form I created, and their question data will then be posted to the public folder. Other users can read the postings, answer questions using fields on the Outlook form, or post questions of their own. Questions that aren't answered within a certain amount of time are deleted from the folder automatically. Questions that have been answered are also saved for a certain amount of time before they expire. A question can only be deleted if it expires or if it is manually deleted after it has been answered. Figure 3 shows the workflow design.
This workflow has three states: AddRequest, AnsweredRequest, and ExpiredRequests. The workflow begins with the Create action, which starts the workflow and sets it to the AddRequest state. The AddRequest state allows three actions: Enter sets up the expire time value, Change moves the data to AnsweredRequest state, and Expiry takes the expired question to ExpiredRequests. The AnsweredRequest state supports two actions: the Enter action sets up the expiring time frame, and the Expiry action takes the answered questions to the ExpiredRequests. The Delete action fires automatically when a user deletes an answered question manually. For demonstration purposes, each action is scripted to e-mail the administrator, reporting the current state of the data. In addition, the two Expiry actions will delete the data from the folder.
Set up the work environment by installing and configuring Exchange Server for workflow. The steps I followed for Exchange 2000 Release Candidate 1 in my particular environment are listed here. Some of these steps may sound overly aggressive with distribution rights and security holes, but this configuration supported workflow properly on my machine.
First, create a service account with a mailbox assigned to it. Make sure the mailbox is created within the same Storage Group as the public store you are working with. Add the user to the Domain EXServers group.
Using the Component Servers MMC, go to the properties of the Workflow Event Sink package. Set the identity of this package to be the service account you just created. Under the CdoWfEvt.EventSink.1 interface properties within the Workflow Event Sink package, make sure to check the Can Register Workflow role. Within the roles of the Workflow Event Sink, add the users of the workflow to the Can Register Workflow role. Also make sure to add the service account you created earlier and your users to the Privileged Workflow Authors.
Go to the Exchange System Manager. Add a public folder for this workflow to run on. Make sure that all users you plan to use with this workflow have access to author and edit data within this folder.
Install the Outlook form called QuestionRequest.oft (included with this article's sample code, which is available from the link at the top of this article) into the organizational forms library.
Open the workflow designer and browse to the folder that you created earlier. When the workflow designer opens, go to the Import Workflow Process from XML tool and import the WorkflowExample.xml sample file.
On the General tab, check the "Default workflow process for this folder" box and verify that Run as Privileged is checked. This will allow your scripts to create instances of COM objects and perform other privileged tasks. Click on the Design tab and turn on each action. Each time you click an action arrow, you will notice that the action script changes. Enter each action script and modify the sendmail function parameters to be the e-mail address of your administrator (mine was administrator@example.com). In the Process List, click your folder name. Set the workflow to be activated.
Your workflow is now installed and running on your public folder. Go to your Outlook client, click the folder in which you installed the workflow process, and select Create a New Form | Organizational Forms Library | Question Request. Once this form installs, fill out the Subject and Question fields and click the Save button. This posts the form to your folder. This action just entered you into the workflow, and should send your administrator the first e-mail stating that a question was created.
You can now log onto Exchange as somebody else and answer the posting. This will cause another e-mail to be sent to your administrator as your data moves from the AddRequest state to the AnsweredRequest state. At this point you can manually delete your answered posting (exiting the workflow), which will cause the last action to occur and a final e-mail to be sent to the administrator.
If you leave a question unanswered, this will eventually cause the Expiry action to fire, deleting the message and sending e-mail to your administrator with this information.
You can see from this sample app that creating a powerful workflow application is much easier with Exchange 2000. You barely have to do any coding; you just visually design your workflow. Exchange 2000 also provides a COM interface into the workflow process, letting you take full control and create a custom workflow application that allows you to take advantage of the routing, event handling, and audit trails in Exchange 2000.
The Evolution of CDO
With the release of Exchange Server 5.0, CDO became the method for accessing and programming Exchange data. CDO was developed to give programmers access to the Microsoft Messaging API (MAPI) quickly and easily from a COM-based interface.
Before Windows® 2000 there were two distinct versions of CDO. CDO 1.2.1â€"the Exchange 5.5 version of CDOâ€"was a set of objects based on MAPI that allowed developers to access Exchange services such as e-mail, calendaring, and contacts. There was also a version of CDO for Windows NT® (CDONTS), which allowed access to the SMTP services of Microsoft Internet Information Server. CDONTS has been renamed and is now called CDO for Windows 2000 (CDOSYS). This COM interface provides an upgraded library based completely on Internet standards and supports access to new services, such as Network News Transfer Protocol (NNTP) for handling Usenet news over TCP/IP.
The new version of CDO for Exchange 2000 (CDOEX) has also been rewritten from the ground up to conform to Internet standards. CDOEX has moved away from a strict basis in MAPI, but it still provides COM-based access to Exchange e-mail, calendaring, and contact functionality.
Microsoft has also provided some additional libraries under the CDO umbrella. These new libraries provide COM access to other areas of Exchange 2000. CDO for Exchange Management (CDOEXM) gives developers access to user and server administrative tasks like adding mailboxes and modifying server configurations. CDO for Workflow objects (CDOWF) allows programmers to access the Exchange workflow engine and its powerful capabilities for routing and managing workflow applications. A road map to the CDO library can be found at https://msdn.microsoft.com/library/techart/cdo_roadmap.htm.
Creating Messages and Appointments
The Visual Basic code examples in this section come from the beta release of the Exchange 2000 documentation. I have tested all of these examples in my own lab environment against the released version of Windows 2000 and Exchange 2000 RC1. Figure 4 shows my test environment for Windows 2000, Exchange 2000, Active Directoryâ„¢, and Web Storage System.
.gif) |
| Figure 4The Test Environment |
With CDO 1.2.1, it takes 11 lines of code to create an outbound e-mail message:
Set CDOSession = CreateObject("MAPI.Session")
CDOSession.Logon
Set oFolder = CDOSession.Outbox
Set oMessages = oFolder.Messages
Set oMsg = oMessages.Add
oMsg.Subject = "Test Subject"
oMsg.Text = "Test Message"
Set oRcpt = oMsg.Recipients
oRcpt.Add , "SMTP:corky@seanmccormick.com"
oRcpt.Resolve
oMsg.Send
With CDOEX, this same task takes only six lines of code:
Set iMsg = CreateObject("CDO.Message")
iMsg.To = "corky@seanmccormick.com"
iMsg.Subject = "This is a test"
iMsg.TextBody = "This is a test message"
iMsg.From "smccormick@example.com"
iMsg.Send
You first instantiate your message object, then you set the appropriate properties of your message object for the message to be delivered. (Notice that you no longer have to resolve a recipient of a message.) To send the message you need to set the From address and run the Send method. It's a little less code, but a big difference from the way you used to accomplish the same task in CDO 1.2.1.
Next, let's look at how to create a calendar appointment. In CDO 1.2.1, the code would look like this:
Set CDOSession = CreateObject("MAPI.Session")
CDOSession.Logon
Set oFolder = CDOSession.GetDefaultFolder
(CdoDefaultFolderCalendar)
Set oMessages = oFolder.Messages
Set oAppt = oMessages.Add
oAppt.StartTime = "4/8/2000 2:30 pm"
oAppt.EndTime = "4/8/2000 3:30 pm"
oAppt.Subject = "Getting Married
oAppt.Location = "1234 Church St."
oAppt.Text = "Remember to pick up the ring"
oAppt.Update
With CDOEX, you create an appointment in your calendar like so:
Dim CalendarURL As String
Dim iAppt As New Appointment
CalendarURL =_"file://./backofficestorage/example.com
/MBX/smccormick/calendar/"
iAppt.StartTime = #4/8/2000 2:30:00 PM#
iAppt.EndTime = #4/8/1000 3:30:00 PM#
iAppt.Subject = "Getting Married"
iAppt.Location = "1234 Church St."
iAppt.TextBody = "Make sure to pick up the tuxedos"
iAppt.DataSource.SaveToContainer CalendarURL
As you can see, the method for accessing and creating a calendar appointment using CDOEX is much like the method for creating and sending a message. You create your appointment object, then set the necessary properties to make it a valid appointment. Finally, you save the appointment by calling the DataSource.SaveToContainer method with the URL of your calendar as an argument.
Integration with Active Directory
From a developer's point of view, there are many exciting service additions to Exchange 2000; integration with Active Directory is probably the most significant. Exchange no longer maintains its own directory; it now relies on Active Directory. Because of this integration, all of your Exchange user administrative tasks are now handled with an Active Directory user administration tool instead of an Exchange user administration tool. In addition, some Exchange objects have been replaced with Active Directory objects. Instead of distribution lists, you now create groups and instead of creating a custom recipient, you now create a mail-enabled Active Directory user.
Since Exchange no longer has its own directory, Exchange 2000 has been spared the task of directory replication. Active Directory handles this task better, faster, and more efficiently than Exchange. Programmers now access these features in Active Directory through the Active Directory Services Interface (ADSI), just as they accessed the Exchange 5.x directory.
Creating Mailboxes and Users
If you have an Exchange 2000 mailbox configured for an Active Directory user, that user is said to be mailbox-enabled. If you have a user within the Active Directory who has an e-mail address configured, but that address is not configured with Exchange, that account is considered mail-enabled. A mail-enabled account is the same as a custom recipient in the Exchange 5.0 directory schema. It allows your Active Directory users to see this account in the global address list and use the e-mail address as a recipient without having to use any Exchange resources.
To create mailboxes for Exchange users, you can either mailbox-enable an existing Active Directory user or create a new Active Directory user and mailbox-enable it. Figure 5 shows how to create an Active Directory user and mailbox-enable that new account. The code starts with a CDO.Person object. Once the appropriate properties of this new object are set, it is saved to the Active Directory with the DataSource.SaveTo method. CDOEXM objects are then used to create the mailbox and mailbox-enable the new Active Directory account.
This code takes an existing Active Directory account and mail-enables it to create a custom recipient within your directory:
Dim objPerson As New CDO.Person
Dim objRecip As CDOEXM.IMailRecipient
objPerson.DataSource.Open _
"LDAP://Kenny2000/CN=TestUser,CN=users,DC=example,DC=com"
Set objRecip = objPerson
objRecip.MailEnable "smtp:test@seanmccormick.com"
objPerson.DataSource.Save
Once again, you first get the Person object, then manipulate its Exchange properties with the CDOEXM objects. ConclusionExchange 2000 has many new features that should impress developers who are building Web-based collaborative applications. Almost all Exchange services have been rewritten to support Internet standards such as XML, HTTP, WebDAV, SMTP, NNTP, and LDAP. This makes Exchange faster and more reliable. CDO for Exchange was rewritten from the ground up and provides a new class of services to developers. The new methods of accessing Exchange data will turn any ADO or OLE DB expert into a CDO expert as well.The workflow engine will allow you to create workflow applications quickly and visually. The new COM interfaces will enable you to build more complicated workflow applications with less effort. Other new services like instant messaging, content indexing, Web Storage System events, the workflow engine, and integration with Active Directory will help make you look like a collaboration/workflow guru in no time. |
|
| For related articles see: Microsoft Exchange Development Center For background information see: https://msdn.microsoft.com/library/psdk/cdo/amsmtp_3kdv.htm https://msdn.microsoft.com/library/psdk/cdo/oleobjaf_9m2b.htm https://msdn.microsoft.com/library/techart/cdo_roadmap.htm Sean McCormick is a senior systems consultant for EnterpriseWise in Nashville, TN, designing and developing n-tier apps using the Microsoft DNA architecture. Sean has created solutions in the areas of manufacturing, financial reporting, workflow, sales automation, and knowledge management. You can reach Sean at https://www.seanmccormick.com. |
|
From the July 2000 issue of MSDN Magazine.