Aplicación

Consulta

Para obtener el listado de aplicaciones de CMS la API dispone del método:

Encontramos dos versiones disponibles, existiendo filtros comunes para ambas versiones y filtros que sólo pueden aplicarse en un caso u otro; la respuesta obtenida también varía según la versión.

• Ejecutando la v1.0, el listado de aplicaciones mostrará los atributos uuid, nombre y codigoAplicacion. 
• La respuesta que encontramos en la definición del método en la API, se corresponde con la versión v1.1.

Para ambas versiones encontramos el filtro codigo, siendo este el código asociado a la consulta a ejecutar en función de las necesidades definidas en cada contrato.

Los diferentes filtros por versión se encuentran listados en la descripción del método en la definición de la API.

Podemos consultar el detalle de una aplicación mediante el método disponible:

Además de los atributos propios de la entidad, en la respuesta visualizaremos la sección de enlaces que nos permite el acceso directo a información extendida sobre la aplicación:

Otro listado que es posible consultar es el de aplicaciones por plataforma, donde será requerido filtrar por el identificador de la plataforma (uuidPlataforma), el código de la plataforma (codigoPlataforma) o el identificador de la relación grupo lógico-entorno-plataforma (idRelGrpLogEntPlat).

Creación y edición

Es posible crear aplicaciones mediante el método disponible para tal fin:

Requisitos funcionales comunes a cualquier rol:

• • El nombre no puede superar los 100 caracteres ni puede existir otra aplicación con el mismo nombre.
  • La descripción no puede superar los 255 caracteres.
  • La criticidad es obligatoria y debe ser válida.
  • El código de la aplicación debe cumplir los siguientes requisitos:
    • 9 caracteres como máximo.
    • Alfanumérico.
    • Todo en mayúscula.
    • No puede comenzar por número.
    • No puede contener espacios en blanco.
    • Obligatorio.
  • Los responsables asociados deben ser válidos y haberse obtenido de la tabla maestra de contacto filtrando por los siguientes códigos: 
    • Responsable de producto: codigo=RESP_PRODUCTO (para AT1) y RESP_PRODUCTO_AT2 (para AT2)
    • Responsable funcional: codigo=RESP_FUNCIONAL (para AT1) y RESP_FUNCIONAL_AT2 (para AT2)
    • Responsable de sistemas: codigo=RESP_SISTEMAS (para AT1) y RESP_SISTEMAS_AT2 (para AT2)

Requisitos funcionales (Gestores de aplicaciones)

• • El código ALM de la aplicación no debe existir para otra.
  • Los responsables asociados sólo son obligatorios para las aplicaciones registradas por el gestor de aplicaciones de AT1.
  • El proveedor sin expediente debe ser válido.
  • La clasificación de plataformas es obligatoria para el gestor de aplicaciones de AT1.
  • El horario de uso no deberá superar los 250 caracteres.
  • La disponibilidad es obligatoria y debe contener un valor válido para el gestor de aplicaciones de AT1.
  • El tipo de gestión debe ser válido.
  • La suite aplicaciones deberá ser válida y estar en estado VIGENTE.
  • El nivel de recepción CSU debe ser válido.
  • El número de usuarios potenciales no puede superar los 250 caracteres.
  • El contrato indicado debe ser válido.
  • La categoría de la aplicación debe ser válida y no debe ser "Servicios tecnológicos" (400002).
    

Requisitos funcionales (Sistemas) - Gestión de servicios tecnológicos

• • El código ALM no se tendrá en cuenta y será el mismo que el indicado en el código de aplicación.
  • La categoría debe ser "Servicios tecnológicos" (400002).
  • Los responsables asociados son opcionales.
  • El proveedor sin expediente no es necesario indicarlo y se ignorará el valor.
  • La clasificación de plataformas es obligatoria.
  • El horario de uso no es necesario indicarlo y se ignorará el valor.
  • La disponibilidad es obligatoria y debe contener un valor válido.
  • El tipo de gestión se ignorará, ya que por defecto será GESTION SAS.
  • La suite aplicaciones se ignorará, ya que por defecto será SERVICIOS TECNOLOGICOS.
  • El nivel de recepción CSU no es necesario indicarlo y se ignorará el valor.
  • El número de usuarios potenciales no es necesario indicarlo y se ignorará el valor.
  • El contrato no es necesario indicarlo y se ignorará el valor.
  • El soporte interno SAS no es necesario indicarlo y se ignorará el valor.
  • La implicación del ciudadano no es necesario indicarla y se ignorará el valor.
  • El desarrollo a medida y el lenguaje de programación no son necesarios y se ignorarán sus valores.
  • El valor de ocultoAutoservicio será ignorado y forzado a NO.

También podremos modificar diferentes atributos de una aplicación mediante el método:

Requisitos funcionales

• • La aplicación a modificar debe ser válida.
  • Mismos requisitos a nivel de campos que en la creación.
  • El código de aplicación no es editable.
  • No se permite dar de baja una aplicación si existe una relación grupo lógico-entorno-plataforma con alguna versión activa.

Entidades asociadas

Suite de aplicaciones

Podrá consultar la suite filtrando por el identificador de la aplicación que estamos consultando (uuidAplicacion) y con la versión v1.0.

Se suministra un enlace en la consulta del listado y detalle de la aplicación.

La vinculación entre una aplicación y su suite se realiza a través de la actualización de la propia aplicación.

Componentes

Para conocer los componentes contenidos en una aplicación, puede consultar lo siguiente haciendo uso del filtro uuidAplicacion:

Versiones

Consulte el apartado correspondiente a las versiones en la documentación.

Relaciones grupo lógico-entorno-plataforma

Para obtener las plataformas en las que está desplegada la aplicación, se puede usar el siguiente método filtrando por el identificador de la aplicación que estamos consultando (uuidAplicacion) y el atributo estado con la versión v1.0. 

Se obtiene así la relación de todas las versiones y las plataformas en las que están instaladas para una misma aplicación.

Se suministra un enlace en la consulta del listado y detalle de la aplicación.

Áreas funcionales

Podemos comprobar el listado de áreas funcionales a las que se encuentra asociada una aplicación, filtrando por el identificador uuidAplicacion y el atributo estado con la versión v1.0.

Se suministra un enlace en la consulta del listado y detalle de la aplicación.

Asociar y quitar áreas funcionales

La aplicación se creará en estado inactivo hasta que se realice la asociación de al menos un área funcional; por lo tanto, al crear la aplicación será necesaria la ejecución del siguiente método:

Requisitos funcionales

• • La aplicación debe ser válida.
  • El área funcional debe ser válida y pertenecer al conjunto de datos obtenido de la consulta anterior.
  • La relación no debe existir previamente.
  • El área funcional a asociar debe pertenecer al área de negocio de SISTEMAS si la categoría de la aplicación es "Servicios tecnológicos".

Para eliminar relaciones entre aplicación y área funcional, existe el método:

Requisitos funcionales

• • La aplicación debe ser válida.
  • El área funcional debe ser válida.
  • La relación debe existir previamente para poder ser eliminada.

Otras consultas relacionadas con aplicaciones

Información extendida de contactos

Se puede consultar información extendida sobre algunos contactos asociados a la aplicación a través de los enlaces correspondientes con la versión v1.0:

• Responsable de producto
• Responsable funcional
• Responsable de sistemas

Expediente asociado

Además, se puede consultar el expediente asociado a la aplicación filtrando por el identificador uuidAplicacion y con la versión v1.0.