About the author: José Antonio Fuentes, Front-End Developer at VSN
Jose Antonio Fuentes works as a front-end developer at VSN. Currently, he is focused on the front development of VSNExplorer and VSN NewsConnect. Nevetheless, he has been involved in projects with VSNLivecom and other company solutions during his six years in the company. He has a Computer Applications Development degree and 13 years of working experience, not only in Broadcast and Media. Jose Antonio has worked in multiple projects and fields, from radars to position airplanes at an airport to military communication systems and Big Data.
We are more than familiar with data at VSN’s development team. For us, they are like a horse that needs to be tamed. The animal strength is powerful, but it might become a problem without control. It is the same situation for data; we can have enormous amounts of information, but it is more valuable if the user can apply program rules to operate with it.
At VSN, we always want to go one step further in the innovation of metadata technology. That’s why we developed a rules editor for metadata generated by our assets in VSNExplorer. Basically, this system works like a programming language that allows our clients to create and manage thousands of data operations quickly as if it were an Excel sheet. Therefore, users can apply different conditions to metadata that will make easier their media management, like showing or hiding fields, displaying the results of arithmetic operations or changing the selected values depending on other areas.
What would an ideal rules editor look like?
The editor’s interface must be accessible and easy to use. We don’t want more complications; we want to simplify our customers‘ operations when programming its own rules in the MAM system. We answered this challenge by developing a simple visual interface for our rule editor. The tool offers syntax highlighting and coloring while we are programming rules for each asset template for an improved visual understanding of the code. Also, each element of the rule language has its color for better visualization. For example, the operands appear green on our screens and the execution moments are red. Another element that makes creating rules easier is the autocompletion of terms. The system suggests how to end the code, avoiding mistakes and reducing time while we are writing.
Once the user finishes the code, it can compile it (as the code of any other language). Once it’s compilated, the editor points out the syntax errors and mistakes. Therefore, the user can consult and correct them in a simple manner. Apart from this, the rule editor is an ally to create an exchangeable script catalog between installations. The user can export the code to a file and move it to work in another editor. Also, we took some necessary measures in terms of security and flexibility. The system allows to temporarily or permanently disable the created rules according to the operational needs of the customer’s assets.
A programming language to control data
At VSN, we knew that the language’s syntax had to be very simple. The development team wanted to create a comprehensive language to allow any VSNExplorer user to create its script in minutes. Let’s take a look at the elements of our rule’s language.
1.The elementary values: These are the primary data to operate and introduce in our assets as in most programming languages. They are the foundations of our code. We are talking about whole numbers (ex. “-123, 4837”) real numbers (ex. “382.4344”, “-948.32”), boolean elements (ex, “true,” “false”) and texts, defined as chains in the technical language (ex. “VSN,” “John Smith”).
2. The operands: If we climb another level, we will find the operands. Unlike the elementary values of our forms, we can’t create new operands while we are writing, as the metadata field of the asset defines them. Operands are represented by an identifier enclosed in square brackets, like [userName].
3. Sentences: Let’s take another step to the third level with the sentences, where our two first elements of the puzzle fit. Basically, they are operations created with elementary values and operands. We will display two examples.
In the first one, we want to define a user name as Toni; In this case, the operand will be represented by square brackets by [userName]. We will introduce an elementary value with the text “Toni” to determine the name. We will create the sentence using the equal symbol (=), which assigns that value to the operand. The expression will be [userName]=“Toni”.
The second example is a little tricky. We can operate with operands and elementary values. Let’s imagine that we want to multiply by ten a product’s price. We will use a sentence to assign a value to the operand [tenProductsPrice], which will multiply by ten each operand define by the units [unitPrice]. The expresion will be “[tenProductsPrice]= [unitPrice] *10”. Of course, all this code language might sound a bit abstract and we can get lost once we open the editor. That’s why we’ve created the next language element.
4. Comments: Each programming language must allow comments to clarify each code line. The VSN’s rule editor allows commenting code fragments introducing “//” for a simple line comment or /* and */ for multiple lines. If we come back to our previous example, all these operations will look like this:
5. Control blocks: Now it’s time to roll up our sleeves. If you are familiar with programming languages, you’ll know the code is like a river; sometimes, we need to bifurcate it depending on some conditions. These are defined as adding control blocks. In our editor, those are created using if….else statements.
Let’s imagine that we want to define when we want the field “Identification Card” to show or that field to hide in our form. The expression with comments will be like this:
6. Execution momments: Let’s look to the sixth and final level of our programming cocktail. With the execution moments, we define when we want to execute each code portion in our data. Sometimes, we need to run them when our asset is open, while we are operating or even as soon as it is closed. We defined them in our language:
- OnOpen: executed once the asset form is open.
- OnEdit: executed when we start to edit the form.
- OnChange([operating]): executed when the code changes the value of an operand.
- OnClose: The code will be launched at this moment of execution as soon as the form is closed.
If we use our previous example again and want to execute the rule once the asset form is open, we will define the rule with the execution moment OnOpen:
Controlled metadata and further automation for our clients
Thanks to the new rules editor, our clients and users have the opportunity to automate many data operations that until now were impossible to do. For example, imagine we have the fields “last year total” and “current year total.” We would like to add those data in a single lot. We can create a rule to add them and save it under the name of “General total.”
Furthermore, let’s think about a client with a metadata field called “External ID” automatically filled by a workflow. Thanks to the customized rules, we can mark this field as read-only. This way, users can’t modify it by mistake. We can also automatically activate a “completed” field when a user introduces content in another one.
We at the VSN’s Development team know that this functionality might be a landmark in the use of VSNExplorer. That’s why we are still working to improve it and expand the use of this tool to other products.
Subscribe to our newsletter to stay updated about our activity: