Integration

Welcome to the Demander integration area 🚀

This guide was created for ERPs and developers who need to integrate their systems with our sales force solution.

Here you will understand directly:

How integration with Demander works.
What types of data flows exist.
Which mechanisms you can use.
And which approach makes the most sense for your scenario.

📌 First, understand if your scenario needs integration

The best way to work with Demander is through system integration.

When a company has an ERP integrated with Demander, the ERP must be the official source of registration data. In this case, information such as customers, products, salespeople, and prices must be registered or modified in the ERP and sent to Demander through the integration.

However, it is also possible to work without integration and manage registrations directly in Demander. This scenario makes sense mainly when the company does not have an integrated ERP or when a specific field is not sent by the ERP.

👉 See how to identify whether your scenario should use manual registration or integration in the article Manual registration and ERP integration.

🔄 How does integration with Demander work?

If your scenario uses integration, it is important to understand that it can happen in two independent flows:

Sending data: ERP information is sent to Demander.
Querying data: Demander information is queried by the ERP.

You do not need to use the same mechanism for both flows.

This is intentional and allows you to choose the most suitable technology for each need, considering factors such as data volume, frequency, performance, and implementation effort.

Below, we explain each of these flows and the available mechanisms.

🔃 Types of data flows

In Demander, integration can be divided into two main flows: data sending and data querying.

Each flow has different objectives and characteristics, and in many scenarios it is common to use distinct technologies for each.

Understanding this separation is important to define the best integration strategy, considering factors such as data volume, frequency, performance, and implementation effort.

Below are the two types of flows used in Demander integrations:

Sending data to Demander (ERP Data → Demander)

This is the flow where your ERP or system sends information to Demander.

Examples:

Salespeople.
Customers.
Products.
General registration updates.

👉 Here you are feeding the sales force.

Querying data in Demander (Demander Data → ERP)

In this case, your system fetches data from Demander for internal use.

Examples:

Orders placed by salespeople.
Customers registered by salespeople.
Customers updated by salespeople.
Other data receipt options in the ERP.

👉 Here you are consuming data from the sales force.

💡 Why separate sending and querying?

Because each flow has different characteristics.

The data sending:

May involve large data volumes.
May require layout validation.
Frequency may vary between companies and segments.

The data querying:

Frequency may vary between companies and segments.
May depend on the ERP model (code, structure, effort, among other options).

Integration mechanisms

Currently, Demander offers three integration mechanisms:

Text File API

How it works:

Integration based on text files.
UTF-8 encoding.
Pipe-separated fields (|).
Each line represents a record/table, with the table identified by the first field.
The remaining fields follow the specific layout of each entity.

Simplified example:
18|123|Sample Company|Tax ID|... (18 means customers, 123 is the customer code, and so on for the remaining fields)

✅ Strengths:

High performance for large data volumes.
Facilitates batch processing.
ERP freedom to configure periodicity and internal handling.

⚠️ Points of attention:

Layout validation is handled by the implementation.
May require more initial development effort.
If the ERP does not work with text files, initial difficulties may arise.

📝 Documentation:

Demander Synchronizer

The Demander Synchronizer is a Java executable that acts as a bridge between your database and the sales force.

In short, it functions as an interface to transform database data from the ERP or Demander into text files (in the Demander layout).

Internally, the Synchronizer uses the text file API, so it shares some strengths and points of attention of the previous mechanism.

How it works:

Installed on a server or machine with access to the ERP database.
Allows configuring scripts for: reading, insertion, and updating.
Automatically generates files in Demander layout (depends directly on scripts).
Also consumes ready-made Demander files.

👉 In practice: you connect directly to the database and let the Synchronizer handle data transformation. You will need to build scripts according to database standards and the Demander layout.

✅ Strengths:

Significantly reduces development effort.
Automates generation and reading of files in Demander layout.
Ideal for those seeking quick implementation.

⚠️ Points of attention:

Dependency on an executable running in the environment.
If the installation is in the cloud, difficulties may arise in some installation scenarios.
In some more complex processes, difficulties may arise (insertion of orders and order items).

📝 Documentation:

Demander Synchronizer

REST API (JSON)

The Demander REST API allows integrating data via HTTP requests using JSON.

It is Demander’s newest integration mechanism, so not all endpoints are currently available, but new endpoints will be implemented as needed.

✅ Strengths:

Modern integration standard (HTTP + JSON).
Allows greater control over application logic.

⚠️ Points of attention:

May not be ideal for large volumes.
Still evolving (new endpoints added based on demand).

📝 Documentation:

Demander Integration API

💡 Suggestions for different scenarios

As mentioned, we understand integration as something to be evaluated according to the reality of each application and company. In this section, we suggest integration mechanisms for different flows and business realities.

Less work, more results

With the goal of deploying a functional and simple integration, Demander’s suggestion is to use the Demander Synchronizer for both flows.

Build data selection queries according to the ERP-Demander layout and create data insertion scripts for main or temporary tables, then read into production tables using an internal routine of the third-party system itself.

More independence for third parties

If the goal is to ensure greater independence and decision-making power for your application, Demander’s suggestion is to use one of the integration APIs according to your technology preference.

In this format, you can control periodicity and which data is sent, as well as build screens within the application to assist users, support, and future improvements, even though it increases complexity.

Most common scenario

As new integrations emerge, a pattern that works very well has been observed: it ensures considerably less work while delivering substantial independence to the third party.

This pattern is Demander’s most common recommendation: splitting the integration flows and working with different mechanisms.

For sending data from the ERP to Demander, work with the Demander Synchronizer. Since no custom publication code is required, you only install the executable, connect the database, and create data selection scripts according to the layout.

For querying data from Demander to the ERP, work with one of the integration APIs according to your technology preference. Since data insertion into the ERP can be controlled with greater independence by the third party, this aids support and future enhancements while ensuring the quality of data entered into the system.

🔗 Standardized ERP integrations

In addition to the integration options presented in this article, Demander has standardized integrations with select ERPs.

These integrations exist to facilitate deployment and reduce the effort required to develop and maintain an integration from scratch. When an ERP already has a standardized integration with Demander, part of the rules, structures, and necessary processes is already defined.

This allows the company to leverage an integration already built for that ERP, instead of having to build all communication between systems customly.

👉 If you use an ERP that already has a standardized integration with Demander, check the Native ERP integrations menu to review available options and understand how each integration works.

💬 Unsure if your ERP has a standardized integration with Demander? Contact our team. We are available to help identify the best path for your scenario.

🛒 Integrations with e-commerce systems

Demander can also be integrated with e-commerce systems.

This type of integration has different requirements from a traditional ERP integration. In addition to sending and receiving registration data, there may be specific processes related to the product catalog, customers, prices, orders, and other information exchanged between the e-commerce and the sales force.

For this reason, e-commerce integrations have dedicated documentation with specific guidelines for this scenario.

👉 If your goal is to integrate Demander with an e-commerce platform, check the E-commerce integrations menu to learn about available options and understand how this scenario works.

💬 Not sure if your system fits this scenario? Contact our team. We can help understand your platform’s characteristics and point you toward the most appropriate solution.