Flow of Requests

This section describes the workflow where devices are communicating directly with the Notification Server.

Important:REST API access must be restricted to authorized devices. For more information, see Authorizing Update Requests.

Once an update has been added to FlexNet Operations it is available for download to a device. The workflow for handling an update is as follows:

Flow of Update Requests in FlexNet Operations, Steps 1 - 6

The steps for obtaining update information are:

1.

A device sends an initial request for updates to the Notification Server (see /uai/2.0/updates or /uai/2.0/signed-updates).

2.

The device receives back a polling ID.

3.

The device uses the polling ID periodically to request the updates until they are available (using /uai/2.0/updates/{pollingId} or /uai/2.0/signed-updates/{pollingId}).

4.

The Notification Server, when it receives the first request for updates, logs the request with the FlexNet Operations back-office.

5.

The Notification Server retrieves the information about updates that are possible from the package currently installed on the device.

6.

The Notification Server then returns the update information in response to the latest poll from the device. This may include several updates possible from the package currently installed on the device. (Anonymous devices will only receive updates when the Entitlement check is set to None. Served devices will only receive updates when the Entitlement check is set to Account or None.)

At this point, the device must decide which update, if any, to proceed with. If one is chosen, the following happens:

Flow of Update Requests in FlexNet Operations, Steps 7 - 12

7.

The device requests the manifest using the ID in the update (using /uai/2.0/updates/manifests or /uai/2.0/signed-updates/manifests). (A manifest is a list of files needed to perform the update.)

8.

The device receives back a polling ID.

9.

The device uses the polling ID periodically to request the manifest until it is available (using /uai/2.0/updates/manifests/{pollingId} or /uai/2.0/signed-updates/manifests/{pollingId}).

10.

The Notification Server requests the manifest from the FlexNet Operations back-office.

11.

The Notification Server retrieves the manifest from the FlexNet Operations back-office database.

12.

The Notification Server then returns the manifest in response to the latest poll from the device.

Finally, the device requests each file listed in the manifest using the supplied URLs, also contained in the manifest. The device should use a checksum provided by the original update response to verify the authenticity of each file retrieved. The files can then be used to perform the update.