Was ist OData und wofür wird es in der Industrie genutzt?

OData steht für „Open Data Protocol“. Es beschreibt, wie Datendienste im REST-Stil aufgebaut sind: Clients lesen und ändern Ressourcen mit gewöhnlichen HTTP-Nachrichten, die Ressourcen werden über URLs adressiert, und ein Datenmodell beschreibt, welche Objekte und Eigenschaften es gibt. So steht es in der OData-Spezifikation von OASIS.

Der praktische Gewinn liegt in der Einheitlichkeit. Wer einen OData-Dienst kennt, kann die Abfragelogik eines zweiten Dienstes ohne neue Einarbeitung nutzen. Die Tabelle stellt OData einer individuell gebauten Schnittstelle gegenüber.

Die Idee eines gemeinsamen Datenzugriffs ist älter als die Norm. Im Mai 2012 schlugen unter anderem Microsoft und IBM beim Standardisierungsgremium OASIS ein technisches Komitee für OData vor, Microsoft brachte sieben Spezifikationsteile ein. OASIS verabschiedete OData 4.0 am 24. Februar 2014 als Standard, 2016 wurde es als ISO/IEC 20802 angenommen. OData 4.01 folgte am 23. April 2020.

Warum das für Verbindungen zählt, zeigt eine Überschlagsrechnung. Rein zur Illustration: Sechs Systeme, die jeweils individuell miteinander sprechen, brauchen bis zu 6 × 5 / 2 = 15 Verbindungen. Sprechen alle sechs über denselben Standard mit einer gemeinsamen Schicht, sind es sechs Anbindungen. Die Zahlen sind ein Rechenbeispiel, kein Messwert aus einem Projekt.

OData ist kein einzelnes Dokument, sondern eine Familie von Spezifikationen. Die folgende Übersicht nennt die Teile, die in der Praxis am häufigsten gebraucht werden.

Vier Mechanismen tragen den Standard.

• Adressierung: Eine Menge steht hinter dem Dienstpfad, etwa Products. Ein einzelner Datensatz wird über den Schlüssel in Klammern angesprochen, etwa Products(1).
• Abfrageoptionen: Mit $filter grenzen Sie Datensätze ein, mit $select wählen Sie Eigenschaften, mit $expand binden Sie verknüpfte Daten ein, mit $orderby, $top und $skip sortieren und blättern Sie.
• Schreibzugriff: Datensätze werden mit POST angelegt, mit PATCH oder PUT geändert und mit DELETE entfernt. ETags schützen vor Überschreiben, wenn zwei Anwender gleichzeitig ändern.
• Metadaten und Batch: Das Service-Dokument listet die verfügbaren Mengen, $metadata beschreibt das Modell. Mit Batch-Anfragen lassen sich mehrere Operationen in einem Aufruf bündeln.

Die Reihenfolge ist bei den meisten Anbindungen ähnlich.

1. Datenmodell klären

   Welche Objekte brauchen Sie, etwa Aufträge, Materialien oder Standorte, und welche Eigenschaften sind dafür nötig?

2. Dienst prüfen

   Rufen Sie das Service-Dokument und $metadata ab. So sehen Sie, welche Mengen und Felder der Dienst tatsächlich anbietet.

3. Abfragen und Zugriff festlegen

   Definieren Sie Filter und Felder so, dass nur nötige Daten übertragen werden, und klären Sie Authentifizierung und Berechtigungen.

4. Betrieb und Pflege

   Überwachen Sie Antwortzeiten und Fehler und planen Sie ein, dass sich das Modell des Dienstes ändern kann.

Vier Abgrenzungen verhindern typische Missverständnisse.

• Kein Maschinenprotokoll: OData spricht mit Datendiensten, nicht direkt mit einer Steuerung. Dafür gibt es Protokolle wie OPC UA oder Modbus.
• Kein Datenstrom: OData arbeitet mit Anfrage und Antwort über HTTP. Für Ereignisse, die ein Sender laufend verteilt, eignen sich Protokolle wie MQTT besser.
• Keine Datenbank: OData beschreibt den Zugriff, nicht die Speicherung. Dahinter kann jede Datenhaltung stehen.
• Nicht beliebiges REST: OData ergänzt REST um feste Regeln für Modell, Abfragen und Fehler. Ein beliebiger JSON-Dienst ist deshalb noch kein OData-Dienst.

Die Hürden liegen selten im Protokoll, sondern in dem, was dahinter bereitgestellt wird.

• Dienste in unterschiedlichen OData-Versionen, die ein Client getrennt behandeln muss
• Zu breite Abfragen, etwa $expand über viele Beziehungen, die Antwortzeiten erhöhen
• Unklare Berechtigungen: Wer darf welche Mengen lesen oder ändern?
• Felder mit gleichem Namen, aber unterschiedlicher Bedeutung in verschiedenen Systemen

OData ist für pronubes ein möglicher Zugang zu Quell- und Zielsystemen. Die Produktteile übernehmen dabei unterschiedliche Aufgaben.

• pronubes Edge: Edge bindet Maschinen, Anlagen und Zielsysteme an, ohne dass für jede Verbindung ein eigenes Schnittstellenprojekt entsteht. Systeme mit standardisierter Schnittstelle eignen sich dafür besonders gut.
• pronubes Zones: Zones bildet Standorte, Produktionsbereiche, Systeme und Datenflüsse in einer klaren Struktur ab. Das hilft, Daten aus einem OData-Dienst eindeutig dem richtigen Standort und Bereich zuzuordnen.
• pronubes Insights: Insights macht sichtbar, ob Verbindungen und Datenflüsse im laufenden Betrieb stabil arbeiten. So erkennen Sie früh, wenn ein Dienst langsam antwortet oder Fehler liefert.