Processing a File Request
The File Request Processing (C1-FREQP) batch is used to process the uploaded legacy file records in the staging table. By default the records with PENDING and RETRY status are processed.
The C1-FREQP batch retrieves all the records with PENDING and RETRY status, against the File Request Type that is provided in the batch. In the case for the records with RETRY status, only those records are processed where the RETRY count is either less than or equal to the configured RETRY count, against its corresponding REQUEST TYPE. Before processing any of the file request, the C1-FREQP batch validates the following,
-
In case the Error Log File Path is incorrect
-
The C1-FREQP batch is terminated with the ERROR status.
-
Thread iteration strategy is being used for C1-FREQP batch. A list of ThreadWorkUnits is created on the number of available requests that are present with PENDING and RETRY status for the priority that is provided in the CI_FILE_REQUEST_DETAIL table. Each request is processed for all of the configured services against its corresponding file request type (<File_Request_Type>).
Following steps are performed before processing the file request,
If... | Then... |
---|---|
If the file request type does not exist |
|
If the validate request payload flag is true, and the xml payload for every individual service that is configured in the corresponding <File_Request_Type> is not provided. |
|
If the pre-processing algorithm is configured for the service then invoke the pre-processing algorithm. |
|
If the validation fails while parsing the xml payload |
|
The service used in executing the C1-FREQP batch will be executed using the corresponding payload.
If... | Then... |
---|---|
If there is a failure while executing the service |
|
If the service execution is successful for the payload |
|
Once the request is successfully executed with all of its available services for that specific file request type, the status for that request is updated as PROCESSED.
-
The service name is always the root element of its respective XML payload.
-
The services are executed in a sequence with respect to the given sequence number (<SEQ_NUM>) for each service.
-
The <version> element should not be used in any of the payloads.
-
The system would not handle any Java Exceptions or Unknown Errors.
If... | Then... |
---|---|
Execution is successful | Status is set as PROCESSED |
Execution is cancelled | Status is set as CANCELLED |
Execution is Rejected | Status is set as REJECTED |
Following is the XML payload for a person-account relationship.
<root>
<request>
<payload>
<C1_PERSON_BO>
<personOrBusiness>PersonName</personOrBusiness>
<division>CA</division>
<personName>
<nameType>PRIM</nameType>
<entityName>Rudolph1,Jack2</entityName>
<isPrimaryName>true</isPrimaryName>
</personName>
<C1-AccountBO>
<setupDate>2001-01-01</setupDate>
<division>CA</divison>
<accountnumber>
<isPrimaryId>true</isPrimaryId>
<accountidentifierType>C1_F_ANO</accountidentifierType>
<accountNumber>NewAcc2</accountNumber>
</accountnumber>
<accountPerson>
<accountRelationshipType>MAIN</accountRelationshipType>
<isFinanciallyResponsible>true</isFinanciallyResponsible>
<isMainCustomer>true</isMainCustomer>
</accountPerson>
</C1-AccountBO>
</C1_PERSON_BO>
</payload>
</request>
</root>
-
There is no need to provide any reference of a person (<PERSON>) in the account (<ACCOUNT>) i.e. for <accountPerson> relationship, as the system handles this child-parent condition internally.
-
There is no need to have a separate query to fetch the primary key of the parent to map the child in the payload.
<root>
<request>
<payload>
<C1_PERSON_BO>
<personOrBusiness>PersonName</personOrBusiness>
<division>CA</division>
<personName>
<nameType>PRIM</nameType>
<entityName>Rudolph11,Jack22</entityName>
<isPrimaryName>true</isPrimaryName>
</personName>
</C1_PERSON_BO>
</payload>
<payload>
<C1-AccountBO>
<setupDate>2001-01-01</setupDate>
<division>CA</divison>
<accountnumber>
<isPrimaryId>true</isPrimaryId>
<accountidentifierType>C1_F_ANO</accountidentifierType>
<accountNumber>NewAcc2</accountNumber>
</accountnumber>
<accountPerson>
<accountRelationshipType>MAIN</accountRelationshipType>
<isFinanciallyResponsible>true</isFinanciallyResponsible>
<isMainCustomer>true</isMainCustomer>
</accountPerson>
</C1-AccountBO>
</payload>
</request>
</root>
The XML payload mentioned above resembles a multi-threaded batch. It is based on the number of requests that consists of PENDING and RETRY status available in the staging table, CI_FILE_REQUEST_DETAIL, for the supplied PRIORITY. You can specify the following parameters while executing the above multi-threaded batch.
Parameter Name | Description | Mandatory (Yes or No) |
---|---|---|
File Request Type | Used to specify the records with the File Request Type that have the status as either PENDING or RETRY are fetched for processing. | Yes |
Error Log File Path | Used to specify the CSV file (along with the error logs)
that are stored at a provided relative path. This path will always
start with either @SHARED_DIR or @INSTALL_DIR.
|
Yes |
File Request Status | Used to specify the records for the File Request Type that accept input statuses like PEN or RET. | No |
File Name | Used to specify the name of the file (for example CustomerOnboard).
If this value is left blank then all the files with the file request
type having a corresponding file extension are picked from the given
file path. The File Name parameter also supports
inclusion of the partial value,
|
No |
File Request Upload Date | Used to specify the upload date (in YYYY-MM-DD format) that is considered for processing the file request type. | No |
Override Maximum Errors | Used to specify the value to override the maximum number of errors that are allowed before the execution is terminated. | No |
Thread Pool Name | Used to specify the thread pool name on which you want to execute the batch. | No |
Post Execution Check / Clean Up:
Once the batch is successfully completed, the file details are inserted with COMPLETE status and the file request details with PENDING status.