Purpose

This function enables the request for and processing of results from a batch CHESSN Allocation Request

Specifically, this function will:

• Identify outstanding results
  

  Before sending a results request to HEIMS, all requests with outstanding results must be identified. This includes:

  • Successful Requests where results have not been requested
  • Successful Requests where results have been requested but were not ready but now could be
  • Failed Batch CHESSN Allocation Results processes
    If a Batch CHESSN Allocation Results job aborts, no CHESSNs will be committed. Therefore when a new Batch CHESSN Allocation Results process is triggered a check must be done for previous failures or aborts of this job.
    The check will be against the Results Request Job Run ID in the HEIMS Request entity, for requests with a status of Process. If the identified job’s job scheduler status is ABORT or FAILED, the CHESSN Allocation Request must be included in the new Batch CHESSN Allocation Results process.

• Request Results From HEIMS

  A request is sent to HEIMS containing the Request ID of the batch CHESSN allocation request. The request consists of a RequestControlTable only. The function will select and process one Request ID per results request transfer. From the list of outstanding Request ID, the lowest will be processed first.

  The process will request results for any outstanding HEIMS requests, based on the status of the request (i.e. where the status of the request is Process).

  When a results request is performed, the request’s Results Request Job Run ID will be populated with the Job Run ID for the job processing the results request.

  When sending a request for results for another Request ID, the password must be rechecked.

• Receive Results From HEIMS

  The batch CHESSN allocation request will be identified within HEIMS from the Request ID within the RequestControlTable.
  Dependant on the processing status of the batch request, HEIMS will respond with an AllocateChessnBatchResponse including either:
  o A ResponseControlTable identifying the processed batch and its status, and a set of AllocateChessnOut records containing the CHESSN allocation results, or:

  • A Response Control Table only identifying the status of the request.

  Statuses in the ResponseControlTable include:

  • FAILURE: The Request ID given does not match an existing request – Message Code = 7
  • FAILURE: Invalid ClientOrganisationCode provided – Message Code = 12
  • FAILURE: Access to send or view results for the ClientOrganisationCode provided is denied – Message Code = 11
  • FAILURE: An existing Request ID was provided, but the Request ID was not for a batch AllocateStudentChessn method – Message Code = 10
  • PROCESS: Processing for this request has not finished – Message Code = 1 – 6 (The Results Request Job Run ID should be set to Null if the results being requested are still processing.)
  • ARCHIVE: The results for this request have been archived – Message Code = 9 (CHESSN allocation request results will only be kept for 30 days within HEIMS. After this they will be archived and any call to retrieve the results will return no results.) If Archived is returned a new request for the same transaction records should be initiated.
  • SUCCESS: Processing has completed and results returned – Message Code = None. When the results are returned the HEIMS Request Status must be updated to Success.

  When the ResponseControlTable is returned by HEIMS, the HEIMS Request record must be updated to reflect the latest HEIMS Results Status (i.e. Failure, Success, Process). The ResponseControlTable returned, after a results request, will contain a set of messages. These messages must be saved in the HEIMS Request Messages entity for the corresponding Request.

  When a Batch Request fails to process within HEIMS in a reasonable time HEIMS will fail the request. The Request Status returned to the HEP will be Failure when a Batch Results request is sent. The job will then be failed and no CHESSNs updated.

• Validates the Results obtained from HEIMS

  Once the results have been received from HEIMS they will need to be validated. Validations include:

  • The CHESSN must be 10 characters in length.
  • The CHESSN must have no leading zeros.
  • The CHESSN must meet the DEST check digit algorithm.
  • The CHESSN must be numeric only, no alpha characters.
  • The person’s citizenship code must be 1, 2, 3, or 8.

Note: If one of the first five validations fail, an error must be reported and the CHESSN not updated. The process will then stop processing the CHESSN.

• Does a Transaction Record exist for the returned CHESSN?

If not, ignore returned CHESSN.

• Does the person have an Active CHESSN recorded?

If the person has an Active CHESSN recorded and the returned CHESSN does not match the recorded CHESSN; do not replace the CHESSN and report an error only.

• Does the person have a Provisional CHESSN with a HEIMS validation date recorded?

If the person has a provisional CHESSN with a HEIMS validation date recorded and the returned CHESSN does not match the recorded CHESSN; do not replace the CHESSN and report an error only.

• Does the person have a Provisional CHESSN without a HEIMS validation date recorded?

If the person has a provisional CHESSN without a HEIMS validation date recorded and the returned CHESSN does not match the recorded CHESSN, the Provisional CHESSN should be set to Invalid and the returned CHESSN loaded against the person. A comment should be recorded on the Invalidated CHESSN ‘Superseded by CHESSN <new CHESSN> in request <request id>’. This must be reported.

• Is the CHESSN identical to any Active or Provisional (with a HEIMS validation date) CHESSN in Callista against a different person ID?

If it is, do not insert the CHESSN or replace the existing CHESSN, report an error only. The error must identify the holder of the duplicate CHESSN. Manual client intervention is then required.

• Is the CHESSN identical to any Provisional (without a HEIMS validation date) CHESSNs in Callista against a different person ID?

If it is, set the matched CHESSN to Invalid, with a reason of ‘Superseded by a CHESSN for <person ID> in request <request id>’. The returned CHESSN should then be loaded against the correct person. For the person with the matched CHESSN record, a NOT-APPLIC CHESSN record must be created. This enables a new CHESSN to be obtained. This must be reported.

• Does the person have an Inactive CHESSN that matches the returned CHESSN?

If the person has an inactive CHESSN recorded and the returned CHESSN matches the recorded CHESSN; Set the inactive CHESSN to Active and report a warning.

• Is a CHESSN returned for each person included in the request?

If not, the CHESSN record for each person without a CHESSN returned must remain as is. The person can then be included in later CHESSN transaction requests. This must be reported along with a message ‘No CHESSN was returned by HEIMS’. The HEIMS reason for not returning a CHESSN must also be reported.

• For each transaction record, HEIMS business rule validation messages must be validated and reported. Messages include:

Failed validations will be stored in the HEIMS Transaction Messages entity for later reporting.

• Load the Results into person CHESSN table

  When HEIMS processing has completed, results have been returned and Callista has validated the results, each Transaction record will be updated appropriately.

  Once CHESSN results have been successfully validated either:

  • NOT-APPLIC CHESSN records will be updated
  • PROVISIONL CHESSN records will be updated.

  If the results do not include a CHESSN for the person the CHESSN record should remain as is (i.e. NOT-APPLIC or PROVISONL and no validation Date). This ensures the records are included in another batch CHESSN transaction.

  Updated NOT-APPLIC records will include:

  • The CHESSN: Returned by HEIMS
  • Date CHESSN recorded: Sysdate
  • System CHESSN Creation Method: HEIMS
  • Status: Provisional
  • HEIMS Validation Date: Sysdate (Saved as a variable at the start of processing as the processing could be performed over more than one day.)

  Updated PROVISIONAL records will have:

  • HEIMS Validation date: Set to sysdate
  • Status: Set to Invalid only if the CHESSN is being superseded by the CHESSN returned by HEIMS.

  Where a Provisional CHESSN has been superseded by returned data, the pre-existing CHESSN should be set to an appropriate status (Invalid) rather than removed from the system. The superseded CHESSN would then require removal by the HEP after the DEST defined period.
  All records will only be committed at the end of processing.

• Record Errors

  Any errors encountered will be logged for exception reporting. Errors will be logged to:

  • The HEIMS Transaction Messages and HEIMS Request Messages entities for any request or transaction data errors from HEIMS
  • The Job run log for any processing errors.

  Once the load has completed an exception report will be produced

This job is to be run in batch mode, taking into consideration the offline periods for HEIMS.

The following represents the requests for which results will be requested:

Only one instance of this job can be run at any given time. Job conflicts will be created to enforce this.

See ADMJ3900 for details of request and transaction statuses and meanings.

This job is accessed from the main menu.

The CHESSN Allocation Report contains:

Parameters Tab

• Process Results check box
• Request ID
• Person ID
• Transaction Status

  Button

• Find Person (ADMF1211)

Validations include:

• CHESSN returned from HEIMS does not confirm to DEST Algorithm
• Cannot update person chessn with Government Citizenship Code other than 1,2,3 or 8
• Does the returned CHESSN exist for any other person in Callista as Provisional with no HEIMS Validation Date?
• Does the returned CHESSN exist for the current person in Callista as Provisional with no HEIMS Validation Date?
• Does the returned CHESSN exist for any other person as Active or Provisional with a HEIMS Validation Date within Callista?
• Does the returned CHESSN exist for any current person as Active or Provisional with a HEIMS Validation Date within Callista?
• Does the returned CHESSN exist for current person as INACTIVE?
• Does the returned CHESSN exist for current person as INVALID?

ADMJ3910 procedures are to:

1. Select all the requests for which results need to be processed in the ascending order, by Request ID, and process one at a time

2. For each record found (That is, for each Request ID):

• Update Results Request Job Run ID of HEIMS_request table with the Request Job Run ID from the Request Job Run table and commit it
• Reset the Request Object for the Request ID
• Request the Results for the Request ID
• Get the HEIMS server current Date and Time, or
• Get the response of the request sent to HEIMS
• Validate and loads transactions

3. Get the next Request ID.

4. Continue until no more requests (Request IDs) are found.

5. Any unexpected errors that are encountered during the request processing will be logged and the job aborts.

Error reporting is documented separately.

Rules/Notes:

Field

Callista Table

Callista Column

Record ID

HEIMS_TRANSACTION/
PERSON_STUDENT_ENTITLEMENT

PERSON_ID

HEIMS_TRANSACTION/
PERSON_STUDENT_ENTITLEMENT

OrdinarySleUsage

PERSON_STUDENT_ENTITLEMENT

SLE_USAGE

OrdinarySleBalance

PERSON_STUDENT_ENTITLEMENT

SLE_BALANCE

Fee HELP Loan Balance

PERSON_STUDENT_ENTITLEMENT

FEE_HELP_LOAN_BALANCE

Calculation As At Date

PERSON_STUDENT_ENTITLEMENT

CALCULATION_AS_AT_DT