Historial de página

...

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.

...

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á 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.
    El código ALM de la aplicación no debe existir para otra
    • 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 atributo 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:

...