summary |
shortlog | log |
commit |
commitdiff |
tree
first ⋅ prev ⋅ next
Kai Moritz [Sun, 7 Jun 2020 18:00:00 +0000 (20:00 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 17:54:25 +0000 (19:54 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 17:42:56 +0000 (19:42 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 17:36:45 +0000 (19:36 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:19:48 +0000 (14:19 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:13:17 +0000 (14:13 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:12:41 +0000 (14:12 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:11:22 +0000 (14:11 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:10:18 +0000 (14:10 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:09:57 +0000 (14:09 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 11:47:44 +0000 (13:47 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 11:13:55 +0000 (13:13 +0200)]
TMP
Kai Moritz [Sun, 7 Jun 2020 12:03:31 +0000 (14:03 +0200)]
streams - Übungen - Microservices - Schritt 03
--
Release für validate-order:03 und validation-result:03
Kai Moritz [Sun, 7 Jun 2020 12:01:55 +0000 (14:01 +0200)]
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"
Kai Moritz [Sun, 7 Jun 2020 11:00:14 +0000 (13:00 +0200)]
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"
Kai Moritz [Sun, 7 Jun 2020 09:39:05 +0000 (11:39 +0200)]
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
Kai Moritz [Sun, 7 Jun 2020 10:04:08 +0000 (12:04 +0200)]
streams - Übungen - Microservices - Schritt 02
--
Release für details:02
Kai Moritz [Sun, 7 Jun 2020 09:59:21 +0000 (11:59 +0200)]
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!
Kai Moritz [Sun, 7 Jun 2020 09:56:12 +0000 (11:56 +0200)]
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
Kai Moritz [Sun, 7 Jun 2020 09:33:08 +0000 (11:33 +0200)]
streams - Übungen - Microservices - Schritt 01
--
Release für take-order:01
Kai Moritz [Sun, 7 Jun 2020 09:37:39 +0000 (11:37 +0200)]
streams - Übungen - Microservices - Schritt 01
--
README.sh wartet auf /actuator/health, anstatt eine fixe Zeit (REDONE)
(Version aus ursprünglicher Übung übernommen)
Kai Moritz [Sun, 7 Jun 2020 09:27:21 +0000 (11:27 +0200)]
streams - Übungen - Microservices - Schritt 01
--
Dockerfile mit ENTRYPOINT und CMD
Kai Moritz [Sun, 7 Jun 2020 09:22:04 +0000 (11:22 +0200)]
streams - Übungen - Microservices - Schritt 01
--
README.sh wartet auf /actuator/health, anstatt eine fixe Zeit
Kai Moritz [Sun, 7 Jun 2020 08:56:16 +0000 (10:56 +0200)]
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)
Kai Moritz [Sun, 7 Jun 2020 08:42:39 +0000 (10:42 +0200)]
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