3.5 Using the Lab

Making requests against the Lab environment.

Available Endpoints

Endpoint	Microservice	Description
http://localhost:8080/shop-orders	Order	Return and create new orders
http://localhost:8080/chaos-monkey	Order	Inject errors for testing our application
http://localhost:8081/articles	Stock	Query article metadata
http://localhost:8081/article-stocks	Stock	List or change the article stock count
http://localhost:8081/chaos-monkey	Stock	Inject errors for testing our application

Order state

The order is expected to have the following states

State	Description
NEW	Order is created. Stock reservation has not happened.
COMPLETE	Order is created and the article-stock count has been decreased according to the article counts.
INCOMPLETE	Order is created but reservation could not complete.

Sample Requests

In the source folder <PROJECT_ROOT>/code/rest/requests there is an IntelliJ compatible HTTP Request file. You may run requests directly from IntelliJ or use it as reference for your requests.

Get article stock information

1
curl --request GET --url http://localhost:8081/article-stocks

Get order information

1
curl --request GET --url http://localhost:8080/shop-orders

Create new order

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
curl --request POST \
  --url http://localhost:8080/shop-orders \
  --header 'Content-Type: application/json' \
  --data '{
    "articleOrders" : [
        {
            "articleId" : 1,
            "amount" : 1
        }
    ]
}'

Task 3.5.1 - Testing scenario

Run the following queries:

Check the article-stock count
Create an order for one item of article 1
Check the orders and article-stock again

Answer the questions:

Is the article-stock count correct?
Do you see any problems with this implementation?
What happens if you are running out of stock?
What’s the role of a transaction in this case?

Task Hint

This implementation seems to be the most logical and straightforward implementation when we just split a monolith in two microservices and let them communicate with a simple RESTful API.

The happy-path seems to be working quite well. But the edge cases do not behave quite well. Running out of stock will return an exception from the stock service. The TransactionalInterceptor will be triggered by the exception and will issue a rollback.

In the best case our order is not created and the stock is also not reserved. But are we sure that the stock reservation has not been made? The exception might have occurred after the reservation on the stock service has been completed. Think about a simple timeout between these two services.

We could remove the Transactional annotation to not cover the rest call to our stock service. We could then have a look at the response code to determine if the operation was successful. But would that solve all problems? What if an exception occurred in the order microservice just after the stock reservation?

Task 3.5.2 - Injecting an error

Let us inject an error at the end of the createShopOrder method of the order microservice.

Use the chaos-monkey rest endpoint to inject an error with the following request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
curl --request POST \
  --url http://localhost:8080/chaos-monkey \
  --header 'Content-Type: application/json' \
  --data '[
    {
        "clazzName": "ShopOrderResource",
        "methodName": "createShopOrder",
        "enabled": true,
        "throwException": true
  }
]'

This will throw an InternalServerErrorException after execution of the method createShopOrder.

Ask yourself what to expect if an exception is thrown?

Issue the request from the Task 3.5.1 but use article 3 for your order.

What did you observe?
Is there any difference?
Is the data still consistent between stock and order microservice?
Can you imagine why any inconsistency may happen?
What’s the role of a transaction in this case?

Task Hint

As expected, the reservation took place in the stock microservice. However, our local transaction in the order microservice was rolled back as there was an exception. Our Data is no inconsistent as the stock count was decreased but the order was not created.

Last modified February 12, 2024: fix debezium lab version (9e6013e)