Home > System Administration > Services > Configuring Services

Configuring Services

Introduction

Computer Name Check

Using Queues to Allow Multiple Access To Same Database

Running Multiple Instances On The Same Computer

Special Considerations For Directories

Introduction

In basic configurations of Merchant Central you would have one instance of each of the services - Merchant Central Server, Alerts Service, B2B Service, Incoming Transactions Service and Statistics Updater Service. All of these services will talk to the same database.

There are several ways to configure these services so that you can have multiple services running on the one computer talking to the same database, multiple services running over multiple computers talking to the same database, multiple instances talking to different databases, using multiple threads to improve performance, and so on. The table below shows the configuration options available. The actual configurations are described below.

Service

One instance on one database to same database

One instance on multiple computers to same database

Multiple instances on one computer to same database

Multiple instances on one computer to different databases

Multithreaded (for performance)

Merchant Central Service

Yes

Yes. No config required.

Yes. Config required. (1 below)

Yes. Config required. (2 below)

Yes

Incoming Transactions Handler Service

Yes

Yes. Config required. (1 below)

Yes. Config required.  (1 and 2 below)

Yes. Config required. (2 below)

Yes. Config required.  (1 below)

Statistics Service

Yes

Yes. Config required. (1 below)

Yes. Config required. (1 and 2 below)

Yes. Config required. (2 below)

Yes. Config required. (1 below)

Alert Service

Yes

No

No

Yes. Config required. (2 below)

No

B2B Service

Yes

No

No

Yes. Config required. (2 below)

No

1. See Using Queues to Allow Multiple Access To Same Database

2. See Running Multiple Instances On The Same Computer

Computer Name Check

By default the system only allows one instance of a service to run on a database. When a service first starts up it will check the DRSSERVICES table to see if a record exists for that service. If it doesn't, a new record will be written and the service will start up. If a record does exist, it will check the computer name. If the computer name in the record matches the computer name on which the service is starting, the service will be allowed to start. If the computer name is different, the service will not be allowed to start because it most likely indicates that a second service is accidentally being started on the same database. If you change the computer on which the service runs, you will need to manually remove the record from DRSSERVICES table so that the service will be allowed to start.

If you must have multiple services running on different computers to the one database, there are two approaches you can take:

1. Use the instructions for Multiple Instances On A Single Computer below to create instances of the service on each computer. Because the service names are different, they will be allowed to run. This is the preferred approach because it means you took very specific action to identify the services you really want to run.

2. Add the following setting to DYNAMIC.INI:

[Miscellaneous]

MultipleServices=T

This is not as good an approach because it overrides the computer name check which could allow another service to accidentally connect to the database.

Using Queues to Allow Multiple Access To Same Database

You need to use queues if you want more than one instance of Incoming Transactions Service and Statistics Updater Service per database (regardless of whether the services will be running on one or more computers). This is because by default both of these services have a single thread which will process all available data in the database. Queues allow you to separate data so that multiple instances don't try to process the same data. You can also use the same technique to create multiple threads in one instance.

We will firstly examine how to set up a single instance of the service to use multiple queues.

The first step will be to set up the queues. A queue is simply a number. Each location is assigned to a queue number. By default all locations are in Queue 0 (hence the single thread currently used by these services). You might decide to have three queues. You would assign some locations to Queue 0, some to Queue 1 and the remaining locations to Queue 2. It doesn't matter how you assign a location to a queue, the queue number is simply a way to group a number of locations together for processing.

The location's queue number is assigned using the Queue# field in the Advanced tab of the Locations function. As data is received for a location, the system will record the location's queue number.

Next, you have to tell the service which queues it should process. This is done by adding the following sections to the DYNAMIC.INI. The Count is the number of queues to be processed. You have a Queuex entry for each queue, where x is a number starting from one.

[TillIncoming]

Count=3

Queue1=0

Queue2=1

Queue3=2

[StatisticsService]

Count=3

Queue1=0

Queue2=1

Queue3=2

A thread is created for each queue number and the thread will only check for data with that queue number. So in this case, the first thread will only look at data in Queue 0, the second thread will look at Queue 1 and the third thread will look at Queue 2.

This approach will allow a single instance of these services to have multiple threads and improve performance considerably. However, you may want to run multiple instances of the services talking to the same database, either on the same computer or on different computers. For each service you simply tell it what queues it should process. Lets take the queues from above and set the up for two separate instances of the services:

DYNAMIC.INI for the first instance (these services will process two queues):

[TillIncoming]

Count=2

Queue1=0

Queue2=1

[StatisticsService]

Count=2

Queue1=0

Queue2=1

DYNAMIC.INI for the second instance (these services will process one queue):

[TillIncoming]

Count=1

Queue1=2

[StatisticsService]

Count=1

Queue1=2

Running Multiple Instances On The Same Computer

Configuring multiple instances is the same for all types of services. The following steps show how to configure multiple instances of Merchant Central Server but you can use the same approach to configure any of the other services.

1. Create a directory for each instance you require. Lets say you have a standard directory called \drsapps which contains your executables and you want to have two instances of Merchant Central Server running - Main and Backup. Create two new directories \drsapps\main and \drsapps\backup.

2. Copy the service program, for example MerchantCentralServer.exe, and the associated .bpls into each directory.

3. Copy the DYNAMIC.INI you are currently using into each directory. Services will *always* use the DYNAMIC.INI in the same directory as the executable, if one exists.

4. Edit each DYNAMIC.INI to add a new Name setting to the [DRSServers] section. This must be a unique code for each instance you want to run. It should not contain spaces or punctuation. Just keep it to alphanumeric characters.

Example:

[DRSServers]

Name=Main

5. If you are setting up Merchant Central Server, edit the DYNAMIC.INI [DRSServer] section so that the port settings are unique. If they are not unique and you try to run multiple instances on the same ports, you will get network errors about not being able to bind the socket. For all services, you need to change the [DRS] section so that the addresses and ports point to the required Merchant Central Server. (If you are configuring multiple instances of Merchant Central Server you still need to edit this section to ensure Merchant Central Server can point back to itself.)

If you are setting up Incoming Transactions Handler Service or Statistics Service Updater, you may want to set up the queues as discussed in Using Queues to Allow Multiple Access To Same Database above.

6. Install the service by running each specific executable.

Example:

\drsapps\main\merchantcentralserver.exe /install

\drsapps\backup\merchantcentralserver.exe /install

If you check the Windows Services panel you will see two new entries:

Merchant Central Server - Main

Merchant Central Server - Backup

You can use these to stop and start each instance of the service.

That is all that is required to run multiple services.

If you are setting up multiple instances to support different databases you might set up your directory structure based on the name of the client.

Example

/drsapps/client1/MerchantCentralServer.exe

                ...../TillIncomingService.exe

                ...../ StatisticsUpdaterService.exe

                ...../ AlertsService.exe

                ...../B2BService.exe

/drsapps/client2/MerchantCentralServer.exe

                ...../TillIncomingService.exe

                ...../ StatisticsUpdaterService.exe

                ...../ AlertsService.exe

                ...../B2BService.exe

Special Considerations For Directories

If you are using multiple Merchant Central Servers across multiple computers to share the workload, you have to be careful with how you set up your directories. For example, if you set up your report directory as \ drsapps\reports, each MCS is going to assume this is relative to the computer they are running on. It won't allow a central repository for the reports, as is required. In this case you need to set up the directory to include a computer name, for example \\ MAIN\drsapps\reports. Now all MCSs will attempt to share the same directory. There is one further consideration though. MCS is a Windows service and by default, the service user has limited permissions. This generally does not include the permission to access a networked directory. In this case, you need to define a special Windows user who does have this permission and run the MCS service under this user (see your Windows documentation as this will vary from version to version). The MCS will now have permission to access the report directory.

Converted from CHM to HTML with chm2web Pro 2.85 (unicode)