Modul 02 - JSON: Wie Software Daten aufschreibt

Was du danach weißt: Was JSON ist, wie du es liest - und warum du es in Tickets und Systemlogs bei P&I sehen wirst.

Kurze Erinnerung an Modul 01

In Modul 01 hast du gelernt: Software speichert einen Mitarbeiter als Datensatz (Entwickler: Object), der aus Feldern besteht - jedes Feld hat einen Key (den Namen) und einen Value (den Wert).

Jetzt geht es darum, wie dieser Datensatz tatsächlich aussieht, wenn Software ihn aufschreibt. Das Format heißt JSON (ausgesprochen: „Dscheyson").

Was ist JSON?

JSON ist kein Programm und kein Code - es ist ein Textformat. Eine vereinbarte Art, Daten so aufzuschreiben, dass jedes System auf der Welt sie lesen kann. Entwickler, Systeme und Logs verwenden JSON ständig, um Daten weiterzugeben oder anzuzeigen.

Wenn ein Entwickler dir bei P&I schreibt: „Schau mal in den Log, da siehst du den employee record" - dann wirst du JSON sehen. Nach diesem Modul weißt du, wie du es liest.

Der Mitarbeiter-Datensatz als JSON

Datensatz (wie in Modul 01)

NachnameHuber

VornamePetra

Bruttogehalt2.800 €

Beschäftigungsausmaß100

KollektivvertragHandel

Derselbe Datensatz als JSON

{
  "lastName": "Huber",
  "firstName": "Petra",
  "grossSalary": 2800,
  "employmentRate": 100,
  "collectiveAgreement": "Handel"
}

Key

Der Feldname - immer in Anführungszeichen, oft Englisch

Text-Value

In Anführungszeichen - entspricht Datentyp Text aus Modul 01

Zahl-Value

Ohne Anführungszeichen - entspricht Datentyp Zahl aus Modul 01

{ } Klammern

Markieren Anfang und Ende eines Datensatzes (Object)

Auffällig: die Keys sind auf Englisch - lastName statt Nachname, grossSalary statt Bruttogehalt. Das ist in der Praxis üblich. Du wirst diese englischen Feldnamen in Logs und Tickets sehen. Mit der Zeit merkst du dir, welcher Key welchem Feld aus der Personalverrechnung entspricht.

Eine Liste als JSON

Mehrere Datensätze hintereinander - die Liste aus Modul 01 - werden in JSON mit eckigen Klammern [ ] geschrieben:

Mitarbeiterliste als JSON Array

[ { "lastName": "Huber", "grossSalary": 2800 }, { "lastName": "Maier", "grossSalary": 3500 }, { "lastName": "Schreiber", "grossSalary": 1400 } ]

[ ] = Liste (Entwickler: Array) - mehrere Datensätze.
{ } = ein einzelner Datensatz (Entwickler: Object).

Ältere Formate - XML

JSON ist heute der Standard, aber ältere Systeme verwenden an manchen Stellen noch XML - ein älteres Textformat für denselben Zweck. Für dich besonders relevant: ELDA-Meldungen (elektronische Meldungen an die ÖGK) laufen über XML. P&I LogaHR hat jahrzehntealte Teile - es ist gut möglich, dass du XML in Logs oder Exporten siehst.

Du musst XML nicht schreiben. Du sollst es nur erkennen. Das Konzept ist dasselbe wie bei JSON - Key und Value, nur anders aufgeschrieben.

Derselbe Datensatz als XML XML · älteres Format

<employee> <lastName>Huber</lastName> <firstName>Petra</firstName> <grossSalary>2800</grossSalary> <employmentRate>100</employmentRate> </employee>

In XML heißt ein Feld <tagname> - entspricht dem Key in JSON. Der Wert steht dazwischen. Am Ende kommt </tagname> mit Schrägstrich, das schließt das Feld. Wortreicher als JSON, gleiche Logik.

In deiner Arbeit bei P&I

Wenn ein Entwickler dir einen Fehlerlog schickt, sieht er oft so aus - du wirst JSON erkennen und lesen können. Das ist kein Code. Das sind Daten. Du kannst direkt prüfen, ob ein Wert plausibel ist.

Aus einem Fehler-Ticket Fehler drin

{ "lastName": "Schreiber", "grossSalary": 2800, "employmentRate": 100, "entryDate": "2014-03-01" }

Das Problem: Frau Schreiber arbeitet Teilzeit - employmentRate müsste 50 sein, nicht 100. Außerdem: entryDate zeigt 2014, nicht 2024 - zehn Jahre zu früh. Kein Systemfehler, kein roter Alarm. Aber du siehst es sofort, weil du weißt, was die Werte bedeuten.