Customer Ingest facility

Facility

In CMD context Customer facility is a location where the shipping materials will be stored.
In simple words, facility is customer’s another address.
It allows to tell the container from where to pick and deliver.
In CMD, we work with Customer facility though we have other facilities also.

We have 3 types of Facilities: -

Customer Facility

Operational Facility

Commercial Facility- offices, sales, marketing

So, validating postal code is very necessary and be very sure with the address since it is meant for delivery purpose.
In facility, if we select city, region is automatically selected.
One facility can have N no of customers, and one customer can link to N no of facilities.

Facilities have 2 states: -

Active state

Inactive state

# MANDATORY FIELDS

FIELDS	MANDATORY
Customer Facility Name	✅
Either Street Name or P.O. Box	✅
Country Name	✅
City Name	✅
Postal Code	Depends on Country Generic rule
Street Number	Depends on Country Generic rule
Region/ State	Depends on Country Generic rule

Starting with the code

For ingest facility, we have the payload as follows: -

Validations: -

While creating facility, before proceeding with creation we first of all go with the validation part. In order to save the time during validations we are using CompletabeFuture method.
A CompletableFuture in Java is a powerful tool for handling asynchronous programming. It represents a future result of a computation that might not be completed yet, but will eventually be available.
In this case, validations might involve tasks that can run in parallel, such as database queries, external service calls, or complex checks. Using CompletableFuture allows these validations to be performed asynchronously, improving performance and responsiveness.
We have various validations here like: -

Facility status Check
Restricted Country Check
Source system Check
External System Identifiers Check
Country name and country code Check
Restricted Country Update
City Reference Check
Get all County Ruleset
Validate city and region details

10. Validate street Number

11. Mandatory check for StreetName or P.O. Box

12. Validate Postal Code

Creation: -

After performing the validations, the facility creation process follows these steps:

· Start Time Noted: The process begins by recording the start time for tracking the time it takes to create the facility.

· Create and Persist Facility:

o The facility object is created using the validated data.

o The facility is then saved to the database using the save() method. flush() is used immediately to ensure that the data is written to the database, committing the changes.

· Return Facility Code and Status:

o After the facility is saved, the facility code and status are assigned and returned to the user or system.

· Error Handling:

o If there is an error during the creation or persistence step (e.g., database issues, constraint violations), an error response is returned.

TrackDuplicateFacilityRecord: -

· Duplicate Check:

The process checks if a duplicate facility exists based on the facility code and other details.
If duplicate is found, it will be returned and processed.
If no duplicate is found, an empty response is returned.

· Store in DB:

If a duplicate facility is found, store the information in the database.

· Set Workflow Indicator:

If a duplicate is found, set the workflow to pending and set the indicator to DUPLICATE.
If no duplicate is found, set the workflow indicator to NULL.

· Handle Workflow Indicator:

If the workflow indicator is DUPLICATE and the facility code is empty, a new duplicate tracker record is created and saved.
If the workflow indicator is DUPLICATE and the facility code exists, update the existing duplicate tracker.
If the workflow indicator is NULL and the facility code exists, update the existing facility record.

SyncandPublishCustomerService: -

The Sync and Publish Customer Service process is the final stage in facility creation. It involves syncing data with ElasticSearch and publishing the facility details to an external API. Below are the key steps:

Sync Facility to Elastic:

o Check Facility Code: If the facility code is empty, return an error.

o Update Facility History:

Compare previous and current data.
If differences exist, set hasHistoryEvent = true and save the updated data.
If no differences, skip history updates.

o ElasticSearch Operations:

Initialize the sync request.
Iterate through the facility code to retrieve facilityJSON.
If JSON data exists, index the document in ElasticSearch.
If successful, update the sync status; otherwise, return an error.

Publish Facility to External API:

o Create and initialize a ProducerResponse.

o Call the publishCustomerFacility method to send the request to the external API.

o Return the result for the published data or null if an error occurs.

Final Response:

o Return the status of the sync and publish operations, including any errors or successes.

Table Name	Primary Key	Foreign Key	Reference Table
facility_information	facility_cmd_code	· source_of_create· source_of_last_update	· ref_source_system· ref_source_system
facility_history_details	row_id	· facility_cmd_code· source_of_create· source_of_last_update	· facility_information· ref_source_system· ref_source_system
facility_external_identifiers	row_id	· external_source_system· facility_cmd_code· source_of_create· source_of_last_update	· ref_alternate_codes· facility_information· ref_source_system· ref_source_system
facility_address	row_id	· facility_cmd_code· source_of_create· source_of_last_update	· facility_information· ref_source_system· ref_source_system
facility_customer_rel	row_id	· customer_cmd_code· rel_type_code· facility_cmd_code· source_of_create· source_of_last_update	· customer_information· ref_relationship_types· facility_information· ref_source_system· ref_source_system

Detailed Flowcharts

Was this page helpful?