Overview of the Customer Ingest API
smds-cmd-ingest-customer-service
Ingest customer
A service for the creation/updation of customers with various parameters.
Portal Flow
Search if customer name exists -> BVD search -> Start creation process -> choose Address from Azure Maps -> Tax + M&A (Business Details) -> Internal customer? ->BE code -> recheck details -> submit
customerRequest Payload
| Field Name | Value Type | Required |
|---|---|---|
| customerAuditData | Object | Yes |
| customerCode | String | |
| tradingName | String | Yes |
| legalName | String | |
| customerLocalName | String | |
| customerType | String | |
| customerGroupType | String | |
| customerExternalSystemIdentifiers | Object | Yes |
| customerStatus | Object | |
| url | String | |
| communicationNumber | Object | |
| invoiceISOLanguageCodePreference | String | |
| isBrokerage | Boolean | |
| isForwardersCompensation | Boolean | |
| customerWorkflowIndicator | String | |
| isSoleProprietor | Boolean | |
| customerAddress | Object | Yes |
| isWorkflowPending | Boolean | |
| workflowInformation | String | |
| customerIdentifiers | Object | |
| customerWebBillLadings | Object | |
| customerBrands | Object | |
| customerEnrichedInformation | Object | |
| bvdRelationships | Object |
Customer Request payload
customer_information table (Write DB - Postgres)
| Field | Value |
|---|---|
| Customer Cmd Code | IN03812088 |
| Customer Role Type | Customer |
| Legal Name | |
| Trading Name | NEW COMPANY FOR TRIAL |
| Customer Group Type | S |
| Customer Status Code | ZEXC |
| Account Group Type | |
| Customer Website | https://www.maersk.com |
| Email Address | |
| Invoice Language Code | EN |
| BROK | N |
| FOFMC | N |
| Is Sole Proprietor | N |
| VIP Non Roll | |
| Street No | AVE 1 |
| Address Line 1 | JJHHJH |
| P.O. Box | PO 123 |
| Address Line 2 | 7TH D BUILDING |
| Address Line 3 | RAMWADI |
| District | RAMWADI |
| City | PUNE |
| City Code | |
| Postal Code | 411014 |
| State Code | MH |
| State Name | MAHARASHTRA |
| Country Code | IN |
| Country Name | INDIA |
| Latitude | 18.5518236 |
| Longitude | 73.9592893 |
| Phone Type | TEL |
| ISD Country Code | IN |
| ISD Dialing Code | 91 |
| Extension Number | |
| Phone Number | 9045638121 |
| Is Pending | Y |
| Is Deleted | N |
| Create Time | 2025-01-27 09:25:21.813+00 |
| Create User | shreya.shree.s@maersk.com |
| Update Time | 2025-01-27 09:25:45.435+00 |
| Update User | xyz@crb.apmoller.net |
| Source of Last Update | PRTL |
| Interaction ID | |
| Source of Create |
The newly add fields are enriched as the program is running through various functions and 3rd party calls using the customerState.
Data Model
The final data, from each of these tables, is sent to the Read DB (ElasticSearch) and published to EMP Retina (Kafka)
API endpoints:
- CREATION of customer
- VALIDATION of customer payload
_________________________________________________________________________________
Customer Ingestion- Creation of a new customer
-
Data Validation
-
Processing
-
Save to Write DB And sync to Read DB and publish to Kafka
-
Validation The validation process is initiated via
- a POST request to /validate-customer (through Validate customer controller) or
- called at the time of customer creation
The customer payload that needs to be validated, follows these steps:
- The customer code field is checked if empty. (indication if it is to validate create or update customer records)
- If not empty, checks if the customer code in workflow
- If empty, starts with the following validations
- Country Validation
- checks if country code part of the country database
- Source system
- checks against reference data if a valid source system is entered
- External System Identifiers Validation
- Validate external identifier code against reference data
- whether BE is already taken
- Format Validation for Core Customer Attributes
- Region Validation
- City Validation
- Custom Rules Validation
- Customer Code
- Website
- Customer Address Rules
- Status Reason Rules
- Country Validation
- Language Code: Validate against country-specific accepted language codes reference data.
- Workflow Rules: Check the workflow indicator attribute against accepted values
- Source System Rules:
- Customer creation from BVD source is restricted.
- Telecommunication Validation
- Format check
- Country check
- External API: Informatica.
- Customer Identifiers Validation (TAX – PAN/GST)
- Customer Brands Validation (M&A)
- SCPI Source-Based Validation
- Primary email is mandatory for SCPI customer creation
- Processing
- Checks for customer duplicacy
- Check for any ignored states (restricted country RU)
- Check customer code is empty
- If Not, enrich data from DB
- If yes, check if customer in workflow
- If customer in workflow, and it’s a create scenario, update the latest date for updation or creation and save to DB.
- Validate SCPI (email should be present)
- Validate workflow details
- If customer not in workflow, persist customer data to DB
- If customer in workflow, and it’s a create scenario, update the latest date for updation or creation and save to DB.
- Insert the data into customer BVD sync Tracker for newly created customer code.
- Call for any existing customer code in BVD tracker DB
- If existing customer code, Update Bvd sync tracker records and Bvd Id
- Else, add Bvd sync tracker records
- Save and Flush to BVD Sync tracker DB
- Call for any existing customer code in BVD tracker DB
- Check for any validation errors while persisting
- Sync and Publish to Write DB(Elastic Search) and EMP Retina
- Check if customer in workflow
- In workflow, return cannot edit/create customer in workflow
- Else Return Record
<customerCode >created successfully
Other Endpoints
- Create or Update customer relationship PATCH http://localhost:8080/global-mdm/customers/{customerCode}/relationships
o Add parent child relationships between customers
o Request Body customerAuditData and customerRelationships field
- Identify Internal Customer
POST http://localhost:8080/global-mdm/customers/customer-types-queries
o To identify whether customer is internal or not
o Needs a request Body customerTaxIdentifiers fields (identifierCode, identifierValue, isoCountryCode)
- Validate country Ruleset GET http://localhost:8080/global-mdm/customers/rule-sets/{rulesetId}
o To validate country ruleset for a particular country
o Request path needs rule set ID
- Validate Customer Identifier POST http://localhost:8080/global-mdm/customers/validate-identifiers
o To validate customer identifiers based on country rules or VIES(for European countries)
o Request body requires customerIdentifierValidationData fields(identifierCode, identifierValue, isoCountryCode)
o Returns IN1234 : Valid XY76765 : Invalid
- Update Customer PUT http://localhost:8080/global-mdm/customers/{customerCode}
o For Ingest Customer - Updation
o Request Path requires customer code and a request body with the whole customer payload
- Update Customer Status PATCH http://localhost:8080/global-mdm/customers/{customerCode}/update-status
o API to Update Customer Status
o Request Path needs customer code and Request body with customerAuditData, customerStatus("statusCode", "customerStatusReasons"), and action ("SUSPEND-TO-ACTIVE")
- Synchronise Customers POST http://localhost:8080/global-mdm/customers/synchronize
o Request body needs customer code
o Real time auto sync customer of customer data to the Read db (elastic search from Write DB - Post gres)
Customer Creation Flow
Customer Validation Flow
Update customer Flow
Update customer status
Validate Customer icentifier
Fetch Country Ruleset Flow
Create or Update Customer Relationships Flow
Identify Internal Customer Flow
Sync Customer Flow