SAP Build Work Zone

SAP Build Work Zone separa el origen del contenido del lugar donde lo ven los usuarios:

1. Un administrador se suscribe al servicio en un subaccount de SAP BTP y asigna la role collection Launchpad_Admin a los administradores del sitio.
2. En el Channel Manager se registran los proveedores de contenido. Las apps desplegadas en el HTML5 Application Repository del subaccount llegan a través de un proveedor que la suscripción crea automáticamente; los sistemas SAP S/4HANA se añaden como proveedores de contenido remotos.
3. En el Content Manager, los administradores combinan apps, catálogos, grupos y roles, ya sea procedentes de proveedores o creados localmente.
4. En el Site Directory, los administradores crean sitios y les asignan roles.
5. Cada rol se convierte en una role collection en SAP BTP, que se asigna a usuarios o a grupos del proveedor de identidades.

En tiempo de ejecución, el usuario abre el sitio, ve los tiles que permiten sus role collections, y cada app se ejecuta contra su propio back-end. SAP Build Work Zone es una capa de acceso y composición: decide qué ven los usuarios, mientras que las apps siguen ejecutándose donde están desplegadas.

Ambas ediciones se consumen como suscripciones en SAP BTP, y ambas pueden mostrar contenido federado de SAP S/4HANA. Las UI integration cards son compatibles con ambas ediciones: las cards declarativas por completo, mientras que algunas funciones de las component cards solo funcionan en la edición advanced y fallan en tiempo de ejecución en la edición standard. La licencia depende de la edición y del contrato; la descripción de servicio vigente de SAP indica la métrica. Para un launchpad central puro, la edición standard de SAP Build Work Zone cubre el requisito; la edición advanced es una decisión sobre el espacio de trabajo más que sobre el launchpad.

El contenido de SAP S/4HANA no se reconstruye en SAP Build Work Zone. Se federa:

1. Exponer en el back-end. En on-premise y en Private Edition, un administrador selecciona los roles que se van a exponer en la transacción /UI2/CDM3_EXP_SCOPE (Manage Content for Launchpads on SAP BTP). Las releases recientes también admiten roles derivados y compuestos. En Public Edition, la exposición se realiza mediante un communication arrangement para el communication scenario SAP_COM_0647.
2. Conectar en SAP BTP. Las destinations apuntan al sistema SAP S/4HANA, y se crea un proveedor de contenido en el Channel Manager.
3. Consumir. Los roles expuestos, con sus catálogos, tiles y target mappings, aparecen en el Content Manager y se asignan a un sitio.

Cuando el contenido del back-end cambia, el proveedor debe actualizarse antes de que los usuarios vean el cambio, ya sea manualmente en el Channel Manager o mediante actualizaciones automáticas que los administradores pueden configurar para los proveedores basados en ABAP. La federación de contenido mantiene a SAP S/4HANA como propietario de su contenido de launchpad, mientras que SAP Build Work Zone lo presenta de forma central.

• Un punto de entrada para varios back-ends: un solo sitio puede combinar contenido de varios sistemas SAP S/4HANA, apps de SAP BTP y aplicaciones de terceros.
• Reutilizar en lugar de reconstruir: los roles federados aportan los catálogos, tiles y target mappings existentes, de modo que el diseño del launchpad de SAP S/4HANA no se duplica.
• Servicio gestionado: SAP opera el runtime del sitio, por lo que el punto de entrada central no depende de una release del front-end server gestionada por el cliente.
• Temas y marca: la licencia incluye el UI theme designer, de modo que los sitios pueden seguir la identidad corporativa sin código personalizado.
• Espacio para algo más que tiles: las cards y, en la edición advanced, los workspaces permiten a los equipos crear páginas de inicio basadas en roles en torno a sus apps.

Para organizaciones con más de un back-end, SAP Build Work Zone es la forma nativa de SAP de ofrecer a los usuarios una única puerta de entrada.

• Presenta apps; no las ejecuta. Cada app sigue ejecutándose en su propio back-end, con el rendimiento, los errores y el ciclo de releases de ese sistema.
• Dos capas de autorización. Un usuario necesita la role collection en SAP BTP para ver un tile y la autorización en el back-end, mantenida por ejemplo en PFCG, para usar la app. SAP Build Work Zone no sustituye a la segunda capa.
• La federación es una copia con un ciclo de actualización. El sitio muestra el estado del contenido de la última actualización del proveedor, por lo que los cambios en el back-end no siempre son visibles de inmediato.
• La identidad debe coincidir. El single sign-on hacia el back-end depende de una identidad de usuario coherente entre SAP BTP y SAP S/4HANA.
• Sin lógica de procesos. Un sitio puede mostrar tareas y cards, pero la secuencia de pasos entre apps y sistemas se define en otro lugar.

Son límites por diseño: SAP Build Work Zone optimiza el acceso a las aplicaciones, no los procesos que se ejecutan detrás de ellas.

Compruebe la cadena desde el usuario hasta el back-end en este orden:

1. ¿La role collection está asignada al usuario, directamente o mediante un grupo del proveedor de identidades?
2. ¿El rol está asignado al sitio en el Site Directory?
3. ¿Se actualizó el proveedor de contenido después del último cambio en SAP S/4HANA?
4. ¿El rol está incluido en la exposición del back-end?
5. ¿Funciona la destination al back-end para este usuario?
6. ¿Tiene el usuario la autorización del back-end para la app?

Si el tile es visible pero la navegación falla, ejecute /UI2/FLIA en el back-end para el mismo usuario a fin de analizar el intent. La mayoría de los problemas de visibilidad en SAP Build Work Zone son problemas de asignación de roles o de exposición, no apps defectuosas.