Vitalsigns for SmrtCCOps

SmrtCCOps refers to the Vitalsigns deployed on vitalsigns1.smrttouch.com providing Vitalsigns service to the Nobelbiz SmrtCCOps customers (Elead, Time Warner, etc...). The original SmrtCCOps application was configured via the methods described in the Standalone Vitalsigns section. Because each SmrtCCOps client provides the same data in the same formats, a new SmrtCCOps application can be created by cloning an existing SmrtCCOps system. This section describes that procedure. Any additional modifications would be made using the information provided in the Standalone Vitalsigns section.

Prerequisites

There are two parts to setting up a new CCops customer. Setting up the data acquisition, and cloning the Vitalsigns meta-data. Before turning on the new customer data feeds, 4 items of information are required:

  1. A supervisors (agent roster) file. These arrive on vitalsigns1-stg in the /home/vsftp/incoming/<customer> directory.
  2. A disposition code file. These also arrive on vitalsigns1-stg, but are all automatically copied to vitalsigns1 in an existing script. Check for a file named TenantResults_<CustomerName>_<Date>.csv in $HOME/archive/callcenter on vitalsigns1.
  3. The name of each outbound campaign and the return phone number for each campaign.
  4. The redis db number for the data queues for this customer.

If you do not have all of these, you can start the configuration, but not complete it through the data load step. As long as you have number 4 you can do everything except load data. You can prevent the loading simply by not setting up the data load directory in the postgres meta-data repository until you have all prerequisite information.

Data Acquisition

The primary data source for the CCOps implementations is JSON formatted web hook data. There are two sets of messages that are subscribed to for the CCOps implementations, consolidated call messages, and agent state messages. The consolidated call messages provide one JSON message per call (inbound or outbound). These messages contain the entire lifecycle of each call including timestamps for each major event, agent information for those calls that reach and agent, and outcome data. The agent state messages provide one message each time an agent transitions to a new state (i.e. waiting for call, talking, in wrap, etc.).

Nobelbiz handles the subscriptions for these messages for each customer. The actual messages are queued into a redis database that Vitalsigns connects to and extracts the messages to input files on a 15 minute schedule. The extraction for new customers will be done on vitalsigns1.smrttouch.com. All scripts and configuration files for each customer are in the $HOME/nbwebutil directory.

To setup data acquisition you must know the redis db number:

  1. ssh into vitalsigns1.smrttouch.com
  2. mkdir $HOME/input/callcenter/<customer>
  3. mkdir $HOME/work/<customer>
  4. mkdir $HOME/archive/callcenter<customer>
  5. connect to the redis instance using: redis-cli –h acd-cache1.smrttouch.com
  6. at the redis-cli prompt enter: select <dbnum> where db num is the number of the database provided by NobelBiz.
  7. Enter: Keys *
  8. This should return a list of keys in the database. Most of them should look like: queue:<something>:<other info like message type and date>
  9. Make note of what the <something> is, most likely it will be “p”; regardless, that value is required in the next step
  10. cd into nbwebutil
  11. cp configbase.js config<cust>.js
  12. vi config<cust>.js and change the following in section after the “change these rows”comment”:

    a. config.workDir to point to the directory created in step 3 above
    b. config.finaldir to point top the directory created in step 2 above
    c. config.queuePrefix to match the <something> from step 8 above
    d. config.redisDb to the db_num from step 6 above

  13. save the file and exit vi.
  14. Execute the command: node exportAllQueues config<cust>.js
  15. A bunch of stuff will scroll by on the screen. Make sure it does not end with an error, you can ignore the rest.
  16. Check the directory created in 2 above. Assuming there was data in redis, you should see files like inbound_<date>.json, outbound_<date>.json, agents_<date>.json and logins_<date>.json. Note you may not have both inbound and outbound, but you should have at least one of them.
  17. If all worked, add the node command above to the $HOME/bin/loadProd.sh script where you see others like it.

The other thing required in this section is to verify that supervisor files are being received on vitalsigns1-stg and to move them to vitalsigns1. To do this ssh into vitalsigns1-stg.smrttouch.com. Then check for a directory matching your customer in /home/vsftp/incoming. If the directory is there, look in it to see if it contains files named supervisors<date>.csv. If it does not exist or the files are not there, bug Karl to get them. If they are there do the following:

  1. create a directory $HOME/archive/callcenter/<customer>
  2. vi $HOME/doTriangleLoad.sh
  3. near the bottom you will see a section commented as Moving InService Files, it is essentially a for loop processing the files for the InService customer.
  4. Copy from the echo statement through the done to right after the done.
  5. Change the copied lines to use your customer name instead of Inservice.
  6. Save the file and exit.
  7. Check the /home/vsftp/incoming/<customer> directory to be sure it has group level rwx permissions, if not change it so it does.

That is it for the data acquisition.

Cloning Vitalsigns meta-data

All CCOps customers reside in databases hosted on vitalsigns1. The postgres database is named vitalsigns. Connect pg admin to that database (port 5432 at vitalsigns1.smrttouch.com). Before starting, open one of the .json files in the customer’s input directory and find the clientId. This will be a JSON tag in the data, and after it should be a GUID. Grab that GUID and save it somewhere, you will need it in a few steps. Then:

  1. Determine the new application id.
    This is done by examining the contents of the database table "applications", finding the maximum app_id value, and incrementing that value by 1.
  2. Edit the script - "apptables_1.0.sql". This script is found in the distribution at ??????.
  3. Replace the string - <appid> - with the new app_id value determined in step 1.
  4. Execute the script in pg_admin against the vitalsigns database on the postgres server at port 5432 on vitalsigns1.smrttouch.com
  5. Edit the script - "copyapp_ccops.sql" - This script is found in the distribution at ??????.
  6. Replace the string - <appid> - with the new app_id value determined in step 1.
  7. Execute the script in pg_admin against the vitalsigns database on the postgres server at port 5432 on vitalsigns1.smrttouch.com
  8. Insert a line into data_input_ref_val data with values (4333980,’<GUID from above>’,’Customer name’, '2010-01-01')
  9. For each "Outbound Campaign name"/"return number" (item 3 of the prerequisite information) provided, add a row to data_input_ref_val_data with:

    table_id=9899703
    key_Value=<Outbound campaign name>
    return value=<phone number>.

  10. Add a row to data_input_batch_dir with:

    dir_id=<New dir_id>*
    app_id=<New application id determined in step 1>
    dir_path=/home/vitalsigns/input/callcenter/<customer>
    arch_path=/home/vitalsigns/archive/callcenter/<customer>.
    proc_order=1

    * To determine the <New dir_id>, examine the value in the table "object_ids". That value (last_id) is the last meta-data identifier number created/used by Vitalsigns. Update "object_ids" to increment that number by 1 and use the incremented number as the new dir_id. The Vitalsigns dataloader process uses this table as a sequence to produce new meta-data indentifier numbers whenever new data objects appear in the data. For this reason, do not perform this step while the dataloader is executing.

  11. In data_input_batch_dir_ref_files add these rows, with the first value being your new input directory number:

    a. <New dir_id>;"inbound*.json";6603206;"L";25
    b. <New dir_id>;"supervisors*.csv";6603209;"A";27

  12. In data_input_batch_dir_inp_files add these rows, with the first value being your new input directory number:

    a. <New dir_id>;"inbound*.json";3363626;"A";2;"Y"
    b. <New dir_id>;"outbound*.json";3363627;"A";2;"Y"
    c. <New dir_id>;"agents*.json";9887220;"A";4;"Y"
    d. <New dir_id>;"login*.json";9887220;"A";5;"Y"

The only thing that remains is adding it to batch loading.

Edit $HOME/loadProd.sh on vitalsigns1 and add your new appId to the list in the last line.