The Direct Replication Scheme

When a call is finished, GW_Relay will save the data not directly into GW_CDR in the local SQL server but into a buffer table called Log_PendingRepl, in the form of an SQL statement to be executed at the remote Billing Server. Check below

Log_PendingRepl

Notice the use above of the accent instead of the apostrophe, this is because apostrophes have a functional meaning within SQL statements, this way you avoid the SQL interpreter from misinterpreting.  

The Replication Scheme involved two applications: 

• An application called SrcRepl.exe, that runs on the same subnet as the GW_Relays, its job is to read from the Log_PendingRepl table and send the text in the SQL field in a UDP packet with a sum check to the SQLReplic.exe. 

• SQLReplic.exe is the receiving app, it runs on the Computer with the Billing server. The ReplicSQL commits the transaction contained in the received text packet, on the Billing Server and, if successful, returns an acknowledgement UDP packet (ACK) to SrcRepl.exe.  

Only after receiving the ACK is that it will delete the record from the Log_PendingRepl table. SrcRepl will re-send the ACK packet to the OmniMonitor and it will blink the Ack indicator with "Rpl" in green background on the GW_Monitor.

If for any reason SQLReplic can’t perform the transaction, then it sends a not acknowledge packet (NAK) to SrcRepl. When a NAK is received by SrcRepl, it will wait 5 seconds and re-send the same SQL but will send a NAK instead to the OmniMonitor that, this time, will blink the indicator in red. The same SQL will be re-resent until the transaction is successful. After 20 replication failures in a row, ReplSrc will send an Alarm 12 to the GW_Relay that will be broadcasted to all the monitors.

The SrcReplic window shows the last packet sent, while SQLReplic window shows the last transaction performed and the result message below. When there is a replication failure, you can check on these windows to figure out what is going wrong

Possible reasons for transactions to fail:

There's another field in the Log_PendingRepl table which is Priority. This field plays a more complex role in the OmniBox Extended Replication System, but still play one here. After trying 20 times with persistent failure, SrcRepl will not keep insisting in replicating that record because that would stall the whole replication process, at this time, it will lower its priority, so that it will insist on that one only when there is nothing pending. A persisting failure will generate a recurrent alarm # 12 that will warn operators that some human intervention is needed. 

SQLReplic makes an ODBC connection to the billing database, the default DNS is ReplSrc, but a different one may be specified in the S/ command line switch. This connection may require a user name and password, maybe a different port number than the default 1099 or if the computer has several network adapters you may need to specify which IP is it that you need to work with. You specify these parameters using the SQLReplic command line switches. Syntax below:

SQLReplic.exe N/[port Number]  U/[User name] P/[Password] I/{Ip address] S/[ODBC Source name]

The ReplSrc.exe Setup

The ReplSrc parameters are not read from the command line as the SQLReplic, but from the sys_parameter table. ReplSrc parameters are the ones belonging to set 100, 

*This is needed for the acknowledge message sent to the OmniMonitor

**For trouble shooting by #include only, must be always set to 0. 

ReplSrc uses UDP port 1998.