Audit
The RouteLink® Server maintains the master CRN database. Each downstream RouteLink Client therefore has an effective copy of the master database by downloading the add and delete events as they are made available by the server. As discrepancies are found events are placed on the queue and the RouteLink Client downloads the corrective event. Here is the list of discrepancies:
- CRN missing in RouteLink Client
- CRN present in RouteLink Client but not in RouteLink Server
- Mismatched ROR
- Mismatched CPR
Audit Message Flows
The sub chapters that follow describe the message flow for the audit for success and failure conditions. Lastly, this chapter enumerates the specific request and response messages used by the audit.
Starting an Audit
The RouteLink Server decides when an audit is necessary by placing an audit event for a specific prefix on the RouteLink Client's event queue. The following diagram describes the events and flow of messages that occur when a prefix audit for 800 is started. It's important to understand that there will be an audit for each 8xx prefix that is valid at the time of the audit. Currently these prefixes include 800, 833, 844, 855, 866, 877, 888, and 0 (zero). Numbers starting with a 0 denote template records. Please Note: This list will be expanded as new Toll-Free prefixes are added such as 822.
Disclaimer: Any images in this article are intended to be used as a guide for educational purposes only and they may differ slightly from the Production Environment.
Description of a Successful Audit
The following message flow diagram shows the messages for the case when the audit of a prefix is successful. Only 3 messages are required in this best case.
The term, calculate hash, is used to indicate that a SHA-1 hash (40 printable hex digits) is generated from the data stored locally. The specific method for creating the hash is detailed in a later chapter.
Disclaimer: Any images in this article are intended to be used as a guide for educational purposes only and they may differ slightly from the Production Environment.
The diagram points out that both the RouteLink Sever and the RouteLink Client must use databases that are not changing during the audit (to avoid auditing a moving target). When the audit event arrives at the RouteLink Client through an event download, the two databases should, theoretically, be identical. The databases are compared by having both sides calculate the hash for the given prefix.
The “prefix” in the audit indicates to the algorithm to process all CRNs that start with that prefix. In SQL terms, the SELECT can be thought of as using a "where" clause like (in this example the prefix was 800):
“WHERE (crn LIKE '800%')”
The RouteLink Server will request a hash value over a given prefix using the audit request message and the RouteLink Client must calculate the hash and return the result to the RouteLink Server using an audit reply message. The audit reply message is sent to the server using an HTTPS POST. An example of sending an audit reply using wget is as follows:
wget --header="Content-Type: application/json" --header="Authorization: Bearer <access token>" --post-data='{"action":"audit_reply","prefix":"800","sha1": "<40 character hash value>"}' https://api-routelink.somos.com/routelink/v1/audit
The RouteLink Server compares the RouteLink Client's hash to its own hash to see if the two match. Of course, the calculation of the hash must be done using data fed into the algorithm in the exact same order by both sides. There is no requirement that the two sides use the same DB schema – but, the data must be fed into the SHA-1 algorithm in the same order. The data includes the CRNs, RORs, and CPR hashes (not the CPRs themselves). The hash calculation and the order of the data is described in more detail later.