Callback für eine Destination optional machen

Warum machen wir das?

Relevante Links

Akzeptanzkriterien

Funktionale Anforderungen

1. ...
2. ...
3. ...

Nicht-funktionale Anforderungen

Definition of Done

• Dokumentation:
  • API-Changes sind für Konsumenten der API dokumentiert
  • Prozessänderungen sind für Konsumenten der API dokumentiert
• Code:
  • Code Qualität & Formatierung eingehalten
  • Commits orientieren sich an Conventional Commits
  • Bei neuen Dateien sind Lizenz- und Urheberrechtshinweise gemäs der REUSE-Spezifikation vorhanden
• Leistung:
  • Code ist in einer Testinstanz deployt
  • Es gibt keine bekannten Bugs
• Testen:
  • Alle funktionale Anforderungen sind durch Testfälle abgedeckt

Kann die Story umgesetzt werden? (Definition Ready)

• Ist für jeden Beteiligten klar verständlich
• Ist geschätzt
• Hat Akzeptanzkriterien
• Von der API-Änderung betroffene Softwareartefakte sind im Durchführungsplan identifiziert

Durchführungsplan

Betroffene Softwareartefakte

• Zustelldienst
• Self-Service-Portal
• OAuth Dienst
• Token Validator / API-Gateway
• Software Tools und SDKs für Entwickler

Umsetzungsschritte

• ...
• ...
• ...

Als Verfahrensbetreiber,

kann ich eventuell nicht keinen Callback für Benachrichtungen technisch umsetzen und benutze daher stattdessen GET Requests, um die Informationen zu bekommen. Daher soll ich nicht gezwungen werden einen Callback anzugeben.

Relevante Links

Funktionale Anforderungen

1. Callback ist ein optionales Attribut in der Destination