Microsoft Mail is one of the leading contenders in the e-mail application market. With Windows 95, Exchange is the new e-mail client that is gaining popularity with users. When Windows NT is given the Windows 95 user interface, it too will offer an Exchange client. According to BIS Strategic Decisions, a consulting firm in Massachusetts, there were about 2.5 million Microsoft Mail users at the time this book was written. Many Windows 95 users also are connected to some form of e-mail, including internal systems, Microsoft Network (MSN), Internet connections, and other services such as CompuServe, Prodigy, and America Online. Windows NT includes a workgroup version of Microsoft Mail, and future versions of Windows NT will include Exchange. Windows 95's Exchange client supports a wide array of mail types, including the Internet, fax, and MSN. Windows NT's new Exchange Server will be most useful in implementing custom interuser communications.
NOTE
Microsoft has announced its Exchange Server product. This system, which will run under Windows NT Server, lets larger organizations manage mail, Schedule+, Internet mail, and other information-based services. This product should be released in early 1996.
NOTE
It can be expected that eventually Microsoft Mail will be totally replaced with the Microsoft Exchange products. However, at this time it's still as common to see Microsoft Exchange as it is to see Microsoft Mail. Actually, the Microsoft Exchange Server replaces the Microsoft Mail Server.
Applications such as Excel, Word for Windows, and Project, which provide Send and Add Routing Slip menu choices on the File menu, are called mail-aware applications. A mail-aware application (MAA) lets you send an object created by the application to one or more users as an attachment to a Microsoft Mail message.
Schedule+ is a simple appointment scheduling and to-do list application that is closely coupled with Microsoft Mail. Schedule+ 7 is included with Microsoft Office 95. Schedule+ is a workgroup scheduling tool that lets you or your designee set up appointments and schedule meetings with other members of your workgroup. Schedule+ checks the appointment calendar of prospective attendees and notifies you of conflicts. You can let Schedule+ find a date and time when all attendees have an open schedule. This can save a substantial amount of time when your meeting involves a large number of people.
Developers who are migrating their consulting practice from DOS to Windows are likely to find that clients are interested in database applications that interact with Microsoft Mail and Microsoft Exchange. This chapter describes how you might create mail-aware Visual C++ database applications. It also shows you how to obtain and use the Schedule+ Libraries (version 1.0a2), which lets you duplicate the functions contained in the Schedule+ application within a 16-bit Visual C++ application. A brief description of the Windows Telephony API (TAPI), which is part of the Windows Telephony SDK, appears near the end of this chapter.
NOTE
The Schedule+ Libraries are available only in a 16-bit version (as of January 1996). The 32-bit version of these libraries is currently not available from Microsoft. Schedule+ 7 is a 32-bit application.
Creating mail-aware database applications with Visual C++ 4 is as simple as selecting the correct option when creating your project using Visual C++ 4's AppWizard. Making an existing application mail-aware is a much more complex topic, one that is beyond the scope of this book. It would probably be easier to create a new mail-aware application shell, grafting on the working parts of an existing application, than to try to add mail-awareness to an existing application. This book's space limitations restrict the discussion of mail-aware Visual C++ applications to an overview of how MFC 4 implements the transfer of documents using Mail and Microsoft Exchange. Sources of additional background information for mail-aware applications, as well as sample applications, are also included in this chapter.
Microsoft Mail 3.5 for PC Networks was the current version of the full implementation of Microsoft Mail at the time this book was written. The competitive upgrade retail version of Microsoft Mail 3.5 includes one server license and licenses for 10 client workstations. Microsoft Mail 3.5 is designed for enterprise-wide e-mail applications using client-server methodology. Microsoft Mail 3.5 isn't a Windows application. It runs under DOS on a network-connected system.
A variety of mail gateways to networks other than Windows NT Server (NTS) and LAN Manager are available. Novell Corporation has an upgrade to NetWare's Global Message Handling Service (MHS) that lets Microsoft Mail 3.5 users connect directly to MHS. Direct connection to NetWare's directory management system eliminates the need for a NetWare gateway to read the NetWare bindery that provides user mail addresses. An optional application, Microsoft Mail Remote for Windows (also known as Remote), lets modem-equipped computers dial in to the Microsoft Mail 3.5 server. Remote also includes gateways for online e-mail services, such as CompuServe and AT&T's EasyLink. Windows 95 includes Microsoft Exchange, a comprehensive mail system that lets users use Microsoft AtWork Fax, Microsoft Mail, and Internet E-Mail. Microsoft Exchange also may be use to access other services such as CompuServe. Both Windows 95 and Windows NT allow dial-in/dial-out connections, using Microsoft's RAS (remote access server) technology.
MAPI also supports X.400, an international messaging standard developed by the Consultative Committee for International Telephone and Telegraph (CCITT). The X.400 standard is used for wide-area messaging systems and is the standard messaging protocol in most countries outside North America. X.400 deals with messages that are transmitted by the switched telephone network, as well as dedicated telephone lines, satellite links, and other communication services provided by public and private carriers. X.400 compatibility isn't included in Mail.
The following sections provide a brief introduction to Microsoft Exchange, which is included with Windows 95, and a discussion of the Microsoft Messaging API (MAPI) on which Microsoft Mail 3.5 and Microsoft Exchange are based.
Windows for Workgroups, Windows 95, Windows NT Workstation (NTW), and Windows NT Server (NTS) include a workgroup version of Microsoft Mail (also known as Mail). Windows 95 includes Microsoft Exchange, a comprehensive mail system that will be moved to Windows NT with the next release of Windows NT. Microsoft Exchange (called Exchange hereafter) lets the user interface with Microsoft Mail, Internet mail, the Microsoft Network, AtWork Fax, and other mail systems including CompuServe. Exchange is a flexible, powerful system.
User e-mail accounts (called mailboxes) are maintained in a group of files that are collectively called a postoffice. Mail uses the \WGPO0000 folder and a collection of folders in the \WGPO0000 folder to store postoffice files. (There are more than 100 items in an initial set of postoffice folders and files.)
Windows 95's and Windows NT's Mail are limited to communication with users whose e-mail accounts are maintained in a single workgroup postoffice. This postoffice can reside on either a Windows NT Server or a Windows 95 machine. If you're using NTS and all Windows 95 and Windows NT users log on to one Windows NT Server domain, you can maintain a single Mail postoffice for the entire domain. You can create additional postoffices for individual workgroups, but you need to duplicate the e-mail accounts in each workgroup postoffice manually. This could be an administrative nightmare if your system has many users. The examples in this chapter use the Windows 95 version of Mail. Figure 21.1 shows the information that is contained in an individual e-mail account record.
Figure 21.1. An account record for a workgroup postoffice.
The person who creates a workgroup postoffice directory structure is the administrator of the postoffice. Only the postoffice administrator can add, delete, or edit e-mail accounts. Figure 21.2 shows an example of the Postoffice Manager window with a three-member workgroup. The administrator of the postoffice usually maintains a separate account for administrative messages. In this case, the account sa is for system messages.
Figure 21.2. The Postoffice Manager window.
Information pertaining to the administrator's and/or user's mailbox is stored in MSMAIL32.INI and in Windows' registration database. The private profile file in the \WINDOWS directory contains only a few entries. Most of the information is stored in the registry. Following is an example of the MSMAIL32.INI file for the postoffice administrator shown in Figure 21.2:
[Microsoft Mail] ServerPath=E:\wgpo0000 Login=GayDeciev
Microsoft designed Mail to be extensible with add-in applications such as AtWork Fax and Microsoft Electronic Forms (MEF), Microsoft Voice (a voice mail system for Windows 95), and applications provided by independent software vendors (ISVs). The registration database is used to notify Mail of the presence of add-in applications and to provide menu choices to launch the add-ins.
Windows 95 provides the capability to send faxes from within Microsoft Exchange; this capability isn't included with the Windows NT version of Mail that was current when this book was written. The fax subsystem of Windows 95 is called AtWork Fax, a reference to the Microsoft AtWork API designed to manage compatible office equipment, such as a stand-alone fax machine, over a network. Windows 95 also lets you share a fax modem with other members of your workgroup. If you send the fax with a Class 1 fax modem (Class 1 modems have high-speed data-transmission capability) to another Microsoft Exchange user with a Class 1 fax modem, the fax is transmitted as an e-mail message rather than as a .TIF (bitmap) file. AtWork Fax uses the .DCX format, a modification of the .TIF format that provides multiple fax pages in a single file.
All messages, regardless of their type, are stored in the same mail database. For example, users of Microsoft Voice have their voice mail messages stored in the same postoffice as e-mail documents and faxes.
Microsoft Mail is based on the Microsoft Messaging API (MAPI), one of the components of Microsoft Windows Open Services Architecture (WOSA). MAPI consists of the following three categories of functions:
| Function | Description |
| MAPIAddress | Creates and modifies address lists. |
| MAPIDeleteMail | Deletes mail messages. |
| MAPIDetails | Provides details on a specific address. |
| MAPIFindNext | Enumerates messages of a given type. |
| MAPIFreeBuffer | Frees memory allocated for the messaging system. |
| MAPILogoff | Ends the session with the messaging system. |
| MAPILogon | Initiates a session with the messaging system. |
| MAPIReadMail | Reads mail messages. |
| MAPIResolveName | Resolves a recipient's name (as entered by the user) to a unique mail address. |
| MAPISaveMail | Saves mail messages. |
| MAPISendDocuments | Sends a standard mail message attachment. |
| MAPISendMail | Sends a standard mail message. |
NOTE
You can download the current version (which was 1.08 at the time this book was written) of the entire MAPI specification in the form of a PostScript file (MAPIPS.ZIP) or a Windows help file (MAPIHL.ZIP) from Microsoft's Internet FTP site at ftp://ftp.microsoft.com/bussys/mail/pcmail-docs. You need a PostScript or TrueImage printer to use the expanded version of MAPIPS.ZIP. Another file in the same library, MAPIWP.ZIP, provides detailed information on the client side of MAPI 1.0 in the form of multiple Word for Windows 2.0 .DOC files.
Microsoft also is documenting MAPI in the Win32 SDK. Another source to check is the MSDN CDs, both Level I and Level II. Another source of MAPI documentation is the Visual C++ 4 CD. Look in Books Online, SDKs | WIN32 Extensions | MAPI.
A variety of e-mail applications compete with Microsoft Mail, such as Lotus cc:Mail, DaVinci Mail, and the e-mail component of Corel's Perfect Office. Lotus cc:Mail, for example, includes both the e-mail function and a scheduling application similar to Schedule+. Lotus has proposed another industry standard, Vendor-Independent Messaging (VIM), for e-mail applications. Lotus Notes, the most successful of the workgroup productivity tools to date, uses VIM as its messaging protocol. ORACLE Corp. also has introduced an e-mail system, Oracle Mail, that uses the Oracle RDBMS to maintain user accounts on an enterprise-wide scale.
NOTE
Most e-mail applications for Windows include bridges or "glue" that enable the interchange of messages with Microsoft Mail. Conversely, it's likely that future versions of Microsoft products will provide some form of connectivity to the Lotus Notes database. If and when the capability to manipulate the Notes database with a future version of Visual C++ becomes a reality, a variety of new opportunities will be opened to Visual C++ database developers.
Lotus has developed a Notes ODBC driver, which is available from Lotus's forum on CompuServe. This driver might be available from other sources as well. Check http://www.lotus.com/ for information if you have Internet access.
A practical example of using MAPI to exchange information between users is that of a local software company. Each employee has a computer connected to a Microsoft Windows NT Server, and Microsoft Mail is configured on each machine.
The receptionist fields incoming calls and attempts to connect the caller with the recipient. However, sometimes a caller can't be connected. In this case, the receptionist uses a custom Visual C++ application to create a special mail message that has specific information about the call.
The message is then sent to the recipient, who also is running this application. The application receives the mail and takes the message's contents and places the information about the call in a dialog box for the user. This user may then respond to the message when he or she returns. Although the recipient will probably call back the person who called originally, the message could be edited and forwarded to another person.
The primary use of mail-enabled Visual C++ database applications is to create workflow products. Workflow applications substitute e-mail routing methods for the conventional interoffice mail envelope to fill in forms and process documents. The objective of workflow applications is to eliminate the handling of paper documents. The database contains a primary record that identifies each document, plus related records that are used to route the document and to record the events that occur during the processing of the document.
Workflow products fall into three major classifications:
You can use Visual C++ to create specialized workflow applications that fall into any of these three categories. Only commercial workgroup productivity applications currently rely on e-mail systems for managing document routing. There is no fundamental reason, however, why customized EDI and DMS applications can't use e-mail methodology for document transmittal. The question is which e-mail methodology to use.
Ordinarily in this book, discussions of the future of applications and programming tools follow the text that describes today's products. In this case, however, I reversed the order to provide perspective on the development of database-related MAAs and MEAs. The future of mail-aware and mail-enabled applications in the Microsoft environment has been projected in a number of review articles in the computer press. Forewarned is forearmed when it comes to profiting from the development of MAAs and MEAs based on Microsoft Mail, because Microsoft Mail currently is a moving target.
Microsoft's approach to competing with the highly successful Lotus Notes groupware application is to provide toolkits that let developers create their own MAAs. Windows 95 is extensively tuned to the concept of MAPI. Windows NT also is becoming MAPI-enabled. The next section discusses the (limited) applicability of the MAPI to Visual C++ database applications.
Windows 95 and the WIN32SDK offer a powerful punch in the MAPI arsenal. This toolkit will work both with Windows NT and with Windows 95, and it represents Microsoft's attempts to combine the Windows development platforms.
Enterprise Messaging Server (EMS) is a 32-bit Windows NT application that Microsoft demonstrated at the Microsoft Mail Users Conference in mid-1993. EMS is now called Exchange Server and is targeted for an early 1996 release. The server is an add-on to Windows NT Server, in the same vein as SNA Server and SQL Server for Windows NT Server. Exchange Server takes advantage of the international X.400 messaging standard instead of the Microsoft Mail protocol, and it also supports other standard network and messaging protocols such as TCP/IP, Simple and Extended MAPI, X.25, and X.500 directory-naming services. Exchange Server provides the Multipurpose Internet Mail Extensions (MIME) being developed by the Internet Management Group. The backbone of Exchange Server is an RDBMS for storing messages. Using an RDBMS rather than Microsoft Mail 3.5 or Notes' flat file structure lets users create joins and run queries against the database in order to manage messages and attached OLE objects.
Microsoft's challenge is to integrate these officially and unofficially announced products into a cohesive workflow-management development strategy to gain market share from Lotus Notes. The challenge facing Visual C++ database developers is to decide whether to wait for Exchange Server before investing the time required to learn the intricacies of Simple and Extended MAPI. Of course, Microsoft Exchange and Windows 95 became available to users in mid-1995, and a version of Windows NT with Exchange might be released in 1996.
You can use the MAPI functions, MAPI Session, and MAPI Messages to create mail-enabled Visual C++ database applications.
NOTE
Generally, if you retain MFC's document-oriented structure, enabling MAPI support when you create your application will provide most of the mail support that most database decision tool applications will require.
NOTE
The MSDN CDs also include additional articles on MAPI, including "Using Mail and MAPI[md]the Possibilities," an overview of the use of Mail in Executive Information Systems (EISs), and "Creating Workgroup Solutions Using Microsoft Word, Microsoft Mail, and MAPI," which was presented by Michel Girard and Eric Wells at Tech*Ed. Both of these articles provide additional assistance in learning how to use the Mail APIs. "Using Mail and MAPI" makes a vague reference to combining MAPI and ODBC in EISs.
Mail-aware and mail-enabled database applications rely on a fill-in-the-blanks approach to obtaining information to add to specified fields of database tables. You can develop a mail-aware Visual C++ application that generates messages based on choices made from combo boxes and text entered from text boxes, but you can't easily create applications that let the recipient modify the message with control objects. Parsing a completed message to update the database also is a complex process. The Microsoft Electronic Forms Designer add-in for Visual C++, discussed in the following section, provides a solution to these problems.
TIP
To add MAPI to an existing MFC 4 application, follow these steps:
- Using the Visual C++ resource editor, modify the application's File menu by adding a new command called Send Mail. Use the command identifier ID_FILE_SEND_MAIL. This identifier is defined in the AFXRES.H file.
- Add the following bold lines to your application's document message map. Be sure to add these lines outside of the AFX_MSG_MAP block:
BEGIN_MESSAGE_MAP(CMailAwareDoc, CDocument) //{{AFX_MSG_MAP(CMailAwareDoc) // NOTE: ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //}}AFX_MSG_MAP ON_COMMAND(ID_FILE_SEND_MAIL, OnFileSendMail) ON_UPDATE_COMMAND_UI(ID_FILE_SEND_MAIL, OnUpdateFileSendMail) END_MESSAGE_MAP()This technique works for both CDocument- and COleDocument-based applications.
- After making these changes, rebuild the project.
This section describes the Visual C++ AppWizard steps used to create a new application that supports MAPI. The changes that AppWizard makes to the application are slight; it follows the same steps described in the preceding section.
To create a MAPI-compatible application, start AppWizard. In the Step 4 of 6 dialog, select the MAPI (Messaging API) option, as shown in Figure 21.3.
Figure 21.3. Adding MAPI support in AppWizard's Step 4 of 6 dialog.
After you've created your new project, it will have the necessary support for MAPI. The CD that comes with this book has an example of a Visual C++ 4 AppWizard-created MAPI program. Look in the CHAPTR21\Mail Aware folder.
Schedule+ is a mini-PIM (personal information management) system that is included with Microsoft Mail 3+, Windows for Workgroups, and Windows NT. Schedule+ 7, included with Microsoft Office 95, incorporates an appointment calendar, a workgroup appointment management system, and a prioritized to-do (project and task) list. Figure 21.4 shows the to-do list window with three projects and a few prioritized tasks for each project. You can assign scheduled completion dates for each task and block time in your appointment calendar to complete the tasks. Figure 21.5 shows the planning window of Schedule+ with time blocked to complete some of the writing tasks for this book.
Figure 21.4. Schedule+'s project and task manager window.
Figure 21.5. Schedule+'s Planner window with time blocked for task completion.
The appointment management system uses Mail to arrange meetings with other members of a workgroup by comparing the participants' free and busy times. When you request a meeting for a specific date and time, Schedule+ creates a graphic overlay of all of the participants' schedules, including your own. If the time you choose conflicts with a participant's schedule, you can select another time or date. Schedule+ also lets you set up postoffice accounts for resources, such as meeting rooms and equipment. Thus, you also can take into account the availability of the resources you need for the meeting. Figure 21.6 shows the dialog box that you use to request a meeting with other members of your workgroup. Users can respond that they will, won't, or might attend the meeting.
Figure 21.6. The dialog box that is used to set up a workgroup meeting.
The Schedule+ Libraries for C consist of SPLUS.DLL, which contains the functions to manipulate Schedule+ data, documentation for declaring and calling the functions in both Visual C++ and C, and a sample Visual C++ and C application with source code. The Schedule+ Libraries are available for downloading as SAL.ZIP from Library 15, MS Schedule+, of the MSWRKGRP forum on CompuServe and is also included on the MSDN Level I CDs. The Visual C++ documentation is contained in SPLUS-C.DOC, a Word for Windows file. The current version of the Schedule Libraries is 1.0a2.
WARNING
The Schedule+ Libraries are available only in a 16-bit version. At the time this book was written, Microsoft hadn't announced a 32-bit version.
The functions contained in SPLUS.DLL fall into the following two categories:
In addition to declaring SAL function prototypes and global constants, you also need to declare several user-defined data types (structures).
The demonstration project, SALAPP.MAK, includes a program to create tasks and appointments, to specify user information, and to review replies to meeting request messages. The SALAPP form, which probably wouldn't win a prize in a Visual C++ application beauty contest, is shown in Figure 21.7.
Figure 21.7. The SALAPP form used to create a new appointment.
NOTE
Because SALAPP is a 16-bit application, it shouldn't be compiled with Visual C++ 4. Use Visual C++ 1.52, which is included with Visual C++ 4.
SALAPP.MAK also includes the following modules:
Although SALAPP.MAK doesn't perform any functions that you can't handle better with the Schedule+ application itself, the declarations and functions contained in the .C modules can save you a substantial amount of time when it comes to writing your own Visual C++ application that uses SAL.
There are only a few Visual C++ database applications in which you might want to incorporate SAL functions compared to mail-aware and telephony-aware or telephony-enabled applications, the subject of the next section. One application provides a connection between the built-in database of Microsoft Project 4.0 and Schedule+ to create tasks, assign completion dates, and block task times in the schedule of each member of the project team. An automated task assignment system can save a substantial amount of time and prevent errors associated with each member having to manually enter the data.
To create a task database, you can export Microsoft Project's task list to an ASCII file or an Excel worksheet and then use Access to import the ASCII file or worksheet into an Access database table. With Project 4.0, which supports OLE Automation and includes VBA, you could bypass the Access importation step and create a table with Visual C++. Alternatively, you can write VBA code to read the task data into an array and then process tasks for each member of the team without the intervening database.
Microsoft's new Telephony API (TAPI) is the latest addition to the Windows Open Services Architecture. TAPI was developed jointly by Microsoft and Intel Corp. and is a member of Microsoft's "AtWork" series of APIs and applications that are designed to use network connections to interrogate and control devices other than computers. When Microsoft adds the final touches to the other AtWork products, you'll be able to attach and control stand-alone fax machines, copiers, and perhaps even document-filing and transport systems over your network. One of the reasons for including this section in the same chapter as MAPI is that TAPI and MAPI (together with TSPI and MSPI, the service-provider interfaces) share a common model and perform similar functions.
The version of TAPI that was available at the time this book was written (and as supported by Visual C++ 4) is in the process of being finalized. Once TAPI is finalized, the necessary hardware is produced, and the software is written to provide access to telephony devices, you can expect PC vendors to supply computers with built-in telephone handsets or headsets. A phone built into a PC is a natural extension of the audio capabilities now being added to motherboards of PCs, eliminating the need to install an audio adapter card. Plus, a PC with a phone frees the desktop real estate you'll need in order to stack the documentation for these new APIs. The following sections provide a brief introduction to TAPI and show how TAPI fits into the Visual C++ database application picture.
NOTE
There is no MFC wrapper for the TAPI functionality with MFC 4.
NOTE
Microsoft has indicated that, unlike Windows for Workgroups 3.1x, Windows 95 won't have built-in support for ISDN. Microsoft expects others to provide this support. There have been indications that Microsoft will be working on improving Windows 95's ISDN support, probably as part of a Service Pack.
NOTE
Much of the information that follows is based on "The Windows Telephony Approach," a Microsoft white paper that provides a general description of TAPI, and the Microsoft Telephony API and Telephony SPI Specifications that were published in MSDN CD4. The 16-bit version of the TAPI SDK was available on the January 1996 MSDN Level II CDs. For Win32, TAPI support is built in and doesn't use a separate SDK. You can download the preliminary TAPI specification as AP0503.EXE (a self-extracting .ZIP file) from Library 1 of the WINEXT forum or as TAPI.EXE from Library 7 of the Windows User's Group forum (WUGNET) on CompuServe.
You also can search for information about TAPI on Microsoft's Internet site. The Microsoft World Wide Web page (www.microsoft.com) provides linkages to help you find this information. The TAPI SDK is available at ftp://ftp.microsoft.com./Softlib/MSLFILES/TAPISDK.EXE.
Additional information may be found in the WIN32SDK directory of the Windows SDK.
NOTE
To get a list of all the files available from Microsoft on their FTP site, fetch and unzip the file ls-lr.zip. This file is updated daily with the complete listing of the FTP server. Be careful: The resulting text file is more than 160,000 lines long and more than 7M in size[md]a big chunk for most text editors!
TAPI is designed to provide a computer-based connection between line devices and phone devices. TAPI defines these two device classes as follows:
NOTE
Microsoft recently released Microsoft Voice. This product, available to OEMs of voice-compatible modems, adds a complete voice mail and audio messaging system to a PC. Two modem vendors who are planning or producing products incorporating Microsoft Voice are Diamond MultiMedia (TeleCommander 2500 and TeleCommander 3500 voice modem/sound cards) and Creative (the Phone Blaster voice modem/sound card). Other voice-compatible modem producers will certainly offer either Microsoft Voice or a similar product. Microsoft Voice is fully integrated with both TAPI and MAPI.
The purpose of TAPI is to provide connection methodology between devices of the line and phone classes that is transparent to the physical implementation of the devices. Figure 21.8 represents a configuration in which a telephone connected to an adapter card in a workstation serves as a phone device. A voice server that is connected to a public telephone switch through conventional telco line pairs and to the workstation by an Ethernet LAN serves as the line device. Both the workstation and the server require adapter cards or built-in hardware interfaces to the devices, plus a TSPI-compliant driver for the hardware interface. TSPI is discussed in the following section.
Figure 21.8. Devices connected to a TAPI-compliant workstation and voice server.
Like MAPI, TAPI actually consists of two categories of interfaces. One interface is used to connect external devices to a computer or a LAN, and the other provides the services required by computer applications that use the external telephony devices. The two interfaces defined for Windows telephony are described as follows:
Both TAPI and TSPI are designed for compiling into 16-bit Windows 3.1 applications and 32-bit applications for 32-bit versions of Windows (Windows NT and Windows 95). Both interfaces use 32-bit (double word, 4-byte) unsigned integers for handles.
TAPI, again like MAPI, provides two levels of sophistication of telephony services within Windows applications. The differences between Simple TAPI and Extended TAPI, which roughly correspond to the differences between Simple MAPI and Extended MAPI, are as follows:
NOTE
Microsoft Voice is an example of an Extended TAPI application. It can be configured to work as an automated customer support system, can have multiple mailboxes, and can handle distinctive ringing and Caller ID signals.
Simple TAPI and MAPI are sufficient to handle most of the basic messaging requirements of an e-mail system. The proof of this is that, at the time this book was written, Microsoft Mail had reached version 3.5 and had obtained about 30 percent of the mail market. (Lotus's cc:Mail is estimated to have about 50 percent of the market.) Simple TAPI is quite limited in its capabilities. Therefore, you can expect that most applications will implement Extended TAPI and MAPI support.
MAPI uses flat-file databases, created when you install Microsoft Mail 3.5, Windows NT, or Windows 95, to store the data required for workgroup and enterprise-wide postoffices, as well as messages. Microsoft's forthcoming Exchange Server replaces the flat file with an RDBMS that serves the same purpose. The file MAILBOX.PST (typically) holds the messages, while the file MAILBOX.PAB (typically, although the user may select other names for these files) holds the user's address book. TAPI, on the other hand, doesn't include a database element; it stores no user information. The lack of a built-in database gives independent software vendors and Visual C++ database developers a new opportunity to expand their product lines and the scope of their consulting activities.
NOTE
.PST files aren't in Microsoft Access format. This format is proprietary and unpublished.
Microsoft and the ISVs are expected to make existing Windows applications telephony-aware in the first upgrade that follows the widespread availability of line and phone devices and the TSPI drivers to support these products. This should start happening in mid-1996, because TAPI-compatible hardware devices are now available. The initial hardware and TSPI drivers are expected to come from existing telephone switch manufacturers, such as Northern Telecom and Rolm Corp., and vendors of PC-based telephone adapter cards and call-management applications. Both Diamond MultiMedia and Creative Labs have hardware on the market, and other manufacturers are quickly adding voice-compatible products to their communications lines. There are a variety of opportunities for designing and writing large-scale telephony-enabled Visual C++ database applications, such as applications to manage telemarketing "boiler rooms," as well as for add-in products that telephony-enable existing Visual C++ database applications with Extended TAPI, rather than making applications only telephony-aware with Simple TAPI.
NOTE
The authors of this book had the pleasure of testing some of the Microsoft Voice products (including Diamond's TeleCommander). The capabilities of these products offer great potential for database developers. Adding a telephone to the test computer required no new hardware. The TeleCommander (which is also a sound card) speakers and microphone formed a working speaker phone. Replacing the speakers with a headset offered an additional degree of flexibility.
It is likely that forthcoming Visual C++ database applications will take advantage of the Caller ID services that are provided by local telco exchanges under Signaling System No. 7 (SS7). The Caller ID (Individual Calling Line Identification (ICLID)) service provides the date and time of an inbound call, the calling line number, and a message. The message can be the name of the calling party as it appears in the telephone directory, "Private" (indicating that the caller has invoked ICLID's Block feature to prevent the calling line number from being transmitted), or "Out of Area" (indicating that ICLID services aren't available at the caller's location).
NOTE
At the time this book was written, Caller ID was available in all states except California. The value of Caller ID can't be downplayed. Telephone users can screen calls, let answering machines answer incoming calls, and obtain a number to call back when they receive calls that they can't answer. Caller ID is proving to be quite useful in minimizing harassing, nuisance, and other undesirable phone calls[md]not the least of which are phone solicitors!
ICLID data is transmitted by FSK (frequency-shift keying, a method similar to that used by 1,200-bps modems) during the silent period between the first and the second rings. A related service, Automatic Number Identification (ANI), is provided by local telcos for 1-800 inbound WATS (wide-area telephone service) lines and ISDN lines. ANI data is transmitted in the form of DTMF signals before the first ring. Generally, TAPI-compatible hardware will respond to or monitor both ICLID and ANI signals.
You can use ICLID or ANI data to perform a Seek operation on a table that contains an indexed field with the telephone numbers of clients, customers, or subscribers. An application can display the inbound caller's record before the first or second ring. TV shopping channels can use reverse telephone directories stored on CD-ROMs to acquire name and address information on the calling buyer.
NOTE
Most large companies now use Centrex systems (or an equivalent) so that each employee with a telephone has a direct line for inbound and outbound calling. Thus, you can create database records for individuals within large firms. Reverse directories, however, don't include entries for individual Centrex lines.
Another application for TAPI is integrating voice-mail messages with e-mail messages in your in-box. Using MAPI, ICLID and TAPI, and a database similar to that described in the preceding section, you can create applications that make voice-mail messages appear in a format similar to that of Mail messages. Double-clicking a voice-mail message header brings up the caller's record (if one exists) or a blank record for an unidentified caller, and simultaneously plays the voice-mail message through your handset or a set of PC speakers.
Microsoft Voice can be programmed to read your e-mail to you over the phone. This feature can be very useful for people who aren't in their offices and receive important e-mail that must be responded to.
Visual C++ 4 offers a new set of functionality: the Microsoft Comm Control. This OLE control allows an application to interface with a serial port directly. Don't confuse interfacing with a serial port directly with the task of interfacing with a modem. You should interface with modems using TAPI. There are situations in which you've dedicated hardware that is connected to a serial port (perhaps a bar code scanner) that the application must interface with.
You can use the communications control to provide serial communications between your application and a selected serial port. These controls are managed with the MSComm class, which is inserted into your application's project using Insert | Component.
The application can use event-driven communications, a very powerful method of handling serial ports, or use polling to check for events and errors.
Often your application will want to be notified when an event takes place, such as when a character arrives or a change occurs in a comm port status line. The MSComm class permits this type of notification.
The application also can poll for events and errors. This is done by checking the value of an MSComm property (usually after each critical function in your application). Polling is often preferable when the application is small and self-contained. An example is a simple phone dialer.
NOTE
The Microsoft Communications control is covered more fully in Chapter 17, "Using OLE Controls and Automation with Visual C++ Applications."
This chapter covered MAPI, TAPI, and Microsoft Exchange. It discussed mail-aware applications and interfacing with Schedule+. You also saw how to add MAPI support to a Visual C++ 4 application.
Relatively few commercial Visual C++ database applications use the Messaging API. Fewer yet use the Schedule+ Libraries, and none currently use the Telephony APIs. As the use of e-mail becomes more pervasive and service providers create the hardware and drivers required to implement TAPI, the demand for applications that integrate MAPI, TAPI, and perhaps even Schedule+ will increase dramatically. This chapter demonstrated that employing MAPI MFC 4 support is currently the best approach to creating mail-aware Visual C++ database front-end applications.
This chapter completes Part V of this book. The three chapters in Part VI, "Distributing Production Database Applications," describe the process of upgrading a completed Visual C++ database application to full-fledged production status.
