Going Live Checklist

Product Catalog and Events

1. All product catalog entries have been entered.

2. All product catalog entries have been matched with entries the previous billing in the Migration application.

3. Product catalog settings have been verified by the Customer.

4. Settings of Product catalog entries have been verified by Latera employees, including the following items:

• • Billing period

  • Charging scheme (postpaid/prepaid/daily)

  • Service providing scheme

  • Service activation rules

  • Aggregation period

  • Archiving period

      5. Each event has the following checkbox selected: “Cancel duplicate events” and “Re-create event if any substitution changes”.

Basic Contracts and Price Specifications

1. All basic contracts have been entered in the system.

2. All basic price specifications have been entered into the system:

1. 1. with the correct period

   2. at the correct tax rate

   3. in force

   4. linked with basic contracts

3. All individual price specifications have been entered into the system:

1. 1. with the correct period

   2. at the correct tax rate

   3. with a draft status

   4. have remarks concerning individual price specification bindings to contracts to be made after migration

   5. no errors have been detected while changing price specification status to “in force” during test migrations;

4. All price specifications have been verified by Latera employees. 

5. All price specifications have been verified by the Customer employees.

6. Automated check for the last test migration has detected no service subscriptions with prices that failed to be determined.

7. Provisioning of each price plan type has been proven to work in the test environment.

Customers

Within the multi-subsidiary version, tests for each section are performed separately for each company.

1. Customers have been correctly grouped:

1. 1. random checks for customers belonging to different categories (individuals/entities, by regions, etc) have been performed without any faults;

   2. the number of customers per each group corresponds to those given by the Customer.

2. Customers have been subscribed to services:

1. 1. random checks for customers belonging to different categories (individuals/entities, by regions, etc) have been performed without any faults;

   2. the number of customers' subscriptions to each service corresponds to those given by the Customer.

3. Customers have access to Customer Self-Care Portal.

4. Temporary suspension and non-payment suspension services work properly (if they are going to be used).

5. The total balance of customer accounts for all customers corresponds to the one given by the Customer.

6. Random checks of account balances for customers of different categories have been performed by the Customer.

7. Customer statuses are completely accurate.

a. Suspended customers and those with the Suspended status retain the corresponding status after the migration.

Test Environment

For RADIUS (DHCP) workflow:

1. hard is set up as a cluster.

2. Test authentication and authorization is successfully performed (attention: should be checked on the production network with real customers!).

3. All IP addresses for access servers have been entered in the network service settings and in the FreeRADIUS configuration file.

4. New IP addresses are assigned from the source pool.

5. Real / fixed IP addresses are assigned by Hydra.

6. Services are switched on/off on BRAS via event execution.

7. Accounting packets are being received, traffic is accounted, there is no unaccounted traffic at the test database.

8. Watchdog is set up for all FreeRADIUS instances. 

For Netflow accounting scheme:

1. Netflow data is forwarded to the collector server (hcd).

2. There are traffic class specifications entered in the system, and the traffic data is accounted accordingly;

3. Within the registry for IP addresses, all IP addresses used for dynamic assigning are entered.

4. All equipment for which traffic should be accounted is entered into the system (including provider equipment).

Telephony

1. CDRs are rated properly (as per rating over the previous periods and reconciliation/checking).

2. Files from PBX are automatically stored in the assigned directory at the server.

3. CDR importing script runs periodically and performs the import.

Data Migration

1. All automatic checks performed in the Migration application are successful.
2. Latest migration has been verified by the Customer.
3. Latest migration has been verified by Latera employee.
4. Latest successful migration has been performed in less than two days; no changes have been made to the unload algorithm and the migration data during this period.

External systems

1. Invoice export to ERP software is successfully performed by the Customer for the test customers. Importing script executes without faults.

Backup

1. Production database dump is automatically collected daily and copied to a safe storage.

2. The latest production database version with the pre-migration state is backed up and stored at the Latera server.

3. Auxiliary server backup and production database dump to the Latera server is turned off.

4. Replication is set up and is properly performed (should be checked at the backup server).

Payments acceptance

1. Payments acceptance via payment gateways has been successfully tested for faults.

2. Production certificates and credentials are used in hpd's configuration.

Business processes

1. New customer connection process has been tested.

2. The plan of actions for all frequently arising customer support issues has been clarified (viewing PPP sessions, password changing, etc.).

Administration

1. Hardware server configurations correspond to Commercial Proposal requirements (CPU, RAM, storage). It applies both to the Customer owned servers and SaaS installations.

2. All Hydra's scheduled tasks required for system operation run without faults or warnings.

1. 1. For all scheduled tasks operating with CDRs and the RADIUS server correct parameters are set up (Forced closing old CDRs, Deleting old CDRs, Processing session RADIUS accounting data).

3. Debug logging is disabled for all modules and agents.

4. The system servers have the latest stable versions of the following installed:

1. 1. Core (database)

   2. Web apps

   3. Agents.

5. All Debian Linux security updates are installed.

o install updates, it is necessary to perform the following command:

root@billing:~# aptitude update && aptitude upgrade

Note: When performing updates, it is obligatory to review the list of updates in detail. There should be no unexpected updates of Hydra modules.

6. Server monitoring has been set up for:

1. 1. free disk space  

   2. RAM

   3. CPU utilization

   4. other important metrics

7. Monitoring of the billing system has been set up and tested:

1. 1. free space in HYDRA tablespace

   2. important system tasks:

• • • Closing and putting in force charge logs

• • • Preparing charge logs for recurrent services

• • • Obtaining traffic collector statistics

• • • Monitoring customer account balances

• • • Forced closing / deleting outdated CDRs

c. any CDRs rated with errors or unrated.

8. For Service Provider Console and Customer Self-Care Portal:

1. 1. SSL access is set up

   2. A reminder is set up for updating SSL certificate before its expiration

   3. DNS records are set up and active

9. Default passwords to all services have been changed, including those

1. for Oracle users:

• • AIS_NET

• • SYS

• • AIS_ISP_OFFICE

• • AIS_USER_OFFICE

• • AIS_RPC

• • others (if necessary)

SET LINESIZE 1000;
SET PAGESIZE 1000;
SELECT USERNAME,
       VC_PASSWORD,
       'ALTER USER ' || USERNAME || ' IDENTIFIED BY "' || VC_PASSWORD || '";' AS VC_COMMAND
FROM   (
  SELECT USERNAME,
         SUBSTR(
           TRANSLATE(
             DBMS_RANDOM.STRING('p', 250),
             'A `~!@#$%^&*()-=_+[]\{}|;'':",./<>?',
             'A'),
           1, 24)        AS VC_PASSWORD,
         ACCOUNT_STATUS
  FROM   DBA_USERS
  WHERE  ACCOUNT_STATUS    = 'OPEN'
  OR     USERNAME       LIKE 'AIS\_%' ESCAPE '\')
ORDER BY USERNAME;

10. Servers within Hydra are completely ready for going live (should be checked for each server separately):

1. 1. Configuration corresponds with the one in the commercial proposal.

   2. All necessary services are working after the system restart (should be checked via reboot!)

   3. IP address and server hostname are assigned

   4. Firewall is set up and turned on:

• • • No Hydra services are unnecessarily exposed

    • Access to Service Provider Console is allowed only from internal Customer subnets and Latera servers

    • There is no access to 21902 and 21903 TCP ports which were previously opened during implementation stage for connections from IP address 144.76.78.80.

e. Valid timezone is set up, NTP time synchronization is enabled. 

11. Customer Technical Datasheet is created and stored in Latera database.

12. An up-to-date Oracle DST version is used.

13. The number of customers is the same as per the License (active_users1 – total amount of customers in Active state, active_users2 – total amount of customers in Active state having at least one unclosed subscription, active_users3 – total amount of customers having at least one payment or charge in last 6 months)

SET SERVEROUTPUT ON
 
DECLARE
  num_HydraVersion              NUMBER;
  num_MajorVersion              NUMBER;
  num_MinorVersion              NUMBER;
  num_Modification              NUMBER;
  vch_Revision                  VARCHAR2(80);
  dt_InstallationDate           DATE;
 
  num_ActiveUsers1              NUMBER;
  num_ActiveUsers2              NUMBER;
  num_ActiveUsers3              NUMBER;
  num_LicenseUsers              NUMBER;
BEGIN
  MAIN.GET_DB_VERSION(
    num_HydraVersion    => num_HydraVersion,
    num_MajorVersion    => num_MajorVersion,
    num_MinorVersion    => num_MinorVersion,
    num_Modification    => num_Modification,
    vch_Revision        => vch_Revision,
    dt_InstallationDate => dt_InstallationDate);
 
  SELECT COUNT(*)
  INTO   num_ActiveUsers1
  FROM   SI_V_USERS U
  WHERE  U.N_SUBJ_STATE_ID = SYS_CONTEXT('CONST', 'SUBJ_State_on');
 
  -- For version >= 3.5.2
  IF num_HydraVersion > 3 OR
     num_HydraVersion = 3 AND (num_MajorVersion > 5 OR
     num_MajorVersion = 5 AND num_MinorVersion >= 2) THEN
    EXECUTE IMMEDIATE
      'SELECT COUNT(*)
       FROM   SI_V_USERS U
       WHERE  U.N_SUBJ_STATE_ID = SYS_CONTEXT(''CONST'', ''SUBJ_State_on'')
       AND EXISTS (
         SELECT N_SUBSCRIPTION_ID
         FROM   SI_V_SUBSCRIPTIONS
         WHERE  N_SUBJECT_ID = U.N_SUBJECT_ID
         AND    SYSDATE BETWEEN D_BEGIN AND NVL(D_END, SYSDATE)
         AND    C_FL_CLOSED = ''N'')'
    INTO num_ActiveUsers2;
  ELSE
    EXECUTE IMMEDIATE
      'SELECT COUNT(*)
       FROM   SI_V_USERS U
       WHERE  U.N_SUBJ_STATE_ID = SYS_CONTEXT(''CONST'', ''SUBJ_State_on'')
       AND EXISTS (
         SELECT N_SUBJ_GOOD_ID
         FROM   SI_V_USER_GOODS
         WHERE  N_SUBJECT_ID = U.N_SUBJECT_ID
         AND    SYSDATE BETWEEN D_BEGIN AND NVL(D_END, SYSDATE)
         AND    C_FL_CLOSED = ''N'')'
    INTO num_ActiveUsers2;
  END IF;
 
  WITH
    charge_logs AS (
      SELECT N_DOC_ID
      FROM   SD_V_GOOD_MOVES_T
      WHERE  D_END >= ADD_MONTHS(SYSDATE, -6)
      AND   (N_SUM <> 0 OR N_ADD_SERVS_SUM <> 0)),
    payments AS (
      SELECT N_DOC_ID
      FROM   SD_V_PAYMENTS_C
      WHERE  N_SUM <> 0
      AND    D_OPER >= ADD_MONTHS(SYSDATE, -6)
      AND    N_MOVE_TYPE_ID = SYS_CONTEXT('CONST', 'MM_TYPE_Intake')),
    docs AS (
      SELECT N_DOC_ID
      FROM   payments
      UNION ALL
      SELECT N_DOC_ID
      FROM   charge_logs),
    non_canceled_docs AS (
      SELECT D.N_DOC_ID
      FROM   docs                      D,
             SD_V_DOCUMENTS_SIMPLE     VD
      WHERE  VD.N_DOC_ID = D.N_DOC_ID
      AND    VD.N_DOC_STATE_ID IN (SYS_CONTEXT('CONST', 'DOC_STATE_Actual'), SYS_CONTEXT('CONST', 'DOC_STATE_Executed')))
  SELECT COUNT(DISTINCT S.N_SUBJECT_ID)
  INTO   num_ActiveUsers3
  FROM   non_canceled_docs           D,
         SI_V_DOC_SUBJECTS_SIMPLE    DS,
         SI_V_SUBJECTS               S
  WHERE  DS.N_DOC_ID      = D.N_DOC_ID
  AND    DS.N_DOC_ROLE_ID = SYS_CONTEXT('CONST', 'SUBJ_ROLE_Receiver')
  AND    S.N_SUBJECT_ID   = DS.N_SUBJECT_ID
  AND    S.N_SUBJ_TYPE_ID = SYS_CONTEXT('CONST', 'SUBJ_TYPE_User');
 
  SELECT N_VALUE
  INTO   num_LicenseUsers
  FROM   SS_PARS       P,
         SS_PARVALUES  PV
  WHERE  P.N_PARGROUP_ID = SYS_CONTEXT('CONST', 'PARAM_GRP_System')
  AND    P.VC_CODE       = 'PAR_LicensedUsers'
  AND    P.C_ACTIVE      = 'Y'
  AND    PV.N_PAR_ID     = P.N_PAR_ID
  AND    PV.C_ACTIVE     = 'Y';
 
  DBMS_OUTPUT.PUT_LINE('{'||
                       '"active_users1": "'||num_ActiveUsers1||'", '||
                       '"active_users2": "'||num_ActiveUsers2||'", '||
                       '"active_users3": "'||num_ActiveUsers3||'", '||
                       '"license_users": "'||num_LicenseUsers||'"'||
                       '}');
END;
/

Hydra OMS

1. The logic of business processes complies with their description and expected behaviour.
2. Integration with external systems runs normally.
3. Default passwords for Hydra OMS, Camunda, and external systems have been changed.
4. Implemented business processes have been tested for all possible usage scenarios.