Web Service 

A web service is not the same as a Web Browser version.  Our web service layer is a server program that sits between the database and the client machines.  This diagram explains the 3-tier architecture used in enterprise settings.

The business layer can be on the same physical computer as the database, or it can be on a dedicated server.  The large arrows represent chatty connections, while the thin arrow represents the slow connection for which the program has been optimized. Fewer calls are made across this connection. The goal is to have only one call to the server for each 'page' of display on the screen. This single call will return a single dataset (group of tables) which is as small as possible. Eliminating multiple calls reduces latency (roundtrip time) issues, such as when connecting across a satellite connection. And keeping the result set small helps the program remain responsive even when the connection is slow, such as a dial-up connection.

This is not the only solution for multiple locations.  See the Multiple Locations page for other useful alternatives.

Another advantage of using a web service is increased security.  In a direct connection, the MySQL username and password must be stored on the client computer. But in a web service, the client need not have access to the MySQL username and password.  There is still not any security for the AtoZ folder which stores the images.  Each client must still have access to a shared folder in order to view images.  This folder can be local for speed and optionally replicated if there are multiple offices using it. Images may be stored in the database for new users who can get by with less features.

Although it is not shown above, multiple clients can connect through either of the two methods.  And both connection methods can be used simultaneously. In fact, a direct connection is required when updating versions, and this requirement is satisfied by running the OpenDental.exe directly on the server for updates. 

Installation Preparation
Since you will need to perform updates directly from the web server, this would be a good time to set up remote desktop access for the web server and add a remote desktop user who is also an administrator on the server. After setting up remote desktop, you may want to connect from a client machine to ensure that it is functioning properly. It may be best to perform the installation step through remote desktop on a client machine, that way you can perform steps 2 and 3 from the same location. Be sure that you login to remote desktop as an administrative user.

Installation
Performed directly on the web server, possibly through remote desktop. Be sure you are logged in as an administrative user.

1. Make sure dotNet 3.5 is installed on the web server.

2. Install the same version of Open Dental as in the rest of the office. Do this by running the Setup.exe from the shared AtoZ images folder. From now on, when running the Open Dental client on the web server machine, you will always connect directly to the database rather than through the web service.

3. Look in your Open Dental application folder for a bin folder.  A bin folder must be there to use the web service. The only way to get the bin folder there is to run the Setup.exe.  Updating your version of Open Dental on the web server by using the file copy method will not work.  So if you have not updated to a new version, then this would be a good time to update.  If you accidentally updated using the file copy method, then you might need to uninstall and reinstall Open Dental on the web server.

4. If you must have tight security immediately, then set up your MySQL users as described in the MySQL Users section at the bottom of this page.  Alternatively, if you do not require tight security immediately, you could use root with no password for initial testing. 

5. Download this file (right click, Save As): OpenDentalServerConfig.xml, and place it in the application directory of Open Dental on the web server.  Edit the file (right click, "Open with..." Notepad) to set the usernames and passwords.

if you do not require tight security immediately, then you may use root with no password for both of the users in the text file above.

6. (If your server has Windows Server Web as an operating system, then skip this step.)  Turn on more of your IIS features in Windows.  In the Control Panel, select Programs and Features (aka Add/Remove Programs).  At the upper left, select Turn Windows Features on or off.

Turn on all the IIS features.  In the screenshot above, the IIS folder has been expanded to show those features.  If you are a power user, you can selectively only turn on the IIS features that you think will be needed.

7. Open your IIS Management Console as follows.  Right click on My Computer, Manage.  At the left, select IIS. (On Windows Server Web, expand the Roles->Web Service Name->Internet Information services).   You can see that there is a second IIS option further down for the older IIS 6.0.  Do not use that one.  To the right of that, Expand your connections.

Right click on Default Web Site, and Add Application.  If the Default Web Site does not yet exist, you must create it first and point it to c:\inetpub\wwwroot.

Fill out the information as above, and click OK.

9. Edit the DefaultAppPool and make sure it is set to use .NET Framework v4.0 rather than 2.0.

10. Launch the Open Dental program.  In Misc Setup, enter the name of the computer in your network that will be hosting the web service.  This is the only computer you will be allowed to perform updates on.  Any attempt to perform an update from another computer will give the user an error message.  If you are also using the HL7 Service, be sure to look at the specific update sequence listed on that page.

11. You should now be able to connect to your web service from any computer on your local network.  When connecting from a client workstation, the Choose Database window will look similar to this.  Test this first on the server, and then on the workstations.

12. The above connections settings will be used from other workstations, but not from the server.  After the initial testing, the upper direct connection settings will be used anytime you are on the server.  This is required in order to perform version Updates.

64 bit Server
When using Windows Server 2008 64 bit and IIS7, IIS will need to be set to allow 32 bit applications.  If it is not, there will be an error that might include one of the following:
* System.BadImageFormatException
* Could not load file
* Could not create type

In the Management Console:
1. Right click over the AppPool name
2. Select "Set Application Pool Defaults..." or "Advanced Settings..."
3. In the General Section, set Enable 32-Bits Application to True
4. Click OK, you may want to refresh the application pool just to be sure.

MySQL Users
In step 4 and 5 of the installation, the MySQL Users are set up.  You will use a separate management tool for this. We recommend SQLyog or one of the free GUI's available from the MySQL web site. phpMyAdmin is also popular, but may be hard to install. Setting up the MySQL users has turned out to be the most complex and time consuming part of this whole process. We are working on a better management tool for setting up the users.

Notice that there are two MySQL users that may be specified. There is a regular user, and a user with lower privileges. The regular user must have all permissions for all tables starting with "opendental" (if that is the name of your database). The regular user must be able to do everything from adding tables to making a backup of the database. It is during the backup process that the user must also have access to a database that might be called "opendentalbackup_07_14_2006", and the user must also have permission to create tables, etc in this other database. So make sure to either give this user privileges for all databases, or use a wildcard character to give privileges for similar databases.

The other user, UserLow, is a user with much lower privileges. No SQL statements are allowed to be passed to the web service except report queries.  And UserLow is always used for these report queries.  This allows prevention of injection attacks at the database level.  UserLow should have very limited privileges, just SELECT and CREATE TEMPORARY TABLES, and only for the current database.  They will still be able to use queries to select any data, but not to alter it.

Remember that when users connect from the client computers, that they will never see or have access to the users that you setup in this file. They will be connecting using an Open Dental username and password. See the Choose Database window for an example.

Internet Access
Opening up your web service to be accessible from outside your office is beyond the scope of this page and is not advised.  You would need to turn on SSL using a certificate purchased for this purpose.  You would need to forward port 443 on your router to your web server.  You would need to be very careful about security.  All Open Dental passwords would need to be reviewed to make sure they were strong enough.  Your AtoZ folder would not be accessible outside your local network, and this could cause problems if you don't have a carefully thought out solution.  For these reasons and many more, your web service should probably be restricted to use within your office or within your VPN for multiple offices.  But secure access across the internet is now theoretically possible.