Tracks success based on promise time compared with verification time at facilities
Tracks success based on promise time compared with verification time at facilities using a redis streams producer and a consumer.
Solution using java spring boot leverage redis hash and redis sorted sets to arrive at a success metrics per store and queue.
The producer and the consumer share a common record structure to hold the events.
These are the data structures used
- Stream Processing with Redis and Spring Boot Data Blog
- Majority of this code stolen from here
- Instructive spring boot overview
- redis stack
- redis sorted sets
Clone the github
get clone https://github.com/jphaugla/redisPromiseTime.git
docker-compose up -d
- first, build the commmon-event-model
- next, build the full project
cd common-event-model
mvn clean package
cd ..
mvn clean package
- Start the consumer in one terminal session
cd stream-event-consumer
java -jar target/stream-event-consumer-0.0.1-SNAPSHOT.jar
- Start the producer in a different terminal session
cd stream-event-producer
java -jar target/stream-event-producer-0.0.1-SNAPSHOT.jar
A scripts directory has two subdirectories: consumer, producter
The scripts here produce records. A basic workflow starts with a promise record with no verification date and continues with the fulfillment of this promise record. Will see the unfilled order data structure after the promise record be removed when the fulfillment occurs.
cd producer
./orderNull.sh
# observer structures using redisinsight before running fulfillment
./orderFulfilled.sh
Continue by populating additional records
./sameStore.sh
./multipleOrders.sh
The scripts provide interface to retrieve answers from the generated data
# check status
./status.sh
# get status of one store
./getStoreStatus.sh
# get all store status statistics
./getAllStoreStatus.sh
# get recent store sales passing store, queue, start time and end time
./recentStoreSales.sh
# get list of all stores and queues
./allStoreList.sh
Additional feature, rebuild the store success status
- Go into redis insight or redis-cli
- Observe the value for the key StoreSuccess:3333:QV1
- It should have 3 LATE and 2 SUCCESS
- Delete the key StoreSuccess:3333:QV1
./rebuildStoreStatus.sh
Verify the same values returned