This Web Services passes applicant and application data, and/or documents from agencies (whose agents submit admission applications online on behalf of applicants) into Callista SMS. An agency can opt to transfer applicant and application data (in an XML format), via a web service, into an institution's Applicant Portal tables. This option is an alternative to the institution's staff entering the data manually into Callista SMS.

A process runs to validate all applicant and application data. For an application to be transferred all course preferences in the .xml file must be valid. If any part of an application (for example, agent, applicant, other details, documents, etc) fails validation, then no data (including valid data) will be transferred. If applicant and application data is not successfully transferred into the AP tables, the failures are recorded in the S_LOG_ENTRY table and the agency is notified of the failures.

When all applicant and application data has been successfully submitted and transferred into the AP tables, the applications are given a System Applicant Portal Transfer Status of PENDING (see ADMF0910) and are treated as new applications. (If an applicant does not have an existing AP account, then a new AP account and Applicant ID is created.) An email is automatically sent to the applicant(s) and agent informing them of the successful submission(s).

This web service also enables an agency to transfer one or more files as attachments with an application when it is submitted, or at a later date after successful submission (in this case, an Applicant ID must be supplied).

This method seeks to pass course and course version information from an external system into Callista.
This Web Service includes an Insert Only indicator. If this indicator is set to Y, this function inserts the course and course version details.

If this indicator is set to N, this function checks if the course version currently exists based on the course code and version number. If it does exist this function updates the existing course version record. If the course version doesn’t exist a record is inserted into the course and course version tables.

When the record is being updated all values except the course code and version number fields are updated. Therefore, the call to this Web Service must pass through all values in every Web Service call.

All exceptions raised (i.e. table constraints, trigger validations) from the insert or update are returned as an exception to the Web Service and the changes are not committed. The Web Service then returns the exception to the Web Service initiator.

This method is used to facilitate the automatic workflow of discontinuation and intermission applications for Student Course Attempts. It gets (GET method) or inserts (UPDATE method) new Assessors for a Discontinuation or Intermission application (see ENRW3400).

Note: The UPDATE web service method should be called with a complete set of Assessors that are to be associated with an application. This means that if an application already has three Assessors and a fourth is to be added, then the call to the web service UPDATE method should contain all four Assessors (three existing and the fourth new one).

This Web Service shows two methods that allow an external system to access and modify person address information within Callista SMS. The two methods are:

This method follows existing Callista SMS address handling conventions, especially in terms of updating existing addresses (an address update will not actually update the records in the PERSON_ADDR table, but rather insert a new record and update the existing address records to close off their end-date or update their start date).

All exceptions raised (i.e. table constraints, trigger validations) from these two methods are returned as an exception to the Web Service and the changes are not committed. The Web Service then returns the exception to the Web Service initiator.

This Web Service allows a set of student results (grades and/or marks) for multiple units within a specific Teaching period to be uploaded to Callista SMS, for example, this web service would be used to upload results from an institution's Learning Management System (LMS).

There is no file or human interaction involved in the web service transfer as it is purely a 'system to system' function. The web service requires the data in a specific format - for specification details, see the 'td_web_services' technical document for SMS.

The records are transferred in XML format to Callista and uploaded into the same holding area (i.e. the UPLOAD_VALIDATED and UPLOAD_VALIDATED_UNIT_ATMPT tables) as that used for Staff Connect and SMS forms Results upload.

Note: A log of all validation messages is kept in Callista. If required, run GENJ1100 to create an extract of the validation messages.

A 'Loaded-By' value is recorded in the UPLOAD_VALIDATED table.

The load transfer is rejected if:

• No Batch ID or 'Loaded By' values are passed in.
• The Calendar details are insufficent, or more than one Calendar instance exists.
• The same Student Unit Attempt appears twice.

The following Calendar Instance combinations are valid:

Once uploaded, an administrator runs the ASSJ5341 job to process the uploaded records and create Student Unit Attempt Outcomes. (Note: ASSF5340 is not involved in the process.)

If required, the ASSR06J0 report can be run to identify non-enrolled SUAOs. The 'Add Non-Enrolled Student Outcome' form (ASSF5333) may also be used, if required.

This method passes unit and unit version information from an external system into Callista. This Web Service includes an Insert only indicator. If this indicator is set to Y, this function inserts the unit and unit version details.

If this indicator is set to N, this function checks if the unit version currently exists based on the unit code and version number. If it does exist it updates the existing unit version record to match the data passed into the Web Service. If the unit version doesn’t exist a record is inserted into the unit and unit version tables.

When the record is being updated all values except the unit code and version number fields are updated. Therefore, the call to this Web Service must pass through all values in every Web Service call.

All exceptions raised (i.e. table constraints, trigger validations) from the insert or update are returned as an exception to the Web Service and the changes arel not committed. The Web Service then returns the exception to the Web Service initiator.

This method passes unit set information from an external system into Callista. This Web Service includes an Insert only indicator. If this indicator is set to Y, this function inserts the unit set details.

If this indicator is set to N, it checks if the unit set currently exists based on the unit set code and version number. If it does exist, it updates the existing unit set record. If the unit set doesn’t exist a record is inserted into the unit set table.

When the record is being updated all values except the unit set code and version number fields are updated. Therefore, the call to this Web Service should set all of the Web Service parameters with their corresponding values in the client system (even if they are NULL).

All exceptions raised (i.e. table constraints, trigger validations) from the insert or update are returned as an exception to the Web Service and the changes are not committed. The Web Service then returns the exception to the Web Service initiator.