Author:
Fluent Commerce
Changed on:
22 Aug 2024
This document will describe how Feeds work and guide users through understanding any prerequisites to integrate with Feeds.
This document assumes you are knowledgeable and aware of the following subjects:
Feeds is an availability data export tool. They allow users to create a programmatic export of selected data, ready to be consumed by any inventory-aware system.
Feeds contain two technical components:
The Feed component is the “parent” data modal of the Feed. This is where an Feed is configured and set up.
At the Feed level, you can define information such as:
Under an Inventory Feed, there is a one-to-many relationship to Inventory Feed Runs. Each Run is an individual execution that exports a new data file based on the configuration of the parent Feed.
Each Feed Run contains information such as:
Inventory Feed Runs are created by the Fluent system based on the settings configured at the Inventory Feed parent level.
Feeds are designed to export tailored views of availability into your own ecosystem. Once the data has been exported to your ecosystem, it will be in an easy-to-use format and ready to be shared with any other systems that benefit from availability.
Feeds are designed to provide data in a format that can be “owned” by the user. Fluent is designed for configurability and extensibility, and this solution enables our customers and partners to best integrate the data from Fluent into a target storage that can then be integrated into any target system.
The Inventory Feeds service will a run based on the parent configuration, or 5 minutes by default. When a run executes, it will generate an output of the availability from . This generated view of will be saved into an S3 bucket within the Fluent technology stack.
When configuring an feed, a customer- or Partner-owned AWS S3 bucket is required as a target destination. Once the target destination bucket is defined, the Feed service will set up an AWS cross-account replication service. This service will inspect the S3 bucket within the Fluent tech stack. Whenever it identifies any changes or new files added to the Fluent S3 bucket, the cross-account replication service will immediately start to replicate the changes across to the target destination bucket.
At this point, the target S3 bucket will have an exact copy of the availability data generated by the Feed. This data can then be used to provide a view of availability. Additionally, this also provides a historic cache of availability snapshots all the way back to the first initial run of the Feed.
Feed Runs come in two types: FULL and INCREMENTAL. Each Feed automatically determines the type of run based on its configuration and schedule. Users do not set the run type; the system manages it.
A Full Feed Run exports all data within the Feed's configured filters. This type of run establishes a comprehensive starting point for any integration or use of availability data. A Full Feed Run is always triggered the first time an Feed is activated, ensuring the system starts with a complete set of data. This initial run sets a known foundation, enabling subsequent Incremental Feed Runs to function correctly.
An Incremental Feed Run exports only the data that has changed since the last Feed Run. The configured filters and the frequency of the Feed determine the scope of this data. For instance, if an Feed is set to run every minute, the incremental changes will be relatively small compared to an Feed that runs once every hour. Incremental Feed Runs keep data up-to-date with minimal data transfer, focusing only on the changes since the previous run.
When an Feed is created and activated for the first time, it performs a Full Feed Run. This run extracts and exports all data based on the configured data type and filters, providing a complete dataset. Subsequent Feed Runs, triggered according to the configured frequency, will be Incremental Feed Runs. These runs will only export the data that has changed since the last run, again limited to the configured data type and filters.
The availability data exported as part of an Feed will be in a Parquet file format. We have chosen to export in this format because it provides a range of benefits.
Some of these benefits are:
Field | Description | Type |
id | Unique ID for the Virtual or Position | UUID |
status | current status of the Virtual or Position | String |
quantity | quantity value saved for the (only saved in exports of type Virtual_Position) | Integer |
onhand_quantity | quantity value saved for the Position (only saved in exports of type Inventory_Position) | Integer |
group_reference | or reference for the (only saved in exports of type Virtual_Position) | String |
location_reference | reference for the Position (only saved in exports of type Inventory_Position) | String |
virtual_position_type | Type of (only saved in exports of type Virtual_Position) | String |
inventory_position_type | Type of Position (only saved in exports of type Inventory_Position) | String |
created_on | Time the Virtual or Position was created | DateTime |
updated_on | Last time the Virtual or Position was updated | DateTime |
product_reference | Reference for the Product associated with the Virtual of Position | String |
catalogue_id | Unique id for the catalogue of the Virtual or Position | UUID |
external_reference | Ref of the Virtual or Position | String |