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.

Note: You can execute each File Request Processing (C1-FREQP) batch only for a single File Request Type.

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

  • Error is logged in the CI_​FILE_​REQUEST_​DTL_​MSG table against the specific request.

  • Status is updated in the CI_​FILE_​REQUEST_​DETAIL table with an Error flag.
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.

  • Status is updated with an Error flag.

  • The error details are logged in CI_​FILE_​REQUEST_​DTL_​MSG table against the <Request_​ID> parameter.
If the pre-processing algorithm is configured for the service then invoke the pre-processing algorithm.

  • If the SKIP flag is set to TRUE, then the service is skipped from further execution.

  • The service status is updated as SKIPPED in the CI_​FILE_​REQUEST_​DTL_​SERVICE table.
If the validation fails while parsing the xml payload

  • Error is logged in the CI_​FILE_​REQUEST_​DTL_​MSG table against the specific request.

  • The status for the request is updated as ERROR in the CI_​FILE_​REQUEST_​DETAIL table.

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

  • Error is logged in the CI_​FILE_​REQUEST_​DTL_​MSG table against the specific request.

  • Status for this request in the CI_​FILE_​REQUEST_​DETAIL table is as follows,

    • If there is an error that is configured for RETRY status in this specific request for the corresponding file request type, the status is updated as RETRY.

    • If there is an error that is configured for SENT FOR APPROVAL status in this specific request for the corresponding file request type, the status is updated as SFAL.

    • If none of the above conditions are satisfied, the status is updated as Error.

  • No other remaining services are executed for this particular file request type.

  • A rollback operation is performed for every other service that was executed before processing this request.
If the service execution is successful for the payload

  • A record is created for the service in the CI_​FILE_​REQUEST_​DTL_​SERVICE table.

  • Primary key values will be stamped only if the service has the configuration of the corresponding foreign key (<FOREIGN_​KEY_​REF>) in the request type (REQUEST_​TYPE), against this service.

  • The primary key value(s) with its corresponding foreign key is used in the file request dashboard for a 360 degree view.

  • The status of each configured service is based on the following conditions,

    • If the status flag of the business object is configured as TRUE for the service, then the status of the service is set as INPROGRESS.

    • If the service is skipped, the status is set as SKIPPED.

    • If the service fails with an error, that is configured as SENT FOR APPROVAL status in this request for the corresponding file request type, the status of the service is SFAL.

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.

Note:

  • 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.

A common API is further exposed to update the service (<SERVICE>) status that is either in INPROGRESS or SFAL status. Once the respective service lifecycle or workflow is completed, this common API updates the status with the available final status. Following are the various types of finally available statuses,
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
Note: Child-parent relationship is also supported in the XML payloads. For two different configured services (<SERVICE>) in a single file request type (<FILE_​REQUEST_​TYPE>), an XML payload can be provided with parent-child relationship. This can be achieved by Dependent Service Name attribute value.

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>
The use of child-parent relationship in an XML payload, provides the following advantages,

  • 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.

Note: The foreign key reference attribute value is required against the Dependent Schema Name. Ideally, you must specify the foreign key reference attribute for the <C1_​PERSON_​BO>, as shown in the above example.
There might be some scenarios where the Dependent Service Name attribute is not provided, then the XML payload appears as follows,
<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.

  • @SHARED_​DIR is the configured path of the shared directory.

  • @INSTALL_​DIR is the configured path of the installation directory with a property named spl.runtime.environ.SPLEBASE within the spl.properties file.

 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,

  • If the filename isCUST% then the filename that ends with CUST must be considered.

  • If the filename is%CUST then the filename that starts with CUST must be considered.

  • If the filename is%CUST% then the filename that contains CUST must be considered.

 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
Note: If the File Request Processing (C1-FREQP) batch fails or aborts due to some reason, you can restart the batch over and over again with the same set of parameters.

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.

Note: If there is any change in the <REQUEST_​TYPE> configuration then it can be replicated either by restarting the thread pool or executing the Flush All Caches (F1-Flush) batch.