Customer Workflow - HLD

HLD Document:

The below diagram shows the interaction between CMD, Camunda WF, CMD Portal, Active directory and BPM Database.

High Level Techno-Functional Flow:

Low Level Technical Flow:

Customer Workflow Process Flows:

When customer create request is submitted, the Ingest Customer service need to do below activities:

1. First, perform the validations on the input details.
2. If any validation fails, return the validation errors to the user.
3. If No validation errors, Make an entry in the customer_information parent table and the associated child tables.
4. Create an entry in the customer_wf_process_details table.
5. Call the workflow API, passing the workflow input payload. The workflow service will return the process ID.
6. Update the customer_wf_process_details table with the process ID and update customer snapshot.
7. Update the customer_information and child tables, setting is_pending = 'Y'.

When customer update request is submitted, the Ingest Customer service need to do below activities:

1. First, check customer is present in CMD .
2. Check Customer is active and not in workflow.
3. Perform the validations on the input details.
4. If any validation fails, return the validation errors to the user.
5. If No validation errors,Create/Update an entry in the customer_wf_process_details table.
6. Call the workflow API, passing the workflow input payload. The workflow service will return the process ID.
7. Update the customer_wf_process_details table with the process ID and update customer snapshot.
8. Update the customer_information and child tables, setting is_pending = 'Y'.

Workflow Trigger Conditions:

A. Create Scenario:

Ingest Customer service needs to trigger customer workflow in below create scenarios (customer onboarding) :

1. If Customer Address is not Validated then “Address-Quality” WF needs to be triggered
2. If user tries to create duplicate Customer then “Duplicate” WF needs to be triggered
3. If Customer belongs to European Country and Tax is not validated as per Vies then “VIES” WF needs to be triggered.
4. If Customer belongs to Australia Country and Tax is not validated as per ABN then “AUSTRALIA_ABN” WF needs to be triggered.
5. If Customer belongs to NEW ZEALAND Country and Tax is not validated as per New Zealand tax then “NZBN” WF needs to be triggered.
6. f Customer belongs to United Kindom Country and Tax is not validated as per UK tax then “NEW_ZEALAND_NZBN” WF needs to be triggered.
7. If user select Customer group type as SCPI Tax Exempted while creating then “Customer-Group-Change” WF needs to be triggered
8. If Customer is detected as Internal Customer then “Account-Group-Change“ WF needs to be triggered.
9. If customer get created using the BVD source then
   1. If trading name change then “Bvd-Trading Name Change” WF needs to be triggered
   2. If the BVD customer status is ‘Active (insolvency proceedings)’ then “Bvd-Active (insolvency proceedings)” WF needs to be triggered.
   3. If the BVD customer status is ‘Bankruptcy’ then “Bvd-Bankruptcy” WF needs to be triggered
   4. If the BVD customer status is ‘In liquidation’ then “Bvd-In liquidation” WF needs to be triggered
   5. If the BVD customer status is ‘Dissolved’ then “Bvd-Dissolved” WF needs to be triggered
   6. If the BVD customer status is ‘Dissolved (merger or take-over)’ then “Bvd-Dissolved (merger or take-over)” WF needs to be triggered
   7. If the BVD customer status is ‘Dissolved (demerger)’ then “Bvd-Dissolved (demerger)” WF needs to be triggered
   8. If the BVD customer status is ‘Dissolved (bankruptcy)’ then “Bvd-Dissolved (bankruptcy)” WF needs to be triggered
   9. If the BVD customer status is ‘Dissolved (liquidation)’ then “Bvd-Dissolved (liquidation)” WF needs to be triggered
   10. If the BVD customer status is ‘Inactive (no precision)’ then “Bvd-Inactive (no precision)” WF needs to be triggered
   11. If the BVD customer status is ‘Status unknown’ then “Bvd-Status unknown” WF needs to be triggered
10. Customer along with contact also can be created. In this case based on above condition respective customer workflow will be triggered. During review process user/Datasteward should be able to see the customer and contact details under that customer.

B. Update Scenario:

Ingest Customer service needs to trigger customer workflow in below update scenarios (customer amendment):

1. If customer Trading Name Changed then “Trading Name Change” WF needs to be triggered.
2. If user tries to reactivate the customer i.e status change from Suspend to Active then “Suspend-To-Active” WF needs to be triggered
3. If user select Customer group type as SCPI Tax Exempted then “Customer-Group-Change” WF needs to be triggered
4. User Updates Address and if it is not Validated then “Address-Override” WF needs to be triggered
5. User Updates Customer details and found duplicates and still proceeds further with duplicate creation then “Duplicate“ WF needs to be triggered
6. User Changes Existing Tax Number then “Tax-Change“ WF needs to be triggered
7. If Customer belongs to European Country and Tax is not validated as per Vies then “VIES” WF needs to be triggered.
8. If Customer belongs to Australia Country and Tax is not validated as per ABN then “AUSTRALIA_ABN” WF needs to be triggered.
9. If Customer belongs to NEW ZEALAND Country and Tax is not validated as per New Zealand tax then “NZBN” WF needs to be triggered.
10. f Customer belongs to United Kindom Country and Tax is not validated as per UK tax then “NEW_ZEALAND_NZBN” WF needs to be triggered.

BPMN Flow Diagram:

Ingest Customer to Workflow and Portal to Workflow service:

Below is the input payload structure needs to be passed from IngestCustomer service when WF is triggered.

{
    "variables": {
        "requestType": {
            "value": "Update",
            "type": "string"
        },
        "requesterId": {
            "value": "n.n.reddy@gmail.com",
            "type": "string"
        },
        "customerCode": {
            "value": "DK00426436",
            "type": "string"
        },
        "ADSRole": {
            "value": "CMD_IBC",
            "type": "string"
        },
        "financeRole": {
            "value": "CMDFinance",
            "type": "string"
        },
        "workflowIndicator": {
            "value": "DUPLICATE|VIES",
            "type": "string"
        },
        "sourceSystemName": {
            "value": "PRTL",
            "type": "string"
        },
        "workflow_url": {
            "value": "https://<server-url>/global-mdm",
            "type": "string"
        }
    }
}

Based on Country name/code then role needs to be determined in IngestCustomer and the identified role needs to be passed.

Below table give more details on each field in the input payload.

Field Name	Description	Sample Value
requestType	This field indicates the type of request which is either Create or Update	Create or Update
requesterId	This is email id of request submitter which will be used for audit purpose.	any valid Maersk email id
customerCode	This is CMD customer code which will be used for getting complete information about customer.	IN02738845
ADSRole	This is Area Data Steward role or cluster role to which the task need to be assigned for his/her action. ADS can either approve or reject the request.	CMD Super User, CMDAccountGroupManager, CMDConcernCodeManager, CMDCustFacilityManager, CMDDataQualityAssurance, CMDGlobalBusinessAdministrator, CMDHierarchyManager, CMDOnBehalfOfRoleCMDReadOnly, CMDRegulatoryComplianceTeam, CMDSegmentationManager,CMDVipRole, CMDWebBLManager, CMDY_ADMIN, CMD_AEC, CMD_CAD, CMD_CAR, CMD_CIC, CMD_CME, CMD_CWA, CMD_EAF, CMD_EEC, CMD_EME, CMD_ESA, CMD_FRC, CMD_GBC, CMD_GCC, CMD_GEO_CTY_ROLE, CMD_GEO_CTY_ROLE_ReadOnly, CMD_HAE, CMD_IBS, CMD_IDP, CMD_MIC, CMD_NEA ,CMD_NOA, CMD_NWA, CMD_NWC, CMD_OCC, CMD_PKC, CMD_SAC, CMD_SAI, CMD_SAS, CMD_SCA, CMD_SWA, CMD_SWE, CMD_TMS, CMD_VCM, CMD_WME, CMD_WSA
financeRole	This is the role name required for finance approval.	CMDFinance
workflowIndicator	This indicates what type of workflow it is. What the reason the workflow triggered.	SUSPEND_TO_ACTIVEADDRESS_OVERRIDEADDRESS_QUALITYDUPLICATETRADING_NAME_CHANGEVIESAUSTRALIA_ABNNEW_ZEALAND_NZBNUNITED_KINGDOM_VATTAX_CHANGEACC_GRP_CHGCUSTOMER_GRP_CHANGEBVD_TRADING_NAME_CHANGEBVD_ACTIVE_INSOLVENCY_PROCEEDINGSBVD_BANKRUPTCYBVD_IN_LIQUIDATIONBVD_DISSOLVED_STATUSBVD_DISSOLVED_MERGER_OR_TAKE_OVERBVD_DISSOLVED_DEMERGERBVD_DISSOLVED_BANKRUPTCYBVD_DISSOLVED_LIQUIDATIONBVD_INACTIVE_NO_PRECISIONBVD_STATUS_UNKNOWN
sourceSystemName	This indicate what source system requested to create or update record.	PRTL
Workflow URL	Dynamically pass the current running instance URL of workflow service	https://<server-url>/global-mdm

Customer Workflow Data Steward Roles:

Below are the roles with access details.

Sl.No	Role Name	Access details
1	CMD Super User	Allows all customer edits. CDG Team need this role access.
	CMDCustFacilityManager
2	CMDDataQualityAssurance
3	CMDGlobalBusinessAdministrator
4	CMDHierarchyManager
5	CMDOnBehalfOfRole
6	CMDReadOnly
7	CMDRegulatoryComplianceTeam
8	CMDSegmentationManager
9	CMDVipRole
10	CMDWebBLManager
11	CMDY_ADMIN
12	CMD_AEC
13	CMD_CAD
14	CMD_CAR
15	CMD_CIC
16	CMD_CME
17	CMD_CWA
18	CMD_EAF
19	CMD_EEC
20	CMD_EME
21	CMD_ESA
22	CMD_FRC
23	CMD_GBC
24	CMD_GCC
25	CMD_GEO_CTY_ROLE
26	CMD_GEO_CTY_ROLE_ReadOnly
27	CMD_HAE
28	CMD_IBC
29	CMD_IDP
30	CMD_MIC
31	CMD_NEA
32	CMD_NOA
33	CMD_NWA
34	CMD_NWC
35	CMD_OCC
36	CMD_PKC
37	CMD_SAC
38	CMD_SAI
39	CMD_SAS
40	CMD_SCA
41	CMD_SWA
42	CMD_SWE
43	CMD_TMS
44	CMD_VCM
45	CMD_WME
46	CMD_WSA

Camunda Service Request Details for CMD UI:

Endpoint	Input Param	Method Type	Description
/global-mdm/customers/workflows/tasks/deployment	MultipartFile	POST	Deploy the BPMN file to Camunda moduler
/global-mdm/customers/workflows/tasks/process/start	startRequest	POST	Trigger the workflow from Ingest customer
/global-mdm/customers/workflows/tasks	groups,owner,taskId,searchApiRequest	GET	By default we will fetch list of tasks based on groups.If approver didn’t find the details he will use search and filter the tasks based searchApiRequest
/global-mdm/customers/workflows/tasks/{taskId}/{processId}	taskId and processId	GET	Retrieve the Existing customer details from ElasticSearch based on customer code and Get Current WorkflowCustomer details from customer_wf_process_detail table
/global-mdm/customers/workflows/tasks/claim	taskId,processId,userApmId,claimstatus	POST	If any approver wants to review the workflow and approve/reject first he needs to claim the task
/global-mdm/customers/workflows/tasks/comment	taskId and comment	POST	Add the comments to the task
/global-mdm/customers/workflows/tasks/complete	taskId,processId,userApmId,claimstatus	POST	approve/reject the workflow
/global-mdm/customers/workflows/tasks/process/{processId}	processId	GET	Get workflow details based on the processId
/global-mdm/customers/workflows/tasks/history/process/{processId}	processId	GET	Get full workflow history details based on processId

Deployment of Workflows

There are ways to deploy the camunda workflow (.bpm) file.

• When server gets started, it will identify the workflows from configuration file .bpmn under resources folder.
• From Camunda modeler itself can be deployed.
  • Provide the server details where the workflow (.bpmn) needs to be deployed.
    • Deployment Name : Customer_Workflow
    • REST Endpoint: https://<server-url>/engine-rest
  • Deploy from InteliJ itself
• Once deployed test the workflow by hitting the below URL from postman
  • https://<service-url>/global-mdm/engine-rest/process-definition/key/CustomerWorkflow/start

Old References : On-Premises Design/Functionality Of Customer Workflow

In current system the Customer workflow will get triggered during below create scenarios.

1. If Customer Address is not Validated then WF will get generate
2. If user tries to create duplicate Customer then WF will get generate
3. If Customer belongs to European Country and Tax is not validated as per Vies then WF will get generate.
4. If user select Customer group type as SCPI Tax Exempted while creating
5. If Customer is detected as Internal Customer then WF gets generated.

In current system the Customer workflow will get triggered during below update scenarios.

1. Trading Name Change
2. If user tries to reactivate the customer i.e status change from Suspend to Active
3. If user select Customer group type as SCPI Tax Exempted
4. User Updates Address and if it is not Validated
5. User Updates Customer details and found duplicates and still proceeds further with duplicate creation
6. User Changes Existing Tax Number or Adds Tax against EU Country for which VIES tax validation fails

Below are the different types of workflow created based on the scenarios (Create/Update) mentioned above.

1. Suspend-To-Active
2. Address-Override
3. Duplicate-Override
4. VIES-Validation-Failed
5. Trading-Name-Change
6. Tax-Change
7. Account-Group-Change
8. Customer-Group-Change (SCPI-Tax-Exempted)
9. Reactivate
10. BVD_TRADING_NAME_CHANGE - "Bvd-Trading Name Change"
11. BVD_ACTIVE_INSOLVENCY_PROCEEDINGS - "Bvd-Active (insolvency proceedings)"
12. BVD_BANKRUPTCY - "Bvd-Bankruptcy"
13. BVD_IN_LIQUIDATION - "Bvd-In liquidation"
14. BVD_DISSOLVED_STATUS - "Bvd-Dissolved"
15. BVD_DISSOLVED_MERGER_OR_TAKE_OVER - "Bvd-Dissolved (merger or take-over)"
16. BVD_DISSOLVED_DEMERGER - "Bvd-Dissolved (demerger)"
17. BVD_DISSOLVED_BANKRUPTCY - "Bvd-Dissolved (bankruptcy)"
18. BVD_DISSOLVED_LIQUIDATION - "Bvd-Dissolved (liquidation)"
19. BVD_INACTIVE_NO_PRECISION - "Bvd-Inactive (no precision)"
20. BVD_STATUS_UNKNOWN - "Bvd-Status unknown"

Below is the existing contact workflow functionality.

This will be triggered when user create new customer along with Contact.

This workflow will keep on checking for Customer record whether it is approved or rejected.

• If customer record rejected then Contact record deleted.
• If customer record approved then contact will get activated and it will be published

The below query is used to get the role which will be passed to workflow when triggering from UpsertCustomer service.

1. To get the respective role based on Country. This MDM_ROLE will be retrieved by upsertCustomer service and passed to AVOS. WITH COUNTRY_CODE_DETAILS AS ( SELECT DISTINCT CNTRY_NM.ROWID_OBJECT COUNTRY_MDM_ID, CNTRY_NM.NAME COUNTRY_NAME, CNTRY_CODE.CODE COUNTRY_CODE FROM C_ALT_CODE CNTRY_CODE, C_GDA_DFND_AREA CNTRY_NM WHERE CNTRY_CODE.GDA_DFND_AREA_ROWID = CNTRY_NM.ROWID_OBJECT AND CNTRY_NM.TYP_TYPE_CD = 'GDA.COUNTRY' AND CNTRY_NM.ACTIVE_FLAG = 'Y' AND CNTRY_CODE.TYP_TYPE_ROWID = ( SELECT ROWID_OBJECT FROM C_TYP_TYPE WHERE CODE = 'ALT_CODE.RKST' ) AND ( CNTRY_CODE.CODE = ? ) ) SELECT COUNTRY_CODE_DETAILS.COUNTRY_CODE, C_ALT_CODE.CODE CLUSTER_CODE, CLUSTER_NAME.NAME CLUSTER_NAME, CONCAT('CMD_', C_ALT_CODE.CODE) MDM_ROLE FROM COUNTRY_CODE_DETAILS INNER JOIN C_GDA_DFND_AREA_REL ON C_GDA_DFND_AREA_REL.GDA_DFND_AREA_CHLD_ROWID = COUNTRY_CODE_DETAILS.COUNTRY_MDM_ID INNER JOIN C_GDA_DFND_AREA CLUSTER_NAME ON C_GDA_DFND_AREA_REL.GDA_DFND_AREA_PRNT_ROWID = CLUSTER_NAME.ROWID_OBJECT INNER JOIN C_GDA_BDA CLUSTER_INFO ON CLUSTER_INFO.GDA_DFND_AREA_ROWID = CLUSTER_NAME.ROWID_OBJECT INNER JOIN C_ALT_CODE ON C_ALT_CODE.GDA_DFND_AREA_ROWID = CLUSTER_NAME.ROWID_OBJECT WHERE C_GDA_DFND_AREA_REL.HUB_STATE_IND = 1 AND CLUSTER_NAME.ACTIVE_FLAG = 'Y' AND CLUSTER_INFO.BDA_TYPE_CD = 'CLUSTER' AND C_ALT_CODE.TYP_TYPE_ROWID = ( SELECT ROWID_OBJECT FROM C_TYP_TYPE WHERE CODE = 'ALT_CODE.BDACODE' )