Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Agenda

  • Demonstration of current work

  • Review the roadmap

  • Design Questions

Demonstration

Planned Architecture

image-20241204-030548.png

Working Client Management and Authentication

 Mermaid diagram
sequenceDiagram
    actor Sys Admin

    rect rgb(191, 223, 255)
    note right of Sys Admin: One time setup.

        Sys Admin->>Config Service: POST /connect/register
        Config Service->>Identity Provider: Create credentials
        note right of Identity Provider: Created with config role
        
        Config Service-->>Sys Admin: clientCredentials
    end

    Sys Admin->>Config Service: POST /v2/vendors
    Config Service->>Config Database: INSERT dbo.Vendor

    Sys Admin->>Config Service: POST /v2/applications

    Config Service->>Identity Provider: Create credentials
    note right of Identity Provider: Created with dms role
    Identity Provider-->>Config Service: clientCredentials
    Config Service->>Config Database: INSERT dbo.Application
    Config Database -->>Config Service: applicationId
    Config Service->>Config Database: INSERT dbo.ApplicationEducationOrganization
    Config Service->>Config Database: INSERT dbo.ApiClient

    Config Service-->>Sys Admin: clientCredentials
image (2).png

Roadmap

Getting to a pilot-ready release candidate by Tech Congress was always going to be challenging. The team has been working hard, but we need to adjust the milestones and expectations for release candidate 1.

Goals for release candidate are broadly:

  1. Deployable and fully functional in the basic CRUD operations on all Resources and Descriptors.

  2. Proper error handling and edge case management.

  3. Performance on par with the ODS/API.

  4. Be useable for basic field testing and non-critical path use cases.

While we want to be looking ahead to supporting state agency use, at the 2024 Summit we agreed to prioritize service provider / LEA usage scenarios first. Given that,

Milestone

Functional Goals

0.1 DONE

Compliant Discovery API, Descriptor API, and Resource API definition (except GET by query): able to run bulk upload, smoke test. Includes JSON validation based on API schema file. Fake OAuth (1).

0.2 DONE

  • 📢 Milestone 0.2.0 has been reached!

  • .NET application with PostgreSQL storage

  • Level 0 and Level 1 document validation

  • Reference and descriptor validation

  • Error message like ODS/API 7.2

  • Docker and Kubernetes

0.3 DONE

  • Streaming data out via Kafka

  • GET by query using OpenSearch

  • Cascading updates on allowed key changes

  • Abandoned direct Kubernetes support as too costly

  • by 10/1 (Ed-Fi Summit)

0.4 IN PROGRESS

  • Token authorization DONE

  • Client credentials management DONE

  • Namespace authorization NEXT

  • BONUS: Elasticsearch/Kibana instead of OpenSearch/OpenSearch Dashboard DONE

0.5

  • Design spikes around ed-org authorization DONE

  • Concurrency management with eTags DEFER?

  • Extensions DEFER?

  • Multiple data standards DEFER? (DS 5.2)

0.6

  • Dynamic profiles DEFER?

  • Multitenancy and routing DEFER?

0.7

  • Education organization authorization MOVE UP

  • Claimset customization DEFER?

Items for future scope beyond this include: Change Queries, using PostgreSQL for queries instead of OpenSearch / Elasticsearch, real-time level 2 validation using Kafka, identity API, etc.

Design Questions

What plans are there for error detection (i.e. dropped records) and correction?

A question that arose at the Ed-Fi Summit session. Suggestions?

How will year rollover be handled?

Perhaps not germane to the release candidate, but we should still ask: are there special considerations that the development team needs to be thinking about in advance?

  • No labels