Configuration of the Replica Server component

The “replicator.ini” file has all the necessary options for the replica server to work. Here, we put the explanation of the keys and a practical example about a configured replicator.ini.

In this section will be stored the configuration features that are globals for the full server. These conditions will be evaluated when the service starts, so if they are changed with the server in motion, it is necessary to restart the replica service in order the changes take effect.

Besides, it can be done in a way that are reevaluated every so often to be able to change them with no need to get down the replica service. The fact is that in order the things here configured take effect, it is necessary to change some things that is a little complicated to modify on the go, we will see as we go looking it.

This key, which its name implies, defines the port number in which the replica server waits for the commands.
The server does not support any protocol other than the owner of CGSoft, so it will only listen on this port.

Versions not having its own HTTP mini-server may come later.

The server maintains a listen on this port with a depth of configurable connections. Every request that comes will be answered in an independent sub process until the amount of simultaneous connection are reached for which the server has been configured and the maximum amount of simultaneous licenses that the service supports, whichever is less.

The command that is requested is placed in a FIFO queue from which it will be extracted by one of the command processing subprocesses that are waiting to process these commands precisely.

So, may be the case there are commands waiting in the queue, as long as its client do not receive any answer. The fact that the server accepts a connection does not mean that it proceed immediately to process the command. This one will be processed when there is any sub-process available to answer it. This key has no value by default. If it is missing, the service will not start and will report as error that the listen port was not defined.

If the server is going to be on Internet (most of the cases in which is use as replica server will be like that), it is necessary to open this port in the router in order to be accesible from outside.

The value this key brings at the INI that is installed with the server is 7757 and we, particularly recommend not to be changed.

This key has TRUE value by default, to indicate that the service must listen the replica clients requestments by the port configured at ListenPort (7757 by default)

In environments in which several machines are configured as servers to answer the works by separate (selectivity in a database machine, entry queue in another one and listener into another one) this key must be unabled in those machines that are not going to support replica clients and that are going to be used for processing databases only.

It is important to bear in mind that for using this kind of configurations, the databases and the applications must be properly designed to allow the data processing in a proper manner, keeping in mind that the data interdependency is not guaranteed if the processing are done in separated machines.

Integer that indicates how many simultaneous sub-processes of commands processing will be supporting the queue of the waiting commands.

This term should not be confused with that of the maximum amount of connections, as it was discussed before.

The proper value for this field will depend on the load we want the server supports, the amount of processors and available memory… etc.

By default, the amount of subprocesses will be 3 times the amount of processors the server has. It is not efficient to open-ended grow the amount of subprocesses to enlarge the capacity of processing of the server, since they may be more sleeping subprocesses simultaneously executing(maximum one by processor) and the minimum possible amount stopped doing nothing, while it remains waiting for commands the exact amount to hold a medium peak without overwhelming the capacity of processing of the server.

If this key is not declared, the service will calculate the amount it considers the most efficient, so, if you have no idea about what are you doing, we very strongly recommend you not declare this key.

It limits the maximum number of connections this server supports.

You can never grow the amount of connections above the maximum amount of licenses the server supports, but it may be the case of a server supporting little load and it is efficient to lower the amount of connections and the listening depth, so that it does not consume resources unnecessarily waiting for commands that are not going to arrive. In these cases also is a good idea to change the key value.

WorkerThreads.

It enables the Replica Server Log for the server part.

The replica may be working for several databases, and here are monitored each and every connection of the clients connected, no matter which database the call points to.

Its values are from 0(disabled) until 6(maximum log which will tell us each and every one of the operations made).

The log is saved in the Log folder of the operative system itself, that is %SYSTEM32%\LogFiles\CgsoftRpl

In this section the licenses or database this server is going to meet are defined.

The name of each one of the keys inserted in this section represents the number of database license (8 alphanumeric characters) and its value is the former DBID that would be placed at the get_status. The number assigned to each license will be the one used to refer to that database for reading its configuration.

12345678=X; Management Database.

The data base with the license number 12345678 and to which the DBID X was been assigned (the DBID number may be anyone whenever the same server is not repeated.)

In this case, in Windows, a file called 12345678.000 must go.

If you just have installed a server and do not which licenses come with it, the best idea is searching at the Windows folder the files with .000 extension and get its names (8 characters strings) which will represent the license numbers.

Each one of the database defined at the [licenses] section must have a section with own configuration parameters, since a same server may deal with several databases that do not have to have the same parameters (DBMS, location, etc).

The name of the section will have a [dbid-xx] way, where xx will be the number assigned tothe database license at the license definition.

If any of the database defined at the [licenses] has no its respective [dbid-x] section, the server will not be able to start properly the database, so it will not be able to be linked to any service (customer service, selective replica… etc.).

The lifelong old connection string.

It can be ODBC, OLEDB etc…

This string will be used directly to open the database when is necessary to be used. The server never open a connection nor will create the structures in memory until not receive a request or needed internally, (e.g. when processing selective clients or booting up the monitor for the entry queues.)

This key is mandatory and if is missing, the database cannot be used. The ODBC connection string has to be complete, that is, something like ConnString=mi_dsn is not valid, since the server does not know if it is an ODBC string or OLEDB.

In this case, if it is about an ODBC data source, it should be ConnString=DSN=mi_dsn.

It indicates the server in which format the DBMS expects the dates must be formatted in the sentences that are going to be executed at the server.

The format may be:

• dmy
• mdy
• ymd

The dates of the operations that are in the master_replica_queue table MUST be in this format, EXCEPT FOR those ones that have been directly inserted by the clients that inject operations directly (interfaces and terminals that work directly with the server database).

To indicate the server in which format are the clients dates that write directly in the queue (in case they do in a different format) the ULDATE field is used for each one of them. We explain how to do this in the respective section.

The need for different keys for each one of the clients is becayse the date format is not necessarily linked to the DBMS, as happens, for instance, with MySQL, but it can be a parameter of the USER used to create the connection, as happens, for instance, with SQL Server. In this last one, we can have a database which date format is in English by default, and the users used to create the connections use a different format. In this case, the value the DateMask must have has to be the used one by the service to access the database, that is, the one that uses the user that is at the connection string configured in the database.

Example:

We have a SQL Server database in English and a “replica” user has been set which date format is also in English. So, we set the server:

ConnString=xxxxxx;user=replica;xxxxxx
DateMask=mdy

Now, let´s suppose that we create an interface user who needs working with the dates in Spanish because the external database uses this format and we do not want to make a mistake by working with two different date formats. We set the interface MID like that:

MID=9999 (example)
ULDATE=dmy
DLDATE It doesn´t matter
RPDATE It doesn´t matter

With this we are telling the service that those operations there are in the queue which MID is any of the defined ones as replica clients will have its dates in “mdy” format (DateMask). The server is in charge of fixing the dates that come in another different format. Those operations that have its MID with 9999 value will have the date in “dmy” format and therefore, they should be properly fixed at the time to work with them.

By default, the databases of the configurable type are taken, the DBMS used, to tell the type of the replica database.

DbmsName=dbms.oracle.xml
DbmsName=dbms.oracle8.xml
DbmsName=dbms.sqlserver.2005.xml
DbmsName= dbms.sqlserver.7.2000.xml
DbmsName= dbms.mysql.50.xml
DbmsName= dbms.mysql.41.xml
DbmsName= dbms.mysql.40.xml

The XML configuration files have values for the names of certain fields, the date formats by default, the initialization strings, etc. Optionally, it may have insertion queue templates and else, so a developer may create its own DBMS configurarion files if he needs to.

In order the server recognaises a configuration file as valid, this one must be at the same folder which the service is installed in.

This key by defautl is 0, indicating that the operations for this database won´t be taken into a log file.

When this key has a value between 1 to 7, the server is indicated that the operations made in database must be logged.

Usually, these operations are logged in the %SYSTEM32%\LogFiles\CgsoftRpl folder in files. The operations log generates enough information, so the best thing is using this mechanism only when something is wrong and stopped as soon as the issue is fixed.

A server logs with a few clients may grow a lot in a matter of minutes.

This key allows to change the path in which the server stores the logs for this database.

The use of this variable allows that if logs from more than one database at the time are be generated, they may be seperated into different folders, so that the logs of different database operations are not mixed up.

This key allows you to change the size of the work unit for the selectivity analysis and for the attention of the input queue in the database.

At the respective section the selective replica logs analysis is explained that each work unit has a initial log and a number of logs.

The maximum number of records that can have a unit of analysis can be changed here to make the units larger and therefore the analysis threads are more time working with the same MID.

The value given to this key will depend on the selectivity strategy that the database needs to:

• Little concurrency with a lot of load.
• A lot of concurrency with little load.

If a database suffers a lot with operations that handle many data but answers very fast with little data and can handle a lot of simultaneous processes, the most efficient is putting low the value of SelUnitLen and not limit the concurrency.

If on the contrary, the database suffers witn many concurrent operations, but the operations with a high load are well-tolerated, the most efficient is limit the amount of concurrent processes and put this key with a higher value.

When we have database servers that work well with high concurrency and with a lot of load, it is good to leave this key with a value between 500 and 1000 and not limit the concurrency of processes, with what is achieved that the selectivity advances from more evenly.

By default, the amount of logs by analysis unit is 100.

This key by default has a true value to indicate that the operations of the secondary queue must be deleted as they are processed.

If the administrator desires that the secondary queue maintains the operations as it processes them, this key must take a false value.

In case the secondary queue has SENT field, the field will be marked each time an operation is sent to the client to make it easier to analyze the records in the secondary queue.

It is important that this function is used only for errors debugging functions, since it makes no sense leaving data at the secondary queue.

This key allows that the selectivity analysis be more efficient once the database main sub-process falls asleep.

To wake up the sub-process, it is necessary to receive at least a minimum amount of logs, since in case the database has many clients and a lot of simultaneous operations arrive, it is not efficient to prepare little units of selectivity of fewer logs than the SelUnitLen.

This would happen if the analysis sub-process awakes with the first operation that comes in. In this case, as for each client will have only one or two logs, little units of one or two logs will be created, which will make that each analysis sub-processes operates for a short time with each client, causing many access to the database for processing very few operations.

If instead this, the analysis sub-process wait for a bigger amount of logs (15 or 20) the units that would be formed would be at least of this amount of logs, by achieving greater latency of analysis sub-processes, and therefore a better use of the processor resources.

In servers with few clients there is no a big issue about it, in the end, there are more analysis sub-processes than clients, so all the sub-processes will be executed in a concurrent way as long as there are available sub-processes.

Here, the problem begins when there are many clients at stake. In servers that have many clients but few operations arrival frequency, it is efficient leaving the value by default (1).

In servers with many clients and a lot of operations simultaneously arriving, the best is that this number becomes bigger (approximately half of the SelUnitLen).

Anyways, if you don´t know what are you doing, just not declaring this key and let the server calculates the most appropriated number to it.

One of the jobs that a replicated database has to do is accepting and creating new clients.

These clients usually have different features regarding DBMS, since in a distributed system it is usually composed of several components of different databases.

Therefore, it is important that by using the own client log commands, the data format fields can be initializated at the moment of creating the client or while its license is revalidated.

The values by default that the fields have are decided at the moment when the database is created, and they will be generally the values that fewer changes require.

This key defines the date format that the clients will have when write directely in the database (see ULDATE field from the master_replica_slave table), when creating a client by default.
By receiving a command to create a new client, this value will be the one that is returned as parameter “uld”.

Usually, the client will decide if he want to respect this value or change it for another different one. The special value “none” means to leave empty this field when the client in the database will be written. If a replica server that is going to work only as agent is being configured, this value is not necessary to configure it.

This value is similar than the Key DefaultULD with the difference that it operates on the DLDATE field of the master_replica_slave table when creating the new client.

Once more the user is the one who decides the final value.

The “none” key means that this value will be left null.

Similarly, if the server is only a replica agent, it is not necessary to worry about this key.

This value is similar than the Key DefaultULD with the difference that it operates on the RPDATE field of the master_replica_slave table when creating the new client.

Once more the user is the one who decides the final value.

The “none” key means that this value will be left nuell. The same remark regarding the server as agent.

When a database is started, the server tests that the fields and tables which the relations table refers to (RL) have correct combinations, as well as that there is no logs with empty key fields.

In some servers with a lot of work load, this process may fail although the RL table be correct, since the queries launched for this purpose may be complicated.

If the administrator is sure that the RL table is correct (it has been tested by using the XnetSetup2 tool from CGSoft) it may assign a false value for this key to avoid the server checks the RL table from the database whenever it starts it. \
This also may considerably accelerate the start of the service when it is about databases with selective replica and/or entry queue.

Although this key is false, the server will keep checking the presence of empty fields in the logs of the RL table, since for this, queries operations there are no need, and they can cause that fail the translating operations of logs with relations.

This behaviour cannot be unabled.

This key by default has a false value, to indicate that the selective replica process that is made with the logs from the queue is normal.

Such process considers that the insertion and updating operations have to pass by the selection filter, but the deleting operations always are replicated.

This is because a database in which a s selectivity rule is no longer fulfilled, it cannot know once the operation is in queue, since in fact, the log doesn´t exist and there is no way of checking if the operation has to be replicated or it does not.

So, all the deleting operations are replicated. By assigning true value, it is been said the selection process to use the selectivity filter more aggressively, that is, if a table does not appear in the filter, its deleting operations will not be replicated.

If it appears with the ALWAYS=1 mark at least once, the operations will be replicated. If it appears with deleting conditions, a “virtual” log should be set with the operations there are in the queue from the INSERT up until now.

If this cannot be done, the operation will be replicated, if the values there are at the end of the log creation don´t meet the selectivity criteria, the operation will be not replicated either.

This means risks on the databases in which the selectivity rules vary, since deleting operations could stop replicating if the selection rules have changed.

If the rules for the selectivity are not going to vary, this option can do that the traffic between the server and the mobile devices with selective replica be considerably brought down.

This field is used when the database has the batch replication mechanism enabled.

For this, it is required to define the necessary tables and fields for this to be possible, and the client has to accepts operations in batches. The number by default for the records batches in case the clients table is not defined (master_replica_slave) for each one of them, it can be placed here in a global way for the whole database.

If a client the amount of records by batch is not defined and this key is not defined either, such client will never replicate by batches, even if the replica client service accepts it.

This key allows to change the name of the ROWID field in the server database.

The operations traffic between the server and the clients always will be standardized done, that is, the ROWID field name always will be ROWID.

However, once the record comes to the server, it will be modified to use the name of the field indicated in this key. This is used for those cases in which the DBMS considers that the ROWID word is reserved and database fields cannot be created with this name.

For these cases, just rename all the ROWID fields of the database in a way you deem convenient (e.g. MYROWID) and place the new name in this key.

Form this moment, all the operations stored at the server will use the new name and they will be stored in the queue with the changed name.

For sending the operations to the clients, the server will change again the field name and it will put ROWID again, so the client may keep its ROWID field name unchanged. If the client´s database also had the name changed, it is necessary to set the replica client and the machinery of the application in order to use the alternative name.

The ROWID field name, also can be changed through the DBMS file configured in DbmsName. The priority is the following one:

1. If this key is defined, this is the value used.
2. If this key is not defined and a DbmsName is indicated which file defines the name of the ROWID field, this is the one it uses.
3. If the key is not defined, or the Dbms neither (or this one does not redefines the ROWID field) it is considered that the field is called ROWID.

This key operates in the same way as RowIDFieldName but for redefining the name of the “SQL” field in the replica tables.

In some DBMS the word “SQL” is reserved and cannot be used as field name, so it is necessary to redefine it. The difference is that this field is only used in the replica tables and it is not necessary in those of data.

How this key operates, and the priorities for its definition are equals than in RowIDFieldName.

Usually, the server locks the record unique keys (ROWID) when an operation with some of them is going to be made.

This allows that in a system with many clients working with the same tables, the operations that may cause conflicts not to enter at the queues, and excluding them from the analysis processes by being them in process already.

The idea is that when a conflict analysis process starts, its ROWID will be blocked, so that at least with respect to this one, the server status will be maintained until the analysis is finished.

Once the process is finished, the ROWID will be released and the process waiting will be able to continue. If the simultaneous process work with another logs, locking the ROWID will not affect them.

This key may be put to false for accelerating the server work, and its use is ONLY safe when it is about systems in which the data location is perfectly defined(systems with few conflicts) since there are no operations over the same log in different clients, or in those systems in which each client replicates at times in which the other ones are not doing it.

Use this key if the server is going to work as operations receiver of an interface linking to another systems.

Usually, the interfaces are configured through an intermediate database that after replicates with the server by using a replica client.

A way to optimize this mechanism is by doing that the interface writes directly in the server database, but for this, it is necessary that the operations coming from the clients mark the modification fields in the data tables.

Spcially delicated is the deletion of records, that instead deleting physically it must mark the modification field with a value indicating that the record must be deleted.

The interface will be in charge of making the physical deletion when it sends the data toward the other system.

The name of the mark field is also configurable.

This field value only makes sense if the interface mode has been enabled, on the contrary it is ignored.

By default, its value is “UPDATED” and it has to exist in all the database tables, since the server will mark it with each operation that it carries out.

This key usually has a “false” value by default, which it means that those clients using the selective replica will use the secondary queue for selecting the records that are replicated.

When the database is put in the monitoring queue and this key has a “true” value, the server will not process the records of the queue for fulfilling the secondary queue, but it will check the selectivity conditions when the clients make the records requests or batches.

This is a very interesting option for the systems with a big deal of clients, since this way the server will be released from the analysis procesess and modification of the secondary queue.

If also, it is about a simple replica, the clients operating in environments of high concurrency will not be very affected by the use of this facility and at the same time, it will be achieved that the server works easily.

When the clients operate by batches in the downloading and this key is used, it is necessary to use smaller sizes of blocks for the selective clients, since the answers to the blocks request must check the selectivity of each one of the records included in the batch.

This key is used for not stopping the replica if an UPDATE is coming to a record that doesn´t exist at the Server.

Usually, the server doesn´t allow to execute updates over records that it doesn´t have, since this would imply that there is a consistency error in some of the backups. So, this key value by default is TRUE, and in general it should not be touched.
Nevertheless, there are cases in which cleaning processes are made in certain database tables of the server (e.g. the integration processes or by scheduled maintenances) by design of the application itself. In these cases is normal to miss records in the server, since once they are integrated in the main system or backend they are not longer needed in the replica.
If a client sends subsequent modifications to this integration, such modifications in fact are not important or necessary, so they can be ignored without causing problems. In these cases in order the replica do not stop by missing the records, this key can be put to FALSE to indicate the server that just skip these operations which are affecting records that do not exist. The server will let a trace in the master_replica_errorlog table by indicating the table and the ROWID that have failed and will keep executing the operations that follow.
The server administrator work is to verify that in fact the records that have been failing corresponds to tables that have been emptied by maintenance and not because of consistency issues.

Key that indicates if the replicator has to go checking the queue to see if the TBL field is filled or it is not.

It only has to be used when the replicator lives together with another XOne components, dlls or old frameworks that do not fill the TBL field, so if it is about a new system we must put to false to gain in performance.

If the replica has to look for a history, and this is to true, it only searchs it in the table. If it is to false, then it is necessary to search the history at the queue also.

This key value is 0 by default. In case a superior level is specified, the server will let in a file called IQUEUE.LOG.TXT all the operations that come before inserting them at the entry queue. This can be useful during the implementation of a system to verify that the operations coming from each client are being properly received, since in the server once they are processed are deleted from the iqueue. When by any development error or by configuration of the application during the implementation some operations are missing, this mechanism may help to determine if it is about operations that never have come to the server or if they are being losing by some reason (e.g. any error at the database)

Once implemented the system, this key must be unabled, since it penalizes the reception of operations. Just remove it from the configuration file, since by default it is unabled.

Possible levels:
1: It registers entries in the iqueue and errors.
2: It reports duplicated (operations sent more than once, as if we are in the iqueue or in main queue) also it leaves records that the insertion in the iqueue was correct.

By default this key has TRUE value to indicate if the database is being monitored, it is considered to analyze the selectivity of the conditional clients. If a project do not has selectivity, or this one is going to be analyzed by another process (e.g. a procedure stored at the server of the database, another replica server that only is dedicated to selectivity, etc.) then, this key must have a FALSE value for indicating the service to NOT analyzes this database selectivity.

The servier will keep monitoring the entry queue, updating the TBL field and waiting for connections from the replica clients, but it wil not start the selectivity processes.

This key has FALSE value by default (regular behaviour).

The replica clients send as a part of its connection process the IMEI number or the serial number of the terminal. If the server detects that the database has the administration tables plica envían como parte de su proceso de conexión el número de serie o IMEI del terminal. Si el servidor detecta que la base de datos tiene las tablas de administración ( adm_* tables) it will be searched on such tables if the terminal exists and is linked to this database. In case the terminal is not in the adm tables, or is not linked to the database, the logon will be rejected. If the database has not the adm_tables the server will ignore the IMEI of the terminal.

If the key is set with TRUE value, it is mandatory that the database has the adm_ tables and is mandatory ALSO that the terminals send the IMEI. Therefore, in order a client may connect to the replica must meet that:

• The database of the server must have the adm_ tables.
• The terminal must be registered in the adm_ tables.
• The terminal must be linked to the replica client in the adm_ tables.
• The terminal must sent its IMEI.
• The IMEI must coincide with the one that is in the adm_ tables.

If any of these conditions will fail, the server will answer a 201 code (non valid license) telling that this client cannot replicate with this database. This system is usefull in development environments in which we have the same terminal registered in different databases to avoid accidental crossover replicas and in production environments to make more difficult the connection of terminals not controlled by the administration.

By default, this key is not defined, to indicate that the maximum amount of selectivity units processed concurrently has no limit. At the practice, nevertheless, there are many cases in which this configuration causes an excess of concurrency in the database server, specially having in mind that the selectivity operations are very difficult.

In certain servers such as MySql using MyISAM tables, the selectivity insertion operations block the full tables, so the concurrency implies that the most of the selectivity processes are waiting for the selectivity operations to be finished, causing bottlenecks, since they cannot be used for replicating or meeting entry queues, etc.

To fix this without changing the database servers architecture or improve its hardware, the idea is changing strategy and instead using many concurrent processes with little work (SelUnitLen low) using little concurrents processes with a lot of work (SelUnitLen high) since for the database server it is usually equal costly blocking the full table to insert 1000 operations than to insert 10000. So, the idea is giving it a small value to this key and a high one to SelUnitLen, as indicated at the following example.

Example:

Let´s suppose we have a database server with concurrency issues, which counts on 4 logic processors (the amount of processors of the replica server is not impòrtant for this calcule). We can set the selectivity like this:

SelUnitLen=10000
MaxConcurrentSelectiveUnits=6

It is advisable to set the maximum amount of concurrent units between n and 2n, being n the amount of processors (or cores, or execution units in its case) In the servers set this way, it is necessary rising the amount of records of the selectivity unit to compensate for the database work.

This key is optional and only makes sense if the PUSH is set for the database (they exist the respective fieldsin the clients tables).

The key value indicates the amount of time (in seconds) that the server will wait before sending a PUSH notification to a client when there is an amount of operations enough to notify it.

The value cannot be less than 60 (one minute). In case to indicate a lower value, the server will assume one minute. The value by default is 5 minutes (300 seconds).

This key is optional and only makes sense if the PUSH is enabled for the database.

The key value is a number indicating how many operations have to be availables for the devices in order the server considers necessary to send it a notification.

The value by default is 10. If the amount of operations available to be downloaded, in the squeue, in the queue directly if there is no selectivity or DMIs for the device is bigger than this number and it has been a loinger time than the configured one for the sending of notifications (PushTimeout), the server will send the client a notification.

Optional. The value by defautl is “false”. This key allows that the PUSH connector for Apple communicates through the development site instead doing it from the production one. This allows to test the apps in a controlled environment before taking them out to production. As soon as the server comes into production and the certificate for this project´s phase is installed, by removing this key it is achieved that the server send the notifications through the Apple production portal.

This key allows to change the notifications port by which the messages are sent to the Apple PUSH server. The value by default is 2195. This key should not have to be changed, so the best thing is not touch it.

This key allows to tell the service the name of the certificate that will be used for establishing the TLS connections with the PUSH server. The following fields can be used to identify the certificate:

1. Certificate subjet.
2. Certificate serial number.
3. Certificate descriptive name (Friendly Name).

Any of these fields having the string indicated in this key and that is in force, will be used to authenticate the PUSH connections.

The certificate has to be isntalled at the LocalMachine/MY store of the computer which the replica service is executing in. On the contrary, the server will not be able to use it.

For development environments or for systems in which we do not want or cannot install the certificate in the operative system stores, the certificate (.P12, .PFX) can be loaded from a file in the machine files system. In this case, just leaving empty the key that indicates the certificate name (or not putting it) and define this key with the full path of the file within is the certificate.

The most usual when the certicates are placed into files is protect them with a key, which must be defined in the AppleCertPwd key.

If a file is used to store the PUSH certificate for Apple, here the certificate´s key is set. For using the machine store this key is not necessary.

For the devices using Android PUSH, this key is used to define the key assigned for Google for this application. The keys have to be requested for each application developed with PUSH support.

To configure the PUSH in the Android devices is necessary the server has two credentials (the access key and the SenderId). In this key the second of these parameters is described. Each replica database represents one application, so each one of them by separate have to be registered at Google Cloud, getting the credentials and set them at the .INI.

To configure the Blackberry PUSH is necessary to configure the server URL address that will be in charge of delivering the messages. This URL changes for the configurations with BIS and the ones that have BES. At any of the cases will be necessary that the client set its terminals to receive PUSH either in the Blackberry servers and in its own BES.

Port to use the PUSH notifications dispatch to the terminals. The value by default should be valid, but each service should have its own. Once the application is registered we will have the port used for the notifications and it hast to be configured in this key.

In this section are set those databases that have selective replica and or operations input queue and therefore need the server to create for them a monitoring sub-process. This sub-process will be the one in charge of analysing the clients records to create the necessary work units which will be processed by the selectivity sub-processes and supporting the entry queue. Within this section a key must be declared for each one of the databases that are going to be monitored. Each key may have the name the administrator wants to (as long as they are not repeated, of course) and as value will have the number of license (used as key inside the Section [licenses]) so that through this key the server may locate the database in memory and starts it to search those selective clients. In case a database has no selective clients or entry queue, its analysis sub-process will end, which will happen also if the database has not the necessary tables for the selective replica support or entry queue. It is important that the databases defined in this section are defined in the licenses section, or on the contrary the monitoring sub-processes for these databases never will be launched.

In this section the general aspects of the proxy will be set. As this component is totally independent, in the configuration file will not have much more than this section and the definitions of the databases (Section [licenses]), although usually if it is about an scenery in which the server and the proxy are in the same machine, in this same file are all the configuration sections of one component as well as the the other one.

This key has as value the host name or the IP address of the server with which the proxy will connect to send the commands that come from the client. If the proxy is in the same machine than the real server, what will be seen most in this key will be “localhost” or “127.0.0.1” but this does not mean that it must necessarily be so. This field is mandatory and has no value by default, so, if is not put, the proxy will not work properly.

As for the client (remember that the proxy behaves both as a server and as a client) it is necessary to indicate by which port the server is waiting for. This field has no value by default, so it is mandatory.

It has the same meaning than for the server. The value by default will be 3 times the amount of processors of the system, determined when the proxy is started for the first time. This is good to say it at any time, and the first request done to the proxy will require to start all the DLL of extension, and among the things done is precisely the creation of the sub-processes pool, the intermediate structures creation, etc, therefore, this first request will take a little bit, so not to desperate, that are not all as slow as the first one.

Although the IIS can be set to accept a certain number of connections, the extension as such has a limit given by the purchased license and by the physical features of the hardware in which it runs (remember that each request is not going to be just HTML, but it has to consult a server that is limited in connections and load by similar factors). Here,the amount of connections can be limited under the license the extension has for those cases in which the hardware features so demand it.

Once the CGSoft Replicator Server Advanced Edition has finished, we have to copy the necessary files to proceed to the migration. These files are found in the “Windows” filder of the initial server, and are the following ones:

• “replicator.ini”. In case of migration, we need to modify the “ConnString” parameter, indicating the new connection configuration, if it was changed. Figure 1
• File with hexadecimal name and with “.LIC” extension, that is the Replica server license. Figure 2
• As many files as name of 8 digits (we can identify them by looking at the [licenses] of the configuration file “replicator.ini”) and extension “.000” and later “.001”. Only mandatory the existance of the file with extension “.000”. Figure 2.

Figure 1:

Figure 2: