Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Introducción

Todos los proyectos desarrollados para la STIC deben construirse y desarrollarse en base a los requisitos técnicos y tecnológicos que la infraestructura del SAS soporta. En caso contrario deberá especificarse de forma clara y concisa durante la reunión de lanzamiento del proyecto. A continuación se detalla el conjunto de requisitos a contemplar por parte de los proveedores.

Requisitos mínimos de metadatos

En esta sección se establecen los metadatos mínimos y recomendados que deben ir asociados a cada tipo de asset dentro de la plataforma Big Data para que estos se promocionen desde el entorno de preproducción al de producción. Se entiende por assets a todos aquellos elementos que pueden ser creados dentro de la plataforma Big Data. En el caso del SAS la solución es Stratio, por lo que la definición de estos metadatos se realiza en función de los elementos que se pueden crear en los diferentes módulos que la componen. Es por ello que esta sección se subdivide en los tres módulos principales de Stratio, estableciendo para ellos un conjunto de metadatos comunes a todos los tipos de assets del módulo así como los específicos de cada uno de ellos.

Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.

Governance

Metadatos comunes

A continuación, se presenta una tabla con los metadatos que son comunes a todos los assets que se encuentran en la herramienta de Governance. Algunos de ellos se encuentran establecidos en el activo de forma automática por la herramienta. En aquellos casos en los que el metadato no se grabe de automáticamente por la herramienta, se deben establecer mediante la creación de los atributos adicionales que sean necesarios.

Los assets que se generan automáticamente en la herramienta a partir de las bases de datos orígenes (Data Dictionary) son muy numerosos y, por tanto,  no es necesario generar los metadatos de descripción, estado, obsoleto. No obstante, para todos aquellos activos que se vayan generando con el uso de la herramienta sí deben presentar de forma obligatoria en el entorno de producción los metadatos marcados con dicha etiqueta.

Metadatos específicos

En este apartado, se especifican los metadatos que son únicos de cada tipo de activo presentes en la herramienta. Es decir, cada asset debe presentar tanto los metadatos comunes como los definidos en este apartado que se encuentren categorizados como obligatorios.

Colecciones

A continuación, se muestra una tabla con los metadatos exclusivo del asset de colecciones.

Metadatos de los procesos de ingesta.

Además, existe un conjunto de metadatos asociados a los procesos de ingestas.

Todos los metadatos de este tipo comienzan con los caracteres "dlc". 

Technical Views

En la siguiente tabla se presenta el listado de los metadatos únicos que deben presentar las vistas técnicas de una colección determinada.

Dentro de las Technical Views, a nivel de trabla existen unos atributos que son propios de la base de datos origen en la que se encuentran almacenados dichos datos y también otros metadatos que facilitan la parametrización y el trabajo con los procesos de ingesta. Para facilitar la lectura de dichos metadatos, se dividen en las dos tablas siguientes.

Metadatos relacionados con la base de datos

Todos los metadatos de este tipo comienzan con los caracteres "bdl".

Metadatos relacionados con los procesos de ingesta

Todos los metadatos de este tipo comienzan con los caracteres "dlc".

Metadatos de las columnas de las Technical Views

Para las columnas que conforman las tablas dentro de la vista técnica, existen una serie de metadatos que son exclusivos de ellos. En la siguiente tabla, se muestran dichos metadatos.

Business View

A continuación, se presenta una tabla con los metadatos específicos para las vistas de negocio que componen una colección determinada.

Reglas de calidad

En la siguiente tabla se muestran los metadatos específicos de las reglas de calidad tanto genéricas como específicas.

(*) El metadato carácter se creará o no a todas las reglas de calidad ya definidas en la herramienta en función al volumen de estas y el coste de recursos de dichas definiciones. Cualquier regla de calidad nueva que se cree deberá contener este metadato.

Ontologías

A continuación, se muestran los metadatos que son exclusivos de los elementos que componen una ontología.

Communities

A continuación, se muestran en una tabla los metadatos específicos de los assets de las comunidades que componen el glosario de negocio.

Es importante destacar que el metadato que establece el estado ya se encuentra especificado en el apartado de metadatos comunes. No obstante, en el caso de las comunidades este metadato no es intrínseco en la herramienta y, por tanto, es necesario generarlo a través del concepto de atributos adicionales.

Domains    

En la siguiente tabla se muestran los metadatos específicos de los assets de los dominios que componen un dominio concreto dentro del glosario de negocio que se encuentra en la plataforma de Stratio.

Es importante destacar que el metadato que establece el estado ya se encuentra especificado en el apartado de metadatos comunes. No obstante, al igual que en el caso de las comunidades, este metadato no es intrínseco en la herramienta para los dominios y, por tanto, es necesario generarlo a través del concepto de atributos adicionales.

Business terms/rules

En este apartado se agrupan en una tabla los metadatos específicos tanto de los términos como de las reglas de negocio que componen un dominio determinado.

Rocket

Esta sección recoge la normativa aplicable para la gestión del módulo de Rocket de la herramienta Stratio, y al igual que en Governance, se distinguen dos grandes bloques para los metadatos. Por un lado, aquellos metadatos comunes a cualquier tipo de asset y, por otro lado, los metadatos específicos para cada uno de ellos.

Cabe destacar que, en Rocket, no se cuenta con la posibilidad de añadir metadatado adicional, al contrario que en Governance. 

Metadatos Comunes

Existe un conjunto de metadatos que se repiten a lo largo de todos los assets de la herramienta. Estos se generan automáticamente al crear el asset en cuestión, no obstante, el metadato “descripción” se debe rellenar manualmente de forma obligatoria.

Además, dentro del metadato de descripción, se deberán añadir los datos mostrados en la siguiente tabla. Estos se indicarán con el nombre mostrado en la tabla seguido de “: “, separándose entre sí con el carácter “; “.

Es decir, una descripción genérica tendrá la siguiente apariencia:

<<"Descripcion: Primera etapa del proceso de carga de usuario"; "Creacion: 01/10/2023"; "Responsable: Juan Antonio González Pérez">>.

Nombramiento de assets

En esta sección se establecen las normas que deben seguirse para nombrar los assets que se creen dentro de la plataforma Big Data. Estas normas están enfocadas a los assets que componen la solución Stratio implantada en el SAS, encontrándose divididos en función del módulo al que pertenecen.

A su vez, se definen un conjunto de buenas prácticas para que sirvan como guía para cualquier usuario que quiera cualquier elemento de forma general. 

Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.

Buenas prácticas

A continuación, se expone un listado de las buenas prácticas generales que deben seguirse para el nombramiento de cualquier asset que se desee dar de alta en la plataforma Big Data.

• La longitud de los nombres no debe superar el tamaño máximo que permite la herramienta, pero siempre con un límite máximo de 30 caracteres.
• Los nombres han de ser claros y descriptivos, de forma que se entienda el contexto del activo con facilidad y, al mismo tiempo, sean lo más cortos posibles.
• Solo se deben emplear caracteres alfanuméricos y barra baja, evitando así el uso de otro tipo de carácter especial.
• Escribir todos los caracteres alfanuméricos del nombre en minúsculas, incluso cuando el activo se corresponde con una base, esquema o tabla de datos.
• Los caracteres alfanuméricos han de escribirse en español siempre que sea posible y sin usar la letra “ñ”, escribiendo en su lugar “ny”.
  Por ejemplo: año_nacimiento  → anyo_nacimiento

• Usar barra baja ( _ ) para separar identificadores dentro del nombre.
• Cuando la fecha del asset se deba incluir en el propio nombre, debe aparecer al principio y seguir el formato de fecha recomendada por Oracle sin separaciones: YYYYMMDD y YYYYMMDD-24HHMMSS en el caso de ser necesario las horas, minutos, y segundos.
  Por ejemplo: 20220518-140847

• En caso de necesitar un control de las versiones y revisiones del asset, este debe incluirse al final del nombre, separado por una barra baja. El formato tendrá la estructura XXrYY, donde XX e YY son dos números de dos dígitos que indican la versión y revisión del asset respectivamente. La letra r hace referencia a la release de la normativa. Se entiende por revisión cuando se realiza una pequeña modificación en el activo en cuestión sin que los procesos en los que está involucrado se vean muy afectados. Al contrario, un cambio de versión tiene lugar cuando la modificación del activo es más profunda, rompiéndose el modelo o definición de este y afectando en mayor medida a los procesos que lo rodean.
  Por ejemplo, nombre_asset_02r01

• El nombre de los assets obsoletos y/o que se encuentren en desuso pero que se requieren conservar debe comenzar con los caracteres "_OLD_". Estos assets solo se deben encontrar en entornos de pruebas o desarrollo, nunca en el productivo.
• El nombre del asset debe ser autocontenido y autodescriptivo, es decir, su comprensión no debe depender del contexto de la herramienta.
• En caso de necesitar añadir una secuencia numérica, se debe intentar estimar cuál va a ser la cantidad total de elementos que van a ser nombrados. Por ejemplo, si el máximo es 999, entonces, la secuencia numérica empezaría por 001, 002, 003…
• Se debe evitar, en todo momento, incluir información sensible en el nombre de los activos.
• Para aquellos assets que dispongan de carácter técnico o de negocio, se deberá de indicar en el nombre esta misma característica, tal y como se establece en el presente documento.
• Cuando el asset se está implementando en un entorno de desarrollo, debe contener el prefijo “dev”. Este prefijo se elimina de forma automática en la plataforma cuando se pasa a un entorno preproductivo y productivo.

Como añadido a todas estas buenas prácticas, es recomendable disponer de una tabla con todas las abreviaturas que se van a usar en los diferentes assets. En dicha tabla, se deben considerar, también, todos los ámbitos y subámbitos de información a los que pertenezcan los diferentes conjuntos de datos. De esta forma, se consigue que todos los usuarios miembros de la organización puedan acceder con facilidad a un determinado asset, comprendiendo sin dificultades el contexto de este. Dicha tabla se encuentra en la sección [Introducir enlace].

Estructura general de nombres

De forma general, se establece que el nombre de un asset contiene una serie de elementos comunes, los cuales se listan a continuación y en el orden en el que aparecen dentro del nombre.

• • Prefijo _OLD_ que indica que el asset se encuentra obsoleto.
  • Prefijo dev para indicar que el asset está definido en un entorno de desarrollo. Es obligatorio cuando se encuentra en el entorno de desarrollo, pero no debe ponerse para entornos preproductivos y productivos.
  • Fecha de creación del activo.
  • Abreviatura que indicará a qué elemento de la herramienta Stratio pertenece el activo concreto. Este valor aparece indicado en los apartados para cada asset en concreto.
  • Tipo de elemento específico que pueden presentar los diferentes assets de forma independiente. Esta parte del nombre es obligatoria en aquellos activos que presenten distinción de tipos.
  • Descripción que dota de contexto al nombre del activo.
  • Numeración correspondiente al activo en caso de ser necesaria.
  • Versionado del documento, compuesto por un conjunto de dígitos que indican el versionado y la revisión del asset respectivamente.

A continuación, se presenta el orden de los elementos comunes que pueden aparecer en el nombre de un asset.

Donde ZZ es una secuencia numérica ilustrativa de dos dígitos.

Es posible que para un asset en concreto sea necesario añadir una descripción extra a la estructura general aquí presentada. Cada una de estas particularidades se detallan en los apartados de los assets concretos en los que aparecen. Un ejemplo de esto es el carácter técnico o de negocio que presenta una regla de calidad.

Governance

Reglas de calidad

Toda regla de calidad empezará con los caracteres “rc” (regla calidad). El siguiente término indica el carácter técnico o de negocio de la propia regla de calidad, por lo tanto, debe presentar uno de los dos valores siguientes:

• t.  Se refiere a una regla de calidad técnica.
• n.  Se refiere a una regla de calidad de negocio.

Los siguientes elementos que lo componen constituirán la descripción del contexto de la regla de calidad. Esta descripción cambia en función de la información a la que se le aplica la regla de calidad. A continuación, se indica el tipo de regla de calidad, la cual puede tomar cinco valores diferentes, que se listan a continuación.

• com.  Se refiere a las reglas de calidad de completitud.
• act.  Aquellas reglas de calidad que miden la actualidad de los datos.
• con.  Se refiere a aquellas reglas relacionadas con la consistencia de los datos.
• pre.  Esta abreviatura se refiere a aquellas reglas de calidad que calculan la precisión de la información.
• uni.  Aquellas reglas de calidad encargadas de medir la unicidad en un determinado conjunto de datos.
• for. Indica que la regla de calidad comprueba el formato de los datos a los que se aplica.

Seguidamente, se indica si la regla de calidad es planificada o proactiva.

• pr. Indica que la regla de calidad es de tipo proactivo.
• pl. Se refiere a que la regla de calidad es de tipo planificado.

Además, se indica qué se hace con los datos que no cumplen la regla de calidad. Existen tres valores distintos.

• pt. Indica que la regla de calidad no realiza ninguna acción sobre los datos (pass through).
• mf. Establece que la regla de calidad mueve los datos erróneos a otra tabla (move to failed).
• au. Se refiere a que la regla de calidad audita los datos erróneos (audit QR).

Finalmente, se indicará una breve descripción que contextualice el tipo de dato al que se está aplicando dicha regla.

Entonces, un ejemplo de regla de calidad técnica presentará la siguiente estructura:

rc_[t/n]_[com/act/con/pre/uni/for]_[pr/pl]_[pt/mf/au][Descripción breve]

Por ejemplo: rc_n_uni_pr_mf_dni_paciente

Technical Views

Para nombrar las diferentes Technical Views, es necesario tener en cuenta las diferentes tablas que la van a constituir y, a partir de las mismas, constituir un nombre que permita conocer sin ambigüedades toda la información que comprende el asset.

Siempre que la cantidad total de tablas no sea muy elevada, se recomienda indicar en el nombre del asset las abreviaturas de las tablas que lo componen. Cuando, en caso contrario, el número de tablas es muy elevado, el nombre debe ser capaz de describir el ámbito de información que contiene la Technical View.

Para este asset en concreto, no es necesario indicar un prefijo que indique el tipo de activo que constituye. Esto es debido a las siguientes dos razones.

• El nombre que recibe la Techincal View se establece de forma automática, por lo que correspondería un cambio manual de todas las instancias que se creen de este activo.
• En una misma colección las Technical Views y las Bussiness Vews están virtualizadas bases de datos diferentes, por lo que no es necesaria su discriminación ya que se encuentran sintácticamente diferenciadas. En el caso de las Business Views, la sintaxis es “nombre_coleccion”.

Por lo tanto, el nombre debe seguir las buenas prácticas descritas en el tercer apartado del presente documento.

[Descripción Technical View]

Por ejemplo: diagnost_domici_usuario

Business Views

Los nombres de las Business Views dependen tanto del conjunto de datos técnicos como del significado funcional concreto que se le dé a los mismos. Por lo tanto, el nombre debe contener la información necesaria para conocer los dos elementos que componen el asset.

El nombre de estos activos debe contener una descripción que indique los datos técnicos y el significado funcional que componen el activo. Esta descripción ha de ser sencilla y significativa, de manera que cualquier usuario de negocio sea capaz de entender el contexto de los datos técnicos que componen la Business View pertinente.

Para este asset en concreto, no es necesario indicar un prefijo que indique el tipo de activo que constituye. Esto es debido a las siguientes dos razones.

• El nombre que recibe la Bussiness View se establece de forma automática, por lo que correspondería un cambio manual de todas las instancias que se creen de este activo.
• En una misma colección las Technical Views y las Business Vews están virtualizadas bases de datos diferentes, por lo que no es necesaria su discriminación ya que se encuentran sintácticamente diferenciadas. En el caso de las Business Views, la sintaxis es “semantic_nombre_coleccion”.

Por lo tanto, el nombre debe seguir las buenas prácticas descritas en el tercer apartado del presente documento.

[Descripción Business View]

Por ejemplo: multicontagio_covid

Colecciones 

Las colecciones son combinaciones de Business y Technical Views, por lo tanto, en su nombre se debe establecer la información necesaria para poder identificar qué activos lo componen.

Inicialmente, se indica a cuál de las tres capas que se muestran a continuación pertenece la colección.

• raw.  Se refiera a la capa raw.
• cur.  Abreviatura de la capa curación.
• con.  Abreviatura de la capa consumo.
• ori.  Se refiere a la capa origen.

Es importante destacar que, para las capas de origen y raw, la herramienta Stratio no permite modificar los nombres de las tablas y columnas que se leen de forma automática de las fuentes orígenes. En este sentido, como los orígenes de datos se encuentran en Oracle, los nombres de sus tablas y columnas aparecerán en mayúsculas y con los nombres originales de las mismas.

Después de indicar la capa a la que pertenece la colección, se establece una descripción que sea capaz de contextualizar las Technical y Business Views que componen la propia colección. A continuación, se puede observar cuál es la estructura de nombramiento de este asset.

[raw/cur/con/ori]_[Descripción Colección]

Por ejemplo: cur_historia_salud

Para los casos de uso de analítica avanzada, se crean diferentes tipos de tabla en la capa de curado. Cada una de ellas presenta una finalidad específica y un sufijo al final de su nombre para identificarlo. Por este motivo, las colecciones que se generen para los casos de uso de analítica avanzada presentarán los siguientes sufijos.

• par. Se refiere a aquellas tablas parciales, así como uniones de tablas, que sirven para desarrollar los casos de uso.
• ent. Se refiere a aquellas tablas que sirven de entrenamiento para los diferentes modelos de analítica.
• trf . Se refiere a tablas de transformación, aquellas que son finales del caso de uso pero que todavía no se encuentran preparadas para su explotación en la capa de consumo.

Constantes

Las constantes son unos elementos que, una vez definidos, se pueden usar en cualquier punto de la plataforma, por lo tanto, su nombre será específico del uso que se le quiera dar.

El nombre debe comenzar siempre por el prefijo “cons”, el cual indica que corresponde a una constante de la herramienta. La descripción del nombre debe ser suficientemente clara como para que cualquier usuario pueda entender el significado de esta. Al mismo tiempo, debe procurarse utilizar abreviaturas, siempre que sean entendibles, para reducir la longitud del nombre.

Cabe destacar que existen ciertas constantes que son intrínsecas de la herramienta y que, por tanto, no son modificables. Este tipo de activo conserva su nombre original, por lo que esta normativa no aplicaría en dichos casos.

A continuación, se muestra la estructura de nombramiento que debe presentar este activo.

cons_[Descripción Constante]

Por ejemplo: cons_edad_min_vacu_cov

Atributos adicionales

La herramienta Stratio permite añadir atributos personalizados a los elementos que componen su Data Catalog, estos son, las fuentes de datos, las colecciones y las Technical y Business Views.

Estos atributos dependen en gran medida de las necesidades del usuario que las defina y de los activos a los que complementa. Por lo tanto, los elementos que aparezcan en su nombre son muy variados.

Como regla general, se debe establecer un prefijo “atr” para indicar que ese atributo ha sido añadido de forma manual por un usuario concreto. Además, como en el resto de assets, el nombre ha de seguir las buenas prácticas establecidas en el tercer apartado del presente documento.

La estructura que presenta este activo es la que se muestra a continuación.

atr_[Atributo Adicional]

Por ejemplo: atr_cantidad_traumato

Cabe destacar que existen ciertos atributos adicionales que son intrínsecos de la herramienta y que, por tanto, no son modificables. Este tipo de activo conserva su nombre original, por lo que esta normativa no aplicaría en dichos casos. A continuación, se muestra un listado de las abreviaturas que puede presentar.

• bdl.  Se usan para los atributos relacionados con la virtualización de los datos.
• dlc.  Son atributos relativos a la ingesta automática de los datos.
• ontology.  Atributos relacionados al asset de las ontologías.
• related to. Relación nativa definida en la plataforma de Governance.

Activos de negocio

Existen ciertos activos que no están relacionados con otros elementos de la plataforma ni tampoco se puede acceder que no sea el propio menú de la herramienta. Por este motivo, no es necesario aplicar las normas expuestas en el presente documento. No obstante, se recomienda que todos los nombres que se establezcan no sean excesivamente largos y siempre se deben acortar lo máximo posible al mismo tiempo que se conserva su significado.

A continuación, se muestra un listado de estos activos que son exclusivamente de negocio.

• Communities. Estos activos son las primeras entidades de mayor jerarquía que se definen en el apartado de la herramienta Stratio exclusivo para glosarios de negocio.
• Domains. Para cada comunidad creada, se pueden crear elementos que agrupen diferentes dominios de información, llamados Domains.
• Business Rules. Son objetos correspondientes a reglas de negocio que se definen para un dominio concreto.
• Business Terms. Estos activos son términos de negocio que se definen para un dominio específico.
• Process. Este tipo de activo sirve para definir diferentes procesos dentro de cada uno de los dominios previamente creados en la herramienta de forma particular.

Dentro de este orden jerárquico, es necesario que cada uno de los elementos definidos sean coherentes con la estructura establecida. Por lo tanto, se debe prestar especial atención a la estructura del glosario para que la información sea fácilmente localizable.

Ontologías

Las ontologías deben ser nombradas de tal manera que cualquier usuario con perfil de negocio sea capaz de comprender con facilidad y sin ambigüedad las clases y relaciones establecidas en la ontología.

Al igual que ocurre para el conjunto de activos de negocio anterior, no es necesario establecer en el nombre de las ontologías ningún prefijo concreto. Sin embargo, el nombre debe describir de forma breve y concisa, de forma que sea fácilmente legible para cualquier usuario de negocio. Al final del nombre debe indicarse la versión de la ontología, aunque, contrario a lo que se indica en el apartado de buenas prácticas, no se debe indicar la revisión de la versión. Esto ocurre porque la ontología evoluciona como una única entidad a la que no se le puede cambiar el nombre. Solamente se debe crear otra ontología con una nueva versión cuando se cambie profundamente la estructura de esta.

A continuación, se establece la estructura que debe tener una ontología.

 [Descripcion Ontología]_XX

Por ejemplo: sas_03

Rocket  

El módulo de Rocket se divide en diferentes elementos que presentan una posición o estructura determinada en la herramienta. Estos son:

• Proyectos. Es el elemento principal en el cual se definen el resto de assets. Constituye el mayor nivel de detalle de gestión de acceso dentro del módulo.
• Directorios. Al igual que en cualquier sistema operativo, dentro de un proyecto se pueden generar diferentes estructuras de directorios diferentes en los cuales se crean los workflows dentro de Rocket.
• Assets. Estos elementos son los que se usan para construir procesos de manipulación del dato. 

Proyectos

Actualmente, los proyectos se encuentran definidos de forma previa. Estos proyectos han sido definidos en función de la capa de datos a la que pueden acceder y de los diferentes contratos que acceden a la plataforma Big Data. A continuación, se muestra una tabla con los diferentes proyectos definidos.

Directorios

Los directorios dentro de cada proyecto deben seguir las buenas prácticas establecidas en esta normativa. En concreto, se debe poner especial foco en los siguientes aspectos:

• Todas las palabras deben ir en minúsculas. Esto se establece para facilitar el uso del buscador de la herramienta Big Data Stratio, el cual diferencia entre mayúsculas y minúsculas.
• No se deben poner signos de puntación en los nombres de los directorios.
• Aunque la separación entre palabras se definen en las buenas prácticas con el uso de  "_", Stratio Rocket no soporta este carácter en los nombres de los directorios. Por este motivo, se restringe al uso del guion, "-".

La estructuración de cada proyecto se debe dividir en función de los equipos y trabajos típicos que desarrollen en ese espacio, estando siempre enfocado en la optimización de la accesibilidad y entendimiento por parte de nuevos usuarios que carezcan del conocimiento experto.

Assets

Los trabajos de manipulación de datos se definen a través de los assets, que pueden ser de diferentes tipos.   

• AutoMLPipeline
• Batch
• Hybrid
• MLProyect
• Notebook
• Streaming

Por norma general, el nombre debe componerse de unas palabras descriptivas seguidos de su orden de ejecución y la versión del workflow. Estos dos últimos elementos se incorporan por los siguientes motivos.

• Dentro de una misma ruta de directorios de un proyecto de Rocket se pueden definir varios workflows que dependan unos de otros. Por lo tanto, para facilitar el entendimiento general de un proceso, se debe poner en cada workflow el orden de ejecución, mediante "OEXX".
• Es importante notar que, al contrario que en el resto de assets en los que el versionado es opcional, en el caso de los workflows es obligatorio ya que el trabajo de versionados es típico de los diferentes desarrollos llevados a cabo por los equipos del SAS. El valor de este versionado debe ser el último funcional del asset en cuestión y no de una versión desfasada.
• Por último, como excepción a la norma general, no es necesario indicar el tipo de asset ya que viene indicado en la interfaz de la plataforma y en sus metadatos.

A continuación, se establece la estructura que debe tener un asset de Rocket.

 [Nombre workflow]_OEXX_YYrZZ