Jobs

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

Operation list and operation object and attributes

A job could be executed on a few entities or on thousand of entities if you use a tag. You can retrieve a paginated result list with the operation for each entity, simply sending a GET request using the URL above. The result list have an array of operation objects.

You can apply for the operation results list sending a GET request using the URL above. You must replace {jobId} with the identifier of the operation you want to retrieve.

You can also replace {jobId} with the identifier of the operation you want to retrieve and the pagination settings using {start} and {size} parameters.

Update job

Once the Job is created you can update the job to:

  • Modify Job request parameters. You only can mofiy the next parameters
    • active
    • notify
    • callback
    • userNotes
    • schedule.start
    • schedule.stop
  • To change (append or remove) entities target list.

A previously created Job can only be updated when this job active parameter is set to false and the job has not started.

When you finish the modification, in the latest PUT call, you have to change active parameter to true to enable the execution is started

As in the POST operation the platform establishes a limit in the JSON size. See creating a Job section for more information about it.

If Job is already started, i.e. IN_PROGRESS status, you have to change active parameter to false to pause the execution, in this state you can’t modify the features of the job

If Job is already paused you have to change active parameter to true to resume the execution

you can’t update the target section of a job based in a filter, for that you have to change active parameter to false and create a new job with the new filter

You can update an already created job sending a PUT request using the URL above. You must replace {jobid} with the identifier of the job you want to update.

Cancel job

Please, pay special attention to the fact that cancelling a job does not imply any roll-back in the already executed steps. So please, be extremely careful when you execute operations.

When you cancel a job, in a first moment the job state will be cancelling. This state will become cancelled when all of its operations are cancelled.

Search for jobs, devices, subscribers, subscriptions operations

Retrieves the list of devices providing a lot of options for:

  • Filter (See Specific Filter Fields)

  • Order (see Sorting)

  • Select Required Fields (see Selecting)

  • Summary (see Summary)

It is possible to obtain the results in two different formats, see HTTP Header Options:

JSON Format (Default) CSV Format