BlogAnnounced at MongoDB.local NYC 2024: A recap of all announcements and updatesLearn more >>
MongoDB Developer
Atlas
plus
Sign in to follow topics
MongoDB Developer Centerchevron-right
Developer Topicschevron-right
Productschevron-right
Atlaschevron-right

No Connectivity? No Problem! Enable Offline Inventory with Atlas Edge Server

Rami Pinto Prieto8 min read • Published May 02, 2024 • Updated May 02, 2024
Atlas
Facebook Icontwitter iconlinkedin icon
Rate this tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
If you haven’t yet followed our guide on how to build an inventory management system using MongoDB Atlas, we strongly advise doing so now. This article builds on top of the previous one to bring powerful new capabilities for real-time sync, conflict resolution, and disconnection tolerance!
In the relentless world of retail logistics, where products are always on the move, effective inventory management is crucial. Fast-moving operations can’t afford to pause when technical systems go offline. That's why it's essential for inventory management processes to remain functional, even without connectivity. To address this challenge, supply chains turn to Atlas Edge Server to enable offline inventory management in a reliable and cost-effective way. In this guide, we will demonstrate how you can easily incorporate Edge Server into your existing solution.
Multi-store offline inventory architecture
In the first part of our tutorial series, we explored how MongoDB Atlas enables event-driven architectures to enhance inventory management with real-time data strategies. Now, we are taking that same architecture a step further to ensure our store operations run seamlessly even in the face of connectivity issues. Our multi-store setup remains the same: We’ll have three users — two store managers and one area manager — overviewing the inventory of their stores and areas respectively. We'll deploy identical systems in both individual stores and the public cloud to serve the out-of-store staff. The only distinction will be that the store apps will be linked to Edge Server, whereas the area manager's app will remain connected to MongoDB Atlas. Just like that, our stores will be able to handle client checkouts, issue replenishment orders, and access the product catalog with no interruptions and minimal latency. This is how Atlas Edge Server bridges the gap between connected retail stores and the cloud.
Without further ado, let's dive in and get started!

Prerequisites

For this next phase, we'll need to ensure we have all the prerequisites from Part 1 in place, as well as some additional requirements related to integrating Edge Server. Here are the extra tools you'll need:
  • Docker (version 24 or higher): Docker allows us to package our application into containers, making it easy to deploy and manage across different environments. Since Edge Server is a containerized product, Docker is essential to run it. You can choose to install Docker Engine alone if you're using one of the supported platforms or as part of the Docker Desktop package for other platforms.
  • Docker Compose (version 2.24 or higher): Docker Compose is a tool for defining and running multi-container Docker applications. The Edge Server package deploys a group of containers that need to be orchestrated effectively. If you have installed Docker Desktop in the previous step, Docker Compose will be available by default. For Linux users, you can install Docker Compose manually from this page: Install the Docker Compose plugin.
  • edgectl (version 0.23.2 or higher): edgectl is the CLI tool for Edge Server, allowing you to manage and interact with Edge Server instances. To install this tool, you can visit the official documentation on how to configure Edge Server or simply run the following command in your terminal: curl https://services.cloud.mongodb.com/edge/install.sh | bash.
With these additional tools in place, we'll be ready to take our inventory management system to the next level.

A quick recap

Alright, let's do a quick recap of what we should have in place already:
  • Sample database: We created a sample database with a variety of collections, each serving a specific purpose in our inventory management system. From tracking products and transactions to managing user roles, our database laid the groundwork for a single view of inventory.
  • App Services back end: Leveraging Atlas App Services, we configured our app back end with triggers, functions, HTTPS endpoints, and the Data API. This setup enabled seamless communication between our application and the database, facilitating real-time responses to events.
  • Search Indexes: We enhanced our system's search capabilities by setting up Search Indexes. This allows for efficient full-text search and filtering, improving the user experience and query performance.
  • Atlas Charts: We integrated Atlas Charts to visualize product information and analytics through intuitive dashboards. With visually appealing insights, we can make informed decisions and optimize our inventory management strategy.
Inventory management system architecture using MongoDB Atlas and Next.js
Building on our previous setup, let's envision a typical retail scenario where our inventory management application will truly shine with the incorporation of Edge Server.
Offline inventory architecture normal scenario
Suppose the area manager needs to update the product catalog. The data seamlessly flows to MongoDB Atlas, where it is then transmitted to Edge Server. Once received, Edge Server stores the update locally and makes it available for retrieval by endpoint devices. This ensures that any changes made centrally are quickly propagated to all connected stores, maintaining consistency across the board.
Offline inventory architecture disconnection scenario
Now, let's consider a situation where a remote store experiences a temporary disconnection from the cloud. Despite this, the data stored on Edge Server remains accessible. Store staff can continue with essential tasks like sales, catalog checks, and placing orders, as Edge Server diligently queues any updates. Meanwhile, changes made by the area manager are queued in the cloud and await synchronization with the remote store once it's back online. This uninterrupted flow of operations ensures business continuity even during connectivity disruptions.
Offline inventory architecture reconnection scenario
Finally, when the remote store reconnects to the cloud, the queued updates are exchanged, ensuring synchronization between the local and cloud databases. Any pending operations are applied, and both systems converge to the same final state. This seamless reintegration process guarantees that all stores operate with the latest data, irrespective of connectivity challenges.
To achieve this, we’ll need to make a couple of adjustments to our existing setup.

MongoDB Atlas configuration

Flag store managers as edge users

Flagging store managers as edge users will allow our app to switch the database connection from Atlas to Edge Server. This is useful for the guide purposes, as it will simplify the setup not requiring extra app deployments to use different users.
  1. Go to your Atlas dashboard, access the Data Services page, locate your cluster, and click on "Browse Collections."
  2. Find the "users" collection and open it. Users are categorized based on whether they are expected to connect to an Edge Server instance (type: “edge”) or directly to Atlas (type: “altas”). Look for the attribute type, which is currently set as "atlas" for all users. Double-click on it, change the value to "edge," and click the "Update" button to confirm. After applying the changes, your users in the collection should reflect this update.
Users collection view in MongoDB Atlas
Let's explore how this flag impacts our application's code. Consider the simplified version of the getServerSideProps function on our main products page:
This function dynamically determines whether to connect to the Edge Server or Atlas based on the user's type. For a more detailed version of this function, including controls for filter facets and user role distinctions, refer to the app/pages/products/index.js file in your cloned repository.

App Services configuration

In this section, we'll ensure that Edge Server is properly configured and ready to run. While most of the setup should have been covered in Part 1 of the tutorial series, we'll review and verify the existing configurations and add any additional steps as needed.
Here are the steps to ensure Edge Server is properly configured and ready to run:
  1. Go to the App Services tab in Atlas, located next to the Data Services tab. Find the app created in Part 1 of the tutorial series and click on it.
  2. First, we’ll verify that Device Sync has been successfully enabled. Access the Device Sync tab in the left-side menu and ensure that you see the "enabled" tag next to the page title.
  3. To check we have the proper data access permissions in place, head to the Rules tab in the left-side menu. Locate your database and click on each collection to confirm the following permissions:
    • In the "locations," "products_area_view," and "users" collections, you should see a "readAll" permission.
    • In the "products" and "transactions" collections, you should see a "readAndWriteAll" permission.
  4. Next, open the Authentication tab and verify that both the anonymous and API Key providers are enabled.
  5. Lastly, we’ll need to get our One-time Registration Token:
    • Go to the Device & Edge Sync tab and click on "Deploy Edge Server."
    • On the next screen, provide a name for your Edge Server services and select the database created in Part 1 as the datasource.
    • Confirm by clicking "Create service."
    • A token will be generated; ensure you copy it and store it securely, as it won't be available again.
App services device & edge sync view
With these configurations in place, your Edge Server instance is now ready to be configured and run effectively.

Configure Edge Server

As we have seen, Edge Server is a "local" server that sits between your client devices and MongoDB Atlas App Services. For most use cases, you'll provision hardware on-premises to host Edge Server. But for the purpose of this guide, you may host it on your own device for convenience. To learn more about hosting options, please visit our Edge Server Host Requirements documentation.
Follow these instructions to set up and run Edge Server on your own device:
We will configure Edge Server using the command-line tool edgectl. By default, this tool will be installed at .mongodb-edge in your home directory. You can reference the entire path to use this tool, ~/.mongodb-edge/bin/edgectl, or simply add it to your PATH by running the command below:
The next command will generate a docker-compose file in your current directory with all the necessary steps to deploy and manage your Edge Server instance. Replace <your-app-id> with the value obtained in the first part of this tutorial series, and <your-auth-secret> with the token generated in the previous section.
Note: To learn more about each of the config flags, visit our documentation on how to install and configure Edge Server.
This application is able to simulate offline scenarios by setting the edge server connectivity off. In order to enable this feature in Edge Server, run the command below.
Action to simulate offline scenarios
Lastly, to start the server, from the edge_server directory, run:
Check the status by running edgectl status. You should see the value "cloud_connected": true indicating that Edge Server is connected to MongoDB Atlas.
Important: Once you are done with the tutorial, remember to stop the server by running edgectl stop in the edge_server directory.

Frontend configuration

Update your environment variables

We’ll need to add an extra environment variable to specify the address of the server hosting your Edge Server instance. In this case, it will be just localhost because it will run on our own device, but you can definitely try different deployment options!
Navigate to the app directory. If you are currently in the edge_server one, you can run the command below:
Open the .env.local file with your preferred text editor or IDE, and add a new line for the environment variable EDGE_SERVER_HOST.
We should have nine environment variables in total by now: MONGODB_URI, MONGODB_DATABASE_NAME , REALM_APP_ID, APP_SERVICES_URI, API_KEY, CHARTS_EMBED_SDK_BASEURL, DASHBOARD_ID_PRODUCT, DASHBOARD_ID_GENERAL, and EDGE_SERVER_HOST.
As usual, please remember to save the updated file.

Run locally

We are ready to launch our new inventory management system! Execute the following commands to run your app locally:
Your app should be up and running on http://localhost:3000. Hurray!

Wrapping up

Congratulations! Your inventory management app is now equipped with the power of Atlas Edge Server, ensuring seamless operation even in challenging connectivity scenarios. Here's a quick rundown of what you've achieved in this tutorial:
  • Enhanced inventory management: Atlas Edge Server enables hybrid architectures without sacrificing real-time monitoring of stock levels, ensuring precise inventory control and timely restocking.
  • Seamless operational workflows: Edge computing ensures essential store tools remain operational during connectivity hiccups.
  • Reduced complexity: By integrating Atlas Edge Server into existing architectures, retailers can offload operational burdens and focus on delivering differentiated experiences to delight their customers.
But wait, there's more to explore! Dive deeper into MongoDB's capabilities and discover how it's revolutionizing the retail industry:

Facebook Icontwitter iconlinkedin icon
Rate this tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Related
Code Example

EHRS-Peru


Jul 07, 2022 | 3 min read
Tutorial

Build a Cocktail API with Beanie and MongoDB


Apr 02, 2024 | 6 min read
Article

How to Enable Local and Automatic Testing of Atlas Search-Based Features


Apr 23, 2024 | 8 min read
Tutorial

Migrate From an RDBMS to MongoDB With the Help of AI: An Introduction to Query Converter


May 02, 2024 | 4 min read
Table of Contents