Release 3 (R3) release notes

Release 3 (R3) enables SMS vendors to begin delivery planning, produce early planning and design artefacts and map SMS data models to VET IS elements in the API. 

VET IS elements in the OpenAPI specification are mature, while still draft. It is still not recommended that vendors begin building at this stage; R3 supports planning rather than implementation.

1. Split OpenAPI specifications: Docs vs Stub  

The two OpenAPI specification names are: 

  • STARS VET Provider Collection API (Client Integration) (Stub) 

  • STARS VET Provider Collection API (Client Integration) (Docs) 

R3 presents a two-fold approach to API documentation: 

a. Docs OpenAPI specification  

  • Provides the full OpenAPI specification to date 

  • Intended for documentation and planning only, any calls to these endpoints will return a ‘501 – Not Implemented’ HTTP response 

b. Stub OpenAPI specification  

  • Continues to include API endpoints that provide a mocked HTTP response 

  • Maintains existing stub behaviour 

  • Excludes reconciliation APIs and endpoints not yet supported by stubbed implementations 

2. Alignment with the draft VET Information Standard (VET IS)  

This release delivers an updated alignment between the draft VET IS, draft validation rules, and the draft STARS APIs. 

The meaning of each field in the API is expressed in the context of the VET IS. You can look up each field and the data that needs to be collected in that field. Descriptions in the API include the VET IS element ID and VET IS description. 

You can start mapping STARS top level resources and data elements to your data model based on the definitions of the elements in the VET IS.

 

3. Renaming of API resources to remove logical model terminology  

Resource names are simplified toward being self-describing, for example moving away from terms like ‘Stakeholder Relationship - Student’ to ‘Student’ and using clearer names such as ‘Program Enrolment’ and ‘Subject Enrolment’.  

Terminology is closer to Student Management Systems terminology. Terminology from the unpublished logical model has been removed. This change applies across the API, not just routes, for example, route names, schema objects and attributes.   

Schema and route names for VET IS elements defined in the OpenAPI specifications are reflective of the target state. No significant structural or naming changes are planned. Clients built using these terms will align with the terminology used in the OpenAPI specification and the VET IS. Mapping layers, target schema and attribute names won’t undergo significant changes. 

4. Updates to cardinality, attribute names and data types  

Several changes have occurred to the model of uploaded VET IS data, in alignment with the draft VET IS 

  • Attribute name changes, for example thirdPartyTrainingOrganisationABN is now ABN 

  • Relocation of attributes, for example NominalHours from SubjectOffering to Subject 

  • Cardinality, for example ProgramEnrolment TransferredFromProgramEnrolment is now a collection of program enrolments. 

Any existing mapping to STARS will need to be re-evaluated to determine whether the mapping is valid or there are better ways to map the data.  

The VET IS schema is now stable. Further significant changes to VET IS schema like this are not expected. 

5. Introduction of reconciliation-related APIs  

APIs supporting reconciliation between VET IS data and submitted SMS data have been introduced.  

These APIs allow a student management system to determine what data has been submitted to STARS. You can work out which data have been submitted and which data are out of date. System state can be verified and used to drive corrective transaction batches. These APIs provide an important pathway to assuring submissions are accurate and complete before making a declaration. 

We don’t have stubs and scenarios for the reconciliation API yet. The Docs OpenAPI specification provides visibility into how we’re going to support these scenarios. You can use the specification for exploring possible use cases. These early release APIs are subject to change. 

6. Introduction of the ability to delete submitted data 

The upload APIs have been updated to allow resources submitted in error to be removed from the submitted data. 

You will see additional properties on resources related to uploads in a transaction batch supporting these workflows.  

We don’t have stubs and scenarios for data submitted in error yet. The Docs OpenAPI specification provides visibility into how we’re going to support these scenarios. You can use the specification for exploring possible use cases. These early release APIs are subject to change. 

7. Upload responses and validation results schemas 

The schema used in response objects in transaction batches has been further refined.  

This represents the last significant planned change to the structure of objects used when uploading into and working with transaction batches. 

There is work being done on finalising the specifics of the data. The structure is reasonably stable. 

8. Updated Stubs 

The stubs and scenarios have been updated to reflect the changes to the OpenAPI specification.  

This provides a representative view of the changes to the data resulting from the specifications changes. The existing scenarios have been updated to show the same workflows with the new data. Behaviours and data flows shown are important to understanding how STARS supports upload and submission workflows. 

Scenarios will continue to be optimised, refined and expanded on, to show core scenarios for building a STARS client. 

9. Known issues 

Issue Test Environment - unable to download the WADL file from download definition dropdown  

Impact Download is blocked in both Chrome and Edge (standard and incognito). 

Workaround`There are two work arounds: 
1. Use Firefox (standard or incognito), where the download works as expected.  
2. Download the API definition by selecting YAML / JSON types. 

Status Resolved