You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Restate has a psql interface to query the state of the system, via `restate sql <query>`.
72
72
For example, have a look at all the K/V state via `restate sql "SELECT * FROM state;"`.
73
-
Have a look at the introspection documentation to learn more.
73
+
Have a look at the introspection documentation to learn more.
74
74
75
75
## Exploring the demo
76
76
@@ -83,24 +83,24 @@ The flow of an incoming order is as follows:
83
83
2. The order workflow then triggers the payment by calling a third-party payment provider (implemented as a stub in this example). To do this, the order workflow first generates an idempotency token, and then uses this to call the payment provider. The payment provider can deduplicate retries via the idempotency key.
84
84
3. The workflow then sets the order status to `SCHEDULED` and sets a timer to continue processing after the delivery delay has passed. For example, if a customer ordered food for later in the day, the order will be scheduled for preparation at the requested time. If any failures occur during the sleep, Restate makes sure that the workflow will still wake up on time.
85
85
4. Once the timer fires, the order workflow sends a request to the restaurant point-of-sales system to start the preparation. This is done via an HTTP request from within `ctx.run`. The status of the order is set to `IN_PREPARATION`. The restaurant will use call the `finishedPreparation` handler to signal that the preparation is done. Once this happens, the order workflow will continue and set the order status to `SCHEDULING_DELIVERY`.
86
-
5. Then, the order workflow calls the delivery manager (`app/ordering/delivery_manager.py`) to schedule the delivery of the order (see description below). It then waits on the delivery manager to signal the different phases of delivery it goes through: `WAITING_FOR_DRIVER`, `IN_DELIVERY`, and `DELIVERED`.
86
+
5. Then, the order workflow calls the delivery manager (`app/ordering/delivery_manager.py`) to schedule the delivery of the order (see description below). It then waits on the delivery manager to signal the different phases of delivery it goes through: `WAITING_FOR_DRIVER`, `IN_DELIVERY`, and `DELIVERED`.
87
87
88
88
### The delivery workflow
89
-
To get the order delivered a set of services work together. The delivery manager (`start` method in `delivery_manager.py`) implements the delivery workflow.
90
-
It tracks the delivery status, by storing it in Restate's state store, and then requests a driver to do the delivery.
91
-
To do that, it requests a driver from the driver-delivery matcher.
89
+
To get the order delivered a set of services work together. The delivery manager (`start` method in `delivery_manager.py`) implements the delivery workflow.
90
+
It tracks the delivery status, by storing it in Restate's state store, and then requests a driver to do the delivery.
91
+
To do that, it requests a driver from the driver-delivery matcher.
92
92
The driver-delivery matcher tracks available drivers and pending deliveries for each region, and matches drivers to deliveries.
93
-
Once a driver has been found, the delivery manager assigns the delivery to the driver and signals the order workflow that it selected the driver.
93
+
Once a driver has been found, the delivery manager assigns the delivery to the driver and signals the order workflow that it selected the driver.
94
94
The delivery has started now. The delivery manager relies for the rest of the delivery updates on the driver digital twin.
95
95
96
-
The driver's digital twin (`driver_digital_twin.py`) is the digital representation of a driver in the field.
96
+
The driver's digital twin (`driver_digital_twin.py`) is the digital representation of a driver in the field.
97
97
Each driver has a mobile app on his phone (here simulated by `external/driver_mobile_app_sim.py`) which continuously sends updates to the digital twin of the driver:
98
98
1. The driver can notify when they start working: have a look at `driver-mobile-app/start_driver` which calls `driver-digital-twin/set_driver_available`.
99
99
2. The mobile app also polls the digital twin to check if a new delivery was assigned to the driver. Have a look at `driver-mobile-app/poll_for_work` which regularly calls `driver-digital-twin/get_assigned_delivery`.
100
100
3. During delivery, the mobile app sends regular location updates over Kafka to the digital twin of the driver. Have a look at the method `driver-digital-twin/handle_driver_location_update_event`. In the Docker compose file (`docker-compose.yaml`), the `runtimesetup` container executes a curl request to let Restate subscribe to the topic.
101
-
4. Once the driver has arrived at the restaurant, the driver's mobile app notifies its digital twin (by calling `driver-digital-twin/notify_delivery_pickup`).
101
+
4. Once the driver has arrived at the restaurant, the driver's mobile app notifies its digital twin (by calling `driver-digital-twin/notify_delivery_pickup`).
102
102
The digital twin then notifies the delivery manager that the driver has picked up the delivery (by calling `delivery-manager/notify_delivery_pickup`).
103
-
5. Finally, the driver arrives at the customer and the driver's mobile app notifies its digital twin (by calling `driver-digital-twin/notify_delivery_delivered`).
103
+
5. Finally, the driver arrives at the customer and the driver's mobile app notifies its digital twin (by calling `driver-digital-twin/notify_delivery_delivered`).
104
104
The digital twin then notifies the delivery manager that the driver has picked up the delivery (by calling `delivery-manager/notify_delivery_delivered`).
105
105
6. The delivery manager then notifies the order workflow that the order got delivered, so that it completes.
0 commit comments