Epc State Transition - Integration

1. Overview

These APIs are part of a system for:

  1. Fetching Realm Mappings (e.g., store/location information) when using realm-based integration.
  2. Creating a mapping from a store ID to a specific realm (if needed).
  3. Updating EPC States under the selected context (realm-based or external store-based).

Additionally, an Exponential Backoff retry strategy is suggested for handling transient failures.

2. Integration Mechanism

The system supports multiple ways to indicate the context under which you want to update EPC states:

3. Authentication

4. Environments and Base URLs

Use the appropriate base URL depending on your environment:

5. Sequence Diagrams

Below are example workflows depending on which integration mechanism is used to set the context.

5.1 Realm-Based Sequence Diagram

sequenceDiagram participant User as Client Application participant API as gStore API participant DB as Database User->>API: GET /userRealms (Authorization: Basic ...) API->>DB: Retrieve Realm Data DB-->>API: Realm Data API-->>User: Realm Mappings (JSON Array) note right of User: 1. Call /userRealms (once to retrieve or confirm realm) User->>User: Map store to realm (if needed) note right of User: 2. Create the Mapping (internal logic) User->>API: POST /epcs/states Note over User,API: HTTP Headers:
X-REALM-SELECTED-URN: <realmNetworkNamespace>
(Authorization: Basic ...) API->>DB: Update EPC State alt On Success DB-->>API: State Updated API-->>User: 202 Accepted else On Failure API-->>User: Error Response note right of User: 3. Exponential Backoff loop Retry with Backoff User->>User: Wait for RetryInterval User->>API: POST /epcs/states
(X-REALM-SELECTED-URN) API->>DB: Update EPC State end end

5.2 External Store ID-Based Sequence Diagram

sequenceDiagram participant User as Client Application participant API as gStore API participant DB as Database User->>API: POST /epcs/states Note over User,API: HTTP Headers:
Authorization: Basic ...
X-EXTERNAL-STORE-ID: <storeId> API->>DB: Update EPC State alt On Success DB-->>API: State Updated API-->>User: 202 Accepted else On Failure API-->>User: Error Response note right of User: Exponential Backoff loop Retry with Backoff User->>User: Wait for RetryInterval User->>API: POST /epcs/states
(X-EXTERNAL-STORE-ID) API->>DB: Update EPC State end end

5.3 External Store Number-Based Sequence Diagram

sequenceDiagram participant User as Client Application participant API as gStore API participant DB as Database User->>API: POST /epcs/states Note over User,API: Headers:
Authorization: Basic ...
X-EXTERNAL-STORE-NUMBER: <storeNumber> API->>DB: Update EPC State alt On Success DB-->>API: State Updated API-->>User: 202 Accepted else On Failure API-->>User: Error Response note right of User: Exponential Backoff loop Retry with Backoff User->>User: Wait for RetryInterval User->>API: POST /epcs/states
(X-EXTERNAL-STORE-NUMBER) API->>DB: Update EPC State end end

Key Points:

6. EPC State Transition

6.1 Endpoint

POST /epcs/states

Full URL (QA Example):

POST https://qc-gdynamite.dev.kalama.cloud/gStore/api/v0.2/epcs/states

6.2 Description

This endpoint updates the state of one or more EPCs under the chosen context (realm-based or external store-based).

6.3 Request Headers

Depending on the integration method, one of these headers is used:

And in all cases:

6.4 Request Body

Content-Type: application/json

Sample Request Body:

[
  {
    "epcId": "30340c19e0286080178ffb02",
    "state": "LOCKED",
    "reasonShortText": "Damaged",
    "updatedAt": "2024-04-23T18:25:43.511Z"
  },
  {
    "epcId": "30340c19e0286080178ffb03",
    "state": "FREE",
    "reasonShortText": "Available",
    "updatedAt": "2024-04-23T18:25:43.511Z"
  }
]
Field Type Description
epcId string Unique identifier for the EPC (e.g., 30340c19e0286080178ffb02).
state string New state for this EPC (e.g., LOCKED, FREE, etc.).
reasonShortText string Short explanation/reason for the state change (e.g., Damaged, Available).
updatedAt string ISO 8601 timestamp of when the EPC state was updated (e.g., 2024-04-23T18:25:43.511Z).

6.5 Responses

7. Realm Mappings (Realm-Based Only)

This section applies only if you are using realm-based integration with X-REALM-SELECTED-URN.

7.1 Endpoint

GET /userRealms

Full URL (QA Example):

GET https://qc-gdynamite.dev.kalama.cloud/gStore/api/v0.2/userRealms

7.2 Description

Retrieves a list of realms (store locations or other realm types) available to the authenticated user.

7.3 Request Headers

7.4 Response Body

Sample Response:

[
  {
    "realmNetworkNamespace": "gdynamite:grg:ca:ca0294",
    "displayName": "Store#294 GRG | Yorkdale Shopping Centre Toronto On",
    "description": "Store#294 GRG | Yorkdale Shopping Centre Toronto On",
    "isSelected": false,
    "formattedAddress": "3401 Dufferin Street, Yorkdale Shopping Centre, North York, ON, M6A 2T9, Canada",
    "countryCode": "CA",
    "brand": "Garage",
    "type": "STORE",
    "realmLineages": [],
    "storeId": "CA0317",
    "assignedPlaceRealms": []
  }
]
Field Type Description
realmNetworkNamespace string A URN-like identifier for the realm (e.g., gdynamite:grg:ca:ca0294).
displayName string A user-friendly name for the realm.
description string Descriptive text about the realm.
isSelected boolean Indicates if the realm is currently selected (if used in a UI context).
formattedAddress string Full address of the realm.
countryCode string Country code (e.g., CA).
brand string Brand name associated with this realm (e.g., Garage).
type string Type of realm (e.g., STORE).
realmLineages array Array of additional realm lineage details (if any).
storeId string Store's ID (e.g., CA0317).
assignedPlaceRealms array Array of realm objects assigned to this user, if applicable.

8. HTTP Retry Mechanism with Exponential Backoff

For transient errors (e.g., network timeouts, 5xx responses), use an Exponential Backoff strategy. A common formula is:

RetryInterval = FixedDelay + (BackOffMultiplier * 2^(RetryCount))

8.1 Example: 1-Hour Calibration

Suppose we want to allow retries for up to ~1 hour. Let’s set:

Retry Attempt Formula Interval (seconds) Cumulative Wait (approx.)
1 30 + (15 * 2^1) = 30 + 30 60 1 minute
2 30 + (15 * 2^2) = 30 + 60 90 2.5 minutes
3 30 + (15 * 2^3) = 30 + 120 150 5 minutes
4 30 + (15 * 2^4) = 30 + 240 270 ~9.5 minutes
5 30 + (15 * 2^5) = 30 + 480 510 ~18 minutes
6 30 + (15 * 2^6) = 30 + 960 990 ~34 minutes
7 30 + (15 * 2^7) = 30 + 1920 1950 ~67 minutes

By the 7th retry, you are already exceeding 1 hour of total wait time. In a production scenario, you might configure a maximum number of retries or a maximum cumulative wait time (whichever comes first).

Tip: Fine-tune FixedDelay, BackOffMultiplier, and maximum retries based on your application’s SLA and tolerance for delayed processing.

Alternative Calibration Example

Retry n Calculation Total Time (secs)
1st Retry 1 120 120
2nd Retry 2 120 + 240 360
3rd Retry 3 360 + 480 840
4th Retry 4 840 + 960 1800
5th Retry 5 1800 + 1920 3720

9. Summary of Endpoints

9.1 EPC State Transition

9.2 Realm Mappings

10. Additional References


End of Documentation

For further clarifications on error codes, rate limits, or advanced usage (e.g., bulk updates, filters, partial updates), please contact the API maintainers.