Use activities to check if the progress of operations like upload, transcodings or batchUpdates. Activities also include information on changes of documents in ElasticSearch.
General Structure
The activities response contains 3 properties: activities, modelChanges and modelChangesES. For performance reasons we recommend that you only fetch data you really need.
ModelChangesES
Every time a document (a mediacontainer) is updated in ElasticSearch, it will be logged and available in modelChangesES. There is one entry per mediaContainerId which contains all information regarding latest updates. Changes are available for 60 seconds. Every entry also contains an object “affectedModels” which gives you an information on which models have changed. Every of those entries contains and updated properties with the timestamp of the ElasticSearch update and well as a timeRange array which contains the timestamp of the first and last payload for this update.
The backend combines updates to ElasticSearch, therefore different changes (e.g. multiple metadata changes) could be send in one batch to ElasticSearch. The timeRange array contains information on the first and last timestamp used for this update.
How to use modelChangesES
Let’s assume you send 3 metadata updates to the API, every API call with 50ms difference (0,50,100). Let’s further assume those updates are send as one batch (please note that there is no guarantee how updates are combined!). Now the modelChangeES update will look like this:
{
model: 'es:mediacontainer',
id: 123,
affectedModels: {
mediaContainer: {
timeRange: [0,100]
updated: 200
}
},
updated: 200
The updated property in affectedModels contains the timestamp the data has been sent to ElasticSearch. The root level property is the latest timestamp of updates sent to ElasticSearch, i.e. if there are multiple affectedModels the most current updated timestamp from all models will be set as updated timestamp on root level.
Reference
Find activities
Find all activities available for this user (depending on his membership to security groups). This call is also used to set a heartbeat so the API knows that the user is still active.
Type | Name | Description | Notes |
---|---|---|---|
upload | Actvity from upload progress | ||
miscActivities | There are a number of misc activities | ||
TBC | |||
Create activity
Create an activity from the client. Make sure to send an activity update at least every 30 seconds. If the API server does not receive activity updates for more than 90 seconds, it will kill the activity. Otherwise activities might get stuck.
Update activity
Updates an activity. If the activity/job does not exist or is already completed, the update is ignored. The response, regardless of the state of the job, is always jobId and percent.
Destroy activity
Destroys an activity, for example when an upload is cancelled by the user.
Get jobResult for activity
Returns the result of a (batch) job. Can only be fetched after activity’s progress for this job is 100% (job is completed). If there is no job result, an empty object is returned.