Existing data locked up in legacy services, applications, and databases can be hard to access — but it doesn’t have to be. There are tools and methods available to make the process a whole lot easier. In this post, we’ll look at how our fictional logistics company, Acme Freight, addresses this common use case with the open source API framework, LoopBack. (For details, see the Unlock enterprise data using APIs developer journey.)

Scenario

Acme Freight has existing enterprise data locked in an Enterprise Resource Planning (ERP) system. Acme developers need to access data in the ERP system to deliver a better and smarter supply chain solution for the company’s customers. With LoopBack, they can access that data by exposing the ERP system using an API.

ERP implementation

Within the broader Acme Freight application, the ERP microservice reveals APIs to access a traditional ERP system data model. The APIs are defined in an Open API Specification file, also known as Swagger.

The ERP application is made up of the following components:

Models:

  • Suppliers
  • Products
  • Distribution Centers
  • Shipments
  • Retailers
  • Users

Data sources:

  • ElephantSQL (PostgreSQL)
  • In-memory DB
  • Extendable to almost any data source

With the preceding models and data sources, the APIs enable you to:

  • Log in securely as either a supply chain manager or retail store manager
  • Securely access Products, Suppliers, Distribution Centers or Retailers
  • Securely create, read, update and delete Shipments in the system

The componentized architecture of LoopBack enables developers to focus on the actual models that are stored in the database rather than individual APIs. Using this approach, a developer simply defines the types of objects an application needs to work with, and LoopBack automatically generates the APIs to access the data, authentication requirements, and API documentation.

Pluggable data sources

One major advantage of LoopBack is that it is data-source agnostic — the connectors handle the actual storage and retrieval of data from a data source. At any point, you can swap out the data source from underneath the application. This allows developers to quickly develop locally using a simple in-memory database and push to production with a highly available database by simply setting an environment variable.

Let’s take a quick look at how the ERP application implements this capability. The server/datasources.json file holds the default data source information, and looks like this:


{
  "transient": {
    "name": "transient",
    "connector": "transient"
  }
}

The transient connector is used for embedded models, but notice that there isn’t a real database defined in this file. Instead, the data source is programmatically configured every time the application is started. To see how this is done, take a look at datasources.local.js. That’s right — you can use JavaScript to define which data source is used.

Note: The datasources.local.js file is called by default to define which data source to use, but you can also define it as datasources..js. The file that matches the NODE_ENV environment variable (usually “development” or “production”) will configure the data source.

Taking a look at the datasources.local.js file, we see that it defaults to an in-memory database:


// default to in-memory data source
var datasources = {
  "db": {
    "name": "db",
    "connector": "memory"
  }
};

However, directly below this declaration is a conditional statement that redefines the database when VCAP_SERVICES is set. VCAP_SERVICES is the environment variable for defining service credentials on Bluemix and other Cloud Foundry services. Essentially, when this application is pushed to Bluemix, where an ElephantSQL service is bound to it, the application will use that dedicated service instead. This is a powerful way to keep development, staging, and production environments separate while using a single code-base.

Bootstrapping data

Another core feature of LoopBack is the ability to bootstrap data when the application is launched. Using boot scripts, we load up a default set of retailers, products, suppliers and distribution centers and store them in whichever data source is connected to the application.

LoopBack will automatically execute any scripts in the server/boot directory in alphabetical order. We take advantage of this to automatically seed the data source with any tables that need to be created, as well as a default set of shipments, distribution centers and more.

The two boot scripts responsible for populating the data are 100-create-tables.js and [110-create-static-data.js](https://github.com/IBM/acme-freight-erp/blob/dev/server/boot/110-create-static-data.js). Since LoopBack runs these scripts alphabetically, we prefix the files with numbers to ensure that the tables are created before they are seeded with data.

LoopBack FTW

These are just a couple of the ways in which we are leveraging the power and flexibility of LoopBack to unlock the data in the Acme Freight ERP system. This is really only the tip of the iceberg. And did we mention it’s open source and Free As In Beer? 🙂

Learn More

Join The Discussion

Your email address will not be published. Required fields are marked *