Technical integration for data ingestion

Technical integration for data ingestion

Document Contents

This document provides an overview of the various potential technical integration options available when implementing Mondra. The intended audience is primarily Technical Compliance and Technology team members.
Additionally, we provide an overview of Mondra’s technical credentials and high-level system architecture.

Mondra Hypermodelling and required seed data

For a complete overview of the Mondra solution please see the Proof Of Value (POV) overview document and/or request access to the Retailer POV software. At its core, the Mondra solution uses its Hypermodelling technology to calculate environmental Product Footprints. The solution does this for all food & beverage products in a Retailer’s assortment.

The Hypermodelling engine requires seed data to function. This seed data is best drawn from Compliance / PLM solutions, which for food typically contains all data that is required. This document describes integration with Oracle’s Retail Brand Compliance (ORBC) solution, but integration with TraceOne and other systems is also possible.

Mondra Hypermodelling - seed data definition

A separate document has been provided which details of the required seed data. In summary, we require:

• Product basics & volume (Sales)
• Recipe tree, supply & sites
• Packaging




Data extraction - options

To get started we need an extraction of data from ORBC. In phase 2 of the program, this will extend to a full private-label Food & Beverage assortment. Mondra will support and accommodate whichever approach is preferred to get phase 2 started, but options C and D are much preferred long term. In all options Sales Volume (SV) data is handled separately.




Data sync & compliance workflows


Beyond the first extraction of data required to trigger Hypermodelling, we will move into the coexistence of Mondra and ORBC. In this state product composition and supplier details must be maintained between both systems, to be synchronized. 

Mondra fully recognizes the criticality of maintaining compliance workflows in ORBC and never overwrites its data directly. The mechanism for achieving this will need to be designed, agreed and delivered in Phase 2. Some potential options to start a conversation are covered on the page.

A proposed flow for discussion is below:


Data sync & compliance workflows - options

To fully support compliance workflows data must be synchronized between solutions. Some potential options to explore:



System architecture overview

High-level snapshot of Mondra Platforms architecture, shown with proposed integration to Retailers ORBC instance.


SaaS solution on Azure cloud. Ready to scale

• Azure Cloud
• ReactJS + Typescript
• .NET Core
• Databricks + PySpark
• SQL Server, Azure Data Lake Gen2



Mondra tech & security credentials

Our technical team are experienced in meeting the requirements of enterprise technology & security teams.
The following provides a high-level overview of the Mondra security approach:





Next steps

Under Phase 2 of the program, we would welcome starting a conversation on the following topics with your Technology and Technical teams in the coming weeks.

• Compliance workflows – hard limits and user preferences
• Security audit requirements as supplier
• Initial data extraction planning
• Full data sync & compliance workflow design workshops



    • Related Articles

    • Partner Integration Strategy

      Integrating with partners for the purpose of data acquisition Leverage existing data held in third party solutions, within the Mondra platform, to deliver additional customer or planet value. Reciprocate by enhancing the partner’s solution with ...

    • The Story Behind Mondra

      Mondra origins Mondra was founded in the year 2020 by our CEO and founder Jason Barrett. The Mondra leadership team have originated from a data analytics background and have all worked with similar large corporates to create business value from data. ...