-
Notifications
You must be signed in to change notification settings - Fork 6
Movida Resource: Scheduling
A 'Scheduling' is a shortcut for 'Scheduled Title'. In the VoD world, it corresponds to the period where a Title is scheduled in a particular Platform.
A VoD Schedule is composed of many Schedulings; it is composed of all the list of all the titles that have been scheduled in it (from a put up date to a take down date). In Movida, a scheduling looks like this:
!http://github.com/downloads/bebanjo/almodovar/scheduling.png!
In this case, "Episode 10, One to Go" of Series (or Title Group) "CSI: Crime Scene Investigation. 9" is scheduled in Platform BeBanjo Movies from Apr 1, 2010 to June 1, 2010
This is how this very same Scheduling would look through the API:
<scheduling>
<id type='integer'>23816</id>
<put-up type='datetime'>2010-04-01T00:00:00Z</put-up>
<take-down type='datetime'>2010-06-01T21:59:59Z</take-down>
<scheduling-type>archive</scheduling-type>
<rights-status>cleared</rights-status>
<publication-status>valid</publication-status>
<tags>Drama,Action</tags>
<link href="https://movida.example.com/api/schedulings/23816" rel="self"/>
<link href="https://movida.example.com/api/title_groups/190" rel="title_group"/>
<link href="https://movida.example.com/api/titles/613" rel="title"/>
<link href="https://movida.example.com/api/assets/1231" rel="asset"/>
<link href="https://movida.example.com/api/schedulings/23816/conflicts" rel="conflicts"/>
<link href="https://movida.example.com/api/platforms/1" rel="platform"/>
<link href="https://movida.example.com/api/schedulings/23816/publications" rel="publications"/>
<link href="https://movida.example.com/api/schedulings/23816/workflow" rel="workflow">
</scheduling>
Schedulings are accessed via the Schedule of a Platform, Title Group or Title. Refer to the Movida Resource: Schedule page to find out how to access the Schedule.
By default, when accessing a list of Schedulings, you will get the whole list. This list could be a massive one, so the following parameters can be used to filter them down:
-
scope: 'going_online','coming_offline' or 'online'
-
going_online: Will return all the schedulings that are going online within the supplied from and to dates
-
coming_offline: Will return all the schedulings that are coming offline within the supplied from and to dates
-
online: Will return all the schedulings that are online at any time between the supplied from and to dates, even if these were put up before that period or are being taken down after that period
-
from: a date or datetime. If a date is passed, bear in mind it will adjust to midnight that date. Examples would be: ** 2010-01-01 ** 2010-01-01T00:00:00 ** 2010-01-01T00:00:00Z
-
to: a date or datetime. If a date is passed, bear in mind it will adjust to midnight that date. Examples would be: ** 2010-02-01 ** 2010-02-01T23:59:59 ** 2010-02-01T23:59:59Z
IMPORTANT These parameters are optional, but the moment you use one of them, the 3 of them are required
So, to recover all items that are online on a specific platform in a defined period, you would do:
$ curl --digest -u robot_user 'https://movida.example.com/api/platforms/1/schedule/schedulings?scope=online&from=2010-01-01&to=2010-03-01'
If you wanted however, to see what titles are going online in a specific period, you would do:
$ curl --digest -u robot_user 'https://movida.example.com/api/platforms/1/schedule/schedulings?scope=going_online&from=2010-01-01&to=2010-03-01'
And finally, if you wanted to see which titles will be taken down on a specific period, you would do:
$ curl --digest -u robot_user 'https://movida.example.com/api/platforms/1/schedule/schedulings?scope=coming_offline&from=2010-01-01&to=2010-03-01'
Any of these would return the schedulings array for that platform, with the applied filters.
If you look carefully at the previous example, you'll notice each scheduling has a self link, whose url you can use to access it directly:
$ curl --digest -u robot_user "https://movida.example.com/api/schedulings/23816"
<scheduling>
<id type='integer'>23816</id>
<put-up type='datetime'>2010-04-01T00:00:00Z</put-up>
<take-down type='datetime'>2010-06-01T21:59:59Z</take-down>
<scheduling-type>archive</scheduling-type>
<rights-status>cleared</rights-status>
<publication-status>valid</publication-status>
<tags>Drama,Action</tags>
<link href="https://movida.example.com/api/schedulings/23816" rel="self"/>
<link href="https://movida.example.com/api/title_groups/190" rel="title_group"/>
<link href="https://movida.example.com/api/titles/613" rel="title"/>
<link href="https://movida.example.com/api/assets/1231" rel="asset"/>
<link href="https://movida.example.com/api/schedulings/23816/conflicts" rel="conflicts"/>
<link href="https://movida.example.com/api/platforms/1" rel="platform"/>
<link href="https://movida.example.com/api/schedulings/23816/publications" rel="publications"/>
<link href="https://movida.example.com/api/schedulings/23816/workflow" rel="workflow">
</scheduling>
In case your company is publishing titles to certain platforms using Bebanjo's Metadata SDK (not to confuse with Metadata product), your schedulings will carry information regarding:
-
The publication status, which values can be:
-
invalid; in case the scheduling is not ready to be published in the platform, due to validation errors in its metadata. Trying to publish a scheduling in this status will cause an error as described in Movida-Resource:-Publication
-
calculating; in the odd case that the publication status of the scheduling is being calculated. Publishing is an asynchronous process and this is a transient status.
-
valid; in case the scheduling is ready to be published.
-
sent; in the case the final platform is configured to notify back the ingest of the publication, this is the state that will have the scheduling while no notification from the platform has been received.
-
failed; this state shows a problem with the publication in the final platform.
-
published; in the case the scheduling has been successfully published and no changes are pending to be republished [*]. In the case the final platform is configured to notify back the ingest of the publication, this state means that the platform has notified that the publication has been successful.
-
-
A link to its publications. Please refer to Movida-Resource:-Publication for details
<scheduling>
<id type='integer'>23816</id>
<put-up type='datetime'>2010-04-01T00:00:00Z</put-up>
<take-down type='datetime'>2010-06-01T21:59:59Z</take-down>
...
<publication-status>valid</publication-status>
...
<link href="https://movida.example.com/api/schedulings/23816/publications" rel="publications"></link>
</scheduling>
[*] Please note that when the metadata of a published scheduling changes, the publication status will be one of ‘valid’ or ‘invalid’. This is to indicate that there are changes that hasn't been published. If you need to know if a given scheduling has ever been published, you should check the publications link.
In case your company is using BeBanjo's Sequence product, in each scheduling you'll find a link to the workflow of the scheduling:
<scheduling>
...
<link href="https://movida.example.com/api/schedulings/23816/workflow" rel="workflow">
</scheduling>
Please refer to Movida-Resource:-Workflow for more details about that link.
As our Introduction and Conventions page suggests, you can update an asset using a PUT request to each asset URI. You only need to include those attributes of the asset that you wish to update:
cat scheduling_update.xml
<scheduling>
<put-up>2014-06-17T06:00:00Z</put-up>
<take-down>2015-11-01T06:00:00Z</take-down>
<link href='https://movida.example.com/api/titles/613' rel='title'></link>
<link href='https://movida.example.com/api/platforms/1' rel='platform'></link>
</scheduling>
curl --digest -u robot_user:password -H "Content-Type: application/xml" -X PUT -d @scheduling_update.xml "https://movida.example.com/api/scheduling/23816"
As always Movida will return the full XML of the scheduling just updated:
<scheduling>
<id type='integer'>23816</id>
<put-up type='datetime'>2014-06-17T06:00:00Z</put-up>
<take-down type='datetime'>2015-11-01T06:00:00Z</take-down>
<scheduling-type>archive</scheduling-type>
<rights-status>cleared</rights-status>
<publication-status>valid</publication-status>
<tags>Drama,Action</tags>
<link href="https://movida.example.com/api/schedulings/23816" rel="self"/>
<link href="https://movida.example.com/api/title_groups/190" rel="title_group"/>
<link href="https://movida.example.com/api/titles/613" rel="title"/>
<link href="https://movida.example.com/api/assets/1231" rel="asset"/>
<link href="https://movida.example.com/api/schedulings/23816/conflicts" rel="conflicts"/>
<link href="https://movida.example.com/api/platforms/1" rel="platform"/>
<link href="https://movida.example.com/api/schedulings/23816/publications" rel="publications"/>
<link href="https://movida.example.com/api/schedulings/23816/workflow" rel="workflow">
</scheduling>
The following example shows how to destroy a particular scheduling. Only a DELETE HTTP request to its URL is required:
$ curl -u robot_user:password --digest -H "Content-Type: application/xml" -X DELETE "https://movida.example.com/api/schedulings/1"
The DELETE request doesn’t return anything, as that target platform is now gone.
When a scheduling is deleted, if it had a workflow associated, this will be also deleted.
Some accounts will show two assets links.
<scheduling>
<id type="integer">9005222</id>
<put-up type="datetime">2014-01-20T06:50:00+00:00</put-up>
<take-down type="datetime">2015-01-20T06:50:00+00:00</take-down>
...
<link rel="self" href="https://movida.example.com/api/schedulings/900577"/>
<link rel="asset" href="https://movida.example.com/api/assets/240571"/>
<link rel="assets" href="https://movida.example.com/api/schedulings/900577/assets"/>
...
</scheduling>
For historical reasons, the rel="assets" is a deprecated resource that should not be use anymore. If you are new integrator and you only see the rel="asset" you can ignore this. In case you see both links you must use rel="asset".