Provision BDS
Contents
Learn how to provision Billing Data Service (BDS).
Tenant Provisioning
This page describes the following provisioning procedures:
Create configmap
- Download bds-config archive:
pureengage-helm-production-local.jfrog.io/bds-config-100.0.005+0003-pe
- The archive contains two tenants examples in the result folder:
- multiregion configuration file:
config-t100-100.json
- single-region configuration file:
config-t101-101.json
- This procedure demonstrates a multi-region scenario.
- Extract archive:
developer@docker:/media/sf_shared/OpenShift$ tar xvzf bds-config-100.0.005+0003.tgz bds-config/Chart.yamlbds-config/values.yaml bds-config/templates/bds-configmap.yml bds-config/result/config-t100-100.json bds-config/result/config-t101-101.json bds-config/result/main.json
- Update bds-config/result/config-t100-100.json:
- In the "globals" section:
- Add "gws" section:
"gws": { "host": "BDS_CFG_GWS_HOST_PLACEHOLDER", "auth_host": "BDS_CFG_GWS_AUTH_HOST_PLACEHOLDER", "grant_type": "client_credentials", "client_id": "BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER", "client_secret": "BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER" }
- Add/modify "SourceId": "MultiCloudPE". If the
modeValue = MULTICLOUD_PE
, theSourceId
value is by default set asMultiCloudPE
in theglobals
section.
- Add "gws" section:
- In tenants/<tenant_name>/, populate contact_center_id with correct value. You can get this value by running a command specified in Get contact center ID from GWS.
- For example: "contact_center_id": "e01f1720-c1ec-11eb-a4b5-53da51249f17"
- Configure your Genesys Info Mart endpoint by replacing corresponding placeholders. This step is optional, but if you do not complete it, then you must populate placeholders’ values in bds-manual-secrets (see Create secrets)
- Example:
- Where,
"gimdb": { "db_type": "postgre", "driver_name": "PostgreSQL", "server": "BDS_CFG_GLOBALS_GIM_DB_HOST_PLACEHOLDER", "port": 5432, "database": "BDS_CFG_GLOBALS_GIM_DB_NAME_PLACEHOLDER", "username": "BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER", "password": "BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER" }
- db_type supports
sql_server
,postgre
, andoracle
databases - driver_name must be
FreeTDS
,PostgreSQL
, andOracleODBC-12.1
correspondingly for sql_server, postgre, and oracle databases. - server supports both FQDN and IP values.
- db_type supports
- Configure your GVP endpoint in each region of your tenant by replacing corresponding placeholders. This step is optional, but if you do not complete it, then you must populate placeholders’ values in bds-manual-secrets (see Create secrets).
- Example:
"gvp": { "gvp_primary_rs_name": "GVP", "db_type": "sql_server", "driver_name": "FreeTDS", "server": "BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_HOST_PLACEHOLDER", "port": 1433, "database": "BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_NAME_PLACEHOLDER", "username": "BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_USR_PLACEHOLDER", "password": "BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_PSW_PLACEHOLDER" }
- Add Consul endpoints in each region of your tenant (For example: /tenants/<tenant_name>/regions/us/ash/):
"consul": { "url_api": "BDS_CFG_CONSUL_TOKEN_PLACEHOLDER", "token": "BDS_CFG_CONSUL_GLOBALS_TOKEN_PLACEHOLDER" }
- Configure the production_date according to your business needs. Genesys recommends to set the production date as one day prior to the date in which you want to go-live.
- For example, if you want to go-live on January 25, 2022, then you must set the production date as at least one day prior to January 25, that is, January 24, 2022 or earlier dates.
- "production_date": "2022-01-24"
- In the "globals" section:
- Execute the following command to create the configmap file:
helm install --debug bds-config bds-config --version=100.0.005+0003-pe -n bds
- Manually create extract and transform folders on shared storage which is mounted by PVC.
Create secrets
AKS
- Create file with secrets (change all * to your real variables):
apiVersion: v1 kind: Secret metadata: name: bds-manual-secrets namespace: bds type: Opaque stringData: BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER: ** BDS_CFG_BDS_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_GWS_CLIENT_SECRET_PLACEHOLDER: ** BDS_CFG_CONSUL_TOKEN_PLACEHOLDER: ** BDS_CFG_CONSUL_URL_API_PLACEHOLDER: ** BDS_CFG_CONSUL_URL_API_REGION_PLACEHOLDER: ** BDS_CFG_CONSUL_WESTUS2_TOKEN_PLACEHOLDER: ** BDS_CFG_CONTACT_CENTER_ID_PLACEHOLDER: ** BDS_CFG_CS_CONSUL_PLACEHOLDER: ** BDS_CFG_GIR_ES_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_HOST_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_HOST_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_HOST_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_USR_PLACEHOLDER: ** BDS_CFG_GWS_AUTH_HOST_PLACEHOLDER: ** BDS_CFG_GWS_HOST_PLACEHOLDER: ** BDS_CFG_LEGACY_GLOBALS_SFTP_PSW_PLACEHOLDER: ** BDS_CFG_LEGACY_GLOBALS_SFTP_USR_PLACEHOLDER: ** BDS_CFG_SFTP_HOST_PLACEHOLDER: ** BDS_CFG_SFTP_PATH_PLACEHOLDER: ** BDS_CFG_SOURCEID_PLACEHOLDER: **
- Install this secret to the AKS cluster by executing the following command:
kubectl create -f bds-manual-secrets.yaml
- Since manual secrets are used, you must override bdsApp.secrets.gim.mounts.name, bdsApp.secrets.gvp.mounts.name, and bdsApp.secrets.consul.mounts.name to " ". For more details on these parameters, refer Configure BDS.
OpenShift
- Create file with secrets (change all * to your real variables):
cat <EOF > ./bds-manual-secrets.yaml apiVersion: v1 kind: Secret metadata: name: bds-manual-secrets namespace: bds type: Opaque data: BDS_CFG_GLOBALS_GVP_DB_USER_PLACEHOLDER: BDS_CFG_GLOBALS_GVP_DB_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_CME_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_CME_USER_PLACEHOLDER: BDS_CFG_GLOBALS_CME_GVP_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_CME_GVP_USER_PLACEHOLDER: BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER: BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER: BDS_CFG_CONSUL_GLOBALS_TOKEN_PLACEHOLDER: BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER: BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_USR_PLACEHOLDER: BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_PSW_PLACEHOLDER: BDS_CFG_CONSUL_TOKEN_PLACEHOLDER: BDS_CFG_BDS_DEV_GWS_CLIENTID_PLACEHOLDER: BDS_CFG_BDS_DEV_GWS_CLIENT_SECRET_PLACEHOLDER: stringData: BDS_CFG_GLOBALS_GVP_DB_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_USER_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER: ** BDS_CFG_CONSUL_GLOBALS_TOKEN_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_PSW_PLACEHOLDER: ** BDS_CFG_CONSUL_TOKEN_PLACEHOLDER: ** BDS_CFG_BDS_DEV_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_DEV_GWS_CLIENT_SECRET_PLACEHOLDER: ** EOF
- ImportantIn the secrets manifest file, specify the base64 encoded secrets values in the data section and the plain text values in the stringData section, which will be converted into base64 string after the file is created. The secrets values are validated either from the data or stringData sections or both. However, in Kubernetes, you cannot leave any values as blank in the secret manifest file.
- Install this secret to the OpenShift cluster by executing the following command:
developer@docker:~$ oc create -f bds-manual-secrets.yaml secret/bds-manual-secrets created
- Since manual secrets are used, you must override bdsApp.secrets.gim.mounts.name, bdsApp.secrets.gvp.mounts.name, and bdsApp.secrets.consul.mounts.name to " ". For more details on these parameters, refer Configure BDS.
Kubernetes
- Create file with secrets (change all * to your real variables).
cat <EOF > ./bds-manual-secrets.yaml apiVersion: v1 kind: Secret metadata: name: bds-manual-secrets namespace: bds type: Opaque data: BDS_CFG_GLOBALS_GVP_DB_USER_PLACEHOLDER: BDS_CFG_GLOBALS_GVP_DB_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_CME_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_CME_USER_PLACEHOLDER: BDS_CFG_GLOBALS_CME_GVP_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_CME_GVP_USER_PLACEHOLDER: BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER: BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER: BDS_CFG_CONSUL_GLOBALS_TOKEN_PLACEHOLDER: BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER: BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER: BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_USR_PLACEHOLDER: BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_PSW_PLACEHOLDER: BDS_CFG_CONSUL_TOKEN_PLACEHOLDER: BDS_CFG_BDS_DEV_GWS_CLIENTID_PLACEHOLDER: BDS_CFG_BDS_DEV_GWS_CLIENT_SECRET_PLACEHOLDER: stringData: BDS_CFG_GLOBALS_GVP_DB_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_USER_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER: ** BDS_CFG_CONSUL_GLOBALS_TOKEN_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_WESTUS2_PSW_PLACEHOLDER: ** BDS_CFG_CONSUL_TOKEN_PLACEHOLDER: ** BDS_CFG_BDS_DEV_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_DEV_GWS_CLIENT_SECRET_PLACEHOLDER: ** EOF
- ImportantIn the secrets manifest file, specify the base64 encoded secrets values in the data section and the plain text values in the stringData section, which will be converted into base64 string after the file is created. The secrets values are validated either from the data or stringData sections or both. However, in Kubernetes, you cannot leave any values as blank in the secret manifest file.
- Install this secret to the Kubernetes cluster by executing the following command:
kubectl create -f bds-manual-secrets.yaml secret/bds-manual-secrets created
- Since manual secrets are used, you must override bdsApp.secrets.gim.mounts.name, bdsApp.secrets.gvp.mounts.name, and bdsApp.secrets.consul.mounts.name to " ". For more details on these parameters, refer Configure BDS.
GKE
- Create file with secrets (change all * to your real variables):
cat <EOF > ./bds-manual-secrets.yaml apiVersion: v1 kind: Secret metadata: name: bds-manual-secrets namespace: bds type: Opaque stringData: BDS_CFG_GLOBALS_GVP_DB_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_USER_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_CME_GVP_USER_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_GLOBALS_GWS_CLIENT_SECRET_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_HOST_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GIM_DB_PSW_PLACEHOLDER: ** BDS_CFG_CONTACT_CENTER_ID_PLACEHOLDER: ** BDS_CFG_SOURCEID_PLACEHOLDER: ** BDS_CFG_CS_CONSUL_PLACEHOLDER: ** BDS_CFG_GWS_HOST_PLACEHOLDER: ** BDS_CFG_GWS_AUTH_HOST_PLACEHOLDER: ** BDS_CFG_BDS_GWS_CLIENTID_PLACEHOLDER: ** BDS_CFG_BDS_GWS_CLIENT_SECRET_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_HOST_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_USR_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_PL_EASTUS2_PSW_PLACEHOLDER: ** BDS_CFG_CONSUL_TOKEN_PLACEHOLDER: ** BDS_CFG_CONSUL_URL_API_PLACEHOLDER: ** BDS_CFG_GIR_ES_PLACEHOLDER: ** BDS_CFG_CONSUL_URL_API_REGION_PLACEHOLDER: ** BDS_CFG_CONSUL_WESTUS2_TOKEN_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_HOST_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_NAME_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_PSW_PLACEHOLDER: ** BDS_CFG_GLOBALS_GVP_DB_WESTUS2_USR_PLACEHOLDER: ** BDS_CFG_LEGACY_GLOBALS_SFTP_PSW_PLACEHOLDER: ** BDS_CFG_LEGACY_GLOBALS_SFTP_USR_PLACEHOLDER: ** BDS_CFG_SFTP_HOST_PLACEHOLDER: ** BDS_CFG_SFTP_PATH_PLACEHOLDER: **
- Install this secret to the GKE2-2 cluster by executing the following command:
kubectl create -f bds-manual-secrets.yaml
- Since manual secrets are used, you must override bdsApp.secrets.gim.mounts.name, bdsApp.secrets.gvp.mounts.name, and bdsApp.secrets.consul.mounts.name to " ". For more details on these parameters, refer Configure BDS.
Create StorageClass, Persistent Volume, and Persistent Volume Claim
AKS
- Create StorageClass and Persistent Volume, (only if your configuration requires it). If they already exists, then skip to the next step.
- Create Persistent Volume Claim (PVC).
- Create file bds-pvc.yaml by referring the following sample code:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bds-pvc namespace: bds spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi storageClassName: azurefile volumeMode: Filesystem
- Apply bds-pvc.yaml, by executing the following command:.
kubectl apply -f bds-pvc.yaml -n bds
OpenShift
- Create Storage Class (only if your configuration requires it):
- Create file bds-storageclass.yaml by referring the following sample code:
allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: < storage-class-name > parameters: kind: Managed storageaccounttype: Premium_LRS provisioner: < provisioner > reclaimPolicy: Retain volumeBindingMode: Immediate
- Apply this yaml:
oc create -f bds-storageclass.yaml
- Create file bds-storageclass.yaml by referring the following sample code:
- Create Persistent Volume (PV) (only if your configuration requires it):
- Create file bds-pv.yaml by referring the following sample code:
apiVersion: v1 kind: PersistentVolume metadata: name: < pv-name > spec: accessModes: - ReadWriteOnce capacity: storage: 10Gi persistentVolumeReclaimPolicy: Retain storageClassName: < storage-class-name > volumeMode: Filesystem
- Apply this yaml:
oc create -f bds-pv.yaml
- Create file bds-pv.yaml by referring the following sample code:
- Create Persistent Volume Claim (PVC):
- Create file bds-pvc.yaml by referring the following sample code:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: < pvc-name > namespace: < namespace > spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: < storage-class-name > volumeMode: Filesystem
- Apply this yaml:
oc create -f bds-pvc.yaml
- Create file bds-pvc.yaml by referring the following sample code:
Kubernetes
- Create Persistent Volume (PV) (only if your configuration requires it).
- Create file pv.yaml by referring the following sample code:
cat <EOF > ./pv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: bds-pv labels: type: local spec: storageClassName: manual capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: "/genesys/data" EOF
- Apply this yaml:
kubectl create –f pv.yaml
- Create file pv.yaml by referring the following sample code:
- Create Persistent Volume Claim (PVC).
- Create file pvc.yaml by referring the following sample code:
cat <EOF > ./pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bds-pvc namespace: bds spec: storageClassName: manual accessModes: - ReadWriteOnce resources: requests: storage: 3Gi EOF
- Apply this yaml:
kubectl create –f pvc.yaml
- Create file pvc.yaml by referring the following sample code:
GKE
- Create StorageClass and Persistent Volume, (only if your configuration requires it). If they already exists, then skip to the next step.
- Create Persistent Volume Claim (PVC).
- Create file bds-pvc.yaml by referring the following sample code:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bds-pvc namespace: bds spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi storageClassName: nfs-client volumeMode: Filesystem
- Apply bds-pvc.yaml, by executing the following command:.
kubectl apply -f bds-pvc.yaml -n bds
Create watermarks on persistent volume
The extract, transform, and load processes in BDS relies on watermark dates. Typically, the watermark date is either the agreed go-live date, or a date that is one day earlier than the date when data exists in all relevant data sources.
Watermark dates are automatically created for BDS persistence volume. You can also manually update the watermark in scenarios where you want to reprocess or catch up the data.
To automatically create watermarks, run BDS. Running BDS creates the watermark file and updates all the watermark related fields such as extract_watermark, transform_watermark,
and load_watermark
with the production date. Note that the production date is configured as part of Tenant provisioning.
To manually create watermarks, perform the following steps:
- Create the pod yaml by referring the following sample code.
cat <EOF > ./pv-static.yaml apiVersion: v1 kind: Pod metadata: name: static-pv spec: volumes: - name: pv-test persistentVolumeClaim: claimName: bds-pvc containers: - name: test image: ubuntu command: [ "/bin/sh" ] args: [ "-c", "while true; do echo hello; sleep 10;done" ] volumeMounts: - mountPath: "/tmp" name: pv-test EOF
- Execute the following commands to verify the status of the pod created, create the watermarks folder, and create the tenant json file.
- Where,
developer@docker:~/OpenShift$ kubectl apply -f pv-static.yaml -n bds pod/static-pv created developer@docker:~/OpenShift$ kubectl get pod static-pv -n bds NAME READY STATUS RESTARTS AGE static-pv 1/1 Running 0 68s developer@docker:~/OpenShift$ kubectl exec -n bds -it static-pv bash 1000670000@static-pv:/$ cd /tmp 1000670000@static-pv:/$ mkdir watermarks 1000670000@static-pv:/tmp$ cd watermarks/ 1000670000@static-pv:/tmp/watermarks$ echo -e "{ \n\t\"extract_watermark\": \"YYYY-MM-DD\",\n\t\"transform_watermark\": \"YYYY-MM-DD\",\n\t\"load_watermark\": \"YYYY-MM-DD\",\n\t\"source_extract\": {\"GIM\": \"2022-05-26\", \"WFM\": \"2022-05-26\", \"GIR\": \"2022-05-26\"}\n}" > <tenant_name>.json
- extract_watermark - The last successful extraction date in YYYY-MM-DD format, should be greater than or equal to the production date.
- transform_watermark - The last successful transformation date in YYYY-MM-DD format, should be less than or equal to the extract watermark, and greater than the production date.
- load_watermark - The last successful load date in YYYY-MM-DD format, should be less than or equal to the transform watermark, and greater than the production date.
- source_extract - The last successful source extract date from all or specific data sources such as GIM database, GVP RS database, and so on. Supported data sources are: 'GIM', 'WFM', 'GVP', 'GIR', 'S3', 'INVENTORY', and 'ALTOCLOUD'.
- <tenant_name> - The name of the tenant as it is configured in the Config.json file for BDS. A watermark file will be created in the json format for the tenant with the name specified here, for example, MultiRegionExampleTenant.json.
- Execute the following command to verify the watermark values created in the tenant's json file. You will see a result similar to the following example. In this example, MultiRegionExampleTenant.json is the tenant file that contains the extract, transform, and load watermark values for the tenant.
cd /tmp/watermarks/ MultiRegionExampleTenant.json { "extract_watermark": "2021-06-27", "transform_watermark": "2021-06-27", "load_watermark": "2021-06-27" }
- Exit and remove pod.