Running operations
Job execution
To execute a job you only have to send a POST request with a job object in the body pointing to the desired entities. There are three ways to reference the job target entities:
Adding an array of target entities
- entities: the same parametrization is applied to all entities
The target array of entities IDs is the easy way to select multiple devices and apply an operation on them. There is a limit in the number of entities in the array, by default the value is 100 . Please consult with your administrator to know the limit configured.
Due to operational issues, the service incorporates a limit in the size of the JSON file. This limit can be configured administratively and by default the limit is set at 300
KBytes. Please consult with your administrator to know the limit configured.
If you need to launch a operation over a large list of entities you can create a Job (POST
) setting the active
parameter to false and using updating operation (PUT
) to append new entities to the target considering the mentioned limit.
Using a previously created tag
You can’t mix target references or filter references with tag references.
If you create a job using tags, there is a previous state, INITIATING
, this time is used to create the internal structure of the job, when the platform has finished this internal work, the state of the job will be idle if the tob is not active or scheduled if the job is active
Using filters
You can’t mix filter references with target references or tag references.
You can’t use a previously created filter.
resourceType
is an optional query string parameter for this option. This parameter restrict the filter to an specific type of entity, If you include this parameter in the uri of the request only the entities belonging to the selected type will be considered. The available values for this parameter are:
entity.device
, if you want to take into account only devices.entity.asset
, if you want to take into account only assets.entity.commsModule
, if you want to take into account only communication modules.entity.subscription
, if you want to take into account only subscriptions.entity.subscriber
, if you want to take into account only subscribers.
API specification scheduling
There are two special scheduling modes for a job, both of them are optional.
scattering
window
The scattering section is oriented for a job scheduling with protection of a mobile operator cell, if you introduce this section in a job scheduling you have to indicate a operations spread for the job and a strategy factor. This is oriented for using the most time of de planned time of the job trying that the operations don’t fall down a mobile cell.
The window section is oriented for a job scheduling where you want specify a concrete group of days of the week when you want that the job can execute operations and the specific time of the day where you want that de job can execute operations.
The time periods of the window must be multiples of one hour, no interim periods allowed. window examples:
Option | Allowed |
---|---|
“start”: “09:00:00Z” “stop”: “15:00:00Z” | Allowed |
“start”: “09:30:00Z” “stop”: “15:30:00Z” | Allowed |
“start”: “09:00:00Z” “stop”: “15:30:00Z” | Not allowed |