Expanding Exchange Server

Microsoft's vision for Exchange Server encompasses more than just email. The perfect server for today's electronic office must include features such as document management, collaboration, and workflow in addition to email and calendar functionality. Lotus Notes' success is largely a result of the product's groupware capabilities, and Microsoft is well aware that Exchange Server must include similar functionality to maintain Exchange Server's long-term success. Currently, Exchange Server doesn't quite meet this standard, but Microsoft has made progress in increasing Exchange Server's groupware capability. Third-party groupware applications can bridge the gap between Microsoft's vision for Exchange Server and reality.

Several software vendors offer groupware applications that integrate with Exchange Server and Outlook. For example, Eastman Software produces WorkFolder for Microsoft Exchange and Document Manager for Microsoft Exchange, two products that organize business processes on an Exchange Server system. Document Management Extensions for Microsoft Exchange from 80-20 Software is a low-cost Exchange document-management solution at $98 per seat. Keyfile offers Keyflow for Microsoft Exchange Server, an Exchange workflow application. And Compaq introduced Work Expeditor for Exchange at the 1998 Microsoft Exchange Conference in Boston, Massachusetts.

This product selection indicates a demand for groupware applications in the Exchange Server community. However, before I discuss the functionality you should look for in collaborative solutions, consider what you can do with standard Exchange Server and Outlook.

Is Exchange Enough?
Using Exchange Server and Outlook to build a collaborative environment is completely feasible. You can create public folders to store project documentation, use a distribution list to grant access to the documentation to only the project team, and combine Outlook forms with public folders to input and store structured information such as customer contact information. Also, you can combine Collaboration Data Object (CDO) Routing Objects with Outlook forms to build basic routing applications. (For more information about routing applications, see "Building Routing Applications in Exchange," October 1998.)

Is this functionality enough for your company? Exchange Server's features offer sufficient collaboration functionality for many businesses. For example, my organization uses public folders to share documents, and users access those documents via Network News Transfer Protocol (NNTP) news-readers and Web browsers. However, you need a third-party product if you require advanced features. Exchange Server public folders don't let you set different access controls on individual documents within a folder or automatically maintain different versions of a document as various people contribute.

Exchange Server might also meet your workflow needs. Workflow items are intelligent documents that know to whom the document must go, what the recipient needs to do with the document, and whether the document must meet any conditions before continuing in the routing process. Exchange Server offers serial routing, which is fine for simple workflow items. For example, travel requests in which an employee asks a manager for authorization to take a trip are straightforward serial routing requests. The employee creates a request, and the routing application sends the request to the authorizing manager, who can approve or disapprove the item. If the manager approves the request, the application routes the item to the travel department, which makes the necessary reservations.

Parallel routing complicates the process by introducing concepts such as splits, joins, and merges. For example, a parallel routing application must account for documents that require two or more managers' approval. What does the application do with a document if some, but not all, the managers reject the document? Can the document proceed to the next step if three managers approve the document and one manager rejects it? Add to this scenario conditional routing, which controls the flow of items based on the data they contain, and collecting electronic signatures, which verify that the right people interact with the item, and you have a very complex environment.

Exchange Server can't account for these complex conditions, despite CDO Routing Objects' potential. Microsoft acknowledges this limitation and explains that CDO Routing Objects deliver simple document routing rather than workflow functionality. (Also, CDO Routing Objects are an enabling technology, not a finished application. Be prepared to write code to use CDO Routing Objects.) To conceptualize the subtle difference between routing and workflow, think of routing as the mechanics of moving an item from place to place along a predefined route, and workflow as the mechanism that controls the interaction between the recipient and the item at each stage in the item's routing cycle.

If Exchange Server doesn't offer the features your company needs, third- party solutions are an alternative. You can use a third-party product with Exchange Server and Outlook, or you can invest in a separate document management system. To expand Exchange Server's standard capabilities and add information access control, choose a product that integrates with Exchange Server and Outlook.

Extending Exchange Server and Outlook's Horizon
Outlook has always been an extendable client. Software developers can use two technologies to incorporate new functionality into Outlook. First, developers can use the Messaging API (MAPI) to build an information service provider that describes a foreign repository's contents to a MAPI client, such as Outlook. The second technology is Outlook's Add-In Manager, which lets products add options to Outlook's menus.

MAPI. Many document management and workflow products that integrate into Exchange Server use their own repositories to hold information about an application's documents. Sometimes the repository also stores document data, but usually NTFS directories store documents. These products can store content in public folders, but only MAPI or Internet Message Access Protocol (IMAP)4 clients can access documents in Exchange Server public folders (and IMAP4 has limited access). Thus, many vendors develop-ing applications that integrate with Exchange Server give products a document repository. Developers build an information service provider to map the application's repository to Outlook.

When Outlook starts, it consults a profile to determine the set of information services it will use during a session. Users can manually select a profile; if a user doesn't select a profile, Outlook uses the default setting. The system stores profiles in the HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Windows-MessagingSubsystem\Profiles Registry key. When you connect Outlook to an Exchange Server system, Outlook uses a profile to find the name of the server and the mailbox to connect to. The profile also gives Outlook the names of one or more .dll files to load to connect to the information service. These .dll files contain the code necessary for an information service to respond to the MAPI function calls Outlook generates.

To examine the .dll files Outlook calls, go to the Outlook Tools menu, Services, select an information service, and click About. Screen 1 shows details about the Lotus Notes information service provider, nwnsp32.dll. When you install the Lotus Notes client 4.52 or later, your system loads this .dll. Outlook can use nwnsp32.dll to browse the contents of a Lotus Notes mailbox. However, accessing another email system's mailbox and being able to work effectively with the contents of the mailbox are not the same. Be sure to test standard options for compatibility before implementing this solution.

   Previous  [1]  2  Next