Attendees

Agenda

• Introductions
• Review of SIG Goals
• Review of Existing Features and their Backlogs
  • Focus for this meeting are Profiles, Composites, Database Segregation and Deployment 
• Participants share how they are using these features and what changes will support them better
• Agenda for next meeting

Materials

ODS API FEATURE ENHANCEMENTS

Meeting Notes

• Review of SIG Goals

  • ODS API platform comes with various features (e.g. Composites, Profiles, Change Queries, Dependency endpoint etc.), often developed initially as optional Minimum Viable Feature (or MVF) to explore feature's usefulness and adoption. These features have growing backlog of improvement requests.

    The goals of this special interest group are to:

    1. Provide input on field usage of existing features
    2. Make recommendations to the Ed-Fi Alliance on prioritizing feature backlog.
    3. Make recommendations to the Ed-Fi Alliance on discontinuation of features that are proving low value to field work.

  • This meeting is on existing features and future meeting is to focus on requests for new features.

• Review of Existing Features and their Backlogs

  • Focus for this meeting are Profiles, Composites, Database Segregation and Deployment 

• • Profiles
    • Profiles define data policy: A Profile definition identifies a subset of API Resources, and can also limit the data (properties, collections and collection items: that is available for reading and writing. Profile setup currently requires recompile and redeployment. Should we invest in developing profile feature that can be updated without redeployment?
      • EA - The issue is that each district may have own set of rules for different circumstances and need to mimic different data sharing agreements districts have with vendors. Requirements often change during the initial phase and significant time is spent in rebuilding and redeploying.
      • Instructure - Dynamic profile will allow building a policy UI that could be used by the end users to setup and administer their data policy.  
      • Wisconsin - In Wisconsin, an early adopter of profile – didn’t pan out as vendors don’t like to change content type to apply the profile - have only used profile to deny access to a particular field.
        • Is this a one-time action for the vendor or constant? Will come back to later.
        • Profiles currently requires API client to apply a special content type header identifying the profile. API does not restrict one profile per client – can switch profile and get response with that profile applied. This requires client code changes when a profile is applied vs when not. Should we Eliminate need to explicitly reference a profile in the HTTP header?
      • EA - Pair it to dynamic profiles when feature gets built, API clients don’t have to voluntarily request a profile – should be hardwired to what the vendors have access to. These need to go hand-in-hand.
        • Most cases have one profile – 90%. With multiple profiles, we can either setup a default with it or we could setup more than one pair of credentials one per profile.
  • Composites
    • Composites are intended to make API interactions simpler as it provides subject-oriented data from multiple API resources in a single request. Composites are flexible in what it allows you to do, and the feature is complex. Custom composites can cause performance issues if designed unwisely. Composite feature maintains a distinct HQL based authorization logic that has required changes during most of recent authorization enhancements such as multiple authorization strategy support, ownership-based authorization, edorg subtype support.
    • So far, we have only heard of one custom composite and it was in the transcript area. “If Composite beyond Enrollment Composite is not useful for the field, should we go with simple fixed enrollment API implementation?”
      • EA - We are using the enrollment composite in current production to get staff – section rosters back and the engineer working on that has been working around the page size limitations of the composites.
      • Wisconsin - enrollment composite – push people who need to use but lack of extension support limits to use to composite because there is very critical business logic on the extension -need to be able to surface that.
      • Instructure - At Instructure, we deploy enrollment API with ODS, tell people they are welcome to use it, ultimately up to implementer – would suggest a composite something like One Roster or another rostering standard would be more helpful and more useful than the current enrollment format.
      • EA - A comment regarding page size limitations of composites – API hosts should be able to set limit to something that is reasonable for our environment.
      • EdWise - If there are challenges in releasing enhancements to core Ed-Fi API and managing this other beast built on top of it without justified ROI, is there a way to spin those off as an Exchange Community/GitHub repo?
      • Instructure - It is hard enough to get the default API implemented let alone custom ones so the more we can encourage standard use of existing APIs the better we will be in the long term. As a provider I would much rather have standard APIs.
        • The challenge with standard APIs it is hard to answer questions that certain apps need in real time.
      • EdWire - Redesigning the feature using GraphQL may make sense accepting query language in the API and let client applications decide what data they need.
        • ODS API platform provides multiple database segregation and deployment modes.
  • Database Segregation and Deployment

• • • Instance-Year Specific mode was added by community contribution, and it lacks support in certain areas such as swagger and deployment PowerShell. Is Instance-Year Specific mode the best mode of deployment for larger cloud implementations?
      
      • EA - API client should not be aware deployment modes and URL should not change. Should be no reason for client to specify a year in their request. Year, Instance, District etc. can be codified with API Client information in the admin database. 
      • Wisconsin - Wisconsin is updating multiple years at a time and knowing which one is being targeted is important.
      • EdWise - There are also different Ed-Fi versions from year to year and some states provide three years of data. Updating API Client information every year would be a maintenance challenge in large state implementations for each district.
        
        • One API deployment instance all env
      • EdWire - Consider change instance year to a different name such as “environment instance” where instance is something more generic (could be a district, year or something else) that lets you provide logical grouping of ODS together and share the admin and security database.
      • Instructure - Instructure only deploy shared instance environments and hard code in the domain of which server to use. This way deployments are much easier to deal with. URL from chat:  https://0C98FE0BB6134471AC400820F645A428.edfi331b.datahub.dev-pdx.ax.inseng.net

• Agenda for next meeting

  • Next meeting will continue the discussion on deployment modes (including Database Connection Mapping) and go on to discussing new features.

Next Meeting 17 Nov 2022 12:00pm - 1:15pm CT