Quercus Message Link Developer’s Guide<>

Messages

Summary

This section lists all current and future Quercus Message Link messages.

The Direction column identifies the direction of messages from a Quercus perspective:

Out — Quercus is pushing information about a change made in the Quercus

In — Quercus is accepting information about a change made by another system

List of messages

Message

Direction

Description (event)

Available

A1

Course data

Out

To provide course data when new records are created or existing records are updated.

Y

A1a

Course Instance data

Out

To provide course instance data when new records are created or existing records are updated

Y

A1b

Course Curriculum data

Out

To provide course curriculum data when new records are created or existing records are updated.

Y

A2

Course data

In

Updates or creates course data from external systems.

A2a

Course Instance data

In

Updates or creates course instance data from external systems

A2b

Course Curriculum data

In

Updates or creates course curriculum data from external systems

B1

Biographic data

Out

To provide biographic data when new records are created or existing records are updated.

Y

B2

Biographic data

In

Updates Quercus biographic from external systems.

Y

C1

Module data

Out

To provide module data to external systems when a new module is created or an existing module is updated.

Y

C1a

Module Instance data

Out

To provide module instance data to external systems when new records are created or existing records updated.

Y

C2

Module data

In

To receive details of modules from external systems. Modules can be created in Quercus provided the module code does not already exist.

C2a

Module Instance data

In

To receive details of modules instances from external systems.

D1

Applicant

Out

To provide applicant data when new records are created or existing records are updated.

D1

Applicant

In

To create or update applicant record from external system.

E1

Student Enrolment

Out

Provides details of student enrolments to external systems.

Y

E2

Student Enrolment

In

Enrols student (existing person) on a course instance.

F1

Fee Transaction

Out

Provides details of financial transaction generated in Quercus to external systems.

Y

F2

Fee Transaction

In

Updates student account with transaction generated to an external finance system.

G1

Student Curriculum

Out

Provides details of changes in the student curriculum to external systems.

Y

G2

Student Curriculum

In

Update student’s curriculum in Quercus from external system.

H1

Marks & Standards - Student Overall Grade

Out

Provides details of a student’s overall course grade to external systems.

Y

H1a

Marks & Standards – Student Assessment

Out

Provides details of a student’s assessment results to external systems.

Y

H2

Marks & Standards – Student Overall Grade

In

Updates a student’s overall course grade with data from external systems.

Y

H2a

Marks & Standards – Student Assessment

In

Updates a student’s assessment results with data from external systems.

Y

I1

Attendance

Out

Provides details of student attendance to external systems.

I2

Attendance

In

Update student’s attendance from external systems.

J1

Student sponsorship

Out

Provides details of student sponsorship to external systems.

Y

J2

Student sponsorship

In

Update student’s sponsorship from external systems.

K1

Bio data deduplication

Out

Validates bio data against external system to identify possible duplicates or exact matches.

K2

Bio data deduplication

In

Provides list of possible duplicates matching passed bio data from the external system.

L1

Person Note

Out

Provides details of new and existing notes to external systems.

Y

L2

Person Note

In

Updates Quercus with new and existing person notes.

Y

M1

HESA Person

Out

Provides details of HESA attributes relating to a person.

Y

M2

HESA Person

In

Update HESA Person record from external systems.

Common rules and practices

Inbound messages will not generate outbound messages to other systems

Messages into Quercus will create or update the relevant records with the payload in the message but will not spawn new messages out of Quercus.

It is expected that the inbound messages will be dispersed to all targets from the source of the message.

Enterprise service bus compatibility requirements

Quercus Message Link is designed to operate with open standard based enterprise service buses from various vendors including Oracle, IBM, Microsoft and Apache.

The only requirement is that ESB can interact with Oracle database and dequeue or enqueue XML messages from Oracle Advanced Queue or into Oracle Advanced Queue.

WSDL definitions

The exact format of the WSDL file depends on the specific enterprise service bus (ESB).

Quercus Message Link can operate with various ESB and therefore WSDL definitions are not provided in this document.

Additional resources will be made available detailing examples of WSDL files for the Oracle Service Bus 11g.

Naming conventions

All database objects associated with the Quercus Message Link system have a common prefix so they can be easily identified.

For the database tables and packages the prefix is APIWS_ which is short for API Web Service.

For the database queue types the prefix is AQ_ which is short for Advanced Queue.

Database queue tables are suffixed with _QT which is short for Queue Table, e.g. MESSAGE_OUT_QT.

Date and timestamp formats

All dates are expressed in the standard XML format YYYY-MM-DD where:

YYYY indicates the year

MM indicates the month

DD indicates the day

All date timestamps are expressed in the standard XML format YYYY-MM-DDThh:mm:ss where:

YYYY indicates the year

MM indicates the month

DD indicates the day

T indicates the start of the time section

hh indicates the hour

mm indicates the minute

ss indicates the second

Inbound message validation

Each message that is enqueued to Quercus will go through a series of validations before Quercus is updated with the message details. The validation process ensures that data quality and consistency is maintained throughout Quercus.

The following validation checks are applied to each inbound message:

Check order

Check

Details

1

XML Format

Each message is first checked for well formed XML. If the message is not in a proper format then it is rejected and sent to the hospital queue.

2

Message Type

Each message must have a message type as part of its metadata. The message type must be a valid type as defined in the APIWS_MESSAGE table.

If the type is not found or not enabled then the message will be sent to the hospital queue.

3

Mandatory Fields

Each message is checked for mandatory fields, if any mandatory field is omitted then the message is sent to the hospital queue.

4

Lookup Fields

Lookup fields are those fields that contain data which require a lookup on the Quercus database, e.g. PERSON_TYPE.

If the data in the lookup field is not in Quercus then the message will be sent to the hospital queue.

In other words, inbound messages will not create new static data. The static data must exist already exist on the database and if any new static data is required then it should be manually entered. This ensures data quality.

Note: All lookup codes must be in upper case

Inbound message update mode

An attribute called UPDATE_MODE exists on all repeated lists, e.g. departments against a module instance, within a message. The UPDATE_MODE can be ADD_UPDATE or REPLACE. By default the UPDATE_MODE is ADD_UPDATE.

When the UPDATE_MODE is set to ADD_UPDATE Message Link will add new records to Quercus if they do not already exist or if they exist it will update the values in the record with the values from the message provided that all validation rules are satisfied.

When the UPDATE_MODE is set to REPLACE Message Link will REPLACE any records for the master object with the records in the list from the message. Example:

Course structure

Quercus database

Message IN

Module Code

Module Type

Module Code

Module Type

X

Core

X

Core

Y

Core

Y

Optional

Z

Optional

D

Core

In UPDATE_MODE = ADD_UPDATE the result would be as follows:

Module code

Module type

X

Core

Y

Optional

Z

Optional

D

Core

In UPDATE_MODE = REPLACE the result would be as follows:

Module code

Module type

X

Core

Y

Optional

D

Core