Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Introducción

Se ha integrado en el componente Contenedor de ThinKPs la posibilidad de desplegar aplicaciones basadas en Spring Boot. Para simplificar la integración de estas aplicaciones con Sofia2 se ha avanzado con la funcionalidad del módulo Sofia4Boot descrito aqui.

Las aplicaciones desplegadas dentro del contenedor de Sofia2 pueden ofrecer cualquier tipo de funcionalidad, incluso si no requiere de Sofia2 más que el contenedor y el sistema de gestión (en entornos desplegados tras un Nginx puede requerir cierta configuración, como abrir puertos).

Autorización

Las aplicaciones Spring Boot que usen en contenedor de ThinKPs necesitan proporcionar ciertos credenciales a la plataforma Sofia2. Para esto es necesario disponer de un ThinKP asociado a una ontología, y proporcionar como propiedad el token de acceso (ver sección de propiedades más adelante).

Creando una aplicación nueva

Para crear una aplicación basada en Spring Boot para Sofia2 se debe empezar con incluir en el POM las dependencias necesarias. Sofia2 dispone de un repositorio Nexus con las dependencias requeridas.

Atención! Sofia4Boot requiere de una versión de Java igual o superior a 1.8

Repositorio Nexus de Sofia2

<repositories>
     <repository>
    <id>SOFIA2</id>
    <url>http://sofia2.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

Dependencias de Sofia4Boot

<dependency>
    <groupId>com.indra.sofia2.boot</groupId>
    <artifactId>sofia4boot</artifactId>
    <version>1.3</version>
</dependency>

Además hay que incluir las dependencias propias de Spring Boot (en esto no hay diferencias respecto a una aplicación SpringBoot típica). Es particularmente importante asegurarse que la aplicación que generamos es autocontenida (y ejecutable). Para esto lo más normal es usar el plugin de Spring Boot:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Durante el diseño de la aplicación hay que tener en cuenta que a la hora de arrancarla, el contenedor añadirá elementos adicionales a la configuración, como por ejemplo, limitación de memoria y propiedades de configuración. Un ejemplo de comando de arranque puede ser: -Xmx256m -Dspring.boot.admin.url=http://127.0.0.1:8101 -Dspring.boot.admin.prefer-ip=true. Esto incluye por ejemplo la configuración interna necesaria para registrar la aplicación en la instancia spring boot admin de Sofia2.

Clase principal

Para la clase principal usaremos una plantilla habitual para Spring Boot, a la que añadiremos el soporte para que se integre con el sistema de administración (esto se consigue añadiendo la anotación @EnableSpringBootAdminRegister).

@SpringBootApplication
@EnableSpringBootAdminRegister
public class S4BApp 
{
    public static void main (String [] args) {
        new SpringApplicationBuilder(S4BApp.class).run(args);
    }
}

La anotación @EnableSpringBootAdminRegister se encargará de registrar la aplicación en la consola, con lo que se podrá gestionar en una ventana de la consola de Sofia2:

Modelado de una ontología

La forma más fácil de modelar una ontología es descargarse las clases generadas desde el Control Panel de Sofia2. Para esto hay que ir a la opción de menú ‘Mis Ontologías’, buscar la ontología que se quiera, pulsar sobre el botón ‘Ver Ontología’ (con un icono representando un ojo), y al final de la ventana deberemos ver un botón con el texto ‘Clase Java de la Ontología’. Esto nos descargará un fichero comprimido con las clases de la ontología.

Esto también puede hacerse a mano. Un ejemplo de modelado de una ontología sencilla sería la siguiente:

Modelo de la ontología de ejemplo

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "level Schema",
    "type": "object",
    "required": [
        "Level"
    ],
    "properties": {
        "Level": {
            "type": "string",
            "$ref": "#/datos"
        }
    },
    "datos": {
        "description": "descripcion",
        "type": "object",
        "required": [
            "date"
        ],
        "properties": {
            "value": {
                "type": "integer"
            },
            "date": {
                "type": "string"
            }
        }
    }
}

Y un ejemplo de instancia:

{
    "Level": {
        "value": 1,
        "date": "string"
    }
}

Las clases Java de modelado serían:

Modelo de datos

public class Level {

    private String date;
    private Integer value;

    public Level() {

    }

    public Level(String date, Integer value) {
        this.date = date;
        this.value = value;
    }

    public String getDate() {
        return date;
    }

    public void setDate(String date) {
        this.date = date;
    }

    public Integer getValue() {
        return value;
    }

    public void setValue(Integer value) {
        this.value = value;
    }
}

Y como la ontología tiene un nivel adicional para controlar siempre los valores, tendremos que incluir un wrapper

Envoltorio de ontología

public class LevelOntology extends Ontology<Level> {

    @JsonProperty("Level")
    private Level level;

    public LevelOntology () {}

    public LevelOntology (String date, Integer value) {
        level = new Level(date, value);
    }

    @Override
    public void setData(Level level) {
        this.level = level;
    }

    @Override
    public Level getData() {
        return level;
    }
}

Acceso al repositorio de la ontología

Para operar con la ontología disponemos de un conjunto de anotaciones que nos autogeneran el código de operación necesario. Un ejemplo de repositorio para la sencilla ontología del ejemplo anterior:

@Sofia2Repository("level")
public interface LevelRepository {

    @Sofia2Query("select * from level")
    List<LevelOntology> findAll ();

    @Sofia2Query("select * from level where Level.value=0")
    List<LevelOntology> findAllZeros ();

    @Sofia2Query("select * from level where Level.value=$value")
    List<LevelOntology> findAllWhereValueMatches (@Param("$value") Integer value);

    @Sofia2Insert
    SofiaId save(LevelOntology levelOntology);

    @Sofia2Query("db.level.remove({\"Level.value\":$value})")
    SofiaIds deleteWhereValueMatches(@Param(value = "$value") Integer value);

    @Sofia2Delete
    List<SofiaId> delete(String id);
}

Este repositorio no tiene código, es sólo un interfaz, siendo la librería de Sofia4Boot la encargada de generar y registrar en el contexto de spring la clase de implementación necesaria, con lo cual ya podremos disponer de ella de la forma habitual en spring:

@Autowired private LevelRepository levelRepository;

Añadiendo funcionalidad

Para este ejemplo, simplemente voy a hacer que cada n minutos se genere un nuevo valor aleatorio para la ontología. Para esto implementamos un servicio proveedor de valores que se encargue de hacer inserciones en la ontología:

@Service
public class Provider {

    private static final Logger log = LoggerFactory.getLogger(Provider.class);
    private Random random = new Random();

    @Autowired
    private LevelRepository levelRepository;

    public void sendRandomMessage () {

        try {
            // --- create new level value
            Instant now = Instant.now();
            Integer value = random.nextInt(10);
            LevelOntology levelOntology = new LevelOntology(now.toString(), value);
            log.info("Inserting data ontology: {}, ", levelOntology);
            // --- insert a random value
            SofiaId id = levelRepository.save(new LevelOntology(now.toString(), value));
            log.info("Created new record with value '{}' and id '{}'", value, id.getId().getOid());
        } catch (Exception e) {
            log.warn("Captured exception running app", e);
        }
    }
}

Y para que se ejecute cada intervalo genero un job con un planificador (un scheduler) que arranque cuando la aplicación haya terminado de cargarlo todo:

@Configuration
public class JobConfig implements ApplicationListener<ContextRefreshedEvent> {

    private final Logger log = LoggerFactory.getLogger(JobConfig.class);
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

    @Autowired
    private Config config;
    @Autowired
    private Provider provider;

    @Override
    public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {

        log.info("Scheduling tasks ({} minutes)", config.getIntervalInMinutes());
        Runnable task = new Runnable() {
            @Override
            public void run() {
                provider.sendRandomMessage();
            }
        };

        Integer interval = config.getIntervalInMinutes();
        scheduler.scheduleAtFixedRate(task, interval, interval, TimeUnit.MINUTES);
    }
}

Para cargar la configuración estamos usando una clase Java mapeada por Spring con un fichero de configuración:

@Configuration
@ConfigurationProperties(prefix = "s4b")
public class Config {

    // el valor por defecto es 1, y la property se mapea contra 's4b.intervalInMinutes'
    private Integer intervalInMinutes = 1;

    public Integer getIntervalInMinutes() {
        return intervalInMinutes;
    }

    public void setIntervalInMinutes(Integer intervalInMinutes) {
        this.intervalInMinutes = intervalInMinutes;
    }
}

Configuración de la aplicación

A parte de la configuración habitual de Spring, existen propiedades adicionales referentes a Sofia4Boot, y además están las propias de nuestra aplicación.

La configuración específica de Sofia4Boot que nos aplica está referida a continuación:

Propiedad Valor de ejemplo Descripción
sofia2.host sofia2.com El host del servicio MQTT
sofia2.port 1884 El puerto para MQTT
sofia2.kp levelkp El kp al que se asocia la aplicación
sofia2.instance levelkp-demo El nombre de esta instancia de thinkp
sofia2.token 5118bt0acc2e464782dfwb52af582h9z El token de autorización del thinkp
sofia2.mqtt false Decide si se utiliza rest (false) o mqtt (true)
sofia2.endpoint http://sofia2.com/sib/services/ssap La URL del endpoint SSAP de Sofia2

Las propiedades propias de este ejemplo, junto con las de Spring Boot:

Propiedad Valor de ejemplo Descripción
logging.file ${spring.application.name}.log El nombre del archivo de logs a generar
server.port 0 Si fuera necesario, el puerto en el que se quiere arrancar el servicio. Esto requiere actualizar la configuración de Nginx
management.security.enabled false Esta property se asegura que se utiliza el sistema de autenticación de sofía, y no el que tiene spring boot admin por defecto
s4b.intervalInMinutes 5 inserta un valor nuevo a la ontología cada 5 minutos

Desplegando en el Contenedor de ThinKPs

Para desplegar nuestra aplicación dentro del contenedor de ThinKPs de Sofia2 deberemos haber completado los siguientes pasos:

  1. Generar una ontología en la plataforma, o seleccionar una que ya esté disponible (puede estar vacía si no se necesitan datos).
  2. Crear un KP, y generar un token, que se usarán para autorizar a nuestra aplicación (como cualquier otro dispositivo).
  3. Implementar nuestra aplicación y disponer del archivo ‘jar’ para desplegarlo.

Hecho esto, accedemos a la consola de Sofia2, menú ‘Contenedor ThinKPs’, y una vez allí haremos click en el botón con el texto ‘Nuevo ThinKP en contenedor’. Rellenamos la ventana que nos muestra la consola asegurandonos de:

  • Marcar el tipo de aplicacion como ‘Aplicación Spring Boot’
  • Seleccionar un token de autenticación (que coincida con el que incluimos en la configuración de nuestra aplicación!).
  • Cargamos nuestro archivo jar
  • Seleccionamos un nombre para nuestro contenedor, asegurandonos de incluir la extensión ‘.jar’

Un ejemplo:

Cuando termine (según nuestra conexión y el tamaño del JAR puede tardar un poco), deberíamos ver una ventana con la descripción parecida a la siguiente:

Aquí tenemos el botón que nos permite arrancar nuestra aplicación (por defecto están paradas nada más crearlas).

Spring Boot Admin

Una vez nuestra aplicación está arrancada y si está configurada correctamente, pasado un rato deberíamos poder verla registrada en el servicio de administración de Spring Boot Admin, en el menú ‘ThinKPs -> Administración de Spring Boot’, como puede verse a continuación:

Pulsando sobre el botón ‘Details’ podemos ver más detalles acerca de nuestra aplicación, como por ejemplo:

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Notebooks Procesando y representando datos en un mapa Leaflet con los Notebooks Sofia2

Los Notebooks Sofia2 (basados en el proyecto open-source Apache Zeppelin) permiten a los científicos de datos crear diferentes modelos y algoritmos desde el Control Panel de la plataforma Sofia2. Desde este entorno web los Data Scientists pueden cargar datos a HDFS, procesarlos con Spark, Spark o Python, consultarlos con HIVE, visualizarlos de diferentes formas y además de todo esto manejar las ontologías Sofia2 desde este entorno.

En este ejemplo de uso de los Notebooks vamos a ver cómo traernos un fichero de un sitio externo, procesarlo con Spark y representar los datos procesados en un mapa OpenStreetMap con Leaflet.

Concretamente estamos hablando de un fichero que ofrece el servicio OpenData del gobierno francés (https://www.data.gouv.fr/fr/) y que contiene los datos de las estaciones de recarga eléctrica de Francia

https://www.data.gouv.fr/fr/datasets/fichier-consolide-des-bornes-de-recharge-pour-vehicules-electriques-irve/

El fichero tiene este aspecto:

Comenzaremos por descargar el fichero hacia el directorio home de nuestro usuario:

Lo siguiente es subir este fichero de nuestro directorio local al sistema de ficheros HDFS de nuestro cluster Hadoop

Una vez en HDFS ya puedo manejar los datos con Spark, en este caso para procesar el CSV usaré la librería com.databricks.spark-csv. Para cargarla en el classpath de Spark lo más sencillo es hacer esto:

Y de esta forma tan sencilla puedo convertir el CSV almacenado en HDFS (load(“/examples/IRVE-201510.csv”)) a un DataFrame (df) y de ahí a una tabla persistente (df.write.saveAsTable)

Y una vez tengo la tabla ya puedo consultar los datos de esta de forma muy sencilla:

Además de representarlos en diferentes formatos:

Finalmente haremos la consulta que queremos representar en el mapa:

Tras esto voy a convertir los datos de la consulta a JSON para poder representarlos fácilmente, para esto usaré la librería Gson.

Haré la consulta, mapeando las columnas de los datos obtenidos a los nombres que quiero usar en el JSON:

Los datos tienen esta pinta:

Y ya solo me queda hacer el HTML+JS para pintar mi mapa, en Zeppelin para incrustar un HTML basta con empezar el párrafo con:

Mi HTML tiene este aspecto:

En él podemos ver que estamos usando Thunderforest como Layer (y un apikey que debéis generar en http://www.thunderforest.com/docs/apikeys/ para evitar la marca de agua).

El código que maneja mi JSON con las estaciones es este:

Que genera un botón Show me the map que al pulsar muestra el mapa con un marker para cada estación:

Además de ver la representación en el propio Notebook si en las opciones del párrafo selecciono Link this paragrah:

Esto me genera un URL en la que veo el mapa:

https://sofia2.com/console/notebook/#/notebook/2D1Y4DKY7/paragraph/20160519-175034_779917343?asIframe

y puedo ir pinchando sobre los diferentes markers:

Notebooks Procesando y representando datos en un mapa Leaflet con los Notebooks Sofia2

Premio enerTIC para el proyecto de eficiencia energética de SENA basado en Sofia2

SmartEnergySena

 

El proyecto de eficiencia energética desarrollado por el Servicio Nacional de Aprendizaje (SENA) de Colombia, en colaboración con Indra, ha ganado el premio de enerTIC 2017 en la categoría de Smart International Projects.

 

Sofia2InfografiaRecortada

 

La plataforma Smart Energy está basada en Minsait IoT Sofia2 (http://sofia2.com), la solución IoT con capacidades Big Data de Minsait, la unidad de transformación digital de Indra. Actúa como un gran “cerebro” integrador capaz de monitorizar los distintos dispositivos de medición de energía, agua y gas desplegados por las diversas sedes del SENA, almacenar información, visualizar gráficos y establecer previsiones de consumo mediante la combinación de los datos históricos de la base de datos y los recogidos en tiempo real.

 

Según el primer estudio sobre 28 sedes del SENA, los ahorros podrían llegar a suponer una reducción de alrededor del 25% en el caso de la factura energética, con un retorno de inversión de 1,7 años, en el supuesto de implementar medidas de poca inversión.

 

Estamos muy orgullosos de formar parte de este proyecto como base tecnológica de la plataforma Smart Energy. Puedes leer la noticia completa aquí

Premio enerTIC para el proyecto de eficiencia energética de SENA basado en Sofia2

Funcionalidad soporte multi-BDTR

image0141

En la Release 4.2 de Sofia2 IoT Platform se introdujo el concepto de multi-BDTR. Hasta ahora una instalación de Sofia2 sólo podía funcionar con una BDTR y con una BDH, es decir, si se usaba MongoDB como base de datos BDTR entonces todas las ontologías se almacenaban en esta base de datos.

En esta versión hemos añadido la capacidad de que en una misma instalación de Sofia2 se puedan gestionar diferentes BDTRs, de esta forma cuando creamos una ontología podemos seleccionar la base de datos sobre la que queremos que trabaje. Esta opción la podemos encontrar en Opciones Avanzadas > Seleccionar instancia BDTR en todas las pantallas de creación de ontología:

image0132

Esta funcionalidad nos permite tener tanto bases de datos relacionales como no relacionales en nuestra instancia de Sofia2. Para trabajar con bases de datos relacionales ,como puede ser un PostgreSQL se ha añadido una nueva funcionalidad que nos permite crear ontologías sobre este tipo de base de datos, a la cual podemos acceder desde el menú Ontologías > Crear Ontología > Crear Ontología en Base de Datos Relacional

image006

Lo que nos llevará al formulario para crear la ontología paso a paso, donde nuevamente en Opciones Avanzadas encontraremos el listado de BDTRs relacionales disponibles en la instancia de Sofia2:

post

La configuración de todas las BDTRs las realiza el administrados del sistema de la instancia de Sofia2, para ello se ha creado un nuevo rol SYS_ADMIN. Si accedemos a la instancia de Sofia2 con este rol podremos ver en un primer momento un listado de las BDTRs disponibles para la instancia:

post2

Si accedemos a Crear Instancia tenemos un formulario con todos los campos necesarios para configurar nuestras BDTRs:

post3

Cabe destacar que solo podemos tener una BDTR por defecto y que será en la cual se creen todas las ontologías si no seleccionamos ninguna BDTR en concreto en el apartado de Opciones Avanzadas de creación de ontologías.

Funcionalidad soporte multi-BDTR

10 Tendencias Tecnológicas para 2018 según Gartner: Digital (III)

Tras revisar la tendencia dedicada a Intelligenthoy trataremos la tendencia Digital, que se compone de Digital Twins, Cloud a Edge, Plataforma conversacional y experiencia inmersiva:

Tendencia 4: Digital Twins:

Un Digital Twin es una representación digital de una entidad o sistema del mundo real. En el contexto de IoT, los “gemelos digitales” están vinculados a objetos del mundo real y ofrecen información sobre el estado de las partes que componen la Thing, responden a los cambios,… Con un estimado de 21 billones de sensores y endpoints conectados para 2020, existirán Digital Twins para para miles de millones de cosas en el futuro cercano. Potencialmente esto permitirá ahorrar miles de millones de dólares en reparaciones y mantenimiento (MRO) además de optimizar el rendimiento de los assets IoT.

A corto plazo, los gemelos digitales ofrecen ayuda con la gestión de activos, pero también ofrecerán valor en la eficiencia operativa y mejoras sobre cómo se usan los productos y cómo se pueden mejorar.

Fuera del IoT, existe un potencial creciente para vincularlos a entidades que no son simplemente "cosas". "Con el tiempo, las representaciones digitales de prácticamente todos los aspectos de nuestro mundo estarán conectadas dinámicamente con sus contrapartes del mundo real y usando capacidades basadas en inteligencia artificial permitirán simulación avanzada, operación y análisis ", dice Cearley. "Los planificadores urbanos, especialistas en marketing digital, profesionales de la salud y planificadores industriales se beneficiarán de este cambio a largo plazo hacia el mundo gemelo digital integrado". Por ejemplo, los modelos futuros de humanos podrían ofrecer datos biométricos y médicos, y los gemelos digitales para ciudades enteras permitir simulaciones avanzadas.

Tendencia n° 5: Del Cloud al Edge:

Edge computing describe una topología informática en la que el procesamiento y recopilación de la información se ubica más cerca de las fuentes de esta información. Los desafíos de conectividad y latencia, las restricciones de ancho de banda y una mayor funcionalidad en el Edge favorecen los modelos distribuidos. Las empresas deberían comenzar a utilizar patrones de diseño Edge en sus arquitecturas, especialmente en el ámbito IoT.

Aunque es común suponer que la computación cloud y Edge son competencia, en realidad es un malentendido de los conceptos. Cuando se implementan en conjunto, Cloud se usa para crear el modelo orientado a servicios y Edge ofrece un estilo de entrega que permite la ejecución de aspectos desconectados del servicio en la nube.

Tendencia n° 6: Plataformas Conversacionales

Las plataformas conversacionales impulsarán un cambio de paradigma en el cual la carga de traducir la intención cambia del usuario a la computadora. Estos sistemas son capaces de ofrecer respuestas simples (¿Cómo está el clima?) o interacciones más complicadas (reserve una reserva en el restaurante italiano en Parker Ave.)

Estas plataformas continuarán evolucionando hacia acciones aún más complejas, como la recolección de testimonios orales de testigos de crímenes y actuando sobre esa información creando un boceto de la cara del sospechoso basado en el testimonio. E

l desafío que enfrentan las plataformas de conversación es que los usuarios deben comunicarse de una manera muy estructurada, y esto a menudo es una experiencia frustrante. Un diferenciador principal entre las plataformas de conversación será la solidez de sus modelos de conversación y los modelos de API y eventos utilizados para acceder, invocar y organizar servicios de terceros para ofrecer resultados complejos.

Tendencia nº 7: Experiencia inmersiva

La realidad aumentada (AR), la realidad virtual (RV) y la realidad mixta están cambiando la forma en que las personas perciben e interactúan con el mundo digital. Combinado con plataformas conversacionales, surgirá un cambio fundamental en la experiencia del usuario hacia una experiencia invisible e inmersiva. Los proveedores de aplicaciones, los proveedores de software de sistemas y los proveedores de plataformas de desarrollo competirán por ofrecer este modelo.

Durante los próximos cinco años, la atención se centrará en la realidad mixta, que está emergiendo como la experiencia de inmersión donde el usuario interactúa con objetos digitales y del mundo real mientras mantiene una presencia en el mundo físico. La realidad mixta existe a lo largo de un espectro e incluye pantallas montadas en la cabeza (HMD) para AR o VR, así como AR basado en teléfonos inteligentes y tabletas.

Dada la ubicuidad de los dispositivos móviles, la liberación de Apple de ARkit e iPhone X, Tango de Google y Arcore, y la disponibilidad de kits de desarrollo de software de AR multiplataforma como Wikitude, esperamos que las batallas por AR basados ​​en teléfonos inteligentes y MR se calienten en 2018.

10 Tendencias Tecnológicas para 2018 según Gartner: Digital (III)

Nueva guía e IDE de desarrollo de soluciones sobre Plataforma Sofia2

image0172

 

Uno de los objetivos fundacionales de la Plataforma Sofia2 es el de simplificar y agilizar el desarrollo de todo tipo de aplicaciones, desde aplicaciones IoT en las que intervienen Gateways o dispositivos móviles a grandes sistemas Big Data, sin olvidar las aplicaciones web puras de gestión, para las que Sofia2 es un facilitador.

En este ámbito se ha añadido en la sección de Documentación  de la web sofia2.com una nueva guía que explica paso a paso cómo construir aplicaciones web (en la guía basadas en Spring Boot y Angular):

image0172

 

Complementando la guía se ha generado un entorno de desarrollo empaquetado como un ZIP que contiene todas las herramientas necesarias para construir estas soluciones (incluyendo JVM Java, IDE Eclipse, Maven, Apache Tomcat,…)

Nueva guía e IDE de desarrollo de soluciones sobre Plataforma Sofia2

Integración instancia GIT en GitLab con instancia de Plataforma Sofia2

asoc-git-01
Se ha incorporado una nueva funcionalidad a la plataforma consistente en la asociación de una instancia de SCM GIT sobre GitLab con la instancia de plataforma Sofia2 para poder utilizar dicho repositorio como repositorio SCM de nuestros desarrollos sobre plataforma, además de futuras incorporaciones de automatizaciones para la gestión de funcionalidades como la exportación e importación de configuración y datos, proyectos web, etc.
No todas las instancias de plataforma tendrán disponible la funcionalidad, puesto que está pensado más bien para su uso con instancias que se utilicen como entorno de desarrollo o pruebas, más que con instancias productivas. Para que la funcionalidad esté disponible se debe de habilitar por configuración en la propia instalación de la instancia.
Lo primero que hay que hacer para poder hacer uso de la funcionalidad es crear la asociación. Para ello, accedemos con usuario administrador a la consola de plataforma y en el menú de administración, pulsamos sobre la opción repositorio GIT
asoc-git-01
Y creamos la asociación:
asoc-git-02
Introducimos los datos de URL del repositorio GIT, usuario, password y el private token del usuario administrador para la integración y marcamos la integración como activa:
asoc-git-03
Para poder realizar el enlace correctamente en el repositorio GIT debe de existir un usuario “project_sofia2” (del que debemos conocer su password y el private token) con rol administrador y un grupo llamado “ProjectSOFIA2” con el usuario administrador anterior como propietario.
asoc-git-04asoc-git-05
Solo se permitirá una configuración de Repositorio GIT por instancia y su activación/desactivación, pero no el borrado:
asoc-git-06
En la ventana de visualización se pueden ver los proyectos existentes en el grupo “ProjectSOFIA2”
asoc-git-07
A partir de este paso, cuando un usuario crea un proyecto en Sofia2, automáticamente se crea un proyecto en el repositorio GIT dentro del grupo ProjectSOFIA2 y el usuario correspondiente al usuario Sofia2 que crea el proyecto como owner del proyecto y añadido al grupo, además de crear una estructura base de proyecto a partir de un template.
Creamos el proyecto en Sofia2 Control Panel:
asoc-git-08
Y se crea proyecto en GIT, en el grupo ProjectSOFIA2:
asoc-git-09
Cada proyecto creado en Git se define con:
asoc-git-10
Finalmente, se crean los usuarios asociados con el proyecto:
  • Un usuario con rol owner en Git para el usuario que crea el proyecto
  • Un usuario con rol developer en Git por cada usuario asociado al proyecto Sofia2
  • Todos los usuarios quedarán asociados al grupo de usuarios del proyecto
A partir de este paso, cuando se añaden usuarios al proyecto Sofia2 con repositorio asociado, se crean y añaden usuarios al repositorio y grupo en GIT.
     – Los datos de los usuarios de Git se tomarán de los datos de usuarios de Sofia2.
     – Datos de usuario en Sofia2: Usuario, Nombre Completo, Email
     – Datos de usuario en GitLab: Usuario, Nombre, Email
     – Contraseña: se envía link al mail desde el API de GitLab con contraseña autogenerada para repositorio.
Si un proyecto ya existiera previa a la asociación del repositorio GIT con la Plataforma se tendría que editar el proyecto para que se realizara todo el proceso igual que si se creara de cero con el enlace a GIT activado.

En posteriores versiones se evolucionará la funcionalidad con algunas mejoras:
  • Marcador a nivel de proyecto para indicar si se quiere asociar o no el proyecto a repositorio GIT.
  • Visualizado de datos de enlace a Git con los datos de Grupo/proyecto y usuarios en Git dentro de la ventana de proyecto.
  • Visualización datos básicos de información de repositorio: Branches, Tags, Files, Activity, Commits, Graph, Compare, etc.
  • Funcionalidades para poder guardar contenidos desde consola en dicho repositorio por cada usuario de proyecto. Se hará especifico en cada una de las funcionalidades, por ejemplo, export/import, proyecto web, notebooks, etc.
Integración instancia GIT en GitLab con instancia de Plataforma Sofia2