Tenants management
Tenants in LiveObjects
In LiveObjects, a tenant is a logical partition that isolates the resources of an entity, ensuring their operational independence.
There is two types of tenant :
-
Customer : Customers manage fleet of devices. Customer features are described in the other chapters of this document.
-
Vendor : Vendors manage the customers. Vendors create, configure and delete customers. It is the object of this chapter.
Tenant configuration
As LiveObjects manages different connectivities, and different ways of processing and providing data, each tenant must be crafted according to the user needs, and it is the vendor responsibility to provide a fully operational customer tenant.
The configuration parameters of a customer are stored in its offer settings attribute. The offer settings are divided into sections, each section is linked to a function of LiveObjects and contains a list of parameters that need to be set.
{
"offerSettings": {
"deviceManagement": {
"content": {
"enabled": true,
"maximumAssetsNumber": 100000,
"maximumTagsNumber": 10,
"maximumPropertiesNumber": 10
},
"revision": 1
},
"cellular": {
"content": {
"enabled": true
},
"revision": 1
}
}
}The offer settings update is a critical operation. Their update is error-prone and an improper use may cause dysfunction. The manual update is locked and is delegated to the BSS component through offers and options.
It is the responsibility of vendors to manage the parameters in the offer settings of the customer they have created. They can be assisted by support vendors or LiveObjects admin. Support vendors are account managed by Orange entities and that can provide assistance to the vendors for managing customers and investigating.
BSS
BSS (Business Support System) is the component that manages the update of the customers offer settings. It provides predefined maintained configurations and guarantees that the parameters values remain consistent.
BSS stores rules. Rules are created by admins. Vendors subscribe customers to rules and rules update the parameters value in the customer offer settings.
These rules can be offers or options. A tenant must subscribe to 1 offer and can subscribe to 0 to X options. Rules apply one by one on customer in order to update its offer settings. The offer applies first, and then all the options, from the first subscribed to the last. If 2 options modify the same parameter, the last option subscribed has the last say.
Vendors can subscribe customers to a rule with 1 of this 3 indexes : an id, a name, and a display name. It is highly recommended to take the display name, it îs the only way to keep track of the rule update. id and name points to a specific version of a rule, whereas display name always points to the latest.
A BSS rule is composed of pre-conditions and post-conditions :
-
A tenant can be subscribed to a rule only if all its pre-conditions are verified. (For example, a specific Lora option will not be available if Lora connectivity is not activated on the tenant) To make the things easier, API
GET /api/v1/vendor/bss/customers/{tenantId}/compliance/validatedprovides only the list of the rules that can be applied on a customer. -
The post-conditions are commands that apply to offer settings values. When offer settings are updated, all post-conditions are applied.
{
"offerSettingsPostConditions": [{"settingSection": "cellular", "value": {"enabled": true}, "action": "SET"}]
}{
"offerSettingsPostConditions": [{"settingSection": "deviceManagement", "settingPath": "maximumTagsNumber", "value": 10, "action": "ADD"}]
}| A tenant can’t be subscribed to a disabled rule, but tenants that have already subscribed to this rule are not unsubscribed. |
How to create a consumer?
step 1 : create the structure of the new customer
First the vendor should create a tenant :
POST /api/v1/vendor/customers
{
"name":"customerName",
"login":"customerMainUserLogin",
"email":"mainuser@home.com"
}The customer is created but is not ready to use. Offer settings are empty and its status is deactivated. Users can’t access its.
NOTE : Customer is not yet activated, this will be done when the offer is applies at step 3.
step 2 : retrieve available offers and options
The vendor must configure the customer with the BSS with 1 offers and some options. The following API provides the rules validated for the targeted customer : the rule is available to the vendor and all its pre-conditions are met.
GET /api/v1/vendor/bss/customers/{tenantId}/compliance/validated
{
"created": "2021-08-12T09:59:57.397Z",
"disabled": false,
"displayName": "SMS-Connect OFR", (1)
"id": "d338f9ebc-f763-414b-b6d0-51b0354-1a06",
"name": "SMS-Connect OFR v2.24", (2)
"offerSettingsPostConditions": [
{
"action": "SET",
"settingSection": "smsconnect",
"value": {
"connectivities": {
"20406": {
"enabled": true,
"limits": {
"maxMsisdn": 10000,
"maxSmsOutPerDay": 10000,
"maxTags": 20
}
}
},
"enabled": true
}
}
],
"preConditions": [{
"tenantContextLogic": {
"==": [
{"var": "parent.offerSettings.bss-vendor.content.options.SMS-Connect \"OFR"}, true
]
}
}],
"tags": [
"SMS-Connect",
"France",
"OBS",
"Official"
],
"type": "OPTION" (3)
}| 1 | Save the display name, this is the value you need when you select an option. |
| 2 | Rule name : usually contains display name and version (unique) |
| 3 | Type of the rule : Offer, Option or Admin Option |
step 3 : set offers and options
The vendor shall then select BSS rules for the customer, first, one offer (customer is activated after this operation, and its main user receives the user activation mail) and then the options (if required). It is highly recommended that the customer subscribes to the rule display name. This ensures that the latest version of the offer is selected and that rule update will be taken into account.
POST /api/v1/vendor/bss/customers/{tenantId}/subscriptions?ruleDisplayName={displayName}
When a customer subscribes to a new rule, the offer setting are refreshed. The selected offer is applied first and then all options. The last rule applied has the final say on the parameter setting.
| Some options have ADMIN_OPTION as type. It means that only a LiveObjects admin can subscribe a customer to this option. Admin option are the last applied. |
Rules management
Delete a rule subscription
If you need to remove a rule applied on a customer, here is the command to apply. This command works only with the ruleId, contrary to the subscription command.
DELETE /api/v1/vendor/bss/customers/{tenantId}/subscriptions?ruleId={ruleId}
| Some options may apply several times on a tenant. (For example, when the rule updates a parameter with an add operation). In this case, only last is removed. |
| Do not un-manage a customer from BSS. Customer would be doomed. Its offer settings could no longer be updated and there would be no guarantee that it could continue to operate. |
How to remove a customer?
It is a 2 steps operation :
-
Deactivate the tenant with the dedicated BSS option : Disabled
-
Remove the customer from LiveObjects
Vendor subscribes customer to option Disabled :
POST /api/v1/vendor/bss/customers/{tenantId}/subscriptions?ruleDisplayName=Disabled
Vendor removes the customer from LiveObjects
DELETE /api/v1/vendor/customers/{tenantId}
| Tenant will actually be deleted 7 days after sending the command. During this period, customer cannot be used but its vendor can reactivate it. |