App Descriptor (manifest.json)

El app descriptor agrupa sus atributos en namespaces, cada uno perteneciente a un consumidor distinto:

Un _version en el nivel raíz indica qué esquema de manifest sigue el archivo. El ID de sap.app debe coincidir con el namespace del componente en Component.js, no puede superar los 70 caracteres y debe ser único en el sistema. Por tanto, el app descriptor es el único lugar donde se declaran la identidad de una aplicación, sus conexiones de datos y su contrato de navegación.

Al launchpad le interesa sobre todo sap.app → crossNavigation:

• Inbounds declaran los intents que acepta la aplicación: un semantic object y una acción, un título e icono de tile opcionales, los tipos de dispositivo, una firma de parámetros con valores obligatorios y por defecto, y una regla para parámetros adicionales (permitidos, ignorados o no permitidos).
• Outbounds declaran los intents que la propia aplicación dispara cuando navega a otras aplicaciones.

Lo que ocurre a continuación depende de la plataforma:

1. SAP BTP y SAP Build Work Zone: la aplicación se despliega con su descriptor, por ejemplo en el HTML5 Application Repository, y el sitio utiliza los inbounds como sus target mappings.
2. Launchpad ABAP (SAP S/4HANA on-premise y Private Edition): el target mapping de un technical catalog, creado con el launchpad app manager (/UI2/FLPAM), hace referencia al ID sap.app de la aplicación. El índice de aplicaciones SAPUI5, generado por /UI5/APP_INDEX_CALCULATE, lee los descriptors de las aplicaciones desplegadas.
3. SAP S/4HANA Cloud Public Edition: las aplicaciones entregadas por SAP llevan descriptors como cualquier aplicación SAPUI5; las aplicaciones personalizadas se despliegan en el repositorio ABAP de SAPUI5 del tenant de desarrollo con su tile definido en la aplicación, y un administrador concede el acceso mediante un business role.

La aplicación alder.mm.supplierrating de Alder Manufacturing, con un inbound ilustrativo Supplier-rate, solo se abre si un tile dispara exactamente ese intent. El app descriptor publica el contrato de navegación; el contenido del launchpad decide quién puede utilizarlo.

El esquema del manifest evoluciona con SAPUI5. Cada versión del esquema la entiende una release correspondiente de SAPUI5, y el SAPUI5 SDK publica la correspondencia, por ejemplo el esquema 1.60.0 para SAPUI5 1.120 y posteriores.

A partir de SAPUI5 1.136 está disponible una nueva versión mayor 2 del manifest. Sigue las buenas prácticas actuales y elimina funciones que las versiones anteriores solo habían declarado obsoletas, de modo que pasar a ella es una migración, no un cambio de número. El SDK enumera los cambios necesarios, y el UI5 linter informa de las configuraciones obsoletas del manifest.

Dos ajustes relacionados se confunden a menudo:

• _version describe el esquema en el que está escrito el archivo.
• sap.ui5 → dependencies → minUI5Version indica la release mínima de SAPUI5 que necesita la aplicación.

Criterio de decisión: fije minUI5Version en la release de SAPUI5 más baja entre los sistemas en los que se ejecutará la aplicación, y elija una versión de esquema que esa release entienda. Una discrepancia entre el esquema del app descriptor y el runtime es una causa habitual de funciones que, sin avisar, no hacen nada.

• SAP Fiori elements: el descriptor selecciona el floorplan de cada página mediante sus destinos de enrutamiento y contiene ajustes de página como la carga inicial, la gestión de variantes o el tipo de tabla. Las anotaciones describen los datos; el descriptor describe la aplicación.
• Variantes de aplicación: un proyecto de adaptación no edita el archivo original. Crea una variante con su propio archivo de cambios del descriptor (manifest.appdescr_variant), donde el ID de sap.app es el ID de la variante y sap.ui5 → componentName apunta a la aplicación base. La aplicación original permanece intacta y sigue recibiendo las actualizaciones de SAP.
• Adaptación por key user: flexEnabled indica que la aplicación está habilitada para la flexibilidad de SAPUI5, en la que se basa la adaptación de UI en runtime.

SAP describe el descriptor como de solo lectura tras la entrega; por eso los cambios en aplicaciones entregadas por SAP se realizan mediante variantes y cambios de flexibilidad. El app descriptor es el ancla a la que hacen referencia las extensiones, no un archivo que se deba parchear.

Revise estos puntos cuando una aplicación no se inicie o no navegue como se espera:

1. ID no coincidente. El ID de sap.app difiere del namespace de Component.js, por lo que no se encuentra el componente.
2. ID duplicado o demasiado largo. Las comprobaciones de consistencia del índice de aplicaciones SAPUI5 señalan los IDs duplicados y los de más de 70 caracteres.
3. El inbound no coincide con el tile. El semantic object, la acción o la firma de parámetros difieren del intent que dispara el tile; una regla "not allowed" para parámetros adicionales rechaza los parámetros sobrantes. En el launchpad ABAP, /UI2/FLIA muestra cómo se resolvió el intent.
4. Tipo de dispositivo desactivado. El inbound o sap.ui excluye los teléfonos, de modo que la aplicación solo funciona en escritorio.
5. Fuente de datos incorrecta. La URI de dataSources apunta a una ruta de servicio que no existe en el sistema de destino o que no está enrutada hacia él.
6. Índice desactualizado. El índice de aplicaciones SAPUI5 todavía no conoce una aplicación modificada. El despliegue desde SAP Business Application Studio lo actualiza automáticamente; las SAP Notes, los support packages, las actualizaciones de versión y algunas importaciones de transportes requieren /UI5/APP_INDEX_CALCULATE.

La mayoría de los problemas del app descriptor son discrepancias de contrato entre el archivo, el contenido del launchpad y el back-end, no errores de sintaxis.