<< Click to Display Table of Contents >> Navigation:  PAS - Softwareentwicklung > API Vorgaben

Implementierungen der API

Jeder API Call erhält in PUM folgende Informationen

•Der Call erhält eine Aufrufparameter-Struktur. Diese Struktur ist als Klasse in der API-Hierarchie definiert.

•Der Call erhält eine Ergebnissstruktur. Die Ergebnisstruktur ist als Klasse in der API Hierarchie definiert.

oAufruf- und Ergebnisstrukturen werden i.d.R. nicht zwischen verschiedenen Calls genutzt. Für sehr einfache Antwortstrukturen gibt es allgemeine Strukturen, die wiederverwendbar sind.

•Wenn man in der API auf ein bestimmtes Objekt in der Datenbank referenzieren möchte, dann wird die OOP des Objektes als Attribut in der Parameterklasse definiert

oWeiterhin muß man in PUM angeben, welche Zielklasse die Referenz sein kann - entweder genau oder als Klasse in einem Teilbaum der Hierarchie. Das dient zur Fehlersuche bei einer fehlerhaften OOP.

oWenn ein Attribut als Referenz auf "Gop" oder "GOP" endet, dann sollte das Attribut die Rolle "identgop" bekommen. Dadurch kann man später bei der CodeGenerierung gezieltere Informationen erhalten.

oDie Attribute der Aufrufparaeter-Struktur müssen die nullable Information des Attributes in PUM gewissenhaft ausgefüllt haben

▪Dann können bessere Checks durchgeführt werden, ob Parameter gesetzt sind.

•Ein API-Call ist ein alleinstehender Call oder Teil einer CRUD Struktur.

•Im Request wird eine OOP mitgegeben (als Parameter in der URL), die als Verweis zur der Session dient, die diesen Aufruf tätigt. Dadurch muß die Aufrufparameter-Struktur im Fehlerfall nicht deserialisiert werden.

Abarbeitung

Bei der Abarbeitung durch Gemstone/S wird eine Requeststruktur aufgebaut, in der man auch die Session abfragen kann (aMSKOptions) - und damit i.d.R. auch in das gesamte Domain-Model. (Über Session -> User -> customer ...). Über die OOP der Session gelangt das System also an die Session und prüft, ob diese noch nicht abgelaufen ist. Danach wird der Call-Parameter deserialisiert und mit beiden Informationen wird die erste Aufrufebene eines Calls aufgerufen.

Erste Aufrufebene

Diese Routine ist die initiale Aufruf-Methode in der Service-Klasse auf der Klassenseite. Dier Call macht folgendes:

•Prüft, ob die Session diesen Call überhaupt ausführen darf - wirft ggfs. Exceptions

oPUM kann dabei schauen, ob es eine Assoziation von der Projektklasse zur der APIGuardExecution class gibt und wenn es diese gibt, dann kann er einen Aufruf in eine Methode, die mit den Informationen den berechtigten Zugriff checken kann.

•Sie prüft die Parameter der Methode - wirft ggfs. Exceptions

•Sie ermittelt ggfs. weitere Werte und legt diese im Parameter-Argument ab

•Ruft die zweite Ebene mit den gleichen Parametern auf. Der Name der Methode ist der gleiche Name, lediglich mit einem "_" vorangestellt

Zweite Aufrufebene

In dieser Methode finden die Arbeiten auf der Domain-Ebene statt (Neu erzeugen, Löschung, Veränderungen). Der Name der Methode ist der gleiche Name wie der API Call, lediglich mit einem "_" vorangestellt

Abarbeitung - Abschluß

Jeder Call baut eine Call-Abschlußstruktur zusammen und übergibt diese nach dem Call wieder an das Framework und diese leitet die Rückmeldung ein (Erzeugung des JSON, Events absenden). Außerdem wird im Falle eines reparierbaren Concurrency-Problems der Cal noch einmal durchgeführt.

Konsequenzen

Diese Unterteilung eines Calls in verschiedene Aufrufebenen erhöht die Wiederverwendbarkeit der API Call Logik in anderen internen Methoden.