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 v2.0.

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 en su versión v2.0:

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 en su versión v2.0:

Requisitos funcionales comunes a cualquier rol:

• • El nombre es obligatorio y no puede superar los 100 caracteres ni puede existir otra aplicación con el mismo nombre.
  • 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 en la creación. No editable.
  • La plataforma es opcional y debe ser una plataformá existente en CMS.
  • Los proveedores de la aplicación se extraen de los contratos:
    • El proveedor de desarrollo es el proveedor asociado al expediente de la aplicación.
    • El proveedor administrador de sistemas es el proveedor asociado al expediente asociado a la plataforma de la aplicación.
  • 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 codigo=RESP_SISTEMAS_AT2 (para AT2).

Requisitos funcionales (Gestores de aplicaciones de AT1)

• • El código ALM es obligatorio y no debe superar los 255 caracteres.
  • El código ALM de la aplicación no debe existir para otra.
  • El responsable de producto, el responsable funcional y el responsable de sistemas son obligatorios.
  • El lenguaje de programación es opcional y no debe superar los 250 caracteres.
  • El campo ¿Desarrollo a medida? es obligatorio.
  • El campo ¿Revisión OCA? es obligatorio.
  • El obligatorio indicar un contrato (expediente) de la aplicación dentro del conjunto de contratos existente.
  • El campo ¿Es aplicación? será forzado a SI en la creación. Es editable.
  • La aplicación será marcada como aplicación centralizada automáticamente.
  • El campo Soporte Interno SAS es opcional.
  • El tipo de gestión es obligatorio y debe ser válido.
  • La categoría de la aplicación debe ser válida y no debe ser "Servicios tecnológicos" (400002).
  • La descripción es obligatoria y no puede superar los 255 caracteres.
  • La disponibilidad es opcional y debe contener un valor válido.
  • El horario de uso es opcional y no deberá superar los 250 caracteres.
  • La implicación del ciudadano es opcional.
  • El nivel de recepción CSU es opcional y debe ser válido.
  • El valor de oculto en web autoservicio es opcional.
  • La suite aplicaciones deberá ser válida y estar en estado VIGENTE.
  • El número de usuarios potenciales no puede superar los 250 caracteres.
  • Los elementos enviados en el array de clientes deben ser válidos y la aplicación debe tener al menos un cliente asociado.
  • El ámbito OCA es obligatorio.
  • El área funcional es obligatoria y debe ser válida.

Requisitos funcionales (Gestores de aplicaciones de AT2)

• • El código ALM es obligatorio y no debe superar los 255 caracteres.
  • El código ALM de la aplicación no debe existir para otra.
  • El responsable de producto y el responsable funcional son opcionales. El responsable de sistemas es obligatorio.
  • El horario de uso es opcional y no deberá superar los 250 caracteres.
  • El lenguaje de programación es opcional y no debe superar los 250 caracteres.
  • El campo ¿Desarrollo a medida? es obligatorio.
  • El campo ¿Revisión OCA? será informado a NO.
  • La categoría de la aplicación debe ser válida y no debe ser "Servicios tecnológicos" (400002).
  • La descripción es obligatoria y no puede superar los 255 caracteres.
  • El horario de uso es opcional y no deberá superar los 250 caracteres.
  • 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 valor de oculto en web autoservicio será forzado a SI.
  • El ámbito OCA es obligatorio.
  • El área funcional es obligatoria y debe ser válida.

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).
  • El responsable de producto y el responsable funcional son opcionales. El responsable de sistemas es obligatorio.
  • 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 lenguaje de programación será forzado a NO APLICA.
  • El campo ¿Desarrollo a medida? será informado a NO.
  • El campo ¿Revisión OCA? será informado a SI.
  • El campo ¿Es aplicación? será forzado a NO.
  • El campo Soporte Interno SAS será forzado a NO.
  • 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 valor de ocultoAutoservicio será forzado a NO.
  • Los servicios tecnológicos no registran clientes, por lo que puede enviarse el array a vacío.
  • El área funcional es obligatoria y debe ser válida. Sólo se permiten áreas funcionales dentro del área de negocio de SISTEMAS.

También podremos modificar diferentes atributos de una aplicación mediante el método en su versión v2.0:

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.

Requisitos funcionales (Gestores de aplicaciones)

• • Todos los clientes que no se envíen durante la edición en el array se desvincularán de la aplicación.
  • 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 DEPRECADO

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.

Clientes asociados

Se pueden consultar los clientes asociados a la aplicación filtrando por el identificador uuidAplicacion y con la versión v1.0.