Most things in Ooyala Flex are Objects. As such, configuring Ooyala Flex involves creating, editing, and configuring various Object Types in the Settings and Access sections. The configuration screens in Ooyala Flex are split up into a sub-sections for each Object Type. These sub-sections are found either under the Settings section or the Access Section.
It's also worth reminding readers that Ooyala Flex supports fine-grained Access Control. Therefore the configuration sub-sections available to you depends on your Role and your Role's associated Permissions.
The Actions and properties available when creating and configuring Ooyala Flex Objects vary based on the Object Type. For example, some Object Types can be started and stopped, such as the Resource Object Type. Others cannot. On each Object page in the Ooyala Flex User Guide we provide a summary table to show what Actions and properties are supported by each Object Type.
Copying an Object
Some Objects support copying. When you copy an Object, a new Object is created that duplicates all of the properties of the original Object. The Super User is then required to enter a new name for the Object. Copying is an extremely useful and time-saving when you wish to create a new Object that is based on the properties of an existing Object.
1) To copy an Object, navigate to the Object Details section of the Object you wish to copy, for example an Action.
2) In the Object Setting view, click the Copy icon.
3) In the Copy section, enter a name for your copy, and any other details that are applicable to the specific Object type.
4) Click the Save button to finalise.
5) The copied Object will initially be disabled when created. So in order to start utilising it, you must enable it first.
Exporting and Importing Objects
Many Object Types in the Access and Settings sections can be exported and imported in XML format. This functionality is extremely useful when Super Users wish to copy configurations from one Ooyala Flex environment to another.
To export an Object, simply click the Export icon in the Object Setting view.
Then If you are a Super User, your web browser will then commence the download of the Object data to your local computer.
An example of the contents of an exported Object file is shown below:
Importing an Object
1) To import an Object, simply click the Import Icon in the Fixed List View.
2) In the Import section, click the Choose File button.
3) When you have chosen your the file, click Upload.
If you are going to import an Object from another Account there are three parameters that may need to be changed. These are:
Some Object Types support extended configuration through an additional Configuration Tab. This tab allows Super Users to enter further configuration information through a custom form. Within some configuration screens, there are some fields (or entire sections) that are optional. These are made available by clicking on the + symbol. If you wish to remove these configuration items later, simply click the - symbol and the options and any associated values will be deleted.
Where values can be added to extended configuration fields, Super Users have the option of adding fixed values or a Script. A Script is a fragment of code that is evaluated at run-time to generate an output value. Scripting is an extremely valuable tool as it offers the ability to add more intelligence to the behaviour of Ooyala Flex and further customise the platform in a more dynamic way.
The screen shot below shows a Configuration Tab with scripting inserted into a field.
Some Object types support Plugins. A Plugin is a functionality of code developed against Ooyala Flex's API that implements specific functionality. Plugins allow developers to extend the functionality of Ooyala Flex. Examples of Object Types that support Plugins are:
If an Object Type supports Plugins then when a new Object of this type is created, the Super User will be asked to select a specific Plugin type. If the plugin is configurable, then the Super User will be presented with an Extended Configuration tab to enable the Plugin properties to be configured.
The below screen shot shows a Plugin being selected when creating a new Action:
1) Create a new Action and select a Plugin from the Plugin drop down.
2) Once created, the Super User can further configure the properties for this Plugin, using the Extended Configuration tab.
Note: We recommend that you refer to the API Guide and Plugin Guide for further information on this subject.
Objects and Metadata
Some Object Types support Metadata Schema. A Schema is used to associate data fields with an Object Type. This means that when a new Object is created, Ooyala Flex will automatically create a new Schema Instance for that Object.
Some Object Types allow you to define "Variants". A Variant is a more specific type of an existing Object Type which is defined by a User. For example Ooyala Flex supports the Asset Object Type. This means that in Ooyala Flex you can create, update and search for Assets. But what about if you want to create a new Object Type that is like an Asset but more specific? What if you wish to assign different data fields to your more specific Type? Let's say you want to create a type called "Video" that is simply a type of Asset with more specific data Fields. To do this you create a Variant. When you create a Variant, you do the following:
1) Select the Ooyala Flex Object Type you want to base your Variant on (i.e. Asset)
2) Create a name for your Variant (i.e. Video)
3) Supply an optional Metadata Schema to help describe properties of your Video
Now, every time you create a new Asset, you have the option of creating an Asset of type Video which will comprise its own Metadata Schema specific to the Video concept.
You can only create Variants or Object Types that support Variants.
Once you have created your new Video Variant you can create new Variants and you can also search by Objects of type Video.
The following Object types support Variants:
Note: Variants can only be created from existing Ooyala Flex Object Types, not Object Types that are created by Users.
It is possible to create multiple Variants for a single Object Type. As a result of this one can also specify the default Variant for an Object Type. This will mean that when an Object is created, if no Variant is explicitly selected, the default Variant will be chosen for the User.
Variants and Schema
A Variant can support more than one Schema. This means that when you create a new Instance of an Object that supports Variants, you not only select a Variant, you also select the Schema you wish to apply. A Variant always has one default Schema. If you create a new Variant without specifically selecting a Scheme, then the default will be assigned.
Variants and Metadata
If the Object Type you are configuring supports Variants, and a Variant has been set up for this Object Type in your Account, the following options apply.
• When you create a new Object of this Type you will be asked to select the particular Variant and Metadata Schema as shown below:
• When you edit the Object properties, you will be presented with a Metadata Sub-tab as shown below:
• When you edit the Object properties, you will be able to change the current Variant and Schema:
Some Objects support the concept of approval. When an Object is approved by a User it is set to approved and an approved Event is triggered. When approving an Object an optional comment can be added. This comment is stored in the comments stored with each Object. Conversely, Objects that support approval can also be Un-approved. When un-approving an Object an optional comment can be added.
Note: Approval functionality is only available if the relevant Permissions have been enabled in the User's Role.
Some Object Types support locking. This means that only one update can be made to an Object at a time. This can be extremely important under some circumstances. For example if a Job is moving an Asset Object from one location to another it would not be prudent to allow another Job to run the same move on the same Asset Object. This could result in unpredictable outcomes and lead to system instability.
There lock types supported in Ooyala Flex are:
Exclusive: Exclusive locks. When a statement modifies data, its transAction holds an exclusive lock on data that prevents other transActions from accessing the data. This lock remains in place until the transAction holding the lock issues a commit or rollback.
Shared: Shared locks exist when two transActions are granted read access. One transAction gets the shared lock on data and when the second transAction requests the same data it is also given a shared lock. Both transActions are in a read-only mode, updating the data is not allowed until the shared lock is released.
Note: Locking is managed in Ooyala Flex through the Locking Service.
Some Object types support locking. This means that how they are accessed and updated can be controlled by Ooyala Flex. If the Object being reviewed supports locking, the locking field will be present. If the Object is locked, you will be able to inspect information about what other Object is locking this Object.
If an Object is locked, the lock symbol will be shown.
Note: Certain Objects support locking, whilst others don't. Above we have used an Asset as an example.
While an Object is locked you can roll over the symbol to see what Objects are locking that one. The Lock Owner field shows the Object ID of the locking Object. Clicking on this field will take you to the Details view for the lock owner.