Configuring the Service
Now we will incorporate our service into a VTS application and configure it. First, create a new, standard VTS application. Do not enable remote configuration yet. Set the start page title to be "Test Service" and the start page file name to be "TestServ".
We want create a VTS page that displays the innards of our service, just so we can see what is going on. Edit the "Pages\TestSrv.SRC" file to be like the following:
[
Title = "Test Service";
]
Main [
Return(Self);
{ RPC status }
\System\Edit(40, 110, 180, 70, "RPC Status:",
\SampleService\ServiceMode, 0);
{ Server name }
\System\Edit(230, 110, 370, 70, "Server:",
\SampleService\CurrentServer, 0);
{ Sequence Error Counts }
\System\Edit(40, 210, 180, 170, "Sequence Errors:",
\SampleService\SequenceErrors, 0);
{ Sequence Numbers }
\System\Edit(40, 260, 180, 220, "Sequence Act:",
\SampleService\LastHeartbeatCount, 0);
\System\Edit(230, 260, 370, 220, "Sequence Exp:",
\SampleService\HeartbeatCount, 0);
]
Note: A better way of doing this would be to interactively drop an instance of a drawing method that displays the required information on a page; however, the creation of drawing methods is outside the scope of this document, so the addition of the above code to the TestServ file is sufficient for now.
Adding a module declaration to the VTS application's APPMOD.SRC root file incorporates the service into the application. Suppose that the service code above is contained in file SAMPSERV.SRC. Then the APPMOD.SRC may appear similar to:
[
Constant POINTS = 0x0002 { Point template class };
Constant GROUPS = 0xFF00 { Collections of point types };
Constant LIBRARIES = 0xFF01 { Library class module };
Constant GRAPHICS = 0xFF02 { Shared drawing methods for points };
Constant PAGES = 0xFF03 { Graphic pages & dialogs };
Constant SERVICES = 0xFF04 { Service class };
Constant PLUGINS = 0xFF05 { Plug-in class };
Constant PRIORITYSTART = 0xFF06 { Items that are pre-started };
Constant TSERVICES = 0xFF07 { Threaded service class };
[ (POINTS) {========= Modules that are point templates ===========}
]
[ (GROUPS) {==== Modules that are collections of point types =====}
]
[ (LIBRARIES) {====== Modules that contain library objects ======}
]
[ (GRAPHICS){= Modules that are shared drawing methods for points }
]
[ (PAGES) {=== Modules that are graphic pages and dialogs ===}
TestSrv Module "Pages\TestSrv.SRC";
]
[ (SERVICES) {=== Modules that are services that are started ===}
SampleService Module "SampServ.SRC";
]
[ (PLUGINS) {=== Modules added to other base system modules ===}
]
[ (PRIORITYSTART) {= Modules/variables that are to be pre-started }
]
[ (TSERVICES) {== Modules that are threaded services to run ===}
]
]
Note that VTS has already added a line similar to:
[ (PAGES) {===== Modules that are graphic pages and dialogs =====}
TestSrv Module "Pages\TestSrv.SRC";
for the initial TestServ page file that we added.
Before we can use the service, it is necessary to inform VTS which workstation, or workstations are potential servers for the service. This is normally done in the application's Config.ini file. The variables in our Config.ini file for our simple application might look like this:
[System]
Page = TestSrv
SimulateIO = 0
RPCExternalConfig = 0
DispMgrHeight = 300
DispMgrFullScreen = 0
DispMgrWidth = 400
[RPCManager-Servers]
Name = FREDSPC
The [RPCManager-Servers] section of Config.ini specifies the list of potential servers, in order of descending priority. Each "Name=" line in the section carries the workstation name of the potential server. In our simple example, we have only one potential server, "FREDSPC". All other workstations that run this service will be clients to FREDSPC. (As you follow through this example, you should use the workstation name of the PC that you wish to be the server, rather than FREDSPC.)
Now compile the application and run it. If all has gone well, you should see a display similar to the following:
Next, we will enable remote configuration. That way, when you bring on one or more clients, the remote configuration service (EditLockoutManager) will ensure that subsequent code changes you make on the server will be correctly propagated to the clients. Ensure the application is running on your server. On another PC (which will become a client), acquire and run the application (i.e. perform a Get From Server operation from the VAM on the client). You should now have a server and a client that will maintain the simple numeric synchronizable state accurately, no matter how you disrupt communication between them or stop and start the application.
You can repeat the last step to add more clients, if you wish.
The section that follows outlines the process of adding backup servers for our simple service.