Flows and Entry Points
The right pane of the analysis page contains the list of services, in our case there are 7 services. Next to each service name we have the number of flows the service is involved in. For example: oms-inventory contributes to 12 flows while oms-trucking is active in 2 flows.
Entry points
The entry points of a service represent the API exposed by the service and which component was detected using that API
Select the oms service (in the graph or in the list)
This service has 4 entry points - meaning we observed four APIs that triggered some functionality of this service.
Click on VIEW next to the Entry Points - you will see 3 entry points listed under EXT, meaning they are called from outside the system of services and one entry point is under NON, meaning it is called from another service in the system.
Navigate and click on the entry point under NON, and then click Show Services. You see that this API is called from the oms-inventory service.
Click on the crosshair icon next to the oms-inventory service - the oms-inventory service will grow and shrink in the graph so you can easily locate it.
Flows
Go back to the services list and select the oms service.
Click on VIEW next to Individual Flows of the oms service - a list of 9 flows in which the service participates is shown.
Select the flow /service/inventory/multi-create (POST) - a sequence diagram showing the interaction between the services of that flow is shown, the flow is also highlighted on the flows list on the left pane.
In the left pane we see that this flow was called 7 times and the average execution time is 90 milliseconds. We also see that 95 percentile of the execution is 369 milliseconds, in other words 5% of the flows took 369 milliseconds or more.
Let’s review the sequence diagram: (1): We see that an external component (Consumer lifeline) calls the API /service/inventory/multi-create (POST) and in turn oms-inventory is calling oms API /service/address/validate/french (POST) 5 times in a loop. Looking on the right pane we can see that the oms service is calling a GET API to www.google.com in the context of this flow
Scroll up in the left pane and click on Filters, and expand the SERVICES section. Click on None and then select the oms service. Scroll down (left pane) - you should now see only the 9 flows involving OMS (out of 21)
Two out of the 9 flows have a red dashed line next to them - this means that these flows are circular. To clarify what is a circular flow open the flow /service/modify/fulfillment/shipping/items/{lineItemId} (PATCH). You can see that oms is calling oms-shipping to get a shipping id and in turn oms-shipping is calling oms-inventory to get an inventory-id but then oms-inventory calls oms back. Circular flows are an architectural issue that needs to be resolved, for example, oms might provide the validation info in the call to forward to inventory and this will save the need to call the oms service back. The below screenshot highlight the circular interaction in the flow.
Another two flows have a yellow orange dashed line next to them - these flows are multi-hop flows, meaning complex flows across multiple services. This is also an architectural issue since any point of failure in any service will fail the whole flow. Open the two multi-hop flows and review the interaction.
Remove the filter on the services graph: Scroll back up in the left pane and do Show All for the SERVICES (Filters section)