Modul 10 · QS in der Praxis
Schnittstellen — wenn Systeme reden
Was du danach weißt: Was eine API ist, mit welchen externen Systemen LogaHR
spricht — und warum Fehler an Systemgrenzen eine eigene Kategorie sind,
die weder Datenproblem noch Engine-Fehler ist.
LogaHR spricht nicht allein
LogaHR ist kein isoliertes System. Es sendet und empfängt ständig Daten:
Lohnverrechnungsdaten fließen in die Finanzbuchhaltung,
Meldungen gehen an ÖGK/ELDA, Mitarbeiter greifen über das Self-Service-Portal zu,
und externe HR-Tools tauschen Stammdaten aus.
Jede dieser Verbindungen ist eine Schnittstelle
(englisch: interface oder API).
P&I LogaHR
↔
ÖGK / ELDA
Meldungen, Beitragsnachweise (XML)
→
Finanzbuchhaltung
Lohnkosten, Buchungsbelege
↔
Mitarbeiterportal
Self-Service, Gehaltszettel, Urlaub
↔
Zeiterfassung
Stundenerfassung → Abrechnung
Was ist eine API?
API steht für Application Programming Interface —
eine definierte Vereinbarung, wie zwei Systeme Daten austauschen.
Das klingt technisch, aber du kennst das Konzept bereits:
Du bestellst beim Kellner.
Der Kellner geht in die Küche.
Die Küche bereitet zu und gibt zurück.
Du musst nicht wissen, wie die Küche arbeitet —
nur was du bestellen kannst und was zurückkommt.
LogaHR schickt eine Anfrage.
Die API nimmt sie entgegen.
Das andere System verarbeitet und antwortet.
LogaHR muss nicht wissen, wie ÖGK intern arbeitet —
nur welche Daten es schickt und was es als Antwort bekommt.
Die ELDA-Meldung aus Modul 09 war bereits eine API — du hast es nur noch nicht
so genannt. Jedes Mal wenn LogaHR Daten an ein externes System schickt und eine
Antwort erwartet, nutzt es eine API.
Eine API hat eine konkrete Adresse — den Endpunkt
(englisch: endpoint).
Wenn LogaHR Mitarbeiterdaten von einem internen Dienst abfragt,
sieht das vereinfacht so aus:
Endpunkt — Anfrage & Antwort
JSON · vereinfacht
GET /api/mitarbeiter/4721
Antwort:
{
"id": 4721,
"name": "Huber Maria",
"eintrittsdatum": "2023-03-01",
"beschaeftigungsausmas": 50,
"kollektivvertrag": "Handel"
}
Der Endpunkt /api/mitarbeiter/4721
ist die Adresse — die 4721 ist die Mitarbeiter-ID aus Modul 01.
Das System antwortet mit einem JSON-Objekt das du aus Modul 02 kennst:
Felder mit Namen und Werten.
Entwickler sagen dazu: „ich rufe den Endpunkt ab" oder „der Endpunkt gibt zurück…"
Fehler an Schnittstellen — eine eigene Kategorie
Schon in Modul 03 hast du gelernt, zwischen Datenproblem, Regelkonfiguration
und Engine-Fehler zu unterscheiden. Schnittstellenfehler sind eine vierte Kategorie:
| Fehlerart |
Wo es passiert |
Beispiel |
| Datenproblem |
Innerhalb LogaHR — falscher Feldwert |
Beschäftigungsausmaß 100 statt 50 |
| Regelkonfiguration |
Innerhalb LogaHR — falscher Config-Eintrag |
Falsches Gültig-ab-Datum beim KV-Satz |
| Engine-Fehler |
Innerhalb LogaHR — Berechnungslogik falsch |
Aliquot-Formel rechnet mit 30 statt 31 Tagen |
| Schnittstellenfehler |
An der Grenze — Übertragung, Format, Timing |
Buchungsbeleg erreicht Finanzbuchhaltung nicht, Feldformat stimmt nicht überein |
Das Tückische: LogaHR kann intern alles korrekt berechnet haben —
und trotzdem kommt der Buchungsbeleg falsch oder gar nicht in der Finanzbuchhaltung an.
Das Datenproblem liegt an der Grenze zwischen zwei Systemen,
nicht im einen oder anderen allein.
Diese Fehler brauchen zwei Teams um sie zu lösen.
In deiner Arbeit bei P&I
Was du nach Pfad 2 kannst
- Fehler einordnen: Datenproblem, Regelkonfiguration, Engine, oder Schnittstelle?
- Ein Fehler-Ticket schreiben, das ein Entwickler sofort bearbeiten kann
- Den Jahreswechsel als kritischste QS-Phase erkennen und gezielt testen
- ELDA-Fehler nach ihrer Herkunft unterscheiden: intern oder externe Ablehnung
- Verstehen, warum LogaHR nicht allein steht — und was an Systemgrenzen schiefgehen kann
Du bist Expertin für das Was — was ein korrektes Ergebnis ist,
was österreichisches Arbeitsrecht fordert, was ein Kunde erwartet.
Die Entwickler sind Experten für das Wie — wie die Software es umsetzt.
Deine Stärke ist, diese beiden Welten zu übersetzen.
Das war das Ziel von Pfad 2.
Bevor du in Pfad 3 weitergehst — Ereignisketten, systematische Testfallplanung,
die Frage wo ein Fehler wirklich sitzt — gibt es noch ein praktisches Modul:
Modul 10.5 zeigt dir, wie du das alles auf Englisch mit den Entwicklern besprichst.
Lesen und schreiben hast du schon; jetzt kommen die Gesprächssituationen dran.
Denke mal nach:
Welchen Schnittstellenfehler hast du bei P&I schon erlebt —
oder kannst du dir vorstellen?
Wie würdest du ihn mit einem Bug-Ticket aus Modul 07 beschreiben?