The dashboard
Once we have explored how Alumio helps companies organize their IT ecosystem, it’s time to dive into how the Alumio dashboard looks and works.
Alumio is a web-based environment, meaning you can access it via your web browser. When you open the Alumio dashboard, this is what you see:
The health monitor is at the top, which displays the status of your current environment with the heart icons. If the heart is green, it means everything is running smoothly. For example, if tasks were to be stuck or failed, the health monitor would indicate it accordingly.
Below the health monitor, we have colorful boxes that provide a complete overview of all the tasks in the environment, including new, skipped, processing, finished, failed, and total tasks.
A new task is created when information is gathered from system A and turns into a processing task when the information travels to system B or flows through the transformers. A finished task is created when the information has reached system B successfully. On the other hand, if this information does not reach system B, the task will be categorized as a failed task.
A skipped task is usually something you may come across during the testing of integrations. During this testing, you may pull certain information from a system, but it may not be exactly what you expected. Therefore, you can choose to skip that task, which can be done manually, in bulk, or as an automated skip if you are certain you do not need this information.
The reason for this process is because, sometimes, system A is more powerful than system B, meaning it can handle a larger volume of data than its counterpart. This means tasks cannot be sent all at once but must be sent in batches instead to avoid system B being overloaded. This process is known as a queuing mechanism, and there is a waiting list for tasks that must be processed later.
This queuing is handled through an automated scheduler, in which you can indicate the number of tasks you want to send at a time. For example, you can choose to send a hundred tasks every minute from one system to another. The number of tasks you can schedule at a time will depend on the capacity of a certain system: some systems may be able to handle 500 tasks at a time, and some may be able to handle significantly less.
According to which view interests you most, you can select via the filtering option whether you want to see the stats from the last 24 hours, from today, or the past hour, or customize it depending on your preference, with the ability to select which routes to view as well. This is meant to be a user-friendly summary of all tasks to help with visibility and a 360-degree view of your integrations.
Despite this, it is important to know that real-time processing is also possible.
Below the task overview, you can view all routes within your system individually and their status. If you have an e-commerce business, this will include data such as product prices, customer orders, etc. This data would vary according to the information about your business.
So, what is a route? A route is the line on which data walks from point A to point B. Point A is known as the incoming configuration, i.e., where the data comes from, and point B is known as the outgoing configuration, i.e., where the data goes. It is important to know that incoming and outgoing configurations are always in one system.
Learn all you need to know about incoming and outgoing configurations in this video: https://www.alumio.com/crash-course/incoming-outgoing-configurations
However, you can set up multiple routes with one incoming and different outgoing configurations or multiple routes with different incoming and outgoing ones. For example, the incoming configuration could be just one, and the outgoing configuration could be three, meaning one system sends information to three different systems. This would mean three different routes are at play, i.e., three lines on which data travels from one system to another. In practice, this could be, for example, Shopware (E-commerce software), sending information to SAP (ERP), Akeneo (PIM), and Navision (ERP).
In the “connections” tab on the left side of the dashboard, we have the routes, incoming and outgoing tasks, which we have already discussed, and something called “Entity transformers.”
So, what are entity transformers? Entity transformers are used to map, change, or enrich your data. They are used to execute data actions within the integrations, such as transforming data into desired formats and developing caching layers that optimize the integrations. For example, if system A has information about a customer that only includes a name field and system B has a customer with a first and last name, the transformers can split that field into two and fill both fields.
Transformers can also enrich a data object by accomplishing extra API calls. In the dashboard, entity transformers can be created and altered by going to Connections -> Entity transformers. If you open the Transformers page, you can view all the transformers present within a specific environment with different names. While naming a transformer, you must make it a point to make the function of the transformer easily understandable with the naming.
You can use as many transformers as needed within the incoming and outgoing configurations or a route. A combination of transformers (having a specific use case) will allow you to map or transform the data as required. This approach also makes the transformers and data transformations more recognizable and manageable.
More on transformers here: How To Use The Alumio Entity Transformer Page
In that same “connections” tab, where we have the routes, incoming and outgoing configurations, and entity transformers, we have HTTP Proxies and Webhooks. Before we delve into what these are, it is important to know that you can choose to tell Alumio when to extract data from point A and at what frequency. For example, you can ask Alumio to extract data from X system every minute, every five minutes, every hour, only on the weekends, etc. Essentially, the customization options are limitless.
In the same way, you can ask for information to be sent to Alumio at a specific time and at a specific frequency, i.e., in real-time, which is made possible through an HTTP Proxy or a Webhook.
Alumio can function as an HTTP proxy between two endpoints for HTTP requests. Instead of sending HTTP messages directly to an endpoint, messages can be sent through Alumio. Alumio will forward the requests to the endpoint and return the response that it receives as if the endpoint was called directly. This gives every existing connection that uses the Alumio HTTP Proxy the logging capabilities that Alumio offers.
Alumio can also receive triggers to start routes from external endpoints. Webhooks allow systems to send automated messages or information to Alumio and are thus a powerful way to push data from one app to another automatically. A Webhook can receive information sent to Alumio from system A and will inform the system it has received the data. However, it will not provide information regarding the completion of the task, because the task will still need to be processed.
As you can see, the UI of the Alumio integration solution is very user-friendly, with a modern design and a home page on which all recent tasks and potential errors are displayed comprehensively. Navigating through the platform is done easily with dropdown menus and colorful visual aids, aiming to deliver a pleasant user experience.
Are you a visual learner? Check out this video about the Alumio dashboard:
