Learning Objective
By the end of this module, participants will be able to:
Understand and configure the enrollment file transformation and validation process.
Identify and set up the necessary components, including FTP locations, archive paths, and database configurations.
Manage and troubleshoot the transformation and validation workflows.
Utilize custom plugins for data handling and formatting within the enrollment process.
Use Case: Convert Customer/Vendor Enrollment Files to Specific ADI Format
Description: The process aims to convert customer or vendor-specific enrollment files into specific ADI standard format (eEnroll2 Template). Each employee record in the enrollment source file, which comes in multiple lines for each benefit within a single policy, needs to be transformed into a single record per employee per policy.
Actors:
Client: The entity providing the enrollment files.
System: The automated process that handles file transformation and validation.
End User: The administrator managing the process and handling notifications.
Pre-conditions:
The client file is available in the input FTP location.
The system is configured with the correct source and target file paths.
Required plugins and process flows are deployed and functional.
Post conditions:
The client file is archived.
A standard XML file is created in the in-progress folder.
The original client file is deleted from the input FTP location.
An entry file named
CLIENT_FILE_RECEIVEDis created.
PF_Enrollment_Inbound Process Flow
The PF_Enrollment_Inbound process flow facilitates the conversion of client-specific enrollment files into a standardized canonical format. This standardized format, typically XML, enables seamless integration and processing within User's systems.
Process Steps:
Data Retrieval:
The process initiates by fetching the client-specific enrollment file from a designated FTP location, identified based on a specified file pattern.
Archiving Original File:
Upon retrieval, the original client file is copied to an archive folder. This archival step ensures a backup for future reference or auditing purposes.
Format Conversion:
The retrieved client file undergoes conversion into a standard XML format. This transformation prepares the data for further processing and integration.
Temporary Storage:
The newly formatted XML file is stored in an in-progress folder. This temporary storage facilitates subsequent processing steps without disrupting ongoing operations.
File Handling After Successful Conversion:
Post successful execution of the conversion process, the original client file is deleted from its original location on the FTP server. This helps maintain data cleanliness and prevents redundancy.
Metadata Creation:
An additional step involves the creation of an entry file named CLIENT_FILE_RECEIVED in JSON format. This file contains metadata such as the original file's name, its path, and the timestamp indicating when the file was received. This metadata aids in tracking and managing file-processing activities.
PF_Enrollment_Data_Validation Process
The PF_Enrollment_Data_Validation process flow is designed to validate a Standard Layout file, categorize records as either good or erroneous, and deliver all validated records to a designated output FTP location. Additionally, it includes functionalities to generate data discrepancy reports and send email notifications in case of validation failures.
Process Steps:
File Pickup and Validation:
The process initiates upon detecting a canonical XML file in the designated FTP location.
It picks up the file and proceeds to validate its content against predefined data integrity rules and formatting standards.
Record Categorization:
Upon validation, records within the XML file are categorized into two main groups:
Good Records: Records that pass validation and conform to specified standards.
Error Records: Records that fail validation due to discrepancies or errors.
Output Generation:
The validated and categorized records are processed to generate a final output file in a specified format.
The output file is then delivered to the configured output FTP location as per the user-defined filename pattern.
Reporting and Notifications:
In cases where validation fails for any records, the system generates detailed data discrepancy reports.
Email notifications are sent to designated recipients to alert them of validation failures and provide necessary details for corrective actions.
Key Components:
FTP Event Trigger: This process flow is triggered by the detection of the canonical XML file in the FTP location, ensuring timely initiation and processing of data validation tasks.
Template Management: The process includes the capability to manage templates associated with the output file format, ensuring consistency and compliance with organizational standards.
User Configuration: Users can configure the output FTP location and define the filename pattern for the generated output file through a dedicated transaction interface, facilitating flexibility and customization based on operational requirements.
Customs Plugin Details: CP_ExcelColumnName_Handler
The CP_ExcelColumnName_Handler Customs Plugin serves the purpose of standardizing Excel column names by removing numerical suffixes such as "_Numbering (_1, _2, _3)" from the column names.
Functionality: This plugin is specifically designed to transform column names in Excel files, ensuring consistency and clarity in data representation. For instance, it seamlessly converts column names like "BenefitID_1" and "BenefitID_2" to "BenefitID" by eliminating numerical suffixes.