This script, ObjHookHCScoreAO.py, serves as a webhook handler for processing customer scoring data, likely originating from an "AO" (Affordability Online) channel. Its primary function is to receive customer data, normalize it, store it in a central scoring table, and then trigger a dedicated workflow to perform the actual scoring.
The script follows a clear, sequential process:
Param1), referred to as Guid. This Guid is essential for tracking the specific scoring request.webhook_code is "HCSCOREAO" and, if so, normalizes it to "HCSCORE". This suggests a centralized scoring workflow is used for different inbound channels.INSERT ... SELECT statement. This query reads a raw data record from a source table, bloom_hcscoreao_payload, identified by the Guid. During this process, it transforms and normalizes the data before inserting it into the main bloom_hcscore table. Key transformations include:
Acctclass, Acctclasstype, and Applicationchannel.Dob) and Gender from their 13-digit South African ID number.Firstname and Surname.Department code ('46').ObjWorkflow object and calls the Run method. It passes the normalized webhook_code ("HCSCORE") and the Guid, initiating the backend customer scoring process.stage_service table, marking the task as "DONE" (though this execution is commented out). Finally, it returns the string "DONE".The script is designed to be called with the following parameters:
payload: The raw payload from the webhook (not directly used in the Process method's logic).webhook_code: A code identifying the webhook source (e.g., "HCSCOREAO").Param1: The GUID for the specific transaction.Param2 - Param8: Additional optional parameters, which are not used in the current implementation.The script interacts with the following database tables:
bloom_hcscoreao_payload: This is the source table where raw data from the AO channel is initially stored. The script reads from this table using the _guid.bloom_hcscore: This is the destination table. The script inserts the cleaned, normalized, and standardized customer data into this table, making it ready for the scoring workflow.stage_service: This table is intended for tracking the status of services. The script contains commented-out code to INSERT a new record at the start and UPDATE the record to "DONE" at the end, suggesting it's part of a larger service management framework.The script includes a commented-out example of the expected JSON payload structure:
{
"Guid": "5e86febf-50ec-4f60-b2e0-88c4014e2e57_MPR3",
"AcctClass": "2",
"AcctClassType": "1",
"ApplicationChannel": "2",
"CellNo": "0722674583",
"CellOtherNo": "2323",
"CtryNo": "1",
"DeceasedFlag": "false",
"DOB": "19840101",
"FCProfile": "0",
"FirstName": "Piet",
"Gender": "M",
"HomeNo": "0909",
"IDNumber": "6912145059085",
"IDTypeNo": "1",
"MSCA": "14",
"PassportFlag": "N",
"RTProfile": "0",
"ScoreCardNo": "1",
"ScoreCategory": "2",
"Surname": "Pompie22s",
"WorkNo": "23"
}
The script relies on several custom modules:
ossysObjData: A base class for data objects, likely providing database connection and execution methods.ObjWorkflow: A class responsible for initiating and managing workflows.