TMP

TMP

TMP

TMP

TMP

TMP

TMP

TMP

TMP

TMP

streams - Übungen - Microservices - Schritt 03
--
Release für validate-order:03 und validation-result:03

streams - Übungen - Microservices - Schritt 03
--
Validation-Results-Service implementiert

* Lauscht auf dem Topic "validations"
* Passt den Status der Order entsprechend an
* "APPROVED" bei "PASS", "DECLINED" bei "FAIL"
* _Hintergrund:_ Single Writer -- Nur der Bounded Context "Order" greift
  schreibend auf das Topic "orders" zu!
* _Beachte:_ Grenzen des Bounded Context sind nicht (müssen nicht) mit
  den Microservices übereinstimmen!
+
_Hier:_ BC "Order" besteht aus "take-order", "details", "validation-results"

streams - Übungen - Microservices - Schritt 03
--
Validate-Order-Service implementiert

* Lauscht auf dem Topic "orders"
* Beachtet nur Order-Aufträge im Zustand CREATED
* Prüft, dass "consumerID", "productID" und "quantity" größer 0 sind
* Wenn ja: "PASS", ansonsten "FAIL"

streams - Übungen - Microservices - Schritt 03
--
Validierung in take-order-service entfernt

* Validierung der übergebenen Zahlen entfernt
* Dies soll ja jetzt iin einem separatem Microservice umgesetzt werden

streams - Übungen - Microservices - Schritt 02
--
Release für details:02

streams - Übungen - Microservices - Schritt 02
--
Referenz auf State-Store wird dauerhaft gespeichert

* Die Referenz auf den State-Store wird nicht bei jedem GET-Aufruf neu geholt
* Der richtige Ort dafür ist ein State-Listener
* Grund: Ruft man die Refrenz direkt nach dem Start der KafkaStreams-Instanz
  auf, befindet sich die App noch nicht im Zustand RUNNING und der Abruf
  schlegt fehl!

streams - Übungen - Microservices - Schritt 02
--
Details-Service für Order-Aufträge implementiert

* Der Service lauscht auf dem "orders"-Topic und baut den Zustand auf
* Über eine REST-Anfrage kann der aktuelle Zustand erfragt werden

streams - Übungen - Microservices - Schritt 01
--
Release für take-order:01

streams - Übungen - Microservices - Schritt 01
--
README.sh wartet auf /actuator/health, anstatt eine fixe Zeit (REDONE)

(Version aus ursprünglicher Übung übernommen)

streams - Übungen - Microservices - Schritt 01
--
Dockerfile mit ENTRYPOINT und CMD

streams - Übungen - Microservices - Schritt 01
--
README.sh wartet auf /actuator/health, anstatt eine fixe Zeit

streams - Übungen - Microservices - Schritt 01
--
Beispiele für Order-Requests hinhzugefügt

(Der Accept-Header ist sinnvoll, weil sich verschiedene Versionen von
httpie-Versionen sonst nicht einheitlich verhalten)

streams - Übungen - Microservices - Schritt 01
--
Microservice Take-Order implementiert

* Microservice implementiert, der neue Orders annimmt
* Orders werden asynchron angenommen
* HTTP-Antwort erfolgt erst, wenn Order erfolgreich in Topic geschrieben
* Für jede Anfrage wird eine UUID generiert, die als Schlüssel fungiert
* Bei Erfolg wird eine URI zurückgegeben, unter der die Order abfragbar ist