This section provides an overview of the new features in v5.3 of the Ed-Fi ODS / API for Tech Suite 3. A comprehensive list of all changes is in the Release Notes section.
The changes include:
Detail about each change follows.
Improvements & Enhancements
This section briefly describes the new features and enhancements built into the ODS / API v5.3 and provides links to additional documentation.
Data Model Changes
Ed-Fi ODS / API v5.3 implements Ed-Fi Data Standard v3.3.1-b, which brings a subset of TPDM elements into the core data model and introduces changes around the domains commonly captured in student information systems and assessment systems. Refer to What's New - v3.3-b for details. These changes are intended to be non-breaking to most API clients. However, platform hosts should be aware that there are database changes and changes to build and deployment pipelines.
Data Standard v3.3.1-b can also be reviewed in the context of API specifications:
- Ed-Fi Assessment Outcomes API for Suite 3 v1.0.1
- ED-FI RFC 24 - CORE STUDENT API
- ED-FI RFC 25 - SURVEY API
- ED-FI RFC 26 - TEACHER PREP DATA MODEL
Teacher Preparation Data Model
Ed-Fi ODS / API v5.3 brings in TPDM core v1.1.0 as a dynamic extension plugin. Teacher preparation providers can use this extension to evaluate program improvements based on how their graduates perform in the classroom rather than on general or anecdotal evidence. See the Teacher Preparation Data Model documentation for more details. Out of the box, the Ed-Fi ODS / API installs TPDM core plugin. If you are interested in TPDM community edition, see the article Installing Ed-Fi ODS / API 5.3 with TPDM-Community v1.1.
In previous releases, when authorization to API resources was to be granted based on a new education organization subtype (originally only LEA and school were supported), the API source code and database had to be modified. Recently, many use cases for authorization based on different education organization subtypes have emerged (e.g., CommunityProvider, PostSecondaryInstitution, Education Service Center, OrganizationDepartment). ODS / API v5.3 includes a simplification to education organization-based authorization to support these use cases.
Extension Plugin Build Without Source Code Installation
Extending the Data Model is one of the key features that draws implementers to the Ed-Fi ODS / API. Typically, this involves a development activity that modifies the ODS, data access code, API surface, Open API metadata, and more. Hence, extending the model requires CI/CD setup for build and deployment of extended API.
Many LEA implementations depend on the as-shipped Ed-Fi-published packages and do not have the resources to develop extensions. So we introduced dynamic extension feature in an earlier Suite 3 release. This feature allowed extension plugins to be created and then consumed at runtime by the ODS / API without source code changes. This opened up the door for LEA implementations to consume domain extensions and data exchange standards that are emerging as extensions without source code changes.
State-specific extensions still required full source download and CI/CD setup. ODS / API v5.3 enables building dynamic extension packages without setting up full CI/CD for entire ODS/API source code build. The SEA Modernization Starter Kit introduces a GitHub Action build that works with published API binaries to build and test extension plugins with the Ed-Fi-published ODS / API binaries. ODS / API and the extension can then be deployed via Binary Installation path.
Support For Multiple Database Servers
Ed-Fi ODS / API traditionally supported different database partitioning strategies, for example, the default Shared Instance), Year Specific, District Specific and more recent Instance Year Specific deployment. While these allowed partitioning data into different databases, all databases were deployed on singe database server. For clear isolation of data for different districts or different school years, the ODS / API now allows similar template patterns on databases as well as database servers.
|Database Provider||Partitioning Strategy|
|Year Specific||Partitioning by year. Different year data is accessed through changing the URL (e.g.,).||YearSpecific|
|District Specific||Partitioning by district. Different district data is accessed through district ID associated with the API client. To use this option, the API client must be configured for exactly one district ID during API key and secret configuration.||DistrictSpecific|
|Instance-Year Specific||Partitioning by instance and year. Different instance and year data is accessed through changing the URL (e.g.,Partitioning by-district-by-year is one specific example of this partitioning Strategy.||InstanceYearSpecific|
MetaEd IDE v2.6
Implementing extensions in ODS / API v5.3 requires implementers to update to MetaEd IDE v2.6.
Find out more about what's new in the latest version of the Ed-Fi ODS / API: