Java- + .NET-SDK: Abgleich der Methodensignaturen

Warum?

Aktuell gibt es noch kleinere Unterschiede zw. Java- und .NET-SDK. Vor der Veröffentlichung der SDKs sollen beide SDKs aneinander angeglichen werden.

Relevante Links und Bemerkungen

Aus Sicht der Nutzer:innen der SDKs werden folgende Funktionalitäten benötigt, die von beiden SDKs abgedeckt werden können müssen:

Funktionalitäten des Senders

• Initialisierung des SDKs mittels Config-Parameter
• Korrekte DestinationID über Routing API ermitteln
• Angabe von Leistungsschlüssel (leikaKey), Name der Verwaltungsleistung und Fachdatenschema (submissionSchema). Das definierte Schema muss dabei im adressierten Zustellpunkt hinterlegt sein (keine automatische Ermittlung, sondern Prüfung der Übereinstimmung). -> siehe auch: #871 (closed) / #872 (closed)
• Optional: Angabe eines Callback für SET-Events (Secret kann vom SDK definiert werden)
• Bei unverschlüsselter Übergabe von Metadaten, Fachdaten und Anlagen:
  • Übergabe von unverschlüsselten Fachdaten (mimeType: entweder JSON oder XML) und Anlagen (ink. Mimetype, optionalem filename (und optionaler description?); Purpose und attachmentId werden vom SDK festgelegt)
  • Übergabe weiterer Metadaten-Attribute (authenticationInformation, paymentInformation, replyChannel, additionalReferenceInfo) -> ggf. in Folgeissues nach MVP
• Bei verschlüsselter Übergabe von Metadaten, Fachdaten und Anlagen:
  • Anlage der Submission inkl. Liste der angekündigten Anlagen (announcedAttachments)
  • Angabe von attachmentIds von Anlagen
  • Übergabe von verschlüsselten Metadaten (keine Unterscheidung zw. JSON und XML, da ohnehin verschlüsselt), Fachdaten und Anlagen
• Submission-Objekt mit allen relevanten Infos erhalten (submissionId, attachmentIds, caseId, authenticationTags, ...)
• Mit Hilfe des Submission-Objekts den Status einer Submission ermitteln

Funktionalitäten des Subscriber

• Initialisierung des SDKs mittels Config-Parameter
• Verfügbare Submissions ermitteln (destinationId, submissionId, caseId)
• Leistungsschlüssel (leikaKey), Fachdatenschema (submissionSchema.schemaUri) und Mimetype (submissionSchema.mimeType) der Fachdaten ermitteln
• attachmentId, mimeType und (falls vorhanden) filename aller Anlagen ermitteln (Prüfung Filename: Pfad ist Länge 1; keine Ordner im Datennamen enthalten)
• Auf Fachdaten zugreifen (entweder JSON oder XML)
• Prüfung des Fachdaten gegen JSON-Schema
• Attachment auspacken (binary, json, xml)
• Auf weitere Metadaten-Attribute zugreifen -> ggf. später / nach MVP
• Empfangsbestätigung oder Zurückweisung senden (accept-/reject-Event)
• Abruf des Event Log (?) -> ggf. erst Thema für Rückkanal-Epic

Akzeptanzkriterien

1. ClientFactory.senderClient(config).submit(frontendEncryptedPayload) vs. Client.GetSender(FitConnectEnvironment.Testing, clientId, clientSecret, logger).SendAsync(encryptedSubmission)
2. Java: Aufnahme von getSubmissionSchema in ReceivedSubmission
3. .NET-SDK: Wie ermittele ich das Format der Fachdaten in einer abgerufenen Submission? JSON oder XML? Welches Fachdatenschema?
4. Alle oben genannten Funktionlitäten sind im Java-SDK verfügbar.
5. Alle oben genannten Funktionlitäten sind im .NET-SDK verfügbar.
6. Alle nach außen sichtbaren Methodenaufrufe sind in beiden SDKs gleich benannt (Ausnahme: programmiersprachenspezifische Konventionen). (wird in #906 (closed) implementiert)
7. Die von den SDKs zurückgegebenen Objekte sind identisch benannt und bilden dieselbe Datenstruktur ab.
8. Die Dokumentation der SDKs wurde entsprechend der neuen Methoden-/Objektbezeichnungen aktualisiert.
9. Die Struktur der Dokumentation der SDKs ist identisch aufgebaut und enthält dieselben Infos.

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

• Tabelle mit allen öffentlichen Methoden/Objekten in beiden SDKs
• ...
• ...
• Definition of Done wurde geprüft |