SAP Build Work Zone

O SAP Build Work Zone separa de onde o conteúdo vem e onde os usuários o veem:

1. Um administrador assina o serviço em um subaccount do SAP BTP e atribui a role collection Launchpad_Admin aos administradores do site.
2. No Channel Manager, os content providers são registrados. Os apps implantados no HTML5 application repository do subaccount chegam por um provider que a assinatura cria automaticamente; os sistemas SAP S/4HANA são adicionados como remote content providers.
3. No Content Manager, os administradores combinam apps, catálogos, grupos e roles, vindos dos providers ou criados localmente.
4. No Site Directory, os administradores criam sites e atribuem roles a eles.
5. Cada role se torna uma role collection no SAP BTP, que é mapeada para usuários ou grupos do identity provider.

Em tempo de execução, o usuário abre o site, vê os tiles permitidos pelas suas role collections, e cada app roda contra o seu próprio back-end. O SAP Build Work Zone é uma camada de acesso e composição: decide o que os usuários veem, enquanto os apps continuam rodando onde estão implantados.

As duas edições são consumidas como assinaturas no SAP BTP, e ambas podem exibir conteúdo federado do SAP S/4HANA. Os UI integration cards são suportados nas duas edições: os cards declarativos integralmente, enquanto alguns recursos de component cards funcionam apenas na edição advanced e falham em tempo de execução na edição standard. O licenciamento depende da edição e do contrato; a service description atual da SAP informa a métrica. Para um launchpad central puro, a edição standard do SAP Build Work Zone atende ao requisito; a edição advanced é uma decisão de ambiente de trabalho, e não de launchpad.

O conteúdo do SAP S/4HANA não é reconstruído no SAP Build Work Zone. Ele é federado:

1. Expor no back-end. On-premise e na Private Edition, um administrador seleciona as roles a expor na transação /UI2/CDM3_EXP_SCOPE (Manage Content for Launchpads on SAP BTP). Releases recentes também suportam roles derivadas e compostas. Na Public Edition, a exposição é feita por um communication arrangement para o communication scenario SAP_COM_0647.
2. Conectar no SAP BTP. Destinations apontam para o sistema SAP S/4HANA, e um content provider é criado no Channel Manager.
3. Consumir. As roles expostas, com seus catálogos, tiles e target mappings, aparecem no Content Manager e são atribuídas a um site.

Quando o conteúdo do back-end muda, o provider precisa ser atualizado antes que os usuários vejam a mudança, manualmente no Channel Manager ou por atualizações automáticas que os administradores podem configurar para providers baseados em ABAP. A federação de conteúdo mantém o SAP S/4HANA como dono do seu conteúdo de launchpad, enquanto o SAP Build Work Zone o apresenta de forma centralizada.

• Um ponto de entrada para vários back-ends: um único site pode combinar conteúdo de vários sistemas SAP S/4HANA, apps do SAP BTP e aplicativos de terceiros.
• Reutilizar em vez de reconstruir: as roles federadas trazem catálogos, tiles e target mappings existentes, de modo que o design do launchpad do SAP S/4HANA não é duplicado.
• Serviço gerenciado: a SAP opera o runtime do site, então o ponto de entrada central não depende de uma release de front-end server operada pelo cliente.
• Temas e identidade visual: a licença inclui o UI theme designer, de modo que os sites podem seguir a identidade visual corporativa sem código customizado.
• Espaço para mais do que tiles: os cards e, na edição advanced, os workspaces permitem que as equipes criem páginas iniciais baseadas em roles em torno dos seus apps.

Para organizações com mais de um back-end, o SAP Build Work Zone é a forma nativa da SAP de dar aos usuários uma porta de entrada única.

• Ele apresenta apps; não os executa. Cada app continua rodando no seu próprio back-end, com o desempenho, os erros e o ciclo de releases daquele sistema.
• Duas camadas de autorização. O usuário precisa da role collection no SAP BTP para ver um tile e da autorização no back-end, mantida por exemplo na PFCG, para usar o app. O SAP Build Work Zone não substitui a segunda camada.
• A federação é uma cópia com ciclo de atualização. O site mostra o estado do conteúdo da última atualização do provider, então mudanças no back-end nem sempre ficam visíveis imediatamente.
• A identidade precisa coincidir. O single sign-on para o back-end depende de uma identidade de usuário consistente entre o SAP BTP e o SAP S/4HANA.
• Sem lógica de processo. Um site pode exibir tarefas e cards, mas a sequência de passos entre apps e sistemas é definida em outro lugar.

São limites por design: o SAP Build Work Zone otimiza o acesso aos aplicativos, não os processos que rodam por trás deles.

Verifique a cadeia do usuário até o back-end nesta ordem:

1. A role collection está mapeada para o usuário, diretamente ou por um grupo do identity provider?
2. A role está atribuída ao site no Site Directory?
3. O content provider foi atualizado depois da última mudança no SAP S/4HANA?
4. A role está incluída na exposição do back-end?
5. A destination para o back-end funciona para esse usuário?
6. O usuário tem a autorização de back-end para o app?

Se o tile está visível mas a navegação falha, execute a /UI2/FLIA no back-end para o mesmo usuário e analise o intent. A maioria dos problemas de visibilidade no SAP Build Work Zone é de mapeamento de roles ou de exposição, não de apps quebrados.