What's New in v5.3

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:

Educator Preparation Data Model

Ed-Fi ODS / API v5.3 brings in EPDM core v1.1.0 (previously TPDM) as a dynamic extension plugin. Educator 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 Educator Preparation Data Model documentation for more details. Out of the box, the Ed-Fi ODS / API installs the EPDM core plugin. If you are interested in the EPDM community edition, see the article Installing Ed-Fi ODS / API 5.3 with EPDM-Community v1.1.

Authorization Simplification

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	appsettings.json ApiSettings:Mode value	appsettings.json EdFi_ODS Connection String
Year Specific	Partitioning by year. Different year data is accessed through changing the URL (e.g., http://website-address/data/v3/2021).	YearSpecific	Database=EdFi_Ods_YYYY Server=Ods_YYYY (substitute actual current year)
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	Database=EdFi_Ods_DISTRICTID Server=Ods_DISTRICTID (substitute actual district ID)
Instance-Year Specific	Partitioning by instance and year. Different instance and year data is accessed through changing the URL (e.g., http://website-address/data/v3/inst-1/2021). Partitioning by-district-by-year is one specific example of this partitioning Strategy.	InstanceYearSpecific	Database=EdFi_Ods_INSTNACEID_YYYY Server=Ods_INSTNACEID_YYYY (substitute actual instance ID and current year)

MetaEd IDE v2.6

Implementing extensions in ODS / API v5.3 requires implementers to update to MetaEd IDE v2.6.

Ed-Fi ODS / API for Suite 3 v5.3