Even though flespi is a product for developers, its purpose is to serve as a foundation for corporate solutions used by multiple people with different sets of responsibilities. And while we have numerous resources covering all the aspects of programming with flespi, the topics related to end solution architecture, permissions control, and resources allocation seem unattended.
We want to stop discrimination and talk about the capabilities the flespi platform has for powering enterprise-level solutions.
Business need
Let’s take the following scenario as an example:
A software company develops a telematics solution for use by truck fleets. These guys want to overlook and manage (if necessary) all the subordinate resources.
The company has dealers responsible for distributing the software on specific markets. The dealers can allocate certain resources to sub-dealers and control sub-dealers’ operations.
Dealers rely on sub-dealers to perform trackers installation and platform setup for end customers. The sub-dealers restrict end users’ resources depending on the selected pricing plan.
End users (transportation companies) assign roles to their employees to define the scope of their responsibilities.
The scheme for the aforementioned scenario will look like this:
Common solution architecture
So, what does it take to implement such kind of solution and how to do it in the most efficient way? The flespi way of establishing hierarchical relations grounds on the notion of subaccounts.
Let’s approach this task layer by layer starting for the bottom one.
Customers
Customers are the actual users of the telematics software who need their vehicles to be connected to the platform. Therefore, a customer’s admin should be able to create new devices of the desired type.
Access to device messages is performed via the REST or MQTT API.
User roles within the customer subaccount can be managed and assigned using ACL tokens.
Note: flespi does not offer an internal mechanism to limit the choice of device types, so you have to take care of such pre-filtering on your side. The same is true if you need to limit the choice of channels available to a certain customer.
Dealers & sub-dealers
Dealers and sub-dealers are intermediaries that can create and manipulate limits (see Know the limits section below) to shape customers accounts according to their pricing model.
If a dealer (sub-dealer) wants to offer additional functionality to its customers, they can create own entities of the flespi platform should the limits allow.
Telematics software company (Master)
This is a small god of their own universe — the substance that creates all subsequent levels of the hierarchy and has full control of all of them.
In most cases, it is efficient to have the channels created in the top-level account. Why? Because it’s a shared resource with huge capacity (50,000 simultaneous connections).
Say, one of your dealers has a new client who wants to connect 500 Teltonika devices. If you let the dealer create a teltonika channel for themselves, they will be paying for the resource used by 1% (and other dealers who may later have customers connecting Teltonikas will not be able to use the same channel). But if the master account creates this teltonika channel, all dealers and sub-dealers will be able to use it for their current and prospect customers using Teltonika trackers. Such implementation allows sharing the channel monthly cost and optimizing its utilization.
Remember, that if someday you approach the limit of 50,000 connected devices, you can create another Teltonika channel in the top-level account.
All in all, we end up with the structure like this:
With such a structure in place:
All subaccounts of all layers have access to the Common channel.
Only subaccounts 2-1, 2-1-1, and 2-1-2 have access to the Extra entity.
Limits created in the Master account can be assigned to any subaccount. Limits created in the Subaccount 2 can be assigned to the children of this subaccount only, etc/
Note: you don’t have to have all four layers of hierarchy — two or three might be enough for your purposes.
Know your limits
Limits are a powerful mechanism for the organization of granular control of the resources use. However, to apply the limits correctly, it is important to understand their intricacies. Below are the major provisions.
A limit in flespi is a collection of restrictions referring to various resources, e.g. channels count, channels storage, API traffic, MQTT sessions count, etc.
The limits of the subaccounts count towards the limits and restrictions of their parent account. E.g. there is a sub-dealer with a limit of 10 channels and two customer subaccounts with no explicit limit on the number of allowed channels. If the sub-dealer already has three channels created, the two customers can share seven channels between them.
The value of -1 means that the limit is not set and the only restriction is the capacity of the parent account.
The value of 0 prohibits the creation of the respective type of items (e.g. channels, devices, streams, etc.).
Sub-dealers can create special “block” limits — the ones with everything prohibited — to block subaccounts for non-payment or other violations.
You can assign the same limit to multiple subaccounts if they need the same set of restrictions.
Note: you cannot transfer flespi platform entities (e.g. channels, devices, streams, etc.) between subaccounts; you should delete them and re-create anew in the proper account.
***
Flespi subaccounts are a flexible and powerful concept letting businesses of any size build a carefully demarcated hierarchical model with clearly defined capabilities, permissions, and limits. Try using subaccounts for your next big project and don’t hesitate to consult us to devise an optimal architecture and achieve the best results.