DFC - n8n experiment

This page describes the workflow used for converting the data obtained using DFC connector and using that to add Variants in airtable. Basically, an alternative of GET Bulk Products.

DFC API endpoint gives output in graph (JSON LD?) format which is different than the table or JSON format we need for working with airtable and other spreadsheets.

Link to the workflow: https://n8n.openfoodnetwork.org.uk/workflow/sQTnELdyzffuugln

DFC Endpoint documentation:

https://staging.openfoodnetwork.org.au/api-docs/index.html?urls.primaryName=OFN%20DFC%20API%20Docs

Login Credentials for DFC endpoint: You can use your OFN API key, but you would need to create a new credential in n8n. You cannot use existing OFN credential in n8n because the field name is different.

Name: X-Api-Token

Value: OFN API key

For this documentation and the workflow, I have used the example of a test enterprise I created earlier. Enterprise details: Name: Test Food Paradise Link: https://openfoodnetwork.org.au/test-food-paradise/shop Enterprise ID: 3856

Total Products: 4, Total Variants: 6 Note: I have tested this workflow on a small enterprise without permissions to manage products of other enterprises.

I have made a rough schematic to explain the workflow.

Basically, instead of storing data variant by variant, DFC splits the data of an each variant and clubs them together into different sections based on the type of data ex. catalog (contains sku, stock value) , offer (contains price, stock value), supplied product (contains name, description, unit details), enterprise etc. Therefore, we need to break “graph” into individual sections and then group items based on variant ids.

Example of individual items from each section:

Catalog Items
{
"@id":
"<https://openfoodnetwork.org.au/api/dfc-v1.7/enterprises/3856/catalog_items/69516>",
"@type":
"<http://static.datafoodconsortium.org/ontologies/DFC_BusinessOntology.owl#CatalogItem>",
"dfc-b:references":
"<https://openfoodnetwork.org.au/api/dfc-v1.7/enterprises/3856/supplied_products/69516>",
"dfc-b:sku":
"TP1",
"dfc-b:stockLimitation":
7,
"dfc-b:offeredThrough":
"<https://openfoodnetwork.org.au/api/dfc-v1.7/enterprises/3856/offers/69516>"
}
Supplied Products
{
"@id":
"<https://openfoodnetwork.org.au/api/dfc-v1.7/enterprises/3856/supplied_products/69516>",
"@type":
"<http://static.datafoodconsortium.org/ontologies/DFC_BusinessOntology.owl#SuppliedProduct>",
"dfc-b:name":
"v1.1",
"dfc-b:description":
"    ",
"dfc-b:hasType":
"<http://static.datafoodconsortium.org/data/productTypes.rdf#non-local-vegetable>",
"dfc-b:hasQuantity":
{
"@type":
"<http://static.datafoodconsortium.org/ontologies/DFC_BusinessOntology.owl#QuantitativeValue>",
"dfc-b:hasUnit":
"dfc-m:Piece",
"dfc-b:value":
1
},
"dfc-b:alcoholPercentage":
0,
"dfc-b:lifetime":
"",
"dfc-b:usageOrStorageCondition":
"",
"dfc-b:totalTheoreticalStock":
0
}
Offers
{
"@id":
"<https://openfoodnetwork.org.au/api/dfc-v1.7/enterprises/3856/offers/69516>",
"@type":
"<http://static.datafoodconsortium.org/ontologies/DFC_BusinessOntology.owl#Offer>",
"dfc-b:price":
10,
"dfc-b:stockLimitation":
7
},
{
"@id":
"<https://openfoodnetwork.org.au/api/dfc-v1.7/enterprises/3856/offers/69517>",
"@type":
"<http://static.datafoodconsortium.org/ontologies/DFC_BusinessOntology.owl#Offer>",
"dfc-b:price":
45,
"dfc-b:stockLimitation":
8
}

Grouping and Merging of items:

All of the three sections have @id and @type field. @type field is used to group items ex. grouping into catalog items, supplied products, offers etc.

@Id is used for combing/merging the data from different sections to get the required data for a variant. @id field basically gives us a URL instead of variant Id, so we have to use expressions to get the Variant Id as shown in the image. To get the variant Id, split the URL and take the last value in the Split array (8th index) or you can use a function to get the Variant Id and then use it to merge data from different sections. This will add a variable for Variant Id in the existing item which is used in merge module later on.

Note: Multiple merges were used, because you cannot merge more than 2 data streams in n8n using the merge module.

Note: I am using a variable Test to store the Variant Id (This is was a test setup, so didn't focus much on names)

Note: Alternatively, you can run multiple API calls to get all the info (1 Api call for catalog items, followed by 1 for supplied products, and then 1 for offer).

Last updated