Anlegen und Zurücklesen: STRICT oder LENIENT

Worum es geht

Ein create antwortet nicht nur mit „ok“, sondern mit dem angelegten Objekt, so wie du es in response angefordert hast. Dafür liest CDMS das Objekt nach dem Speichern zurück, mit deinen Rechten und Filtern, genau wie ein normales Lesen.

Dieses Zurücklesen kann scheitern, obwohl das Anlegen gelungen ist. Zum Beispiel:

Dir fehlt die Leserolle des Modells. Anlegen darfst du, lesen nicht.
Das neue Objekt fällt durch deine Zeilenfilter. Du legst etwa einen Auftrag für eine Firma an, die dein Attributfilter nicht zeigt.
Ein READ-Hook wirft beim Lesen einen Fehler.

Was dann passiert, entscheidet der CreateReadMode: STRICT oder LENIENT.

Die beiden Modi

Wenn das Zurücklesen scheitert

STRICTLENIENT

Wann: Standard. Anlegen und Zurücklesen in einer Transaktion.

1

CDMS→Database
legt das Objekt an, Hooks, flush
2

CDMS→Database
liest es zurück, in derselben Transaktion
3

CDMS
Zurücklesen scheitert, z. B. Leserolle fehlt
4

CDMS→Client
Fehler des Lesens, z. B. 403 missing-permission|order-read; das Anlegen wird zurückgerollt

Ergebnis: Es gibt kein neues Objekt. Die Antwort beschreibt, woran das Lesen gescheitert ist.

Wann: Anlegen und Zurücklesen in zwei Transaktionen.

1

CDMS→Database
legt das Objekt an, Hooks, flush
2

CDMS→Database
Commit: das Objekt ist jetzt dauerhaft gespeichert
3

CDMS→Database
liest es zurück, in einer neuen Transaktion
4

CDMS
Zurücklesen scheitert
5

CDMS→Client
200 in Fehlerform, messageKey CDMS_CREATE_SUCCEEDED_READ_FAILED und die id des neuen Objekts

Ergebnis: Das Objekt existiert. Du weißt seine id, bekommst aber seine Felder nicht.

Gelingt das Zurücklesen, verhalten sich beide Modi gleich: 200 mit dem Objekt.

Die Antwort bei LENIENT

Angelegt, aber nicht zurückgelesen

Anfrage

POST /api/rest/order/create
{
  "data": { "orderNr": "A-1000", "companyId": "123456" },
  "response": ["id", "orderNr"],
  "createReadMode": "LENIENT"
}

Antwort 200

{
  "error": "CreateSucceededReadFailedException",
  "messageKey": "CDMS_CREATE_SUCCEEDED_READ_FAILED",
  "code": "200",
  "layer": "system",
  "id": "5a2b…"
}

Die Antwort hat Status 200, aber die Form einer Fehlerantwort: kein data, dafür error, messageKey und id. Werte bei create deshalb nicht nur den Status aus, sondern auch, ob data da ist. Siehe Das Antwortformat: data und meta.

Den Modus wählen

Welcher Modus gilt?

`createReadMode` in der Anfrage	Einstellung der Installation	Modus
`LENIENT`	–	LENIENT
`STRICT`	–	STRICT
fehlt	`LENIENT`	LENIENT
fehlt	`STRICT` oder nicht gesetzt	STRICT

Pro Anfrage: "createReadMode": "LENIENT" im Körper, neben data und response. Das gilt für POST /create, /create/upload und das Anlegen über die Hub-API eines abstrakten Modells.
Für die ganze Installation: die Einstellung codamai.cdms.api.create-read-mode in der Konfiguration der Anwendung, Standard STRICT.
Singletons lesen beim Anlegen immer im Modus STRICT zurück.

Bei PUT, PATCH und Rollback gibt es keine Wahl: Dort gehören Schreiben und Zurücklesen immer zu einer Transaktion.

Wann welcher Modus passt

STRICT oder LENIENT?

STRICT

alles oder nichts

der Client bekommt entweder das Objekt oder einen Fehler
kein Objekt, das der Anlegende nicht sehen kann
passt für fast alle Formulare

LENIENT

Anlegen zählt mehr als die Antwort

das Anlegen soll auch dann bleiben, wenn der Anlegende es nicht lesen darf
Beispiel: ein Kontaktformular, eine Meldung, ein Upload in einen Eingangskorb
der Client muss mit 200 ohne data umgehen können

Fallen

Wie es weitergeht

Die Klammer um eine Anfrage: Ein Request, eine Transaktion
Wie eine Anfrage anlegt: Ein Objekt anlegen
Die Form von Antworten: Das Antwortformat: data und meta