...

...

Foundational Patterns

These patterns describe several different architectures for an application to access Ed-Fi data.

Direct Database Interaction

...

How it works

The backend application retrieves optimized data from a local data store, thus improving the response time on the originating request. A separate ETL process runs on a schedule to pull data from the Ed-Fi API, reshape it according to the backend application’s needs, and place into the shared data store.

...

This is an emergent pattern that the Ed-Fi community has not widely used. It requires deployment of several additional components that are not present in other patterns (stream processor, change data capture, etc.).

Frontend API Design Pattern

These patterns describe common approaches for building an end-user application that uses one of the Data Access patterns above to access the Ed-Fi data.

Backend-for-frontend

...

Also see: Gateway Aggregation pattern - Azure Architecture Center | Microsoft Learn

Special Case Patterns

These patterns do not fall cleanly into either category above and are specific to the Ed-Fi technology suite.

ODS/API Composites

How it Works

The Ed-Fi ODS/API Platform host can deploy the system with API Composite Resources Composite API definition, such as the Enrollment API. These are specialized API definitions with auto-generated application code that generates complex database queries, allowing the client to make one call that will retrieve information from multiple Ed-Fi Resources. Depending on the API specification, this can effectively be a Backend-for-frontend, or a Central aggregating gateway (described below) - except that the authorization model is not appropriate for direct use by a user application.

...

The Ed-Fi Alliance considers API Composite Resources to be a deprecated technolog technology and recommends that no new integrations be built on this pattern.

...

How it Works

Rather than building a specialized API definition or directly calling the Ed-Fi API from a user application, the system provider instead utilizes API Publisher to copy some of the data from a remote Ed-Fi API instance into a local one. The local copy could be running the Ed-Fi ODS/API or another application that is a compatible Ed-Fi API. The host for the second copy now has full access to the Ed-Fi data in a local data store.

...

In some circumstances, this pattern can also be used to aggregate information from multiple Ed-Fi API deployments. However, this should only be done in a context where uniqueness of certain identifiers can be guaranteed. For example, when retrieving student data, the StudentUniqueId must be unique across all related source systems. This may be feasible when all of the source systems are in the same state, and the state education agency (SEA) has a strong state-wide unique identifier system in place. The EducationOrganizationId values (such as LocalEducationAgencyId and SchoolId) would also need to be unique across these source systems.

Specialized Ed-Fi Resources with Duplicate Data

How it Works

A new domain can be added to the Ed-Fi API, or a new entity can be added to an existing domain. The new entity/entities describe new shapes for data that already exist in one or more other domains in the Ed-Fi API. In effect, this creates a specialized API specification, which could be following either the backend-for-frontend or central aggregating gateway pattern. For example, the Enrollment API could be rebuilt as a new domain in the core Ed-Fi Data Standard.

A custom application would perform extract-transform-load (ETL) operations, copying data from the source resources in the Ed-Fi API into the target resources on the same application server or on another remote server.

When to Use

This pattern is ideal when the new resources benefit from the complex authorization security model in the Ed-Fi API. The new domain could either be an extension or part of the core Data Standard.

Implementation Notes

As with any ETL process, performance will be best when running against a database snapshot and/or running in “off hours”. This is particularly true when both sides of the ETL process are accessing the same instance of the Ed-Fi API.

Ideally, the ETL application would utilize the Change Queries API for reads, so that only newly modified data would need to be synced each day. However, this must be done very carefully: the point of this pattern is to collect information from multiple source endpoints to store in a single destination endpoint. Thus, the change version needs to be tracked across all sources for a given destination.

Row-Level Security

The Family Educational Rights and Privacy Act (FERPA) outlines certain data privacy rights for students plus the rules by which student data can be shared to anyone other than the student or parent. Systems that utilize Ed-Fi data must provide appropriate data security so that school officials, parents, and so forth are only authorized to view "need-to-know" records. What is appropriate may vary from state to state and district to district.

...