...
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
| Warning |
|---|
This is an anti-pattern. |
| Gliffy | ||
|---|---|---|
|
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.
When to Use
The Ed-Fi Alliance considers API Composite Resources to be a deprecated technolog and recommends that no new integrations be built on this pattern.
API Publisher
This is an emergent Ed-Fi specific pattern. The Ed-Fi Alliance would appreciate hearing feedback from anyone who takes this approach.
| Gliffy | ||
|---|---|---|
|
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.
When to Use
This pattern may be useful when bridging across disparate networks and permissions. Although additional software needs to be deployed (extra copy of an Ed-Fi API, and the API Publisher), the only new software that needs to be developed is the backend or client application that serves end users. Arguably, this can be seen as a special case of the Batch and Save pattern above, without the need to develop a custom ETL application.
Implementation Notes
API Publisher’s configuration information allows the system administrator to select which resources to synchronize across systems. The application handles dependency ordering.
The local data store’s schema will depend on the which receiving application is used.
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.
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.
...