Specifically,
this function will:
Callista
Request Status |
HEIMS
Request Status |
HEIMS
Result Status |
Included |
Comments |
Pending |
NA |
NA |
No |
|
Failed |
NA |
NA |
No |
|
Process |
NULL |
NA |
No |
|
Process |
Archive |
NA |
No |
|
Process |
Success |
Null |
Yes |
|
Process |
Success |
Process |
Conditional |
Included If
the Results Request Job Run ID relates to a failed job. For example,
Cancelled, Abort, or Failed.
Excluded If
the Results Request Job Run ID relates to a currently processing
job. For example, Running, Scheduled. |
Complete |
NA |
NA |
No |
|
- 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 HEIMS 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:
HEIMS
Result Status |
Message
Code |
HEIMS
Message |
Callista
Message |
Success |
10201 |
All data fields
identified as Mandatory must not contain a null value |
All data fields
identified as Mandatory must not contain a null value |
Success |
10203 |
Invalid BirthDate |
The birth date
provided is invalid |
Success |
10205 |
Invalid CitizenshipStatusCode |
The citizenship
code is invalid |
Success |
10207 |
If AttendedYear12Code
is equal to 'AttendedYear12’, then Year12State must not be empty |
The Year 12 State
is blank |
Success |
10208 |
Year12State must
be a valid Australian state |
The Year 12 state
is not a valid Australian state or territory |
Success |
10209 |
If AttendedYear12Code
is equal to ’AttendedYear12’, then Year12Year must not be empty |
The Attended
Year 12 year is blank |
Success |
10210 |
If AttendedYear12Code
is equal to ’AttendedYear12’, then Year12Number or Year12SchoolName
must not be blank |
The Year 12 Student
Number and School Name are blank |
Success |
10214 |
If AttendedPreviousHepCode
is equal to ’AttendedPreviousHep’, then HepName and HepNumber both
must not be blank (i.e. at least one of these 2 data elements must
contain a value) |
The Previous
HEP Name and Previous HEP Student Number cannot both be blank |
Success |
10215 |
If AttendedPreviousHepCode
is equal to ’AttendedPreviousHep’, then HepYear must not be blank
|
The Last Year
of Enrolment for the previous HEP is blank |
Success |
10216 |
PostalCountryCode
must be a valid code |
The country code
is not a valid government country code |
Success |
10218 |
If PostalCountryCode
is equal to ‘1100’ (code for Australia), then PostalPostCode must
not be empty |
The post code
must not be blank for addresses in Australia |
Success |
10221 |
The supplied
CHESSN does not match an existing CHESSN in HEIMS |
The supplied
CHESSN does not match an existing CHESSN in HEIMS. (Note: Only used
for Get Entitlement processes) |
Success |
10222 |
FamilyName and
BirthDate do not match those of the student the CHESSN is associated
with |
FamilyName and
BirthDate do not match those of the student the CHESSN is associated
with (Note: Only used for Get Entitlement processes) |
Success |
10223 |
Invalid CHESSN |
The supplied
CHESSN is Invalid (Note: Only used for Get Entitlement processes) |
Success |
10224 |
Year12Details
must be present |
Year 12 Details
must be present when the AttendedYear12Code is equal to ’AttendedYear12’ |
Success |
10225 |
Invalid year
for Year12Year |
Invalid year
for Year12Year |
Success |
10226 |
If value of AttendedPreviousHepCode
is equal to ’AttendedPreviousHep’, then PreviousHepDetails must be
present |
Previous HEP
details must be complete when the AttendedPreviousHepCode is equal
to ’AttendedPreviousHep’ |
Success |
10227 |
If value of AttendedPreviousHepCode
is equal to ’AttendedPreviousHep’, then HepCode must be present |
Previous HEP
Code must be provided when the AttendedPreviousHepCode is equal to
’AttendedPreviousHep’ |
Success |
10228 |
If value of AttendedPreviousHepCode
is equal to ’AttendedPreviousHep’, then HepCode must be valid according
to the Government controlled list |
Previous HEP
Code is not a valid Government HEP code |
Success |
10229 |
Invalid year
for Hepyear |
Invalid year
for HEP year |
Success |
10230 |
PostCode must
be in the range of ‘0001’ to ‘9999’ |
Invalid Australian
PostCode |
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 HEIMS 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.
This job will also perform calculations to determine each student's remaining entitlement and identify any warnings based on Entitlement Position configuration (see ADMF0300). It will also record and update the person entitlement position table.
The job’s report will include all the identified entitlement positions with system outcome type of WARNING or CRITICAL. These will be grouped to allow the administrator to focus on the different outcome types. Critical outcomes will be clearly identified.
The following details are reported:
- Person ID
- Person Name
- Outcome Text
- Outcome Type
- Entitlement Balance/Expected Balance
For each Entitlement/Outcome Type/Context combination, records with the same Entitlement Status are grouped together.
See ADMJ3900
for details of request and transaction statuses and meanings.
This job is accessed from the
main menu.
|