Endpunkt EIS

Im Rahmen der Schnittstelle für das EIS stehen folgende Endpunkte zur Verfügung:

API Endpunkt	interner Tabellenname	eindeutiger Schlüssel	Transaktionsauftrag
/eis/rohmilchabrechnung	RM_Abrechnung	RM_Abrechnung, E4_MandantID	X
/eis/rohmilchanlieferung	RM_Anlieferung	RM_AnlieferungID, E4_MandantID	X
/eis/milchgeldabrechnung	MGA	MGAID, E4_MandantID	X
/eis/archiv	Archiv	ArchivID, E4_MandantID	X
/eis/sonderprobe	RM_Sonderprobe	RM_SonderprobeID, E4_MandantID	X
/eis/a2untersuchung	QM_A2_Untersuchung	QM_A2_UntersuchungID, E4_MandantID	X
/eis/rohmilchprobe	RM_Probe	RM_ProbeID, E4_MandantID	X

Jeder Endpunkt kann technisch als eigene Tabelle (Entität) betrachtet werden.

Zu jedem Endpunkt gibt es einen eindeutigen internen Tabellennamen sowie die zugehörigen eindeutigen Schlüssel (Primary Keys).

Ablauf anhand eines Beispiels

Die Endpunkte arbeiten über die auf den ersten Blick als Umweg erscheinenden Transaktionsaufträgen.

Der Grund hierfür lässt sich am einfachsten über ein Beispiel erläutern.

Bei der Bereitstellung der Daten für das Onlineportal können sich zurückliegende Datenänderungen über einen Zeitraum von mehreren Monaten erstrecken. Beim Abruf der Rohmilchabrechnung werden daher neue und alte Daten in Form von eindeutigen Transaktionsaufträgen bereitgestellt:

[
  {
    "transaktionsAuftragID": 180821,
    "methodeName": "Upsert",
    "tabelle": "RM_Abrechnung",
    "schema": "dbo",
    "daten": {
      "RM_AbrechnungID": 25588,
      "E4_MandantID": 1,
      "ST_LieferantID": 1018,
      "Monat": "2024-10-01T00:00:00",
      "Datum": "2024-10-01T00:00:00",
      "RM_Kg": 6496,
      "Fett_RM": 4.55,
      "Eiweiss_RM": 3.19,
      "Guete_Keime": 59,
      "Guete_Zellen": 335,
      "Gefrierpunkt_MW": -0.523,
      "Keime_Monat": 90,
      "Zellen_Monat": 345,
      "Gueteklasse": 1,
      "Bezahlungsklasse": 1,
      "S_Klasse": {},
      "S_Klasse_TX": "-",
      "Hemmstoff_Anzahl": 0,
      "Zellabzug": 0,
      "Freie_Fettsaeuren": {},
      "ArchivID": {},
      "Harnstoff": {},
      "RM_Lt": 6307.2,
      "Probe_pH_Wert": {}
    }
  },
  {
    "transaktionsAuftragID": 180822,
    "methodeName": "Delete",
    "tabelle": "RM_Abrechnung",
    "schema": "dbo",
    "daten": {
      "RM_AbrechnungID": 21270,
      "E4_MandantID": 1,
      "ST_LieferantID": 1027
    }
  }
]

Die Schnittstelle sendet mit dem Transaktionsauftrag (ID=180821) Daten für die Rohmilchabrechnung (RM_AbrechnungID=25588), die übernommen (Upsert) werden soll. Außerdem wird ein Transaktionsauftrag (ID=180822) übergeben, bei dem die Rohmilchabrechnung (RM_AbrechnungID=25770) gelöscht werden soll.

Wenn diese Transaktionsaufträge durch das abrufende Client-System lokal fehlerfrei ausgeführt und übernommen wurden, kann der Transaktionsauftrag auf dem RestAPI-Server gelöscht werden. Dies wird über den Aufruf des Endpunkts /eis/loescheTransaktionsauftrag realisiert.

Wenn der Transaktionsauftrag nicht gelöscht wird, werden die Daten beim nachfolgenden Abruf erneut bereitgestellt. Eine erneute Verarbeitung der Daten ist dabei fehlerfrei möglich, da die Transaktionsaufträge immer in der korrekten Reihenfolge übergeben werden.

Durch die Transaktionsaufträge wird somit sichergestellt, dass das lesende Clientsysteme nur Daten aus der Übergabe entfernt, die fehlerfrei übernommen wurden.

Transaktionsauftrag

Die ID eines Transaktionsauftrag ist im Zusammenspiel mit dem Endpunkt (aka Datenbereich aka internem Schlüssel) eindeutig.

Bei Upserts ist der übergebene Satz anzulegen oder - falls der Schlüssel schon existiert - zu überschreiben.

Bei Deletes ist der Schlüssel aus der mitgelieferten Tabelle (aka Datenbereich aka Endpunkt) zu löschen.

11 März 2025