SIS SIG - Meeting 2 - 2023.10.11

Participants

Support: Ann Su, Ed-Fi Alliance

Review of & feedback on Ed-Fi Alliance programs to reduce API fragmentation and burden
1. Review state alignment work
2. Review playbooks
3. Use cases that underlay our specifications
Feedback on Error Code and Error Handling proposed changes (from Meeting 1)
Review of priority interventions for 2024 specifications
Topic for future meeting/asynchronous review: Integration Architecture for Data Providers

Error Code and Error Handling

SIS systems shared that today they do not re-write Ed-Fi API error messages. When asked they would use a new "error code", the response was generally that this would be a lot of work, and the hope is to avoid that.
They shared that their primary desire is for API error messages to be understandable by a LEA staff who uses the SIS, who is likely non-technical. The primary use cases they envision to just forward messages as is (what they do today)
The SIS systems did also say they see the need for a technically detailed and accurate message, as a means of supporting developers. However, per the above points, such a message is not appropriate for a district SIS user, who it confuses.
When asked if they see future utility in the error codes, most SIS systems said they would like that option and may use it as their work goes forward.
Some suggestions:
- have 2 error messages: 1 for technical users/developers and 1 for district SIS users (also, SIS system participants pointed out that a new developer would also benefit from the "simpler" message)
- Include both a simple and a technical message with some kind of delimiter, but put the simple message first
- avoid ANY technical jargon in the simpler message (the example from the deck was why even say "uri" - just say "code value")

Alliance support for SEA alignment

Generally like the SEA Playbook direction - want to review the details more

Some narrow points of feedback:

for SEA planning, 3-6 months planning is not enough - needs to be 6-12
The planning stage needs to end (and only end) when a SEA Swagger/sandbox is released
as a (new) best practice, states should solicit feedback from vendors on their data modeling / API specifications
the misalignment can lies with the MSP or consultant a state is using; in particular, the guidance should be strongly to use Ed-Fi as it is defined, and not to "recreate" the current data model of the SEA via extensions and re-writes, as this adds huge overhead to vendors work across states

On the review of SEA data specifications