Table of contents
Ingress setup
- All 3 case notification services are using the same data ingestion ingess. Use this existing setup as needed
PHIMNS Properties
-
For the services to be fully functional, the STLT need to provide CDC their PHIMS properties. This ensures the data in the
TransportQ_Outtable gets updated correctly when the data is being processed by the CDC Case Notification. These data can be pulled from the existing NND Rhapsody route’s Variable Manager on the STLT level.- Require
nbs_certificate_url– STLT most likely will have this hardcoded in the Rhapsody Variable Manager
- Optional – these are optional, some STLT might have or need them:
phin_encryptionphin_routephin_signaturephin_public_key_addressphin_public_key_base_dnphin_public_key_dnphin_recipientphin_priority
- Require
-
Once the data has been provided by the STLT, CDC should update the existing config on the CDC Case Notification config table:
- Table Name:
NBS_Case_Notification_Config - Update record where config name is:
NON_STD_CASE_NOTIFICATION -
Update value: Any values provided by STLT should be matched with the reflected column in the config table
-
Update Script - DB:
NBS_MSGOUTEUPDATE NBS_Case_Notification_Config SET nbs_certificate_url = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_encryption = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_route = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_signature = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_public_key_address= 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_public_key_base_dn= 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_public_key_dn = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_recipient = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED', phin_priority = 'REPLACE WITH VALUE, REMOVE IF NON IS PROVIDED' WHERE config_name = 'NON_STD_CASE_NOTIFICATION'
- Table Name:
Extra Note and troubleshooting
Case Notification Environment Variable
- Case-Notification-Service
- Data-Extraction-Service
- Xml-Hl7-Parser-Service
Case Notification Liquibase
- Case Notification comes with a built-in Liquibase that automatically handles any DB changes upon deployment.
- DB changes detail can be reviewed here:
- Please refer to Deploy Data Ingestion via Helm chart for how to deploy DI.
Liquibase DB Change Verification
- To verify whether the database changes were applied, first ensure the Case Notification container is stable and running; since the container manages Liquibase, it won’t start if Liquibase fails.
- If there is failure by Liquibase, the DI pod will be unstable, and a specific error can be found within the container log.
Kafka
-
Use either one of the two Kafka broker endpoints (
Private endpoints - Plaintext) in the Helm values file. -
Required Debezium Source Connector on
NBS_ODSE..CN_TranportQ_Outdeployed first prior to the services deployment- a. Detail link