When the team receives two files, they will update the procedures for checking and validating the data. In addition, they will implement a new process to connect to Sunlife’s system, allowing them to acquire a unique identifier (comparable to a tracking number). Moreover, they will merge individual reports into a unified document and improve the comprehensibility of error reports.
Trading Partner Flow
A file is placed in a designated location. The process flow retrieves this file and checks for the presence of a corresponding client file in the same location.
If the client file is found, the process creates a JSON trigger file in a specified location and relocates the two source files to the same location as the trigger file.
If the client file is not found, the process flow terminates.
SL_PF_InboundFile_TradingPartner_v2
Client Flow
A file is placed in a designated location. The process flow retrieves this file and checks for the presence of a corresponding trading partner file in the same location.
If the trading partner file is found, the process creates a JSON trigger file in a specified location and also relocates the two source files to the same location as the trigger file.
If the trading partner file is not found, the process flow terminates.
SL_PF_InboundFile_Client_v2
Merge Flow
SL_PF_Outbound_MergeFlow_v2
Once a trigger file is created in the specified location, the merge process flow is activated.
The process first selects the trading partner file.
The data from the trading partner file is converted into a standard file format.
Validation rules are applied to the standardized file format.
Two data streams are generated from the validation process: one for valid records and another for erroneous records.
Validations are performed at the record level for error records, focusing on errors and warning fields.
Validations are conducted at both the record and field levels for valid records.
Two output files are generated—one containing valid records and another containing erroneous records. The details of these files are also stored in the database.
The process then selects the client file.
The data from the client file is converted into a standard file format.
Validation rules are applied to the standardized file format.
Two data streams are generated from the validation process: one for valid records and another for erroneous records.
Validations are performed at the record level for error records, focusing on errors and warning fields.
Validations are conducted at both the record and field levels for valid records.
Two output files are generated—one containing valid records and another containing erroneous records. The details of these files are also stored in the database.
Following this, a mapping process checks the pass percentage for valid records. This percentage must exceed the threshold defined in the transaction parameters.
If the percentage check is successful, both valid record files are forwarded to the merge mapping process.
The merge mapping generates three streams: a merged file, orphaned trading partner records, and orphaned client records.
A subsequent merge mapping consolidates orphaned records into a single file, including a descriptive file name.
An email notification is sent containing the erroneous records, the merged file, and the orphaned file.
Finally, all files are placed in the designated target location.
Solution Design:
Source File_Trigger.txt from FTP Location. With this source, the flow would be triggered and also further in the flow second source is also attached which picks the file from the trading partner file location.
Map values from File Trigger to Context.
Locates Trading_Partner File on the FTP Server.
Converting the Trending Partner file data to a standard file format. After it we move with Validation mapping.
Once the values are mapped to the context, we validate good and bad data in the Trading_Partner File via Mapping. Maps Trading_Partner file data to a standard file
In this validation mapping, we are generating Good records & Bad records along with errors & warnings for the Trading_Partner File.
In the Error Layout, we are generating Errors and Warnings as well.
Error Conditions |
---|
Warning Conditions |
---|
Locates Client File on the FTP Server.
In this validation mapping, we are generating Good records & Bad records along with errors & warnings for the Client File. In the errors & warnings, we get the details of the Bad Records i.e what is wrong in the Bad Records.
In the Error Layout, we are generating Errors and Warnings as well.
Error Condition |
---|
Warning Conditions |
---|
After the validation, Good Records are directly to Pass Percentage Mapping, and Bad Records are inserted into the Database.
Pass Percentage Mapping:
Pass Percentage Condtion |
---|
|
The Condition states: It checks whether the passing percentages for the trading partner and the client are greater than or equal to a configured minimum passing percentage. Here's a breakdown in simpler terms:
Trading Partner Pass Percentage (
$varTradingPartnerPassPercent
): This is the percentage of files or data from the trading partner that passed validation.Client Pass Percentage (
$varClientPassPercent
): This is the percentage of files or data from the client that passed validation.Configured Merge Pass Percentage (
$varConfiguredMergePassPercent
): This is the minimum passing percentage required for the merge process to proceed.This condition checks if the trading partner and the client have passed enough files/data to meet a required threshold. If they have, the result is
'true'
; if not, it's'false'
.
Once the Pass Percentage Conditions are met the flow moves forward with the merging of both the Trading Partner File & Client File data. Also, Orphan records are generated for both the Trading Partner File & Client File. For Example: Suppose If “SSN=1” on the source side it will check if “SSN=1” records exist in Trading Partner Records or Client Records. If the records exist in the Trading Partner file only then it will be an orphan record for the Trading Partner.
Orphan Records will be for only mandatory records not for all.
In the Merge Mapping at the destination side at the root level variables are defined.
Name: varSuccessRecordCount
Value: get-context( 'MergedRecordCount', '0')
Description: This condition is checking to see how many records have been merged. If there are no merged records found, it assumes the count is zero.Name: varOrphanedClientRecordCount
Value: get-context( 'OrphanedClientRecordCount', '0')
Description: This condition checks how many orphaned records there are for a client. If no orphaned records are found, it assumes the count is zero.Name: varOrphanedTradingPartnerRecordCount
Value: get-context( 'OrphanedTradingPartnerRecordCount', '0')
Description: This condition checks for how many orphaned records there are for a trading partner. If none are found, it assumes there are zero orphaned records.
After merged records are updated they are stored at the FTP location & Also an Email Notification will be shared.
If the Pass Percentage Conditions are not met it moves ahead with another flow which sends the Email Notification to the configured email ID stating to re-process the files.
Once the Good Records are merged and stored at an FTP Location, the Client doesn’t want two separate files for Orphan Records. They require merged records with File Descriptions.
On the destination side at the root level, two child records are created Record & Record1
Once the Orphan Records are merged we pass them through the layout and keep it on the FTP Location.
In the Flow, all the records are generated Merged Records & Orphan Records are processed and updated in the Database. Also, Cleanups are initiated which performs cleanup for the Trading Partner File & Client File from the In-progress Folder.
Once all the processes are performed at the end final Email Notification is shared.