Block 06 · Schnittstellen & Datenformate – Lösungen

a) Bestandteile (2 P)

b) Wohlgeformt und gültig (4 P)

Erklärung: Die Falle steckt in b): Viele schreiben „gültig, weil kein Fehler drin ist“. Gültigkeit ist aber immer relativ zu einer Grammatik. Ohne DTD/XSD ist ein Dokument höchstens wohlgeformt.

a) Deklarationen (4 P)

b) DTD für den Lieferschein (6 P)

 1  <!ELEMENT lieferschein (kunde, position+, fahrer?)>
 2  <!ATTLIST lieferschein nr    CDATA #REQUIRED
 3                         datum CDATA #REQUIRED>
 4  <!ELEMENT kunde (name, adresse)>
 5  <!ATTLIST kunde kundenNr CDATA #REQUIRED>
 6  <!ELEMENT name (#PCDATA)>
 7  <!ELEMENT adresse (#PCDATA)>
 8  <!ELEMENT position (kiste, anzahl, bemerkung*)>
 9  <!ELEMENT kiste (#PCDATA)>
10  <!ELEMENT anzahl (#PCDATA)>
11  <!ELEMENT bemerkung (#PCDATA)>
12  <!ELEMENT fahrer (#PCDATA)>

Test · Aufgabe_SD_01_2.java (JDK-Parser mit Validierung, DTD per EntityResolver eingebunden)

--- Lieferschein aus Anlage 6
    gültig (wohlgeformt und DTD-konform)
--- Negativtest 1: keine Position (position+ verlangt mindestens eine)
    ungültig, Zeile 9: Content des Elementtyps "lieferschein" muss "(kunde,position+,fahrer?)" entsprechen.
--- Negativtest 2: Pflichtattribut nr fehlt
    ungültig, Zeile 3: Attribut "nr" ist erforderlich und muss für Elementtyp "lieferschein" angegeben werden.
--- Negativtest 3: anzahl vor kiste (Reihenfolge der Sequenz)
    ungültig, Zeile 11: Content des Elementtyps "position" muss "(kiste,anzahl,bemerkung*)" entsprechen.
--- Negativtest 4: zwei Fahrer (fahrer? erlaubt höchstens einen)
    ungültig, Zeile 20: Content des Elementtyps "lieferschein" muss "(kunde,position+,fahrer?)" entsprechen.
--- Positivtest: ohne Fahrer (optional) und ohne Bemerkung
    gültig (wohlgeformt und DTD-konform)

Erklärung: Jede Regel des Aufgabentexts wird zu genau einer Angabe: „genau ein“ = ohne Zeichen, „mindestens ein“ = +, „optional“ = ?, „beliebig viele, auch keine“ = *. Typischer Fehler: bemerkung+ (verlangt mindestens eine Bemerkung) oder Attribute als Kindelemente deklarieren.

a) Zweck der DTD (2 P)

Die DTD legt verbindlich fest, wie ein Wochenangebot aufgebaut sein muss: welche Elemente und Attribute erlaubt sind, in welcher Reihenfolge und Anzahl sie vorkommen und welche Angaben Pflicht sind. Sie ist damit die gemeinsame Schnittstellenvereinbarung zwischen den 28 Erzeugerbetrieben und dem KistenPortal. Mit ihr kann jede hochgeladene Datei vor dem Import automatisch validiert werden; fehlerhafte Dateien werden mit einer Meldung abgewiesen, statt falsche Daten zu importieren.

b) Fehler im Wochenangebot (8 P)

Kontrolle mit dem JDK-Parser · Aufgabe_SD_01_3.java (Auszug der Ausgabe)

--- 1a) Originaldatei Anlage 5
    GÜLTIGKEIT     Zeile 3: Attribut "jahr" ist erforderlich und muss für Elementtyp "wochenangebot" angegeben werden.
    WOHLGEFORMTHEIT Zeile 15: Elementtyp "bezeichnung" muss mit dem entsprechenden Endtag "</bezeichnung>" beendet werden.  -> Parser bricht ab
--- 1b) nach Korrektur Zeile 15
    ... (Gültigkeitsfehler Zeilen 3, 24, 25, 25, 29)
    WOHLGEFORMTHEIT Zeile 30: Elementtyp "menge" muss mit dem entsprechenden Endtag "</menge>" beendet werden.  -> Parser bricht ab
--- 1c) nach Korrektur Zeile 27
    ...
    WOHLGEFORMTHEIT Zeile 31: Öffnendes Anführungszeichen wird für Attribut "artNr" erwartet, das mit Elementtyp "artikel" verknüpft ist.  -> Parser bricht ab
--- 2) nach Korrektur Zeile 31: wohlgeformt, Prüfung gegen die DTD
    GÜLTIGKEIT     Zeile 3: Attribut "jahr" ist erforderlich und muss für Elementtyp "wochenangebot" angegeben werden.
    GÜLTIGKEIT     Zeile 24: Content des Elementtyps "artikel" muss "(bezeichnung,menge,preis,hinweis*)" entsprechen.
    GÜLTIGKEIT     Zeile 25: Attributwert "A-101" mit dem Typ ID muss eindeutig im Dokument sein.
    GÜLTIGKEIT     Zeile 25: Attribut "einheit" mit Wert "Kilo" muss einen Wert aus der Liste "kg stueck bund " haben.
    GÜLTIGKEIT     Zeile 29: Elementtyp "lieferant" muss deklariert werden.
    GÜLTIGKEIT     Zeile 30: Content des Elementtyps "artikel" muss "(bezeichnung,menge,preis,hinweis*)" entsprechen.
--- 3) korrigierte Fassung
    gültig (wohlgeformt und DTD-konform)

Der Parser meldet Verstöße gegen das Inhaltsmodell erst beim End-Tag (Zeile 24 bzw. 30) und den fehlenden Schrägstrich aus Zeile 27 erst in Zeile 30, wo das falsche End-Tag </artikel> auftaucht. In der Prüfung gibst du die Zeile an, in der der Fehler entsteht. Die vollständig korrigierte Datei steht in Aufgabe_SD_01_3.java (Konstante KORRIGIERT); in Zeile 25 wurde dort die neue Artikelnummer A-104 und die Einheit kg gewählt.

c) Gültig, aber unsinnig (4 P)

Warum die Prüfung bestanden wird: In der DTD sind menge und preis als (#PCDATA) deklariert, also als beliebiger Text. Eine DTD kennt keine Datentypen und keine Wertebereiche; sie prüft nur, ob die Elemente vorhanden sind und in der richtigen Reihenfolge stehen. „ca. 80“ und „-1.90“ sind Text und damit zulässig.

Maßnahmen (zwei davon):

• XML-Schema statt DTD mit Datentypen und Einschränkungen, z. B. menge als positive ganze Zahl und preis als Dezimalzahl größer 0 (Auszug unten, getestet: die KW-47-Datei wird abgewiesen).
• Plausibilitätsprüfung im Importprogramm (Geschäftsregeln): Menge numerisch und größer 0, Preis größer 0 und in einem realistischen Bereich; fehlerhafte Dateien mit Fehlermeldung an den Erzeuger zurückgeben.
• Alternativ: Schematron-Regeln, Eingabe über ein Webformular mit Feldprüfung statt Datei-Upload, automatisierte Tests mit fehlerhaften Beispieldateien.

<xs:element name="artikel">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="bezeichnung" type="xs:string"/>
      <xs:element name="menge" type="xs:positiveInteger"/>
      <xs:element name="preis">
        <xs:simpleType>
          <xs:restriction base="xs:decimal">
            <xs:minExclusive value="0"/>
            <xs:fractionDigits value="2"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
      <xs:element name="hinweis" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="artNr" type="xs:ID" use="required"/>
    <xs:attribute name="einheit" default="kg">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:enumeration value="kg"/>
          <xs:enumeration value="stueck"/>
          <xs:enumeration value="bund"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
</xs:element>

Ausgabe des Tests mit diesem Schema

wochenangebot_korrigiert.xml: XSD-gueltig
wochenangebot_kw47.xml: Zeile 10 cvc-datatype-valid.1.2.1: 'ca. 80' ist kein gültiger Wert für 'integer'.

Ausgabe von Aufgabe_SD_01_3.java (eigene Plausibilitätsprüfung nach erfolgreicher DTD-Validierung)

--- 4) Datei KW 47 gegen die DTD
    gültig (wohlgeformt und DTD-konform)
    ... aber fachliche Prüfung:
    PLAUSIBILITÄT A-110: Menge ist keine ganze Zahl ("ca. 80")
    PLAUSIBILITÄT A-110: Preis muss positiv sein (-1.90)

d) Vorteile eines XML-Schemas (2 P)

• Datentypen und Wertebereiche (Zahl, Datum, Minimum/Maximum, Muster) sind prüfbar.
• Genaue Kardinalitäten über minOccurs/maxOccurs (z. B. 2 bis 5).
• Ein Schema ist selbst ein XML-Dokument (mit XML-Werkzeugen bearbeit- und prüfbar), unterstützt Namensräume und wiederverwendbare eigene Typen.

Erklärung: b) ist die Aufgabe aus W22 in neuem Gewand: erst alle Tags auf Wohlgeformtheit prüfen (Zeilen 15, 27, 31), dann Element für Element gegen die DTD (Zeilen 3, 22/23, 25, 29). c) und d) zeigen die Grenze der DTD, die in W25 bei der eRechnung abgefragt wurde.

a) Objekt und Array (2 P)

Ein Objekt steht in geschweiften Klammern { } und ist eine ungeordnete Menge von Schlüssel-Wert-Paaren; auf einen Wert greift man über seinen Namen (Schlüssel, immer ein String) zu, z. B. eine Kiste mit "kisteId" und "preis". Ein Array steht in eckigen Klammern [ ] und ist eine geordnete Liste von Werten ohne Schlüssel; auf einen Wert greift man über seine Position (Index) zu, z. B. eine Liste mehrerer Kisten.

b) Fehler (4 P)

Korrigiertes Dokument (mit Python json geprüft)

{
  "kisteId": "K-MIX-S",
  "preis": 14.20,
  "bio": false,
  "inhalt": ["Äpfel", "Möhren", "Kartoffeln"]
}

a) Tabelle Kiste als JSON (5 P)

{
  "kisten": [
    {
      "kisteId": "K-OBST-M",
      "bezeichnung": "Obstkiste mittel",
      "groesse": "M",
      "preis": 18.50,
      "bio": true,
      "gewichtKg": 4.5,
      "saisonEnde": null
    },
    {
      "kisteId": "K-GEM-L",
      "bezeichnung": "Gemüsekiste groß",
      "groesse": "L",
      "preis": 27.90,
      "bio": true,
      "gewichtKg": 8.0,
      "saisonEnde": "2027-03-31"
    },
    {
      "kisteId": "K-MIX-S",
      "bezeichnung": "Mischkiste klein",
      "groesse": "S",
      "preis": 14.20,
      "bio": false,
      "gewichtKg": 3.0,
      "saisonEnde": null
    }
  ]
}

b) Eingebettetes Array inhalt (3 P)

Das Objekt der Kiste K-OBST-M aus a) mit eingebettetem Inhalt:

{
  "kisteId": "K-OBST-M",
  "bezeichnung": "Obstkiste mittel",
  "groesse": "M",
  "preis": 18.50,
  "bio": true,
  "gewichtKg": 4.5,
  "saisonEnde": null,
  "inhalt": [
    { "artikel": "Äpfel Elstar", "menge": 1.5, "einheit": "kg" },
    { "artikel": "Birnen Conference", "menge": 1, "einheit": "kg" },
    { "artikel": "Bananen", "menge": 6, "einheit": "Stück" }
  ]
}

c) Gründe für JSON (2 P)

• geringere Datenmenge als XML (keine End-Tags, kein Prolog) – wichtig bei Mobilfunkverbindungen,
• lässt sich direkt in Objekte der App-Programmiersprache umwandeln (JavaScript, Kotlin, Swift, Java) und ist einfacher und schneller zu verarbeiten,
• eingebaute Datentypen (Zahl, Boolean, null),
• De-facto-Standard für REST-APIs mit vielen Bibliotheken.

Erklärung: Die meisten Punktabzüge entstehen durch Datentypen: "ja" statt true, "18.50" als String, ein leerer String "" statt null. Alle Lösungen wurden mit Python json.load auf Syntax geprüft.

a) Kunden und Lieferadressen mit Referenz (5 P)

{
  "kunden": [
    {
      "kundenNr": 10427,
      "name": "Jana Petersen",
      "kundentyp": "privat",
      "email": "j.petersen@mail.example",
      "newsletter": true
    },
    {
      "kundenNr": 20015,
      "name": "Kita Sonnenblume",
      "kundentyp": "oeffentlich",
      "email": "verwaltung@kita-sonnenblume.example",
      "newsletter": false
    }
  ],
  "lieferadressen": [
    {
      "adrId": 1,
      "kundenNr": 10427,
      "strasse": "Lindenweg 4",
      "plz": "21391",
      "ort": "Heidmoor",
      "ablageort": "Garage"
    },
    {
      "adrId": 2,
      "kundenNr": 10427,
      "strasse": "Hafenstraße 18",
      "plz": "21423",
      "ort": "Kleinmoor",
      "ablageort": null
    },
    {
      "adrId": 3,
      "kundenNr": 20015,
      "strasse": "Am Mühlenbach 3",
      "plz": "21391",
      "ort": "Heidmoor",
      "ablageort": "Küche, Hintereingang"
    }
  ]
}

b) Lieferadressen eingebettet (3 P)

{
  "kundenNr": 10427,
  "name": "Jana Petersen",
  "kundentyp": "privat",
  "email": "j.petersen@mail.example",
  "newsletter": true,
  "lieferadressen": [
    {
      "adrId": 1,
      "strasse": "Lindenweg 4",
      "plz": "21391",
      "ort": "Heidmoor",
      "ablageort": "Garage"
    },
    {
      "adrId": 2,
      "strasse": "Hafenstraße 18",
      "plz": "21423",
      "ort": "Kleinmoor",
      "ablageort": null
    }
  ]
}

c) Embedding oder Referenz (4 P)

d) offeneStoppsAlsJson (8 P)

funktion offeneStoppsAlsJson(stopps : List<Stopp>) : string
  json : string := "["
  erster : boolean := true                    // wurde schon ein Objekt ausgegeben?
  zähle i von 0 bis stopps.size() - 1
    s : Stopp := stopps.get(i)
    wenn nicht s.isZugestellt() dann
      wenn nicht erster dann
        json := json + ", "                   // Komma nur ZWISCHEN den Objekten
      Ende wenn
      json := json + "{\"position\": " + s.getPosition()
                   + ", \"kundenNr\": " + s.getKundenNr()
                   + ", \"ort\": \"" + s.getOrt() + "\""
                   + ", \"kisten\": " + s.getAnzahlKisten() + "}"
      erster := false
    Ende wenn
  Ende zähle
  json := json + "]"
  rückgabe json
Ende funktion

Java · Aufgabe_SD_02_3.java (Auszug)

static String offeneStoppsAlsJson(List<Stopp> stopps) {
    String json = "[";
    boolean erster = true;
    for (int i = 0; i < stopps.size(); i++) {
        Stopp s = stopps.get(i);
        if (!s.isZugestellt()) {
            if (!erster) {
                json = json + ", ";                  // Trennzeichen nur ZWISCHEN Objekten
            }
            json = json + "{\"position\": " + s.getPosition()
                    + ", \"kundenNr\": " + s.getKundenNr()
                    + ", \"ort\": \"" + s.getOrt() + "\""   // Zeichenkette in Anführungszeichen
                    + ", \"kisten\": " + s.getAnzahlKisten() + "}";
            erster = false;
        }
    }
    json = json + "]";
    return json;
}

Ausgabe (die erste Zeile wurde zusätzlich mit Python json.loads als gültiges JSON bestätigt)

Tour T3 (Anlage 9):
[{"position": 2, "kundenNr": 20015, "ort": "Heidmoor", "kisten": 6}, {"position": 3, "kundenNr": 10533, "ort": "Wiesede", "kisten": 1}, {"position": 5, "kundenNr": 20022, "ort": "Wiesede", "kisten": 4}]
Leere Liste:            []
Alles zugestellt:       []
Nur letzter Stopp offen: [{"position": 2, "kundenNr": 20022, "ort": "Wiesede", "kisten": 4}]

Erklärung: Der Klassiker ist die Kommaregel. Mit wenn i > 0 entstünde hier [, {"position": 2 …, weil Stopp 1 (Index 0) zugestellt ist und gar nicht ausgegeben wird – ungültiges JSON. Deshalb merkt sich die Lösung, ob schon ein Objekt geschrieben wurde. Zweite häufige Fehlerquelle: der Ort ohne maskierte Anführungszeichen.

a) CRUD-Tabelle (4 P)

b) Zustandslosigkeit (2 P)

Der Server speichert zwischen zwei Requests keinen Sitzungszustand der App. Jeder Request muss deshalb alle Informationen enthalten, die zu seiner Bearbeitung nötig sind: den API-Schlüssel bzw. das Token in jedem Request, die betroffene Ressource in der URI (z. B. Kundennummer) und alle Nutzdaten im Body. Der Server kann jeden Request unabhängig von vorherigen bearbeiten; dadurch kann z. B. jeder von mehreren Servern jeden Request beantworten (Lastverteilung).

a) Endpunkte (6 P)

b) Pfad- und Query-Parameter (2 P)

Pfadparameter sind Teil der Ressourcenadresse und identifizieren eine bestimmte Ressource, z. B. 10427 und 5531 in /kunden/10427/abos/5531 – ohne sie wäre nicht klar, welches Abo gemeint ist. Query-Parameter stehen nach dem ? als name=wert, sind meist optional und filtern, sortieren oder begrenzen eine Ergebnisliste, z. B. bio=true&groesse=L bei /kisten.

c) Zweck von /v1 (2 P)

/v1 kennzeichnet die Version der Schnittstelle. Wird die API später inkompatibel geändert (Felder umbenannt, Struktur geändert), wird sie als /v2 veröffentlicht, während /v1 weiterläuft. So funktionieren bereits installierte, nicht aktualisierte Apps und Partner-Anbindungen weiter und können schrittweise umgestellt werden.

a) Konzept einer REST-API (3 P)

Eine REST-API stellt die Daten des KistenPortals als Ressourcen bereit (Kisten, Kunden, Abos …), die jeweils über eine eindeutige URI adressiert werden. Clients greifen über die Standardmethoden von HTTP darauf zu (GET lesen, POST anlegen, PUT/PATCH ändern, DELETE löschen) und tauschen Repräsentationen der Ressourcen aus, meist im JSON-Format. Die Kommunikation ist zustandslos: Jede Anfrage enthält alle nötigen Informationen, der Server speichert keine Sitzung. Client und Server sind dadurch lose gekoppelt, sodass App, Webshop und Partner dieselbe Schnittstelle nutzen können.

b) Sicher und idempotent (5 P)

c) Doppeltes Abo (4 P)

Ursache: „Abo abschließen“ sendet einen POST-Request, und POST ist nicht idempotent. Der erste Request ist beim Server angekommen und hat das Abo angelegt, nur die Antwort (201) ging bei der schlechten Verbindung verloren. Das erneute Tippen sendet einen zweiten POST, der ein zweites, identisches Abo anlegt.

Lösung: Die App erzeugt für jeden Bestellvorgang einen eindeutigen Idempotenzschlüssel (z. B. eine UUID) und sendet ihn in einem Header (z. B. Idempotency-Key) mit. Der Server merkt sich bereits verarbeitete Schlüssel und liefert bei einer Wiederholung die ursprüngliche Antwort zurück, statt ein neues Abo anzulegen. Weitere mögliche Lösungen: Die App vergibt die Abo-ID selbst und legt das Abo mit PUT /kunden/10427/abos/{uuid} an (idempotent); der Server prüft auf Dubletten (gleiche Kundin, gleiche Kiste innerhalb kurzer Zeit) und antwortet mit 409.

d) PUT und PATCH (4 P)

PUT /v1/kunden/10427/abos/5531 HTTP/1.1

{"aboId": 5531, "kundenNr": 10427, "kisteId": "K-OBST-M", "rhythmus": "woechentlich",
 "liefertag": "DO", "lieferadresseId": 1, "status": "aktiv", "pausiertBis": null}

PATCH /v1/kunden/10427/abos/5531 HTTP/1.1

{"liefertag": "DO"}

e) REST und SOAP (2 P)

• REST ist ein Architekturstil, SOAP ein festgelegtes Protokoll.
• REST erlaubt beliebige Formate (meist JSON), SOAP nutzt ausschließlich XML (SOAP-Envelope).
• REST verwendet die HTTP-Methoden auf Ressourcen-URIs; bei SOAP steht die Operation im XML-Body, meist per POST an einen einzigen Endpunkt.
• SOAP-Dienste werden verbindlich per WSDL beschrieben, bei REST ist eine Beschreibung (z. B. OpenAPI) optional.

Erklärung: b) prüft Verständnis statt Auswendiglernen: Ob ein PATCH idempotent ist, hängt von der konkreten Änderung ab. Das Setzen fester Werte ist idempotent, „erhöhe um 1“ wäre es nicht. Der Body des PUT in d) wurde gegen die Repräsentation aus Anlage 2 geprüft (alle acht Felder, nur der Liefertag ist geändert).

a) Statuscode-Klassen (3 P)

b) Ursachen für 404 (2 P)

• Die App ruft eine falsche oder veraltete URL auf (Tippfehler im Pfad, z. B. /abo statt /abos, oder eine API-Version, die es nicht mehr gibt).
• Die Kundennummer im Pfad existiert nicht (mehr), z. B. weil das Kundenkonto gelöscht oder zusammengelegt wurde.
• Der Endpunkt ist auf dem Server nicht vorhanden bzw. nicht eingerichtet (falsche Basis-URL, z. B. Testserver, fehlerhafte Auslieferung/Routing).

c) Statuscode bei Wartung (1 P)

503 Service Unavailable (idealerweise mit dem Header Retry-After).

a) Bestandteile des Requests (4 P)

ba) Parameter der URL (3 P)

bb) Nachteil des Schlüssels in der URL (1 P)

URLs werden in Server- und Proxy-Protokollen, im Browserverlauf und in Monitoring-Werkzeugen gespeichert; dort kann der Schlüssel ausgelesen und missbraucht werden (z. B. Anfragen auf Kosten der FrischeKiste). Besser: Übertragung im Header.

c) Statuscodes (4 P)

a) createErrorResponse (8 P)

private funktion createErrorResponse(statusCode : integer, meldung : string) : HttpResponse
  body : string := "{\"status\": " + statusCode + ", \"fehler\": \"" + meldung + "\"}"
  response : HttpResponse := new HttpResponse()
  response.setStatus(statusCode)
  response.setHeader("Content-Type", "application/json; charset=utf-8")
  response.setHeader("Content-Length", body.byteLength().toString())   // Bytes, nicht Zeichen
  response.setBody(body)
  rückgabe response
Ende funktion

b) Zeichen und Bytes (3 P)

length() zählt Zeichen, Content-Length muss aber die Länge des Bodys in Bytes angeben. In UTF-8 belegen Umlaute und ß 2 Bytes, das Eurozeichen 3 Bytes. Enthält die Meldung solche Zeichen, ist der Wert zu klein: Der Client liest dann zu wenig Bytes und schneidet den Body ab (ungültiges JSON) bzw. der Rest wird als Beginn der nächsten Nachricht fehlinterpretiert.

Body {"status": 503, "fehler": "Katalog vorübergehend nicht verfügbar"}: 66 Zeichen, davon zweimal ü → Content-Length: 68.

c) handleGetKiste (9 P)

funktion handleGetKiste(request : HttpRequest) : HttpResponse
  // 1. Authentifizierung
  key : string := request.getHeader("X-API-Key")
  wenn key = null oder nicht schluessel.istGueltig(key) dann
    rückgabe createErrorResponse(401, "API-Schlüssel fehlt oder ist ungültig")
  Ende wenn
  // 2. Verfügbarkeit des Katalogs
  wenn nicht katalog.istVerfuegbar() dann
    rückgabe createErrorResponse(503, "Katalog vorübergehend nicht verfügbar")
  Ende wenn
  // 3. Kiste suchen
  kisteId : string := request.getPfadParameter("kisteId")
  kiste : Kiste := katalog.findeKiste(kisteId)
  wenn kiste = null dann
    rückgabe createErrorResponse(404, "Kiste " + kisteId + " nicht gefunden")
  Ende wenn
  // 4. Erfolg
  body : string := kiste.toJson()
  response : HttpResponse := new HttpResponse()
  response.setStatus(200)
  response.setHeader("Content-Type", "application/json; charset=utf-8")
  response.setHeader("Content-Length", body.byteLength().toString())
  response.setBody(body)
  rückgabe response
Ende funktion

Java · Aufgabe_SD_04_3.java (Auszug)

private HttpResponse createErrorResponse(int statusCode, String meldung) {
    String body = "{\"status\": " + statusCode + ", \"fehler\": \"" + meldung + "\"}";
    HttpResponse response = new HttpResponse();
    response.setStatus(statusCode);
    response.setHeader("Content-Type", "application/json; charset=utf-8");
    response.setHeader("Content-Length", String.valueOf(byteLength(body)));   // Bytes, nicht Zeichen!
    response.setBody(body);
    return response;
}

HttpResponse handleGetKiste(HttpRequest request) {
    String key = request.getHeader("X-API-Key");
    if (key == null || !schluessel.istGueltig(key)) {
        return createErrorResponse(401, "API-Schlüssel fehlt oder ist ungültig");
    }
    if (!katalog.istVerfuegbar()) {
        return createErrorResponse(503, "Katalog vorübergehend nicht verfügbar");
    }
    String kisteId = request.getPfadParameter("kisteId");
    Kiste kiste = katalog.findeKiste(kisteId);
    if (kiste == null) {
        return createErrorResponse(404, "Kiste " + kisteId + " nicht gefunden");
    }
    String body = kiste.toJson();
    HttpResponse response = new HttpResponse();
    response.setStatus(200);
    response.setHeader("Content-Type", "application/json; charset=utf-8");
    response.setHeader("Content-Length", String.valueOf(byteLength(body)));
    response.setBody(body);
    return response;
}

// byteLength() aus Anlage 4:
static int byteLength(String text) {
    return text.getBytes(StandardCharsets.UTF_8).length;
}

Ausgabe (Auszug)

=== 1) ohne X-API-Key
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Content-Length: 68

{"status": 401, "fehler": "API-Schlüssel fehlt oder ist ungültig"}
[Kontrolle] Zeichen im Body: 66, Bytes (UTF-8): 68, Content-Length korrekt: true

=== 3) unbekannte Kiste
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8
Content-Length: 57

{"status": 404, "fehler": "Kiste K-XXL-Z nicht gefunden"}
[Kontrolle] Zeichen im Body: 57, Bytes (UTF-8): 57, Content-Length korrekt: true

=== 4) Kiste gefunden
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 104

{"kisteId": "K-GEM-L", "bezeichnung": "Gemüsekiste groß", "groesse": "L", "preis": 27.90, "bio": true}
[Kontrolle] Zeichen im Body: 102, Bytes (UTF-8): 104, Content-Length korrekt: true

=== 5) Katalog nicht verfügbar (Teil b)
HTTP/1.1 503 Service Unavailable
Content-Type: application/json; charset=utf-8
Content-Length: 68

{"status": 503, "fehler": "Katalog vorübergehend nicht verfügbar"}
[Kontrolle] Zeichen im Body: 66, Bytes (UTF-8): 68, Content-Length korrekt: true

Erklärung: Die Aufgabe entspricht W24 T2 A2a, erweitert um die Prüfreihenfolge. Typische Fehler: kein rückgabe nach einem Fehlerfall (die Methode läuft dann weiter und überschreibt die Antwort), istGueltig(null) vor der Null-Prüfung, Content-Length in Zeichen, und im 404-Text der wörtliche Text „kisteId“ statt des Werts der Variablen.

a) Hauptziel (2 P)

Das Hauptziel einer eRechnung ist die automatische, elektronische Verarbeitung beim Empfänger: Die Rechnungsdaten liegen strukturiert (als XML) vor und können ohne Abtippen direkt in Buchhaltung bzw. ERP-System übernommen, geprüft und gebucht werden. Das spart Zeit und Kosten und vermeidet Erfassungsfehler. Eine für Menschen lesbare Darstellung ist dabei zweitrangig.

b) eRechnung oder nicht? (4 P)

a) Empfangen und ausstellen (3 P)

• Empfangen: Seit dem 1. Januar 2025 müssen alle Unternehmen in Deutschland eRechnungen von anderen Unternehmen empfangen können.
• Ausstellen – Übergangszeit: Bis Ende 2026 dürfen Unternehmen noch Papierrechnungen oder andere elektronische Formate wie PDF versenden (PDF nur mit Zustimmung des Empfängers). Im Jahr 2027 gilt das nur noch für Unternehmen, deren Gesamtumsatz im Vorjahr höchstens 800.000 € betrug.
• Ausstellen – Pflicht: Ab dem 1. Januar 2028 müssen alle Unternehmen eRechnungen ausstellen (ausgenommen Rechnungen bis 250 € und Fahrausweise).

b) XRechnung und ZUGFeRD (4 P)

XRechnung ist ein rein XML-basiertes Format: Die Rechnung besteht nur aus strukturierten Daten für die Software (Datenaspekt). Ein Mensch kann sie nur mit einem Anzeigeprogramm (Viewer) lesen. Viele Behörden verlangen XRechnung und nutzen die Leitweg-ID, um die Rechnung an die zuständige Stelle weiterzuleiten.

ZUGFeRD ist ein hybrides Format: ein PDF/A-3-Dokument, das ein Mensch direkt lesen kann, mit einer eingebetteten XML-Datei, die die Software verarbeitet. Es vereint also visuellen und Datenaspekt. Weichen beide Teile voneinander ab, gelten die XML-Daten.

c) PDF-Rechnungen im Jahr 2027 (3 P)

Geschäftskunden (B2B): Nicht mehr zulässig. Die FrischeKiste erwartet für 2026 einen Umsatz von rund 4,6 Mio. € und liegt damit deutlich über 800.000 €. Die Übergangsregel für 2027 gilt daher nicht; ab dem 1. Januar 2027 müssen Rechnungen an Geschäftskunden als eRechnung ausgestellt werden (ausgenommen Kleinbetragsrechnungen bis 250 €).

Privatkunden (B2C): weiterhin zulässig, denn Rechnungen an Privatkunden sind von der Pflicht nicht betroffen.

Erklärung: c) verlangt, den Text auf die Situation anzuwenden: Entscheidend ist der Umsatz des Vorjahres (2026) – diese Angabe steht in Anlage 1, nicht im Text.

a) Konformität sicherstellen (3 P)

• Jede erzeugte Rechnung mit dem offiziellen Validator (KoSIT-Validator: XSD und Schematron) prüfen – auch automatisiert im Build- bzw. Testprozess.
• Die Spezifikation (XRechnung/EN 16931) konsequent umsetzen, insbesondere alle verpflichtenden Angaben und Regeln.
• Erprobte Bibliotheken zur Erzeugung der XML-Dateien verwenden, statt alles selbst zu programmieren.
• Automatisierte Tests (Unit- und Integrationstests) mit den offiziellen Testrechnungen und eigenen Grenzfällen.
• Testläufe mit den Empfängern: Testrechnungen an die Testumgebung des Rechnungsportals der Stadt bzw. an Geschäftskunden senden (Interoperabilität).

b) Online-Prüfseite (4 P)

• Datenschutz und Geheimhaltung: Echte Rechnungen enthalten personenbezogene Daten (Namen, Anschriften, ggf. Bankverbindung) und Geschäftsdaten (Preise, Mengen, Kunden). Das Hochladen auf eine fremde Website ist eine Übermittlung an Dritte, für die es keine Rechtsgrundlage gibt (DSGVO). Deshalb nur Test- oder anonymisierte Rechnungen hochladen.
• Vertrauenswürdigkeit und Aussagekraft: Den Anbieter prüfen (Impressum, Serverstandort, Datenschutzerklärung, Speicherdauer). Das Ergebnis kann falsch, unvollständig oder veraltet sein (z. B. nur XSD statt Schematron, alte XRechnung-Version); es ersetzt keine Prüfung mit dem offiziellen Validator. Besser den KoSIT-Validator lokal betreiben.

c) Warum die Schema-Validierung nicht reicht (6 P)

Erläuterung: Das XML-Schema prüft nur die Struktur (Elemente, Reihenfolge, Pflichtangaben) und die Datentypen einzelner Werte – hier, dass die Datumsangaben gültige Daten und die Beträge Dezimalzahlen sind. Das ist bei allen Werten der Fall. Logische und rechnerische Zusammenhänge zwischen mehreren Werten (Fälligkeit nach Rechnungsdatum, Menge × Preis = Nettobetrag, Summen) lassen sich mit einer XSD nicht ausdrücken. Dafür sind zusätzlich Geschäftsregeln nötig, z. B. die Schematron-Regeln der EN 16931/XRechnung im Validator sowie Plausibilitätsprüfungen und Tests der eigenen Berechnungslogik.

Kontrolle · Aufgabe_SD_05_3.java (Schema-Validierung mit javax.xml.validation, danach Geschäftsregeln)

Schritt 1 - Schema-Validierung: XSD-gültig
Schritt 2 - Geschäftsregeln:
  Regel 1 verletzt: Fälligkeitsdatum 2026-11-16 liegt vor dem Rechnungsdatum 2026-11-30
  Regel 2 verletzt: Position 2: Menge x Einzelpreis = 111.60, angegeben 101.60
  Regel 3 verletzt: Summe der Positionsbeträge = 249.60, Nettogesamt angegeben 259.60
  Regel 5 verletzt: Netto + USt = 277.77, Bruttogesamt angegeben 278.77

Gegenprobe A (Dezimalkomma 18,50): XSD-Fehler in Zeile 17: cvc-datatype-valid.1.2.1: '18,50' ist kein gültiger Wert für 'decimal'.
Gegenprobe B (ungültiges Datum 2026-11-31): XSD-Fehler in Zeile 4: cvc-datatype-valid.1.2.1: '2026-11-31' ist kein gültiger Wert für 'date'.
Gegenprobe C (Element summen fehlt): XSD-Fehler in Zeile 29: cvc-complex-type.2.4.b: Content des Elements 'rechnung' ist nicht vollständig. …

Die Gegenproben zeigen, was das Schema sehr wohl erkennt: falsche Datentypen, unmögliche Daten und fehlende Elemente. Die Umsatzsteuer (7 % von 259,60 € = 18,17 €) ist korrekt (Regel 4 nicht verletzt). Das verwendete Schema ist vereinfacht (Datei im Java-Programm); echte XRechnungen werden gegen die XSD von UBL bzw. CII geprüft.

d) Transportverschlüsselung (3 P)

da) TLS beruht auf einer hybriden Verschlüsselung: asymmetrisch für den sicheren Austausch eines Sitzungsschlüssels, symmetrisch für die schnelle Übertragung der Daten.

db) TLS verschlüsselt nur die jeweilige Teilstrecke (Mailprogramm → Mailserver, Mailserver → Mailserver). Auf jedem beteiligten Mailserver wird die Nachricht entschlüsselt und liegt dort im Klartext vor; Betreiber oder Angreifer mit Zugriff auf einen Server könnten sie lesen oder verändern. Alternative: Ende-zu-Ende-Verschlüsselung der E-Mail mit S/MIME oder PGP – oder die Übermittlung über Peppol bzw. ein Rechnungsportal (HTTPS).

e) Leitweg-ID (2 P)

Die Leitweg-ID ist eine eindeutige Kennung des öffentlichen Rechnungsempfängers (hier der Stadt Heidmoor bzw. der Kita Sonnenblume). Der Auftraggeber teilt sie mit, und sie muss in der XRechnung angegeben werden (Käuferreferenz). Mit ihr wird die Rechnung im Rechnungseingangssystem der Verwaltung automatisch an die zuständige Stelle weitergeleitet und zugeordnet; fehlt sie, wird die Rechnung in der Regel abgelehnt.

Erklärung: c) entspricht W25 T1 A3bc: Dort war der Nettogesamtbetrag aus den Bruttowerten statt aus den Nettowerten gebildet – formal korrekt, fachlich falsch. Genau diese Klasse von Fehlern deckt eine XSD nie ab.