Identify Inventory Failed Events
Authors:
Kirill Gaiduk, Holger Lierse, Girish Padmanabha
Changed on:
15 Mar 2024
Key Points
- Detect Inventory problems or anomalies with the Total Failures card on the Sources Dashboard.
- Identify the specific failure events with advanced filtering on the Events page.
- Understand the what, where, and why of the event failure by using the Event Details Drawer.
Prerequisites
Steps
1. Understand the current state of Inventory Updates.
Navigate to the Sources Dashboard.

2. Detect Inventory problems or anomalies.
Monitor the Total Failures card.

The Total Failures card value reflects the aggregated Metrics data:
- Events with
`FAILED`
and`NO_MATCH`
statuses; - Of the Inventory domain Entity types:
`INVENTORY_CATALOGUE`
,`INVENTORY_POSITION`
,`INVENTORY_QUANTITY`
,`VIRTUAL_CATALOGUE`
,`VIRTUAL_POSITION`
, and`BATCH`
; - Excluding data with
`internal`
source label.
For more details, check the Labels section of the Metrics usage for Platform Observability.
3. Identify the specific Inventory failure events.
Click the Total Failures card link, which will redirect to the Events page.

The Events Search Results are pre-filtered with:
- Event status:
`FAILED`
&`NO_MATCH`
; - Root entity type:
`INVENTORY_CATALOGUE`
&`VIRTUAL_CATALOGUE`
.
4. Identify the events that require deeper analysis.
Inspect the Events Search Results table.

5. Get more information about the specific event.
Click the column value link to open the Event Details Drawer. Inspect the DETAILS and CONTEXT sections.

6. Understand what, where, and why it happened.
Scroll down to the Details Drawer BODY section to inspect the attributes providing the necessary information for the problem understanding and remediation, like:
- error
`code`
(available for`FAILED`
events only); - error
`message`
; `lastRuleSet`
;`lastRule`
;`entityStatus`
(available for`NO_MATCH`
events only);`closeMatches`
(available for`NO_MATCH`
events only).

Explanation through an Example
Failed Events Identification is an initial part of the Processing monitoring to enable users to identify the specific Events that have failed and provide visibility into why those events have failed. The following example for Update (via the customer’s request based on (POS) data) is intended to serve as a reference for the Failed Events Identification .
1. The current state of the Stock-On-Hand is 25 pcs:

2. Current state of the recent (last 30 min) Updates:

3. Incorrect Update customer’s request based on (POS) data is sent.
1{
2 "retailerId": "3353",
3 "entityRef": "DEFAULT:33533",
4 "name": "InventoryChanged",
5 "entityType": "INVENTORY_CATALOGUE",
6 "rootEntityType": "INVENTORY_CATALOGUE",
7 "rootEntityRef": "DEFAULT:33533",
8 "entitySubtype": "DEFAULT",
9 "type": "NORMAL",
10 "source": "POS",
11 "attributes": {
12 "inventoryPosition": {
13 "retailerId": "3353",
14 "locationRef": "F_1686296685026",
15 "productRef": "AH8050-F_1686296685026-96",
16 "qty": "10"
17 }
18 }
19}
4. The Update Failure occurred is displayed on the Sources Dashboard:

5. The user is redirected to the pre-filtered Events page on Total Failures link click:

6. The Details Drawer is opened on column link click:

7. Fixed POS Update customer’s request is sent.
1{
2 "retailerId": "3353",
3 "entityRef": "DEFAULT:3353",
4 "name": "InventoryChanged",
5 "entityType": "INVENTORY_CATALOGUE",
6 "rootEntityType": "INVENTORY_CATALOGUE",
7 "rootEntityRef": "DEFAULT:3353",
8 "entitySubtype": "DEFAULT",
9 "type": "NORMAL",
10 "source": "POS",
11 "attributes": {
12 "inventoryPosition": {
13 "retailerId": "3353",
14 "locationRef": "F_1686296685026",
15 "productRef": "AH8050-F_1686296685026-96",
16 "qty": "10"
17 }
18 }
19}
8. The Update is reflected on the Sources Dashboard:

9. The Stock-On-Hand is successfully updated to 10 pcs:
