Estamos más que familiarizados con los datos en el equipo de desarrollo de VSN. Para nosotros, son como un caballo que necesita ser domado. La fuerza del animal es poderosa, pero puede convertirse en un problema sin control. Es la misma situación con los datos; podemos tener enormes cantidades de información, pero es más valiosa si el usuario puede aplicar reglas de programa para operar con ella. 

En VSN, siempre queremos ir un paso más allá en la innovación de la tecnología de metadatos. Por eso desarrollamos un editor de reglas para metadatos generados por nuestros activos en VSNExplorer. Básicamente, este sistema funciona como un lenguaje de programación que permite a nuestros clientes crear y gestionar miles de operaciones de datos rápidamente como si fuera una hoja de Excel. Por lo tanto, los usuarios pueden aplicar diferentes condiciones a los metadatos que facilitarán su gestión de medios, como mostrar u ocultar campos, mostrar los resultados de operaciones aritméticas o cambiar los valores seleccionados dependiendo de otras áreas. 

¿Cómo sería un editor de reglas ideal?

La interfaz del editor debe ser accesible y fácil de usar. No queremos más complicaciones; queremos simplificar las operaciones de nuestros clientes al programar sus propias reglas en el sistema MAM. Respondimos a este desafío desarrollando una interfaz visual simple para nuestro editor de reglas. La herramienta ofrece resaltado y coloreo de sintaxis mientras programamos reglas para cada plantilla de activo para una mejor comprensión visual del código. Además, cada elemento del lenguaje de reglas tiene su color para una mejor visualización. Por ejemplo, los operandos aparecen en verde en nuestras pantallas y los momentos de ejecución son rojos. Otro elemento que facilita la creación de reglas es la autocompletación de términos. El sistema sugiere cómo finalizar el código, evitando errores y reduciendo el tiempo mientras escribimos.  

Una vez que el usuario termina el código, puede compilarlo (como el código de cualquier otro lenguaje). Una vez compilado, el editor señala los errores de sintaxis y errores. Por lo tanto, el usuario puede consultar y corregirlos de manera sencilla. Aparte de esto, el editor de reglas es un aliado para crear un catálogo de scripts intercambiables entre instalaciones. El usuario puede exportar el código a un archivo y moverlo para trabajar en otro editor. También tomamos algunas medidas necesarias en términos de seguridad y flexibilidad. El sistema permite deshabilitar temporal o permanentemente las reglas creadas de acuerdo con las necesidades operativas de los activos del cliente.  

Un lenguaje de programación para controlar datos

En VSN, sabíamos que la sintaxis del lenguaje tenía que ser muy simple. El equipo de desarrollo quería crear un lenguaje comprensivo que permitiera a cualquier usuario de VSNExplorer crear su script en minutos. Echemos un vistazo a los elementos de nuestro lenguaje de reglas. 

1. Los valores elementales: Estos son los datos primarios para operar e introducir en nuestros activos como en la mayoría de los lenguajes de programación. Son las bases de nuestro código. Hablamos de números enteros (ej. “-123, 4837”) números reales (ej. “382.4344”, “-948.32”), elementos booleanos (ej. “true”, “false”) y textos, definidos como cadenas en el lenguaje técnico (ej. “VSN”, “John Smith”).  

2. Los operandos: Si subimos otro nivel, encontramos los operandos. A diferencia de los valores elementales de nuestras formas, no podemos crear nuevos operandos mientras escribimos, ya que el campo de metadatos del activo los define. Los operandos están representados por un identificador encerrado entre corchetes, como [userName]. 

3. Sentencias: Demos otro paso al tercer nivel con las sentencias, donde encajan nuestros dos primeros elementos del rompecabezas. Básicamente, son operaciones creadas con valores elementales y operandos. Mostraremos dos ejemplos. 

En el primero, queremos definir un nombre de usuario como Toni; en este caso, el operando será representado por corchetes como [userName]. Introduciremos un valor elemental con el texto “Toni” para determinar el nombre. Crearemos la sentencia usando el símbolo igual (=), que asigna ese valor al operando. La expresión será [userName]=“Toni”. 

El segundo ejemplo es un poco complicado. Podemos operar con operandos y valores elementales. Imaginemos que queremos multiplicar por diez el precio de un producto. Usaremos una sentencia para asignar un valor al operando [tenProductsPrice], que multiplicará por diez cada operando definido por las unidades [unitPrice].  La expresión será “[tenProductsPrice]= [unitPrice] *10”. Por supuesto, todo este lenguaje de código puede sonar un poco abstracto y podemos perdernos una vez que abramos el editor. Por eso hemos creado el siguiente elemento del lenguaje. 

4. Comentarios: Cada lenguaje de programación debe permitir comentarios para aclarar cada línea de código. El editor de reglas de VSN permite comentar fragmentos de código introduciendo “//” para un comentario de línea simple o /* y */ para múltiples líneas. Si volvemos a nuestro ejemplo anterior, todas estas operaciones se verían así: 

5. Bloques de control: Ahora es hora de arremangarse. Si estás familiarizado con los lenguajes de programación, sabrás que el código es como un río; a veces, necesitamos bifurcarlo dependiendo de algunas condiciones. Estos se definen como agregar bloques de control. En nuestro editor, se crean usando declaraciones if….else. 

Imaginemos que queremos definir cuándo queremos que el campo “Número de identificación” se muestre o que ese campo se oculte en nuestro formulario. La expresión con comentarios será así: 

6. Momentos de ejecución: Veamos el sexto y último nivel de nuestro cóctel de programación. Con los momentos de ejecución, definimos cuándo queremos ejecutar cada porción de código en nuestros datos. A veces, necesitamos ejecutarlos cuando nuestro activo está abierto, mientras estamos operando o incluso tan pronto como se cierre. Los definimos en nuestro lenguaje: 

• OnOpen: ejecutado una vez que se abre el formulario del activo. 

• OnEdit: ejecutado cuando comenzamos a editar el formulario.

• OnChange([operating]): ejecutado cuando el código cambia el valor de un operando. 

• OnClose: El código se lanzará en este momento de ejecución tan pronto como se cierre el formulario. 

Si usamos nuestro ejemplo anterior nuevamente y queremos ejecutar la regla una vez que se abra el formulario del activo, definiremos la regla con el momento de ejecución OnOpen: 

Metadatos controlados y mayor automatización para nuestros clientes

Gracias al nuevo editor de reglas, nuestros clientes y usuarios tienen la oportunidad de automatizar muchas operaciones de datos que hasta ahora eran imposibles de realizar. Por ejemplo, imagina que tenemos los campos “total del año pasado” y “total del año actual.” Nos gustaría agregar esos datos en un solo lote. Podemos crear una regla para sumarlos y guardarla bajo el nombre de “Total general.” 

Además, pensemos en un cliente con un campo de metadatos llamado “ID externo” que se completa automáticamente mediante un flujo de trabajo. Gracias a las reglas personalizadas, podemos marcar este campo como de solo lectura. De esta manera, los usuarios no pueden modificarlo por error. También podemos activar automáticamente un campo “completado” cuando un usuario introduce contenido en otro.  

Nosotros, en el equipo de Desarrollo de VSN, sabemos que esta funcionalidad podría ser un hito en el uso de VSNExplorer. Por eso seguimos trabajando para mejorarlo y ampliar el uso de esta herramienta a otros productos. 

También te podría gustar:

Suscríbete a nuestro boletín para mantenerte informado sobre nuestra actividad: