Axual Documentation

Welcome to the Axual documentation. Use the menu on the left to navigate through the various sections.

What’s new in Axual `2024.1`?

In the spring release of Axual Platform, most of the improvements have been done to make the migration to the new Streaming and Governance Charts simple.

We have also introduced functionalities to the Self-Service to improve the Governance and Security experience.

Prevent SSL Reuse over Tenant or Instance
Simplify update of an expired SSL Certificate for Applications
Search Applications, Topics, and Environment by Team Owner (and other fields)
Export button for Applications, Topics, and Environment (only Tenant Admins)
Configurable label on top of the Self-Service to distinguish between multiple installations
View Kafka and Schema Registry Listeners for your Application
Cascade deletion of Application, Stream and Private Environment

Support

For urgent production issues, we are on standby 24/7 to answer your questions. Please use the standby number communicated to you.

For non-urgent requests, you’ll find our support options here.

Getting Started

As soon as you understand the basic concepts, and you want to get started building your application, creating a schema, or just want a guide to follow along to, please refer to the Getting started section.

Information Is All Around You

Wherever you are, information is all around you. It gets created by people, devices, applications, processes, etcetera. From a bank transfer between accounts to a car approaching a camera-operated parking garage entrance to an energy meter emitting energy measurements, information is generated continuously. Moreover, this information is not just stored; it gets used to putting things in motion. In your banking app, you want the transaction to appear as soon as it has taken place. You want the garage door to open as you approach it as an authorized person. The energy company wants to do billing based on the energy meter readings of its customers. You could consider these examples as being one-offs. Once the bank transfer is processed, it’s ok to forget about it; you parked your car, so why bother to use this information again, and once the energy bill has been generated, why store the meter reading?

If you look closely at processes happening within an organization, the same information gets reused A LOT! Multiple applications can reuse the data in different ways. APIs might be called multiple times to obtain the same information, or database queries might be executed for the same reason. Wouldn’t it be great if you could grasp this piece of information the moment it occurs? If you could use it in real-time, with the purpose you have?

Streaming Data?

This is where streaming data comes into play. If you hear the term streaming, it makes you think of water, or streaming audio or video, as offered on Spotify or Netflix. There are similarities, but when you talk about streaming data, it’s basically data (or pieces of information) created and made available close to the moment it has started to exist. The moment a transaction has taken place, some piece of information is created describing the transaction. As soon as you approach a garage sensor with your car, an approaching-door-event is generated by the device’s sensors, and when your energy meter performs a reading of the current meter values, it sends out an energy-meter-read event. When we mention streaming data, it is this continuous flow of information we are talking about.

The Streaming Platform

Let’s assume you build an application that wants to detect fraudulent bank transfers or start billing as soon as the last energy meter reading for a customer’s contract period comes in. It would be great if you could get access to the relevant data topic in real-time, so you can act when it’s relevant. The streaming platform is the central place within any organization responsible for capturing data streams and making them available to anyone authorized to access it. On platform level, stability, high availability, and security are guaranteed; it’s producers' and consumers' job to create value for the business.

Producers And Consumers

Producers create messages on data topics. In essence, producers are the "listeners" or the "observers", noticing events taking place or pieces of information being born and sending them to the streaming platform. Producers don’t care who is interested in their information. Their motto is: fire and forget! On the other hand, consumers subscribe to the data streams they are interested in and use the messages on those data streams to "do something" for the business, whether opening a garage door or billing a customer.

The cool part here is that the moment you have this data topic available on the platform. The producer is actively producing data, you can have 1 to n consumers subscribing to the same stream, each having their specific use case. This decoupling of producer and consumer and easy reuse of information is where the streaming platform’s real value lies for the business and its consumers.

Speaking The Same Language: Schemas

Producers might not care about who is reading their messages; they need to speak in a language understood by the other party, the consumers. In other words, the messages they produce to a data stream need to adhere to a specific schema, comparable to an API specification or a database table structure. You might conclude that there isn’t a decoupling between producer and consumer strictly speaking because they need to agree on what schema to use for messages on a particular data stream. This is only partly true; producers are allowed to change schemas considering the backward compatibility of the schemas.

Other benefits of streaming data

The examples above you could describe as being reactive patterns. Consumers respond in their way to an event taking place. This pattern has the added benefit that the consumer cannot only respond to those events in its own way, it can also do so whenever this consumer wants to (within certain limitations). In a streaming manner, asynchronous communication is more frequently used to replace existing request-response means of communication, e.g., between APIs.