Treinamento SAP Fiori

Sumário
Introdução ..................................................................................................................................... 6
Histórico dos desenvolvimentos web e móveis na SAP ................................................................ 6
Experiência de usuário .................................................................................................................. 7
Importância da experiência de usuário..................................................................................... 7
Estratégia de UX da SAP ............................................................................................................ 8
SAP UX Design Services ............................................................................................................. 9
Conceitos do SAP Fiori............................................................................................................... 9
Elementos da experiência de usuário ..................................................................................... 10
Design thinking ........................................................................................................................ 11
Decomposição e recomposição .............................................................................................. 13
Exercícios ................................................................................................................................. 14
Arquitetura do SAP Fiori.............................................................................................................. 14
Exercícios ................................................................................................................................. 16
Tipos de aplicação ....................................................................................................................... 16
Aplicações transacionais ......................................................................................................... 16
Aplicações de ficha informativa .............................................................................................. 17
Aplicações analíticas ............................................................................................................... 18
Arquitetura de aplicações no S/4HANA .................................................................................. 19
Exercícios ................................................................................................................................. 20
Orientações de desenvolvimento SAP Fiori ................................................................................ 20
Gerenciamento de mensagens ............................................................................................... 21
Layouts .................................................................................................................................... 23
Dynamic page layout ........................................................................................................... 24
Flexible column page........................................................................................................... 25
Multi instance...................................................................................................................... 26
Dynamic side content .......................................................................................................... 26
Floorplans ................................................................................................................................ 27
Analytical list page............................................................................................................... 27
List Report ........................................................................................................................... 28
Object Page ......................................................................................................................... 28
Overview Page..................................................................................................................... 28
Wizard ................................................................................................................................. 29
Initial Page ........................................................................................................................... 31
Worklist ............................................................................................................................... 31
SAP Fiori Elements................................................................................................................... 32

2
 Rascunho e bloqueio de objeto .............................................................................................. 35
Exercícios ................................................................................................................................. 36
SAP Fiori Launchpad .................................................................................................................... 36
Home page .............................................................................................................................. 36
Menu de usuário ..................................................................................................................... 37
Notificações ............................................................................................................................. 37
Acessando o FLP ...................................................................................................................... 38
Exercícios ................................................................................................................................. 38
SAP Gateway ............................................................................................................................... 39
Ativando o SAP Gateway ......................................................................................................... 39
Configurando destino RFC ....................................................................................................... 40
Configurando um alias de sistema .......................................................................................... 42
SAP Gateway Service Builder .................................................................................................. 43
Criando um projeto ............................................................................................................. 44
Abrindo um projeto ............................................................................................................. 44
Estrutura de um projeto ...................................................................................................... 45
Criando um modelo de dados ............................................................................................. 46
Gerando os artefatos de tempo de execução ..................................................................... 51
Implementando um serviço ................................................................................................ 52
Detalhes das operações ...................................................................................................... 57
Manutenção de serviços ......................................................................................................... 58
SAP Gateway Client ................................................................................................................. 60
Testando serviços ................................................................................................................ 60
Exercícios ................................................................................................................................. 62
Cloud computing ......................................................................................................................... 63
Ferramentas para desenvolvimento ........................................................................................... 65
SAP BUILD ................................................................................................................................ 65
SAP Cloud Platform ................................................................................................................. 66
Criando uma conta trial....................................................................................................... 67
SAP Web IDE ........................................................................................................................ 70
Conectividade ...................................................................................................................... 87
SAP Cloud Connector .............................................................................................................. 90
Instalação ............................................................................................................................ 90
Configuração ....................................................................................................................... 94
Exercícios ............................................................................................................................... 101
Conceitos do SAPUI5 ................................................................................................................. 102

3
 Componentes ........................................................................................................................ 102
Descritor de aplicação ........................................................................................................... 103
MVC ....................................................................................................................................... 103
Modelos SAPUI5 ................................................................................................................ 104
Visões SAPUI5........................................................................................................................ 106
Controladores SAPUI5 ........................................................................................................... 106
Mapeamento de dados ......................................................................................................... 107
Tipos de mapeamento ...................................................................................................... 108
Formatação ....................................................................................................................... 111
Mapeamento de expressão............................................................................................... 113
Atribuição de modelo à interface de usuário.................................................................... 114
Localização ............................................................................................................................ 115
Mapeamento de dados ..................................................................................................... 116
Roteamento e navegação ..................................................................................................... 116
Fragmentos ........................................................................................................................... 118
Exercícios ............................................................................................................................... 118
Extensão de aplicações ............................................................................................................. 120
SAPUI5 Flexibility................................................................................................................... 121
Configuração de componente ............................................................................................... 122
Extensão de visão .............................................................................................................. 122
Modificação de visão ......................................................................................................... 125
Substituição de visão ......................................................................................................... 127
Substituição de controlador .............................................................................................. 128
Substituição de serviço...................................................................................................... 133
Substituição de textos localizados .................................................................................... 134
Exercícios ............................................................................................................................... 136
Configuração do SAP Fiori Launchpad ...................................................................................... 136
Exercícios ............................................................................................................................... 143
Sites úteis .................................................................................................................................. 144
SAP Fiori apps Library ............................................................................................................ 144
SAPUI5 Documentation ......................................................................................................... 144
Cockpit SCP Trial .................................................................................................................... 144
UI5 Inspector ......................................................................................................................... 144
BUILD ..................................................................................................................................... 144
Fiori Guidelines...................................................................................................................... 145
SAP Development Tools ........................................................................................................ 145

4
Resoluções................................................................................................................................. 146
Experiência de usuário .......................................................................................................... 146
Arquitetura ............................................................................................................................ 147
Tipos de aplicação ................................................................................................................. 147
SAP Fiori Launchpad .............................................................................................................. 148
SAP Gateway ......................................................................................................................... 148
Ferramentas para desenvolvimento ..................................................................................... 168
Extensão de aplicações ......................................................................................................... 222
Configuração do SAP Fiori Launchpad .................................................................................. 226

5
Introdução
O SAP Fiori foi lançado em 2013 como uma suíte de 25 aplicações criadas pela SAP com o intuito
de entrar no ramo da mobilidade. O SAP Fiori e as bibliotecas SAPUI5 vieram como sucessores
da tecnologia de desenvolvimento Web DynPro ABAP/Java, até então o padrão utilizado pela
SAP para entregar aplicações Web.

O SAP Fiori evoluiu de uma suíte para um conceito, hoje sendo aplicado como padrão de
experiência de usuário (UX, ou user experience) em todos os produtos go-forward da empresa,
ou seja, produtos em que a SAP vislumbra a melhoria das funcionalidades correntes e o
desenvolvimento de novas.

Anteriormente limitado à camada de apresentação do SAP ERP, o SAP Fiori UX já abrange

produtos na nuvem, como SAP SuccessFactors, SAP Ariba, SAP Concur, entre outros. Hoje, o SAP
Fiori é a principal camada de apresentação do SAP S/4HANA, última versão do SAP ERP, lançado
em 2015.

Histórico dos desenvolvimentos web e móveis na SAP

A primeira abordagem para dar um pouco de mobilidade aos desenvolvimentos SAP aconteceu
em 2004, com o advento do SAP ITS (Internet Transaction Server). Este motor de foi integrado
ao ERP como serviço e permitia a transformação das dynpro (ou telas) geradas em linguagem de
programação ABAP para uma versão HTML. O SAP ITS, porém, era limitado em uma série de
fatores. Assim como as transações geradas no SAP, poucos eventos eram capturados e não havia
uma adaptação muito eficiente com múltiplos tamanhos de tela. Hoje, o SAP ITS ainda é utilizado
no Fiori UX para demonstração de transações que não foram disponibilizadas em outras
tecnologias (mais informações: https://archive.sap.com/documents/docs/DOC-28486).

A partir de então, a SAP passou a investir em páginas chamadas BSP (Business Server Page).
Estas aplicações já eram mais trabalhadas e possuíam um misto de scripts web e ABAP. Por conta
disso, os desenvolvimentos muitas vezes se tornavam confusos, principalmente no momento de
realizar manutenções, uma vez que não havia a diferenciação clara entre a camada de

6
apresentação e a camada de negócio. Por essa razão, e com o advento do Web DynPro, este tipo
de aplicação caiu em desuso. (mais informações:
https://help.sap.com/saphelp_snc700_ehp01/helpdata/en/5a/f8b53a364e0e5fe10000000a11
405a/frameset.htm).

Com as experiências passadas, a SAP, em 2003, lançou a primeira versão Web DynPro na
variante Java. O Web DynPro é uma tecnologia proprietária voltada para o desenvolvimento de
aplicações de negócio exclusivamente para o SAP ERP, baseada em MVC (model, view,
controller). Para rodar uma aplicação Web DynPro, era necessário um servidor Java, logo, as
aplicações eram geralmente publicadas com a ajuda do SAP Enterprise Portal.
Aproximadamente 18 meses depois, a versão Web DynPro ABAP foi lançada, também rodando
em Java, porém, com controladores codificados em ABAP, dentro do SAP ERP. Em 2010, a SAP
decidiu descontinuar todos os desenvolvimentos Java e migrá-los para a variante ABAP.

As principais características do Web DynPro são a agilidade de desenvolvimento, a integração

direta com o ERP e as primeiras responsividades para determinados tipos de dispositivo (ainda
assim, era voltado para desenvolvimentos desktop). (mais informações:
https://help.sap.com/saphelp_snc700_ehp01/helpdata/en/77/3545415ea6f523e10000000a15
5106/frameset.htm)

Por fim, em 2013, com o mercado de smartphones já sedimentado, a SAP entra no ramo de
mobilidade com a suíte de 25 aplicativos do SAP Fiori (Fiori 1.0). Estes primeiros aplicativos
tinham um forte apelo por demonstrar facilidade e foram muito pensados para a distribuição
em dispositivos móveis, como smartphones e tablets. A SAP incrementou este portfólio de
aplicativos móveis, até que se percebeu que era necessário integrar também aplicações
especialistas que já existiam no SAP ERP. Elas, por um lado, deveriam seguir a facilidade de uso
prometida pelo conceito do SAP Fiori, porém, seria necessário abrir mão de um pequeno
número de campos de preenchimento. Em 2015, surgiu a primeira versão do SAP S/4HANA e,
com ela, a criação massiva de aplicações SAP Fiori, a grande maioria embasada em alguns
padrões de desenvolvimento que agilizaram as entregas, denominados Fiori Elements ou Fiori
Smart Templates. O número de aplicações totalizava mais de 1200 em 2018 e, em 2020, já estava
próximo de 12000 (Fiori 2.0). Algumas delas são baseadas em tecnologias legadas, como Web
GUI (ITS) ou Web DynPro ABAP, porém, com uma nova folha de estilo, que gera uma
padronização visual.

Experiência de usuário

Importância da experiência de usuário

O desenvolvimento de software, antigamente, estava voltado ao máximo de funcionalidades
possível. Não era diferente para os desenvolvedores SAP. Desenvolvedores ABAP estavam (e
muitas vezes ainda estão) acostumados a fazer grandes cockpits com o máximo de
funcionalidade possível, gerando grandes telas de “especialista”.

7
O maior problema gerado por este tipo de abordagem é a grande quantidade de treinamento
que é necessária para se atingir a maturidade do uso da aplicação. Além disso, uma aplicação
com muitos campos para preenchimento e funções importantes em menus escondidos tiram o
foco do usuário, além de diminuir o envolvimento e aumentar a chance de erros. Ou seja,
anteriormente, a hoje chamada “experiência de usuário” não era o foco de um
desenvolvimento.

As ferramentas de maior sucesso atualmente para usuários domésticos, porém, mostrou que
uma interface simples e intuitiva mantém o usuário engajado. Isso também é esperado por um
usuário corporativo. As pesquisas mostram que a experiência de usuário possui um grande valor
de negócio, pois ela aumenta a produtividade ao aumentar o engajamento; diminui os preços
de treinamentos para os recém-admitidos; diminui os custos com auditorias, uma vez que os
processos são mais eficientes e não existem colisões de papéis; e finalmente, porque a chance
de entradas erradas pelo usuário diminui consideravelmente.

Estratégia de UX da SAP
A estratégia de experiência de usuário da SAP está baseada no conceito New, Renew and
Enable, onde:

• New: neste pilar, estão todas as aplicações novas criadas pela SAP. Todas elas têm
grande foco na experiência de usuário. Exemplos são o SAP Cloud For Sales e o SAP Fraud
Management;
• Renew: o segundo pilar se baseia na modernização de interfaces de usuário (UI) para
aplicações que já existem. Exemplos são as aplicações SAP Fiori voltadas para transações
clássicas do SAP ERP;
• Enable: o último pilar apresenta as ferramentas para o cliente adotar e criar
experiências de usuário. Aqui, estão as ferramentas como SAPUI5 Dev Tools, SAP Screen
Personas e SAP Theme Designer.

8
SAP UX Design Services
A SAP gerou uma combinação de serviços e informações que denominou como SAP UX Design
Services. Este conjunto tem por intuito guiar o cliente em um projeto de transformação digital,
de maneira a compreender a melhor estratégia a ser adotada (New, Renew ou Enable). Ela se
baseia em quatro categorias, sendo:

• Advise (aconselhar): serviços que provêm conselhos sobre valor de negócio. A partir
deles, o cliente pode planejar seus projetos de transformação digital;
• Innovate (inovar): utilização de design thinking para despertar a inovação e criação de
POCs para que o cliente ganhe confiança na solução;
• Empower (empoderar): este conjunto de serviços visa dar poder aos atores nas áreas
de experiência de usuário, focando em treinamento como design thinking e SAPUI5;
• Realize (realizar): execução do projeto de transformação de UX. Aqui, estão inclusas
criação de aplicações e extensão de existentes.

Conceitos do SAP Fiori

A SAP agregou alguns conceitos básicos que devem ser pensados e aplicados a todas as
aplicações SAP Fiori. Caso um dos conceitos não seja cumprido, uma aplicação, apesar de
SAPUI5, não pode ser considerada SAP Fiori.

9
Os conceitos são:
• Role-based apps (aplicações com foco em papéis): cada aplicação deve ter foco em um
papel específico (exemplo: comprador, agente de vendas). Com apenas um papel, as
telas tendem a ser mais claras e permitirão um foco maior por parte do usuário;
• Adaptative (adaptativa): usuários podem acessar a aplicação com vários tamanhos de
tela e dispositivos, reduzindo a necessidade de desenvolver aplicações para cada um
dos dispositivos alvo.
• Simple (simples): o mínimo de informação possível, sem botões e menus
desnecessários. Os novos usuários ficam sobrecarregados com muitas opções e
informações. Exemplo clássico são as GUI clássicas, como a tela para geração de um
pedido de compra ou de uma ordem de venda. O treinamento deve ser mínimo ou
nenhum.
• Coherent (coerente): as aplicações devem possuir uma linguagem de design e interação
coerente, isto é, devem apresentar modos de utilização iguais ou próximos. Após
navegar em uma aplicação, o usuário deve se sentir confortável em navegar em outros,
pois eles aderem ao mesmo padrão de linguagem.
• Delightful (agradável, encantador): o usuário deve ter uma sensação agradável ao
trabalhar, ao ponto de sentir prazer ao utilizar a aplicação. Ele deve experimentar uma
conexão emocional pelo uso de recursos visuais e animações.

Elementos da experiência de usuário

São alguns os elementos que compõem uma experiência de usuário bem-sucedida.
• Design visual: desenhos de tela agradáveis. A estética é importante, mas não é o único
objetivo deste elemento. Deve-se manter o foco no trabalho a ser feito, comunicando
também uma identidade visual, com padrões de cor e tipografia consistentes. Distrações
não são bem-vindas e devem ser removidas.
• Arquitetura da informação: organização e estruturação de conteúdo, para que a
estrutura de navegação na aplicação seja eficiente.
• Design de interação: manter a navegação o mais intuitiva possível. Deve-se determinar
como a aplicação se comporta quando uma interação com o usuário ocorre.
Basicamente, como os componentes da interface de usuário serão apresentados em
cada momento.
• Usabilidade: quão simples é a utilização da aplicação.
• Acessibilidade: reações de determinados elementos para pessoas que possuam algum
tipo de deficiência, seja auditiva, de visão ou mental (leitura automática de elementos
de tela, alto contraste etc.).
• Interação homem-máquina: foco na interação entre o usuário e o computador, bem
como maneiras de deixá-lo mais facilitado e menos impactante.

10
Design thinking
Metodologia amplamente utilizada para resolução de problemas complexos. Pode ser
empregado em diversas áreas, de formulação de estratégias para resolução de um problema
existente até a criação de um negócio completamente novo.
O design thinking é muito importante para determinação do real problema ou ponto de
incômodo de uma persona (uma pessoa representada pelo seu papel). Em grande parte das
vezes, não existe a percepção do que realmente pode estar afetando o trabalho de uma persona.
Muitas sessões de design thinking se iniciam com um entendimento de problema e, após
discussões e iterações, percebe-se que a raiz estava em outro ponto. Em alguns casos, chega-se
também à conclusão que o problema não possui solução.
O design thinking é mais focado no que é desejável. Porém, uma solução real e inovadora deve
levar em consideração o misto do que se é desejável, atingível tecnologicamente e
financeiramente viável. Essas áreas também são levadas em conta, porém, em âmbito menor.

No caso do desenvolvimento de soluções SAP Fiori, os três pilares são:

• Desejos do cliente: entendimento das necessidades do cliente e seus desejos. Neste
ponto, são geradas entrevistas e enquetes para entender o que se deseja e quais são os
pontos de incômodo do cliente, caso existam;
• Factibilidade técnica: quais são as tecnologias e ferramentas corretas para se executar
uma ideia;
• Viabilidade financeira: verificação se a ideia é viável em análise financeira, encontrando
os objetivos da organização.

Os ingredientes básicos para um resultado satisfatório no processo de DT:

• Times multidisciplinares: quanto mais variado o time, maior a chance de uma ideia
inovadora ocorrer. Cada componente em um time variado possui um conjunto de
experiências diferentes, podendo agregar conhecimento na geração de uma solução
para um problema complexo;

11
 • Workshops: provavelmente o mais famoso dos ingredientes. O workshop é liderado por
uma pessoa (coach) que é responsável por manter o foco da discussão de uma maneira
construtiva, guiando a equipe através do processo;
• Espaços colaborativos: espaços criativos e colaborativos fazem parte de um processo
de DT. São utilizados materiais diversos, como lousas com canetas coloridas, cartões,
post-its e materiais que auxiliem na prototipação, de maneira geral. A divisão de espaço
com outras equipes também é benéfica, pois existe a troca de experiências e a
diminuição da alienação.

O design thinking, em linhas gerais, possui um roadmap estipulado e é um exercício realizado

em iterações. No entanto, não existe uma ordem exata de execução, podendo haver saltos de
fases ou regressão a fases que já haviam sido concluídas.
De acordo com a Stanford D.School, as etapas de design thinking são:
• Criar empatia: descobrir os gaps entre o que as pessoas dizem e fazem. O estudante
investiga uma situação específica ou um lugar e como as pessoas interagem com ele;
• Definir: o estudante transforma as descobertas em descrições da situação;
• Idealizar: o estudante tenta chegar a uma solução usando qualquer um dos métodos do
design thinking, como brainstorming, por exemplo;
• Prototipar: os estudantes constroem protótipos para a solução sugerida. Um protótipo
visual permite avaliar a ideia e determinar se ela atinge ou não o objetivo estipulado;
• Testar: primeiro momento onde o protótipo é testado e os estudantes recebem
feedbacks para melhorar o produto e chegar a melhores resultados;
• Iterar: mesmo após o produto entregue, existe um processo de aprendizado da
experiência com o produto. Utiliza-se este passo para desenvolver uma versão futura
do produto.

As tarefas do DT podem ser classificadas em dois espaços, sendo:

• Espaço do problema: espaço onde se tenta entender o problema e como enfrentá-lo.
Neste espaço, os participantes tentam identificar representações realísticas dos
usuários da aplicação e documentá-los como personas, definindo objetivos,
necessidades, responsabilidades e desconfortos. Lembrando que, para uma aplicação
SAP Fiori é recomendado ter foco em apenas uma persona por conta do caráter role-
based pregado pelo conceito.

12
 • Espaço de solução: espaço onde se tenta formular uma solução ou estratégia para
resolver o problema.

Decomposição e recomposição
As transações existentes no SAP ERP foram desenvolvidas para uma perspectiva de múltiplos
papéis. Logo, existem inúmeras funcionalidades ou múltiplas opções com a mesma
funcionalidade. Como apresentado, este tipo de abordagem, na maioria das vezes, confunde o
usuário final, que não sabe como deve proceder em determinada ação. Muitas funcionalidades
também ficam escondidas e precisam de navegações em duas ou mais telas. Em outros casos,
estão presentes em menus com muitas quebras.
Existem também transações que são incompletas, o que forçam o usuário a executar múltiplas
navegações por diversas transações até atingir a operação que se desejava.
Em uma aplicação Fiori, este tipo de transação deve ser decomposto, quando se trata de uma
transação muito grande, ou recomposto, em casos de transações que são complementares.
• Recomposição: combinação de duas ou mais transações que são utilizadas para realizar
uma operação de negócio. Este tipo de abordagem aumenta a produtividade do usuário,
uma vez que não são necessárias múltiplas navegações e interações em telas distintas.
• Decomposição: oposto da recomposição. Neste caso, existem múltiplas operações de
negócio em uma transação SAP pesada, agregando muitos papéis, ou seja, múltiplos
tipos de usuário fazem acesso ao mesmo programa e o utilizam para intuitos diferentes.
A quebra em múltiplas aplicações Fiori deve estar focada no papel que cada usuário
executará.

13
Exercícios
1. Qual a nova estratégia de UX que a SAP vem utilizando? Explique cada um de seus
componentes.
2. Quais são os conceitos para se desenvolver uma aplicação SAP Fiori?
3. Quais são os três pilares que são atendidos por uma solução inovadora? Qual deles é o
foco do Design Thinking?
4. Quais são os maiores problemas nas transações SAP clássicas quando levamos em conta
a experiência de usuário?

Arquitetura do SAP Fiori

Para entender a arquitetura SAP Fiori, é necessário compreender cada um dos componentes
presentes. De maneira simplificada, pertencem à arquitetura os elementos:

• Cliente: é o responsável por apresentar as informações ao usuário final. Na maioria dos

casos, é representado por um browser. Também pode ser representado por um outro
tipo de cliente, como o SAP Fiori Client (disponível para plataformas móveis);
• Web dispatcher: é um proxy reverso exposto na DMZ. Ele é utilizado como porta de
entrada para acesso aos sistemas on-premise. Elimina o problema de cruzamento de
domínios (“Same Origin Policy”);
• Frontend server (FES): servidor onde são hospedados os serviços oData, Fiori
Launchpad, aplicações SAP Fiori e bibliotecas SAPUI5;
• Backend server (BES): servidor onde estão os dados e a lógica de negócio. É onde se
implementam os serviços oData;
• Banco de dados: acessado pelo BES, pode ser um banco de dados tradicional ou um SAP
HANA;
• SAP Cloud Platform (SCP): plataforma na nuvem (PaaS) da SAP, possui ferramentas de
desenvolvimento, como o SAP Web IDE;
• SAP Cloud Connector: servidor on-premise que expõe servidores SAP ao SCP. Substitui
o web dispatcher.

Existem basicamente duas arquiteturas mais utilizadas na implementação do SAP Fiori. A

primeira é a arquitetura em hub. Existe um FES e um ou mais BES conectados. O FES é acessado
pelos clientes a partir de um web dispatcher ou um Cloud Connector.

14
Entre as vantagens dessa arquitetura, estão:

• Ponto central de acesso. Todas as requisições chegam através do FES. Existe apenas um
Fiori Launchpad, que pode publicar aplicações de todos os BES;
• Melhor segurança e autenticação: existe uma camada extra até se atingir o BES, onde
estão todos os dados do negócio;
• Separação do ciclo de vida de interface de usuário. Todas as bibliotecas e componentes
gráficos ficam em um servidor apartado. As atualizações de UI são muito mais
frequentes do que as atualizações de lógica de negócio.

A desvantagem desse modelo é que é necessário um servidor adicional e existe um overhead,

pois existe uma comunicação “extra” que é feita entre o FES e o BES.

A segunda arquitetura mais comum é a arquitetura embedded. Neste caso, não existe
distinção entre o FES e o BES. Eles são um único servidor que fornece tanto UI e serviços
quanto lógica e dados de negócio.

15
Entre as vantagens, estão:

• Menor latência de dados (não existe overhead entre BES e FES, pois são o mesmo
servidor);
• Custo reduzido (apenas um servidor para tudo);

As desvantagens são:

• É impossível gerar um Fiori Launchpad como centralizador. Cada servidor terá seu
próprio FLP;
• Mais difícil de manter atualizado: por envolver dados de negócio, existe uma
sensibilidade maior em aplicação de atualizações;
• Exposição a ataques aumentada: não existe uma camada adicional. Mesmo com um
proxy reverso, existe uma maior exposição.

Mais detalhes sobre os modelos de implementação estão disponíveis em

https://www.sap.com/documents/2018/02/f0148939-f27c-0010-82c7-eda71af511fa.html.

Exercícios
1. Quais é a diferença entre o frontend server e o backend server em uma arquitetura SAP
Fiori? Eles podem ser, em algum momento, o mesmo servidor?
2. Cite as vantagens e desvantagens das arquiteturas mais conhecidas.

Tipos de aplicação
As aplicações SAP Fiori podem ser classificadas em três grandes grupos baseados na sua
arquitetura. Nas próximas seções, descreve-se cada um dos tipos.

Aplicações transacionais
São aplicações que envolvem processos de negócios, por exemplo, criar um fluxo de notificação
de ausência.

Em tipos transacionais, existe o movimento de dados bidirecional, isto é, tanto a camada de

apresentação quanto a camada de negócio enviam e recebem dados. Operações de criação,
atualização, leitura e exclusão são comuns neste tipo.

Do ponto de vista de desenvolvimento de software, este tipo de aplicação é o que mais demanda
esforço em comparação aos demais tipos.

Não é necessária a utilização de um banco de dados SAP HANA, porém a performance é superior
quando utilizado em conjunto com o BD proprietário da SAP.

Avaliando a infraestrutura necessária, verificamos os servidores de frontend (Fiori) e backend

(SAP Business Suite ou S/4HANA) conectados. A camada de apresentação é provida pelo servidor

16
frontend. O banco de dados é acessado pelo próprio backend e a informação é transitada para
o SAP Gateway, que faz a transformação para o protocolo oData, consumido pelas bibliotecas
SAPUI5.

Aplicações de ficha informativa

Este tipo de aplicação apresenta uma informação sobre objeto ou transação dentro de um
contexto pré-existente. Este tipo de aplicação não é acessado diretamente de uma tile, e sim
acessada por uma primeira aplicação.

Geralmente, elas são resultado de cliques em listas em resultados de buscas ou de drilldown de

relatórios diversos, provenientes de aplicações transacionais, analíticas ou mesmo outras fichas
informativas.

Podem conter links para aplicações transacionais que relacionam o objeto selecionado (e.g.
conversão da requisição de compra em pedido de compra).

Estas aplicações são sempre somente leitura, baseadas na leitura através de CDS views e
annotations para a renderização. Por isso, são obrigatoriamente dependentes de um banco de
dados SAP HANA.

Para a versão SAP Business Suite, é necessário configurar o SAP Fiori Search. A leitura da
interface gráfica continua a ser realizada no servidor frontend, porém, as leituras dos dados são
feitas através de uma comunicação proprietária chamada InA, que faz acesso diretamente ao
banco de dados SAP HANA. Para versão S/4HANA, este conector já está internalizado.

17
Aplicações analíticas
Aplicações somente leitura que transformam uma grande quantidade de dados em KPIs. Estes
são demonstrados graficamente, permitindo prever situações futuras. Utiliza-se o KPI modeler
para geração dos indicadores. Existem alguns KPIs entregues de fábrica pela SAP. Este tipo é
altamente dependente da performance do banco de dados, não sendo possível utilizar um BD
diferente do SAP HANA.

No caso das aplicações analíticas para a versão Business Suite, assim como nas fichas
informativas, a camada de apresentação é provida pelo frontend server, enquanto os dados são
acessados diretamente do banco de dados SAP HANA. Neste caso, porém, não existe um
conector proprietário. Ao SAP HANA possui uma camada que funciona como um servidor de
aplicação, denominado SAP HANA XS. Ele provê modelos transformados diretamente em oData.
Por esta razão, justifica-se a utilização do banco de dados SAP HANA. Para a versão S/4HANA,
toda esta arquitetura está internalizada.

18
Arquitetura de aplicações no S/4HANA
A arquitetura para a plataforma S/4HANA é simplificada em vários níveis, consistindo em um
arquétipo:
• Um arquétipo: uma modelo para acesso aos três tipos de aplicação, ao contrário da
versão Business Suite;
• Uma central de usuários e autorizações: todos os acessos são mantidos em uma única
base. Na versão Business Suite, era necessário manter acessos tanto na camada de SAP
Fiori como na camada SAP HANA XS;
• Um modelo de negócios: as CDS views são consideradas o ponto central da arquitetura
para todas as modelagens de dados, válidos para cenários transacionais e analíticos. No
modelo anterior, aplicações transacionais eram feitas em ABAP enquanto as analíticas
eram feitas na camada HANA XS;
• Um gerenciamento de ciclo de vida: com artefatos nas camadas ABAP e HANA, era
necessário um gerenciamento de ciclo de vida complexo. Com a estruturação no
S/4HANA, todas as estruturas são criadas e gerenciadas pela camada ABAP;
• Um protocolo e uma camada de implementação: aplicações transacionais e analíticas
usam o protocolo oData diretamente do SAP Gateway, não mais havendo necessidade
de acesso à camada SAP HANA XS.

(Mais detalhes da arquitetura do SAP Fiori em outros landscapes:

https://experience.sap.com/documents/sap-fiori-ux-architecture-for-s4h.pdf/)

19
Exercícios
1. Quais são os três tipos de aplicação que podem ser atualmente desenvolvidos no SAP
Fiori?
2. Qualquer banco de dados pode ser utilizado para os três tipos de aplicação? Explique.
3. Como é feita a comunicação de uma ficha informativa com o banco de dados em uma
instalação SAP Business Suite?

Orientações de desenvolvimento SAP Fiori

É imprescindível que o desenvolvedor SAP Fiori siga algumas instruções para que o resultado
tenha aderência ao conceito proposto de experiência de usuário.
Ao contrário de um programa ABAP ou Web DynPro ABAP, que possuem estruturas mais fixas,
com a camada de apresentação em SAPUI5, é possível atingir o mesmo objetivo funcional de
inúmeras formas, uma vez que existem mais de 100 componentes de interface gráfica entre
controles e layouts. Porém, deve-se buscar os 5 princípios de SAP Fiori: baseado em um papel,
responsivo a múltiplos dispositivos, simples de utilizar, coerente na interação e na navegação e
agradável de se utilizar.

A SAP disponibiliza um manual online de boas práticas sobre a experiência com o SAP Fiori. A
documentação está disponível em https://experience.sap.com/fiori-design-web/ e é aberta a
todo o público. Consultas a esse material devem ser feitas sempre que houver dúvidas, pois o
número de situações possíveis é imenso.
Na sequência, serão abordados alguns dos temas mais importantes no conceito do SAP Fiori.

20
Gerenciamento de mensagens
O gerenciamento de mensagens é um grande problema na dinâmica de uma aplicação. Se não
for bem pensado, pode interromper uma boa experiência de usuário e gerar irritação.

Existem vários controles para a demonstrar mensagens. Todas as mensagens devem ser visíveis
e claramente identificáveis na interface de usuário. A mensagem deve indicar em linguagem
clara qual é precisamente o problema (quando houver um) e sugerir uma solução construtiva.
Evite a utilização de informações técnicas. Interrompa o usuário o mínimo possível (popups, por
exemplo, devem ser demonstrados apenas em situação que exigem interrupção), pensando em
soluções que evitem o problema de ocorrer.

O SAP Fiori trabalha com as seguintes categorias de mensagem:

• Confirmação;
• Informação;
• Sucesso;
• Aviso;
• Erro.

Em comparação ao SAP ERP, não existem as mensagens de término e anulação.

Existem basicamente dois tipos de mensagem:

• Mensagens de estado: são relacionadas a campos da UI e são exibidas em um message

popover (sap.m.MessagePopover). Elas persistem até que uma nova validação seja
executada.

• Mensagens transitórias: são relacionadas a uma ação. Quando é uma mensagem que
precisa interromper a ação do usuário, se utiliza uma message box (sap.m.MessageBox)

21
 ou um diálogo (popup) com uma message view (sap.m.MessageView). Após a
interrupção, fechada a janela ou clicado algum botão, a mensagem deixa de existir e o
programa segue com a ação escolhida.

Os principais controles para exibição de mensagens são:

• Message popover: controle para exibição de validações de formulários. Relaciona a

mensagem a um determinado campo. Geralmente, o message popover é apresentado
no canto inferior esquerdo da tela.

• Message box: controle para exibição de mensagens e erros genéricos, sem relação
direta a um determinado campo. Interrompe a execução, então deve ser usado com
cautela. Pode ser utilizado em mensagens de confirmação para coleta de texto.

22
 • Message strip: controle para informações gerais referentes ao estado de um objeto.
Pode ser fechada pelo usuário.

• Message toast: controle utilizado para demonstração de mensagens de sucesso. Vai

desaparecendo aos poucos, até se tornar invisível.

• Message page: controle utilizado para navegação inexistente ou para quando foi feito
um filtro e não há nada a se demonstrar ao usuário.

Layouts
O SAP Fiori possui uma hierarquia de interface de usuário. Em geral, se inicia a partir do SAP FLP
(Fiori Launchpad). As aplicações são exibidas no formato de tiles na homepage e todas as

23
aplicações atribuídas ao perfil do usuário podem ser encontradas a partir do app finder. Quando
selecionada uma aplicação, ocorre a navegação. Até a chegada à aplicação final, não é possível
interferir no método de apresentação.

A partir de então, para a construção de uma aplicação, é necessário definir o layout a ser
utilizado. Ele define a disposição dos controles na tela. Existem basicamente dois layouts básicos
de página, sendo:

• Dynamic page layout: tela cheia com responsividade;

• Flexible column page layout: tipicamente com 2 ou três colunas.

O layout para tela cheia contém apenas um floorplan, enquanto o flexível pode ter a quantidade
de colunas que for definida. Um floorplan representa um tipo de layout para uma página
completa, definindo a estrutura dos componentes de acordo com um caso de uso.

Obs.: existiam outros dois tipos de layout, full screen layout e split screen layout, que foram
descontinuados a partir da versão 1.48, mas que ainda podem ser encontrados por retro
compatibilidade.

Dynamic page layout

Fundação de todas as aplicações SAP Fiori, contém uma área para título, um cabeçalho com
comportamento dinâmico, uma área para conteúdo e uma barra de rodapé. Responsivo. A área
de cabeçalho pode ser encolhida, assim como a barra de rodapé pode ser inibida.

24
Flexible column page
Controle que demonstra múltiplos floorplans em uma única página. Permite navegação mais
rápida e fluída, em contrapartida à navegação tradicional, feita página a página. Pode possuir de
uma a três colunas. O usuário pode expandir a coluna que ele gostaria de se focar, ou alternar
entre layouts. A coluna mais à direita pode ser vista em modo de tela cheia.

25
Multi instance
Permite ao usuário abrir múltiplos documentos ou objetos em forma tabular, como nos
navegadores da internet. Depois de selecionar um item, o conteúdo é renderizado no container
da área tabular.

Dynamic side content

Apresenta conteúdo adicional em uma área lateral, a fim de dar melhor entendimento ao
usuário sobre a informação que está sendo acessada. Adaptável a diferentes tipos de tela. A
informação principal deve sempre estar disponível, independentemente de a área lateral estar
sendo exibida ou não.

As principais utilizações da área lateral são como filtro de informações da área principal e área
de ajuda. A área dinâmica pode estar à esquerda ou à direita. Em dispositivos de menor tela, ela
fica inibida e é acessível através de um botão.

26
Floorplans
Termo utilizado para identificar tipos diferentes de layout, a estrutura dos controles utilizados
e como suportar diferentes casos de uso. Uma aplicação normalmente possui diversas páginas
e cada uma delas comporta um floorplan.

Analytical list page

Oferece visualização dinâmica de dados e capacidades de BI, permitindo a análise do mesmo
dado em diferentes perspectivas. Os usuários podem realizar um drilldown para investigar a
causa e atuar também em conteúdo transacional. Disponível na versão SAP Fiori Elements.

27
List Report
Apresenta grande número de objetos de negócio ou instâncias de transações e permite verificar
os detalhes de cada registro. Os campos podem ser filtrados e existem opções para
agrupamento e ordenação. Utilizado em conjunto com outro floorplan, o Object Page, para
demonstração de mais detalhes. Disponível na versão de controles SAPUI5 individuais ou SAP
Fiori Elements.

Object Page
Popular e recomendado para cenários clássicos de criação, modificação e exibição de dados.
Possui cabeçalho flexível que pode ser ocultado e uma área de conteúdo para apresentar a
informação. Cada seção é navegável por uma área tabular e é possível gerar ancoragem em
determinado conteúdo. Disponível na versão de controles SAPUI5 individuais ou SAP Fiori
Elements.

Overview Page
A OVP é uma aplicação Fiori e floorplan que apresenta toda a informação necessária para um
usuário em uma página única, baseada em um domínio ou papel específico. Permite a

28
visualização de KPIs (key process indicators) de maneira rápida, em formato de cartões. Os
cartões podem ser organizados de acordo com o tamanho da tela.

Wizard
Utilizado para criação e edição de objetos, este floorplan guia o usuário através da entrada de
dados. Os dados são particionados em passos. Uma vez que o passo é completado, o próximo é
habilitado para preenchimento. Um mínimo de 3 passos é necessário para utilizar este padrão.

Possui duas áreas, sendo a primeira a chamada de tela passo a passo ou walkthrough e a
segunda denominada de tela de sumário.

29
Na tela de passo a passo, o preenchimento do formulário é realizado. Assim como uma tela de
formulário padrão, são inseridos elementos para a entrada e/ou edição de dados.

Na tela de sumário, um resumo é apresentado relacionando cada uma das seções preenchidas
e seus valores. Um link para edição é apresentado ao lado de cada uma delas, permitindo o
retorno ao passo selecionado.

30
Initial Page
A página inicial permite ao usuário a navegação para um objeto apenas, podendo visualizá-lo ou
editá-lo. O ponto inicial de interação é um campo que direciona o usuário para a busca do objeto
a ser manipulado, através de uma ajuda de pesquisa ou live search (digitação que apresenta
sugestões). Se for necessária a exibição de mais de um objeto, deve ser demonstrado utilizando
o floorplan List Page.

Worklist
Uma worklist demonstra uma coleção de itens que necessitam de ação de processamento do
usuário. Trabalhar com uma lista desse tipo envolve revisar detalhes dos itens e tomar ações
sobre eles. Um item atribuído ao usuário deve ser completado ou delegado. Um exemplo
comum e muito utilizado é uma lista de pendências de um workflow.

A diferença maior entre uma worklist e um list report é que, no segundo caso, o propósito da
lista está em encontrar e atuar em uma quantidade de itens maior.

31
SAP Fiori Elements
SAP Fiori Elements são smart templates, um framework para os padrões mais utilizados no
desenvolvimento de aplicações SAP Fiori.

As aplicações desenvolvidas a partir deste método têm seu comportamento ditado por
annotations, que são encaminhadas a partir do serviço oData consumido por ela. Com isso, não
existe qualquer programação realizada no frontend. Apenas quando o resultado não é
totalmente aderente, pode-se realizar modificações em pontos específicos, como a adição de
ações de usuário.

Utilizando estes padrões, garante-se consistência e conformidade com as últimas guidelines de

desenvolvimento. Estes desenvolvimentos sofrerão atualizações automáticas ao se migrar a
versão da biblioteca SAPUI5.

A utilização deve ser estudada, pois os padrões são fixos e não possuem muita flexibilidade.
Quando não aderente, a utilização não é recomendada, pois o esforço de adaptação pode ficar
mais custoso que o desenvolvimento de uma aplicação do zero.

Atualmente, 5 padrões estão disponíveis para utilização, sendo:

• Analytical list page: página que mistura dados analíticos e listagem, permite avaliar os
mesmos dados de diferentes perspectivas. Esta visualização ajuda na identificação de
fatos e situações de negócio e reduz o número de interações para a extração dos
dados. Usuário pode criar filtros, ordenações, agrupamentos, divisões etc.;

32
• List report: exibição de uma lista de objetos. Possui uma área para filtragem de
resultados, que são exibidos dentro de uma lista em visão tabular. Utilizado como
padrão para relatórios, pode ser utilizado em conjunto com a Object Page;

33
• Object page: permite a apresentação de dados de um objeto. Apresenta um formulário
com cabeçalho e corpo, podendo este mesmo formulário ser utilizado para a
criação/edição de um objeto como para a visualização;

• Overview page: página de visão geral, apresenta cartões com informações gráficas, KPIs
etc. Traz informações de múltiplas aplicações e permite realizar navegação para elas. É
desenvolvida para um domínio ou função específica. Este tipo de aplicação deve conter,
no mínimo, 3 cartões. Também possui área para filtro, sendo este aplicado a todos os
cartões que compõem a página;

• Worklist: funciona da mesma maneira como o floorplan. Exibe uma listagem com ações
a serem tomadas pelo usuário. Similar ao List Report, porém com foco na ação.

34
Rascunho e bloqueio de objeto
Um rascunho é uma espécie de documento ou objeto intermediários que ainda não está
efetivado no sistema. Um rascunho é armazenado conforme o preenchimento de um
formulário, sem a necessidade de uma ação explícita do usuário.

No SAP Fiori, os rascunhos são utilizados para:

• Manter uma versão não salva de uma atividade que tenha sido interrompida, para que
o usuário possa editar posteriormente;
• Para prevenir que os dados da aplicação sejam perdidos caso haja um término
inesperado (por exemplo, queda da conexão com a internet);
• Como mecanismo de bloqueio, para que múltiplos usuários não façam modificações
simultâneas em um mesmo registro de objeto ou documento (aplicações Fiori são
stateless).

Quando um usuário inicia a criação de um objeto ou edita um existente, um rascunho é criado

paralelamente, sendo utilizado na validação e no controle de campos. Ao armazenar, o rascunho
é absorvido para o documento original e, depois disso, eliminado.

35
Exercícios
1. Quando o uso do message box é recomendável?
2. Qual é o melhor tipo de gerenciador de mensagem para preenchimento de formulários
com diversos campos?
3. Qual floorplan é indicado para cenários clássicos de criação, edição e visualização de
objetos ou instâncias de transações?
4. Qual é a diferença entre um list report e uma worklist?
5. Quais são os floorplans atualmente implementados em tecnologia SAP Fiori Elements?

SAP Fiori Launchpad

O SAP Fiori Launchpad, ou FLP, é o ponto de entrada para acessar aplicações SAP Fiori. Ele provê
às aplicações serviços de navegação, personalização, ajuda e suporte e configuração de
aplicações.

O FLP trabalha com todos os tipos de dispositivo, sendo adaptável aos diversos tamanhos de
tela. Também é importante ressaltar que o FLP trabalha com base no papel que o usuário
desempenha, ou seja, ele realiza uma leitura no perfil de aplicações disponíveis para o usuário
final antes de apresentar a home page. Assim, usuários diferentes terão acesso apenas ao
conteúdo imposto para seus perfis.

O FLP apresenta uma home page com tiles (ladrilhos), cada uma representando uma aplicação
ou serviço descrito por nome e descrição, podendo conter também status indicadores (número
de tarefas pendentes, por exemplo).

Home page
É o principal componente do SAP Fiori Launchpad e o ponto central de acesso de qualquer
usuário que fará utilização do SAP Fiori.

36
É nela que são apresentadas as aplicações. Os usuários podem personalizar a home page
adicionando, removendo ou agrupando tiles. Algumas vezes, um usuário já pode receber uma
configuração prévia de grupos de aplicação baseadas no seu perfil.

Menu de usuário
Oferece uma gama de serviços específicos para o usuário. É acessado a partir do clique na foto
no lado superior direito. Este menu é acessível não só no FLP, como em todas as aplicações do
SAP Fiori.

Entre as opções disponíveis, as principais são:

• Preferências e configurações gerais;

• Catálogo de aplicações disponíveis para o perfil do usuário (app finder);
• Objetos e aplicações utilizadas recentemente;
• Botão para encerrar a seção.

Este menu pode ser utilizado para modificação da home page e, em contexto de aplicação, pode
apresentar outras opções.

Notificações
O botão de notificações fica ao lado da imagem do usuário, no canto superior direito. A lista de
notificações demonstra notificações geradas pelo sistema, como a caixa de entrada de um
workflow. É possível navegar diretamente para a aplicação notificadora a partir de um clique.
Botões de ação também podem ser apresentados diretamente na caixa de notificação (por
exemplo, aprovar ou reprovar uma pendência).

37
Acessando o FLP
A maneira mais comum para acessar o SAP Fiori Launchpad é a partir do próprio servidor SAP.
Ao acessar o servidor, deve-se digitar a transação /UI2/FLP. O navegador será inicializado com a
página inicial do FLP.

Também é possível acessar o Fiori Launchpad a partir da URL <servidor>/sap/bc/ui2/flp, onde

servidor é a junção do protocolo (http/https) junto ao nome do servidor e porta para o
protocolo (e.g. https://testeserver.com:443). Esta URL pode ser inserida diretamente no
navegador de sua preferência.

Exercícios
1. Qual o principal componente do SAP Fiori Launchpad?
2. Como se acessa o Fiori Launchpad?

38
 3. O que é tile no SAP FLP?

SAP Gateway
O SAP Gateway é um framework disponível nos servidores SAP Business Suite e S/4HANA. Ele é
aberto ao consumo de qualquer dispositivo ou plataforma, com APIs simples e baseado em
padrões de mercado. Ele promove a diminuição da barreira do consumo de dados: uma vez que
o consumo de dados foi definido, qualquer interface pode ser integrada. Além disso, esconde a
complexidade técnica de um landscape SAP, centralizando requisições. A codificação dos
serviços disponibilizados no SAP Gateway é realizada em ABAP.

Os serviços são baseados no padrão oData (Open Data Protocol). Este é um padrão RESTful que
não impõe restrições no formato da mensagem. Os formatos aceitos são JSON, XML e ATOM.
Geralmente, serviços desenhados neste protocolo são mais rápidos se comparados a outros
padrões, pois trabalham com o mínimo de informação (baixo overhead). Os serviços oData
possuem uma chamada específica para busca de metadados ($metadata).

Obs.: para todas as aplicações do SAP Gateway, procure utilizar o idioma em inglês. Muitas
traduções estão faltando em outros idiomas, o que acaba deixando muitos termos no idioma
original do desenvolvimento (alemão).

Ativando o SAP Gateway

Ao acessar o servidor SAP, digite a transação /IWFND/IWF_ACTIVATE. Uma mensagem surgirá
indicando se o Gateway está inativo e você quer ativá-lo ou o inverso. No nosso exemplo, o
Gateway já está ativo, logo não é necessária ação.

39
Obs.: sempre que for necessário o acesso a uma transação iniciada por “/” no SAP, utilize o
prefixo “/n” antes (por exemplo, /n/IWFND/IWF_ACTIVATE). O indicador /<nome>/ indica um
namespace reservado.

Após ativá-lo, a mensagem será exibida e o sistema está pronto para ser utilizado.

Configurando destino RFC

Um destino RFC é uma abstração de uma conexão. Um destino RFC possui um nome que é
utilizado para “esconder” o servidor destino. O desenvolvedor deve se preocupar apenas em
apontar um destino RFC existente, enquanto o próprio SAP fica responsável por redirecionar as
requisições apontadas para este destino ao servidor-alvo.

A configuração de um destino RFC é realizada na transação SM59. Esta tarefa é executada por
um profissional SAP Basis, porém, é importante que o desenvolvedor SAP Fiori saiba identificar
qual destino RFC deve utilizar.

No exemplo, o próprio servidor S/4HANA será utilizado como alvo. Logo, podemos utilizar o
destino RFC NONE, que representa o próprio servidor.

40
Caso seja necessária a configuração de um novo destino, deve-se acessar a transação SM59 e
selecionar o botão Criar.

Preencher o nome do destino, bem como o nome do host de destino.

Na área de segurança, é necessário minimamente a indicação do mandante destino, da

utilização do próprio usuário e da relação de confiança.

41
Obs.: novamente, ressalta-se que este passo não é comum de ser feito por um desenvolvedor
SAP Fiori, porém, é importante se entender do processo para que haja cooperação com a equipe
SAP Basis.

Configurando um alias de sistema

Para registrar um serviço, é necessário gerar um alias de sistema. Assim como o destino RFC, o
alias é um apelido que abstrai o sistema destino. Para visualizar e configurar os alias de sistema,
acesse a transação SPRO e selecione a opção SAP Reference IMG.

Então, expanda o caminho SAP NetWeaver > Gateway > OData Channel > Configuration >
Connection Settings > SAP NetWeaver Gateway to SAP System > Manage SAP System Aliases.

Os alias de sistema serão exibidos. No nosso caso, utilizaremos o próprio S/4HANA como sistema
alvo de consumo dos serviços. Logo, utilizaremos a entrada LOCAL para publicação dos
desenvolvimentos.

42
Caso necessário, seria possível gerar um novo alias de sistema, clicando no botão Criar.

Na sequência, deve se prover um nome, um destino RFC e outras configurações do sistema alvo.
Como padrão, utiliza-se o componente de software DEFAULT, porém, para serviços relacionados
ao workflow, o componente de software a ser apontado é o /IWPGW/BWF.

Obs.: assim como os destinos RFC, não é comum a configuração de um alias de sistema por um
desenvolvedor SAP Fiori, porém, é importante saber analisar qual alias de sistema será utilizado
para publicação.

SAP Gateway Service Builder

Ferramenta que auxilia na criação de um serviço oData, acessível pela transação SEGW. Ela não
tem influência direta no serviço oData que é executado. Ela automatiza a geração de código para
o serviço, provendo uma IDE para estruturar os metadados e aumentando a produtividade de
desenvolvimento. Uma série de artefatos é criada ao se gerar um projeto na transação SEGW,
como classes, configurações de entrada, descritores do serviço etc.

43
Criando um projeto
Para criar um projeto, basta selecionar o botão de criação.

Uma nova janela será demonstrada para preenchimento dos dados do projeto. É necessária a
entrada do nome, descrição, tipo de projeto, pacote e responsável.

Os tipos de projeto disponíveis são:

• Service with SAP Annotations: tipo padrão, gera annotations SAP para os modelos de
dados, como por exemplo, o campo associado na estrutura ABAP, o nome do tipo
utilizado e o rótulo para o campo;
• Service with Vocabulary-Based Annotations: permite a geração de annotations
baseadas nos em um repositório de vocabulário que armazena os casos mais
frequentes. É possível adicionar casos que não estão contidos entre os termos;
• Annotation Model for Referenced Service: quando necessário realizar annotations para
um serviço já existente, utilizar este tipo.
• oData V4 Service: para geração de um serviço na versão 4.0 do protocolo. Atenção à
compatibilidade com a aplicação destino.

Abrindo um projeto
Para abrir um projeto existente, basta utilizar o botão correspondente.

44
Uma caixa de diálogo será aberta para identificação do projeto. Pode-se utilizar a ajuda de
pesquisa para encontrar o projeto mais facilmente.

Estrutura de um projeto
Um projeto possui 3 áreas que são consideradas as mais importantes:

• Data model: modelagem de dados que serão utilizados no desenvolvimento. Aqui se

modelam entidades e seus relacionamentos.
o Entity types – tipos de entidade. São abstrações de dados;
o Associations – relações entre os tipos de entidade, definem uma navegação;
o Entity sets – conjuntos de entidades (como arrays de um tipo);
o Association sets – conjuntos de associações – semelhantes ao entity set.
• Service implementation: são as operações que serão realizadas no serviço. Por
padrão, cada entity set gerado possui um conjunto de operações pré-definidos que
podem ser implementados (CRUDQ).
• Runtime Artifacts: artefatos gerados pela transação após modelagem das entidades e
de suas relações.

45
Entre os artefatos mais importantes gerados, destacam-se as classes DPC (data provider class),
provedora de dados, e MPC (metadata provider class), provedora de metadados. Cada uma das
categorias é gerada em pares: uma finalizada em DPC e uma finalizada em DPC_EXT, bem como
uma MPC e uma MPC_EXT. As classes _EXT são heranças, logo, possuem todos os métodos das
classes mães. Elas são exclusivas para realizar modificações e implementar código ao serviço.
Nunca se deve modificar as classes sem o prefixo _EXT, pois elas serão excluídas e geradas
novamente sempre que for feita alguma alteração no Service Builder.

Criando um modelo de dados

Um modelo de dados define entidades e suas relações. Ele é a base para definir os tipos de dados
que o serviço disponibilizará para o consumo.

Para criar uma entidade, pode-se gerá-la manualmente ou com referência a uma estrutura, um
arquivo ou uma função pré-existentes.

Para geração manual, deve-se clicar sobre Entity Types e selecionar Create. Uma nova janela
será aberta para entrada do nome da entidade e para identificação do entity set, se desejável.

46
Ao prosseguir, a entidade será criada juntamente ao conjunto. O próximo passo é adicionar
propriedades.

Ao clicar em propriedades duas vezes, serão carregados todos os campos mapeados para aquela
entidade. Para adicionar ou remover propriedades, o conjunto de botões em destaque pode ser
utilizado. No exemplo, foram adicionadas duas entidades. Toda entidade deve obrigatoriamente
ter ao menos um campo chave. É necessário indicar no campo EDM Core Type (Entity Data
Model Core Type) um tipo válido.

47
A listagem demonstra os tipos disponíveis para uma propriedade.

Ao se visualizar o entity set, algumas propriedades podem ser habilitadas para ditar o
comportamento da entidade perante aplicações inteligentes, as quais se utilizam de smart
templates para montar a tela SAPUI5, sendo:

• Creatable: possibilidade de se criar uma instância da entidade;

• Updatable: possibilidade de se atualizar uma instância da entidade;
• Deletable: possibilidade de se excluir uma instância da entidade;
• Pageable: possibilidade de ser paginado;
• Addressable: possibilidade de ser endereçado;
• Searchable: possibilidade de ser buscado através do padrão $search;
• Subscribable: possibilidade de ser inscrito (modificações disparam eventos);
• Requires filter: necessidade da instrução $filter para seleção.

Para gerar uma entidade por referência, é necessário clicar com o botão direito sobre Data
Model e ir até a opção Import. Nela, estão disponíveis algumas possibilidades de importação
por referência, sendo a mais usual a estrutura DDIC, RFC e ajuda de pesquisa.

48
Para este exemplo, utilizaremos uma estrutura. Ao prosseguir, será requisitado o nome e a
estrutura ABAP de referência. Por padrão, a opção de criação do entity set já vem habilitada.

A estrutura é carregada para seleção dos campos que irão compor o modelo de dados. Neste
caso, é possível incluir também a ajuda de pesquisa para o campo. As informações técnicas são
apresentadas junto ao descritivo.

49
Ao seguir, os campos selecionados serão demonstrados para adaptação de nome e marcação
de chave.

Ao finalizar, a entidade é criada. Na listagem, é possível verificar o tipo relacionado que foi
indicado.

Nas propriedades da entidade, pode-se verificar que o próprio sistema mapeia

automaticamente o tipo, rótulo e campo de referência sem qualquer esforço adicional.

50
Gerando os artefatos de tempo de execução
Após a estruturação das entidades e suas relações, deve-se executar a geração dos artefatos de
tempo de execução. Para isso, no menu do projeto, deve-se selecionar o botão de geração.

Uma nova janela será demonstrada para identificação dos nomes das classes DPC e MPC e dos
detalhes do serviço. Por padrão, o Service Builder sugere a adição do prefixo Z em todos os
artefatos que serão gerados.

Obs.: Não se sugere a modificação destes parâmetros.

Um pacote será requisitado para prosseguir com a criação de todos os objetos. Caso seja
requisitado mais de uma vez, repita a atribuição do pacote até a finalização. Nunca atribua

51
artefatos de um mesmo projeto a pacotes distintos, isto pode gerar uma série de problemas de
transporte.

Finalizada a execução, é possível visualizar na área de runtime artifacts os objetos descritos nas
telas anteriores.

Implementando um serviço
Após a geração dos artefatos de tempo de execução, é possível realizar a implementação do
serviço.

Na seção Service Implementation, pode-se expandir o nó das entidades e clicar duas vezes sobre
uma das operações. Existem 5 operações pré-definidas para um conjunto de entidades. Elas são
padrão em um protocolo oData, sendo:

• Create: operação de criação de uma entidade. Deve ser fornecida a chave da entidade
juntamente aos demais dados;
• Delete: operação de exclusão de uma entidade. Deve ser fornecida a chave completa
para que a operação ocorra com sucesso;
• GetEntity: operação de busca de uma entidade por chave. Deve ser fornecida a chave
completa para a busca;
• GetEntitySet: operação de busca livre (query). Podem ser fornecidos parâmetros
adicionais para filtragem ($filter) e busca ($search);

52
 • Update: operação de atualização. Deve ser fornecida a chave completa para localização
da entidade e o conjunto de dados que deve ser atualizado. Não é possível modificar a
chave da entidade.

Quando existe uma necessidade que não se enquadra nas operações básicas, é possível gerar
function imports, funções que permitem estruturação de parâmetros, bem como o método
HTTP de utilização. Um exemplo de aplicação é a aprovação de um item de workflow.

Existem duas possibilidades de se realizar a implementação de uma operação: a primeira é

manual, enquanto a outra é realizada por mapeamento.

Para prosseguir com a implementação manual, deve-se primeiro identificar o nome do método
a ser implementado. Na listagem das operações para uma entidade, este nome é demonstrado
ao lado da classe provedora de dados sufixada em _EXT.

Uma vez identificados, clique o botão direito sobre a operação e selecione Go to ABAP
Workbench para navegar ao editor de classes (transação SE24). Caso o método ainda não
tenha sido implementado, uma mensagem será apresentada.

53
Em modo de edição, encontre o método e clique sobre ele. Na sequência, requisita a redefinição
do método. Desta forma, o método da classe DPC_EXT será reescrito, mantendo o método
original proveniente da classe DPC sem modificações.

No exemplo, recupera-se a chave Pernr e busca-se na tabela PA0001 todos os campos que estão
contidos na entidade. Para finalizar, deve-se ativar o método (Ctrl + F3 ou botão Ativar).

Retorne ao Service Builder. Para implementar um serviço a partir de mapeamento, deve-se clicar
o botão direito sobre a operação desejada e selecionar a opção Map to Data Source.

54
Uma nova janela será exibida para entrada dos valores do objeto a ser utilizado como base de
mapeamento. É possível a utilização de três tipos de objeto de dados, sendo business object e
RFCs (de sistema local ou remoto) e ajuda de pesquisa (apenas local).

No exemplo, utilizaremos a RFC BAPI_EMPLOYEE_GETDATA, capaz de buscar dados de um

colaborador a partir de sua matrícula.

Na sequência, o editor é aberto. É possível verificar no lado direito a estrutura da RFC que está
a ser consumida. Na área central, apresentam-se as propriedades da entidade que está sendo
mapeada. O botão Propose Mapping tenta realizar um mapeamento automático a partir de
nome e tipo. Ele pode economizar tempo caso os mapeamentos sejam bastante semelhantes.

55
Com o mapeamento realizado, deve-se gerar novamente os artefatos de tempo de execução
(Generate Runtime Objects) pois o código para execução da RFC é criado diretamente na classe
DPC.

Ao visitar a classe através da transação SE24 ou navegando diretamente pelo Service Builder,
podemos encontrar no método o código gerado automaticamente pela ferramenta.

É criada uma chamada à RFC e, ao final, existe o mapeamento do retorno do módulo de função.

56
Detalhes das operações
Cada operação em uma classe DPC possui parâmetros específicos de entrada e saída que dão
flexibilidade ao desenvolvimento. Listam-se abaixo os destaques para a correta implementação
dos métodos manualmente.

• GetEntity
o IV_ENTITY_NAME: nome da entidade;
o IV_ENTITY_NAME_SET: nome do conjunto de entidades;
o IT_KEY_TAB: relação de campos-chave da entidade, no formato chave-valor;
o ER_ENTITY: instância do objeto que será retornado, no tipo de entidade
especificado no serviço.

• GetEntitySet
o IT_FILTER_SELECT_OPTIONS: conjunto de linhas que traz o ID do filtro e um
range no formato ABAP;
o IV_FILTER_STRING: mesma informação que a anterior, porém no formato
string;
o IS_PAGING: fornece dados para efetuar paginação no serviço, sendo:
▪ TOP: número requisitado de registros;
▪ SKIP: quantidade de registros a serem descartados antes de iniciar a
seleção do TOP;
o IT_ORDER: ordenação requisitada das propriedades (ascendente ou
descendente);
o IV_SEARCH_STRING: string para busca em todos os campos aplicáveis (texto
livre);
o IO_TECH_REQUEST_CONTEXT: referência ao contexto técnico, apresenta
informações complementares da requisição;

57
 o ET_ENTITYSET: tabela com as entidades relacionadas que atenderam aos
parâmetros da busca.

• CreateEntity
o IO_DATA_PROVIDER: fornece os valores da requisição. Deve-se utilizar o
método READ_ENTRY_DATA para mapeá-los para uma estrutura ABAP;
o ER_ENTITY: entidade criada a partir do método.

• UpdateEntity
o IO_DATA_PROVIDER: fornece os valores da requisição. Deve-se utilizar o
método READ_ENTRY_DATA para mapeá-los para uma estrutura ABAP;
o ER_ENTITY: entidade atualizada a partir do método.

• DeleteEntity
o IV_ENTITY_NAME: nome da entidade;
o IV_ENTITY_NAME_SET: nome do conjunto de entidades;
o IT_KEY_TAB: relação de campos-chave da entidade, no formato chave-valor.

Manutenção de serviços
A manutenção de serviços publicados no SAP Gateway é realizada a partir da transação
/IWFND/MAINT_SERVICE. Nela, é possível realizar a manutenção dos serviços entregues pela
SAP e os desenvolvidos pelo cliente.

A listagem demonstra os serviços já registrados.

Ao selecionar um serviço, na área inferior esquerda, é demonstrado o estado do nó no ICF. O

ICF é uma árvore que demonstra a hierarquia de serviços, acessível pela transação SICF.

58
No lado direito da área inferior, é demonstrado o alias de sistema no qual o serviço foi
registrado. É possível adicionar mais de um alias ou remover um existente. Existe também a
possibilidade de navegar para os detalhes da implementação do serviço, através do botão
Service Implementation.

Na área superior, existem dois botões para adicionar ou remover os serviços.

Quando desejável uma adição, é necessário especificar o alias de sistema que terá o catálogo
consumido. É possível também prover o nome do serviço para realizar o filtro. A listagem
apresenta todos os serviços sob aquele alias que ainda não foram filtrados. Para adicionar um
serviço, selecione um entre os listados, clique em Add Selected Services, forneça um prefixo
(geralmente Z) e um pacote para transporte da solução.

59
SAP Gateway Client
O SAP Gateway Client é uma ferramenta para teste de serviços RESTful. Ao desenvolver um
serviço através do Service Builder ou ao ativar um serviço standard, é imprescindível a realização
do primeiro teste através do Gateway Client antes de integrá-lo a uma interface de usuário, pois
ele é executado diretamente no servidor que provê o serviço.

Ele é acessível através da transação /IWFND/GW_CLIENT.

Obs.: muitos desenvolvedores utilizam ferramentas externas para realizar testes nos serviços,
como o Postman ou o SOAPUI.

Testando serviços
Todas as operações de um serviço oData podem ser simuladas a partir do Gateway Client,
através da transação /IWFND/GW_CLIENT. Trata-se de uma ferramenta para execução de
chamadas RESTful.

Inicialmente, deve-se indicar o caminho relativo que se deseja acessar. Os serviços gerados pelo
Service Builder estão localizados sob o nó “/sap/opu/odata/sap/”.

O teste básico a ser feito para verificar o comportamento de um serviço oData é a requisição de
seus metadados. Isto é feito a partir da entrada da URI, com a adição de $metadata ao final do
endereço (e.g. /sap/opu/odata/sap/API_BILLING_DOCUMENT_REQUEST_SRV/$metadata). O
método a ser utilizado é o GET. O código de retorno 200 indica o sucesso na operação, e os
metadados são carregados na área inferior direita.

60
Para a busca de uma entidade por chave, deve-se fornecer a URI no formato
“/sap/opu/odata/sap/<nome do projeto>/<nome do conjunto>(<chave 1>, [<chave 2>, …])”
com o método GET. Por exemplo, consumindo o serviço ZPROJECT_SRV e entidade Person com
chave “00000001”, temos a composição
/sap/opu/odata/sap/ZPROJECT_SERV/PersonSet(‘00000001’). Caso a entidade possua mais de
uma chave, elas devem ser separadas por vírgula e apresentadas na sequência.

Para busca de uma ou mais entidades por query, deve-se fornecer a URI no formato
“/sap/opu/odata/sap/<nome do projeto>/<nome do conjunto>[?<adições>]” com método
GET. No mesmo exemplo, se queremos todas as pessoas que trabalham na empresa “G001”,
temos a composição /sap/opu/odata/sap/ZPROJECT_SERV/PersonSet?$filter=Bukrs eq ‘G001’.
Algumas das adições mais utilizadas são:

• $filter – filtra informações por propriedade;

• $orderby – ordena de acordo com colunas indicadas;
• $top e $skip – seleciona os primeiros valores e pula os primeiros valores,
respectivamente;
• $count – conta resultados;
• $expand – expande conjuntos subordinados;
• $select – seleciona campos de retorno;
• $search – busca por string livre.

Para utilizar as adições, deve-se certificar que a implementação da operação suporta ou prevê
a adição no código.

Para criar uma entidade, é necessário informar, na URI, qual a entidade destino, seguindo o
padrão “/sap/opu/odata/sap/<nome do projeto>/<nome do conjunto>(<chave 1>, [<chave 2>,
…])” com método POST. No corpo da requisição, na parte inferior à esquerda, deve-se colocar
os detalhes da entidade que será criada nos formatos XML, ATOM ou JSON. Logo, baseado nos
exemplos anteriores, se existe o desejo de criar a pessoa de código “00000002”, deve-se utilizar

61
a URI /sap/opu/odata/sap/ZPROJECT_SERV/PersonSet(‘00000002’) com os detalhes para os
demais campos no corpo da requisição.

De maneira similar à criação, para atualizar uma entidade, é necessário informar, na URI, qual a
entidade destino, seguindo o padrão “/sap/opu/odata/sap/<nome do projeto>/<nome do
conjunto>(<chave 1>, [<chave 2>, …])” com método PUT. No corpo da requisição, na parte
inferior à esquerda, deve-se colocar os detalhes da entidade a ser atualizada nos formatos XML,
ATOM ou JSON. Com isso, para atualizar a pessoa de código “00000002”, deve-se utilizar a URI
/sap/opu/odata/sap/ZPROJECT_SERV/PersonSet(‘00000002’) com os detalhes para os demais
campos no corpo da requisição.

Por fim, a última das operações, a exclusão, utiliza o padrão de URI “/sap/opu/odata/sap/<nome
do projeto>/<nome do conjunto>(<chave 1>, [<chave 2>, …])” com método DELETE. Nenhum
outro complemento é necessário. Ainda utilizando o exemplo anterior, para excluir da base a
pessoa com matrícula ‘00000002’, deve-se utilizar a URI
/sap/opu/odata/sap/ZPROJECT_SERV/PersonSet(‘00000002’).

Exercícios
1. O que é o SAP Gateway e quais são suas vantagens?
2. O que é o protocolo OData?
3. Qual é a facilidade trazida pelo SAP Gateway Service Builder?
4. Quais são as 5 operações básicas que podem ser executadas em uma entidade do
protocolo OData?
5. Qual a função de um alias de sistema?
6. Você foi recrutado para um projeto de implementação do S/4HANA e deve criar uma
aplicação SAP Fiori para manutenção dos parceiros de negócios do cliente.
Os business partners substituem a estrutura clássica do SAP, centralizando clientes e
fornecedores em um número e permitindo a criação de papéis.
Por possuir mais experiência no desenvolvimento ABAP, o gerente de projetos te deixa
encarregado da criação dos serviços no SAP Gateway, enquanto um colega fica
responsável pela criação da camada SAPUI5.

Os requisitos apresentados são:

o O serviço deve disponibilizar a leitura individual e em lista de parceiros de
negócios. A leitura individual será realizada pela chave do parceiro. A leitura em
lista permitirá os seguintes parâmetros de filtragem:
▪ ID do parceiro;
▪ Nome do parceiro;
▪ Termo de pesquisa 1 e 2;
▪ Cidade;

A entidade BusinessPartner deve conter as seguintes propriedades, passíveis de

exibição e modificação:

▪ ID do parceiro;
▪ Nome do parceiro (organização ou pessoa);

62
 ▪ Tipo do parceiro;
▪ Termo de pesquisa 1;
▪ Termo de pesquisa 2;
▪ Logradouro;
▪ Número;
▪ Bairro;
▪ Cidade;
▪ Estado;
▪ CEP;
▪ País;
▪ Idioma.

O serviço também deve permitir a ordenação por todas as propriedades

estruturadas na entidade de retorno.

o O serviço deve permitir a criação e atualização de um parceiro de negócios.

o A exclusão de um parceiro de negócios não deve ser permitida.
É desejável a exibição e manutenção de organizações e pessoas.

Após investigação, você descobriu que:

o Para buscar parceiros de negócios, você pode utilizar o módulo de função
BUPA_SEARCH (para buscar todos, passar * no ID do parceiro);
o Para ler um parceiro, você pode utilizar os módulos de função
BAPI_BUPA_CENTRAL_GETDETAIL e BAPI_BUPA_ADDRESS_GETDETAIL com
base no parceiro selecionado;
o Para criar um parceiro, utilize a BAPI BAPI_BUPA_CREATE_FROM_DATA.

Com base nos dados acima, estruture o serviço OData na SEGW. Utilize como padrão o
nome do projeto ZBP_XX, onde XX é o número do aluno. O pacote a ser utilizado é o
ZFIORI_002. Os parceiros devem ser criados no agrupamento TCAG (PARTNERGROUP).
Gere uma estrutura DDIC para a modelagem dos dados.

Cloud computing
Conceito de computação onde serviços, recursos e soluções completas são entregues a partir
da Internet, sem que o utilizador saiba onde estão hospedados os componentes físicos.

A computação em nuvem tem como características:

63
 • Custo benefício: redução geral do custo com hardware, como servidores, banco de
dados e rede. Redução também do custo de pessoal e de manutenção, no geral. Ao
adotar a computação em nuvem, troca-se o custo de CapEx para OpEx;
• Flexibilidade: existe elasticidade de recursos, podendo ser dimensionados para o
cenário atual, em primeira instância, e aumentados de acordo com a necessidade do
negócio;
• Confiabilidade: a maioria dos provedores de serviços na nuvem tem downtime
insignificante;
• Segurança: os provedores também entregam segurança que pequenos negócios teriam
dificuldade em implementar para soluções próprias.

Existem três modelos básicos de comercialização, que englobam níveis de abstração. O

pagamento é realizado de maneira periódica ou por quota, sendo:

• IaaS: Infrastructure As A Service, nível de abstração mais alto, onde a infraestrutura

(virtualização de recursos de armazenamento, servidores e outros tipos de hardware) é
provida através de um serviço em nuvem. Entre os serviços mais comum, estão os
provedores como o Microsoft Azure, o Google Cloud e o AWS;
• PaaS: Platform As A Service, nível de abstração intermediário, onde não só a
infraestrutura é provida, como também recursos para aceleração do processo de
desenvolvimento. Aqui, podem ser disponibilizados bancos de dados, serviços para
conectividade e segurança, frameworks de desenvolvimento etc. O SAP Cloud Platform
se enquadra nesta categoria;
• SaaS: Software As A Service, nível de abstração mais baixo, provavelmente o mais
comum dos modelos ao consumidor final, onde um software é totalmente entregue em
formato de serviço. Neste caso, a plataforma já é englobada, não havendo necessidade
de hardware. Nesta categoria, entram softwares robustos como o SAP SuccessFactors e
SAP Ariba, até os pioneiros webmails.

64
Ferramentas para desenvolvimento
A maioria das ferramentas de desenvolvimento de aplicações SAP Fiori são baseadas em
landscapes da nuvem.

Para desenvolvimento de protótipos, existe o SAP BUILD, ferramenta disponível na nuvem e que
produz exclusivamente mockups de aplicações SAP Fiori, simulando navegação e algumas ações.
Ela pode ser avaliada sem custo, possuindo apenas limitação de projetos.

Para desenvolvimento de aplicações, duas são as abordagens:

• A primeira e mais antiga é a utilização da IDE do Eclipse. Apesar de ser possível, ela não
é mais encorajada, uma vez que as ferramentas de desenvolvimento disponíveis são
mais limitadas.
• A segunda é a utilização do SAP Web IDE, disponível na nuvem, um framework completo
com vários templates e ferramentas que agilizam o desenvolvimento. Existente em
versão trial e produtiva.

Obs.: A versão em nuvem na versão trial será utilizada como padrão para este curso.

A lógica de negócio é extraída de um servidor on-premise, geralmente um SAP ERP. Este é

responsável por gerar e expor serviços em protocolo oData utilizando a linguagem ABAP ou
HANA XS.

Para a conexão entre o SAP Web IDE e os servidores on-premise, existem algumas abordagens
possíveis. As mais comuns são a exposição através de um web dispatcher, funcionando como
proxy reverso, ou a utilização de um Cloud Connector, servidor lightweight SAP que gera uma
conexão segura entre os serviços disponíveis na nuvem e os sistemas on-premise.

SAP BUILD
Um dos maiores problemas no desenvolvimento de software é o direcionamento da expectativa
dos stakeholders. Em um processo padrão de projeto, o usuário só tem acesso ao produto em
fases finais, muitas vezes gerando frustração e retrabalho.

65
Um bom processo de criação de um aplicativo SAP Fiori deve contemplar, em algum momento,
a geração de um protótipo. O protótipo tem o objeto de antecipar entregas, fazendo com que o
usuário final possa experimentar alguns comportamentos e navegações que estariam
disponíveis apenas após algum esforço. Dessa forma, os desenvolvedores podem coletar
feedbacks antes de chegarem ao final do ciclo de desenvolvimento do produto, realizar
adaptações e gerar um novo ciclo de coletas com o protótipo.

Existem alguns stencils (https://experience.sap.com/fiori-design-web/downloads/) para

softwares como o Axure RP e mesmo o Microsoft Power Point, visando a geração de protótipos,
porém, nenhum deles é tão completo e interativo quanto o SAP BUILD.

O SAP BUILD (disponível em https://build.me) é uma ferramenta web colaborativa destinada ao

design e prototipação de novas aplicações SAP Fiori. A equipe de desenvolvimento pode
trabalhar de maneira conjunta no protótipo. Os usuários também podem ser adicionados para
experimentar as propostas e gerar comentários sobre elas.

O SAP BUILD possui versão gratuita limitada a 3 projetos ativos.

Ao final do desenvolvimento de um protótipo, é possível conectar a conta do SAP BUILD ao Web

IDE e convertê-la para uma versão SAP Fiori, preservando navegação e ações. Todo o código é
gerado dinamicamente.

SAP Cloud Platform

O SAP Cloud Platform (antigo HANA Cloud Platform) é uma plataforma na nuvem disponibilizada
como serviço (PaaS).

O SAP Cloud Platform se divide em dois modelos, Neo e Cloud Foundry.

O primeiro e mais antigo possui os serviços já consolidados. Nele, são feitas as configurações de
conectividade. Este modelo permite a publicação de programas Java e JavaScript. Entre os
serviços pioneiros, estão a versão SAP HANA na nuvem, o Portal Fiori na nuvem e uma primeira
versão de IoT disponibilizada pela SAP.

O segundo, Cloud Foundry, é o modelo de plataforma com maior investimento. Baseado em um

hyperscale (AWS, Google Cloud ou MS Azure), este modelo permite rodar qualquer tipo de

66
linguagem (BYOL, ou Bring Your Own Language) a partir de buildpacks. Além disso, possui uma
série de microsserviços para IoT, inteligência artificial, bancos de dados na nuvem etc.

O SCP é a plataforma oficial na qual desenvolvimentos SAP Fiori são realizados. No âmbito do
SAP Fiori, entre os serviços essenciais providos por ela, estão disponíveis a conectividade com
os servidores on-premise, bem como o framework padrão para desenvolvimento, o SAP Web
IDE.

Criando uma conta trial

É possível criar uma conta de avaliação para acessar os serviços disponíveis no SAP SCP e verificar
suas funcionalidades. Para este curso, utilizaremos um dos serviços disponíveis nas plataformas
Neo e Cloud Foundry, o SAP Web IDE.

1. Inicialmente, para se criar uma conta, deve-se acessar o site da SAP através do site
https://www.sap.com e clicar no botão de Log On.

2. Caso você já possua uma conta, realize o log on ao lado direito. Caso contrário, preencha
os dados do formulário junto a um telefone e senha.

67
3. Uma mensagem será encaminhada ao e-mail cadastrado para ativação. Verifique sua
conta de e-mail e clique no botão para finalizar a sua conta. Uma mensagem será exibida
indicando a finalização correta da ativação.

4. Acesse o site https://account.hanatrial.ondemand.com/ e realize o log on com a sua

conta e senha.

68
5. Leia e aceite os termos de utilização para prosseguir.

6. Verifique o número de telefone informado.

69
 Insira o código recebido em seu telefone celular para finalizar a validação.

SAP Web IDE

O SAP Web IDE é uma ferramenta baseada na nuvem que simplifica o processo de
desenvolvimento end-to-end de aplicações Fiori e full-stack.

Com ele, é possível desenvolver diversos artefatos que compõem estes tipos de aplicação, como
interface de usuário, lógica de negócios e artefatos do banco de dados. O SAP Web IDE permite
criar, estender, depurar, testar e implementar aplicações de maneira simplificada.

O editor gráfico para criação de interfaces de usuário facilita a visualização já em tempo de

desenvolvimento. Os templates pré-definidos geram uma série de artefatos automaticamente,
os quais eram desenvolvidos do zero em IDEs anteriores (Eclipse). É possível simular múltiplos
dispositivos a partir de suas ferramentas de teste, permitindo o teste de responsividade antes
da chegada ao dispositivo do usuário final. Também permite a geração de dados falsos
simulando a estrutura de serviços que o sistema trabalhará. Esta característica permite que o
desenvolvedor atue sem ter efetivamente acesso ao sistema provedor de dados. Por fim,
permite o compartilhamento da solução com a equipe a partir da integração com o Git.

70
Acessando o Web IDE
Para acessar o SAP Web IDE, acesse o SAP Cloud Platform Cockpit
(https://cockpit.hanatrial.ondemand.com/) com usuário e senha de sua conta trial. Na área de
ferramentas rápidas, é possível acessá-lo ao clicar no link relacionado.

Também é possível acessá-lo nos ambientes Cloud Foundry e Neo. Ainda no SCP Cockpit, procure
pela área de ambientes (environments) e selecione o acesso ao Neo Trial. Recomenda-se a
utilização do ambiente Neo pois ele não possui limitação de utilização em tempo, ao contrário
do Cloud Foundry, o qual fica ativo por 30 dias, podendo ser renovado por mais 30 dias.

71
No cockpit do Neo Trial, procure pela opção Services.

Na área de pesquisa, busque por “Web IDE”. Os serviços disponíveis serão filtrados. Clique no
serviço SAP Web IDE Full-Stack.

Verifique se o serviço está ativo (caso não esteja, clique no botão Enable e aguarde até que a
ativação seja concluída) e clique em Go to Service.

72
O SAP Web IDE passará a ser carregado. Aguarde na tela até que o processo seja finalizado.
Depois de carregado, o Web IDE demonstrará a página inicial com sugestões para leitura e para
iniciar a trabalhar.

73
Ao lado esquerdo, existem opções de área de trabalho. O espaço Development apresenta os
projetos que foram criados no workspace corrente.

O Database Explorer permite acessar artefatos do banco de dados SAP HANA. Para utilizá-lo, é
necessário ter o ambiente Cloud Foundry habilitado.

No Storyboard, é possível navegar de maneira gráfica entre as visões de um projeto. Esta visão
também permite criar essas navegações a partir de uma ferramenta low coding.

74
A última opção na barra lateral é a área de preferências. Nela, é possível modificar preferências
do editor, verificação de sintaxe, configurações do Git, preferências do Cloud Foundry e
habilitação de extensões.

Na área superior, está disponível o menu com opções para criação de novos projetos, edição de
dados do editor, compilação, implementação e execução da aplicação, busca, alternância entre
visões e ferramentas. No canto direito, é possível alternar entre workspaces e realizar o logout
da conta.

Logo abaixo do menu, existem opções para salvar o arquivo ou os arquivos que estão em edição,
bem como um botão para executar a aplicação e outros dois para navegação entre os pontos
visitados.

Do lado direito, quando selecionada a visão de desenvolvimento, estão disponíveis algumas

ferramentas. Dentre as mais importantes, estão o Git para controle de versão, o histórico do Git
para verificação das alterações, o debug e o console.

75
Quando na perspectiva de desenvolvimento, a área central carrega os detalhes de um projeto
ou mais projetos. Por padrão, a área central apresenta o código de um ou mais arquivos que
estão sendo modificados (Code Editor). A linguagem de cada arquivo é automaticamente
reconhecida, gerando highlights em palavras-chave.

Para visões XML, é possível utilizar também um editor gráfico WYSIWYG, ou what you see is
what you get. Ele permite a transformação do código XML para uma versão final da tela,
inclusive adaptando ao tamanho do dispositivo. Para abrir este modo, deve-se clicar o botão
direito sobre uma visão e clicar em Open Layout Editor.

76
Esta visão mais amigável é muito útil para profissionais de design e prototipação que não detêm,
necessariamente, o conhecimento de programação. A ferramenta de drag-n-drop auxilia na
inserção dos componentes na visão.

Obs.: nem todos os componentes SAPUI5 são corretamente renderizados nessa visão de
desenvolvimento. Quando existe complexidade no desenvolvimento ou dinamismo, recomenda-
se a utilização do code editor, pois o resultado não será corretamente demonstrado na tela.

Criando um projeto
O Web IDE permite atuar em vários momentos de um ciclo de vida de uma aplicação SAP Fiori,
da prototipação ao desenvolvimento, em diversos casos de uso, como criação, extensão

77
• Projetos a partir de um modelo: templates são apresentados para seleção. Estes
modelos representam os tipos de aplicação SAPUI5 mais comuns. Um wizard é
apresentado para atribuição dos dados básicos, conexão com serviço e geração dos
primeiros artefatos.

• Projetos a partir de aplicação exemplo: existem aplicações que são disponibilizadas

como exemplo para desenvolvimento de outras aplicações. Elas servem como exemplo
para experimentar a navegação e os comportamentos de uma aplicação SAP Fiori
profissional.

78
• Projetos de extensão: extensão de aplicações existentes. Aplicações publicadas pela
SAP possuem pontos de extensão pré-definidos. Este tipo de projeto não pode ser
utilizado em smart templates. Neste caso, deve-se utilizar um projeto de adaptação.

O painel de extensão auxilia na identificação de elementos extensíveis e na geração de

código de extensão.

79
• Projeto de adaptação: um projeto de adaptação permite gerar variantes de uma
aplicação SAPUI5. Nem todas as aplicações são elegíveis a este tipo de adaptação.
Umas das premissas é a utilização de smart templates (Fiori Elements).

As alterações são realizadas a partir do editor visual.

O modo seguro deve ser utilizado sempre que possível, para garantir que não haja
incompatibilidades em caso de atualizações. Ao desligá-lo, existe uma maior
possibilidade de modificações, porém, não são garantidas e precisam ser revisitadas

80
 após a atualização.

Importando projetos
O SAP Web IDE permite a importação de projetos e aplicações. Entre as opções, é possível:

• Arquivo ou projeto: importação de um arquivo para um projeto aberto ou de um

projeto completo, anteriormente exportado com a ferramenta do próprio SAP Web IDE;
• Aplicação SAPUI5 de repositório ABAP: importação de uma aplicação completa de um
repositório ABAP. Neste caso, a aplicação é carregada com algumas distorções do
projeto. Não é recomendada, deve-se buscar o código em algum software de
versionamento inicialmente, como o Git;
• Aplicação do SAP Cloud Platform: o SCP também permite ser o host de aplicações
SAPUI5 e Java. Uma aplicação SAPUI5 pode ser importada deste repositório. Assim como
a opção anterior, não se recomenda a importação.

81
Também é possível realizar o clone de um projeto compartilhado pelo Git. Para isso, deve-se
clicar com o botão direito sobre o workspace, selecionar Git > Clone Repository. Com esta
opção, uma equipe pode trabalhar simultaneamente no mesmo projeto, sem risco de
divergência no código.

Deve-se introduzir a URL referente ao projeto. O SCP possui um repositório Git para controle de
versões, porém, qualquer repositório Git pode ser utilizado. Caso a empresa possua um
repositório Git em um servidor dedicado ou em formato de serviço na nuvem, como o GitHub,
este pode ser apontado.

Implantando um projeto
A implantação de um projeto também é feita a partir do SAP Web IDE. Uma vez que o projeto
foi finalizado, as seguintes opções de implantação podem ser selecionadas:

82
• Implantação em repositório SAPUI5 ABAP: esta opção realiza a criação de artefatos em
um sistema on-premise Business Suite ou S/4HANA. Deve-se indicar o destino que será
utilizado para a implantação.

Obs.: sempre tome atenção à versão utilizada no projeto e a versão que o sistema
destino implementa. Elas devem ser compatíveis, caso contrário, funcionalidades podem
não estar disponíveis.

Selecione um nome para a aplicação, uma descrição e o pacote. O nome escolhido deve
estar no dentro do namespace de cliente.

Selecione a ordem na qual o projeto será transportado. Também é possível gerar ordens
de transporte.

83
O processo de implantação pode ser acompanhado pelo console. Primeiro, é realizado
o processo de montagem do arquivo, uma versão compactada que tem melhor
performance na execução.

Depois, ao iniciar o processo efetivo de implantação, cada um dos artefatos é

apresentado.

O processo é finalizado com a atualização do buffer de aplicações e a indicação de

sucesso na implantação.

84
 Após a finalização do processo de deploy, a aplicação estará disponível no repositório
alvo. É possível visualizá-la através da transação SE80, em aplicações BSP.

• Implantação no SAP Cloud Platform: esta opção permite que a aplicação fique
hospedada no SAP Cloud Platform. Esta abordagem é bastante utilizada para extensão
de aplicações em produtos de nuvem da SAP, como o SAP SuccessFactors.
Quando requisitado este tipo de implantação, deve-se informar qual será o nome da
aplicação no repositório do SCP e a versão. Também é possível apontar para outras
subaccounts e realizar o deploy.

85
 Quando finalizada a implantação, a aplicação pode ser também registrada no SAP FLP
em versão nuvem (Portal).

As aplicações que estão registradas no SAP SCP podem ser visualizadas na área de
aplicações HTML5, no ambiente Neo.

• Registro no SAP FLP: registro da aplicação para disponibilização no Portal SAP Fiori
hospedado na nuvem. Quando selecionada esta opção, deve-se indicar um nome único
e uma intenção (objeto semântico + ação) para o objeto que será criado.

Então, deve-se realizar a configuração de como a aplicação será apresentada (tile),

adicionando título, descrição e ícone, se aplicável.

86
 Por fim, deve-se inserir dados sobre a disponibilização desta aplicação, ou seja, em qual
catálogo e grupo ela será disponibilizada.

Conectividade
Para que o SAP Web IDE possa consumir dados de um servidor remoto, é necessária a
configuração dos destinos na área de conectividade.

Um destino abstrai um servidor remoto, de maneira que o desenvolvedor não precisa saber
exatamente qual é o endereço que está sendo acessado. Uma vez indicado o destino, o SAP SCP
realiza a transformação quando as requisições ocorrem. Esta abordagem tem por vantagem a
migração da solução entre sistemas, sem a necessidade de gerar chaveamentos para alternar
entre sistemas de desenvolvimento e sistemas produtivos.

No ambiente Neo, acesse a área Destinations.

87
Selecione New Destination.

Preencha os dados como proposto abaixo:

• Nome: Trainning
• Tipo: HTTP
• Descrição: Trainning S/4HANA
• URL: http://191.209.21.17:9222
• Tipo de proxy: Internet
• Autenticação: BasicAuthentication
• Usuário e senha para acesso ao ambiente.

88
Obs.: caso o servidor seja on-premise e exposto a partir de um Cloud Connector (passo a passo
disponível nas próximas seções, deve-se indicar o tipo de proxy como OnPremise). O tipo Internet
deve ser utilizado quando o servidor está exposto diretamente ou através de um web dispatcher.

Adicionalmente, crie 4 novas propriedades com o botão New Property.

• sap-client: 400
• WebIDEEnabled: true
• WebIDESystem: S4H
• WebIDEUsage: dev_abap,odata_abap,ui5_execute_abap,bsp_execute_abap

Abaixo estão descritas as funções de cada adição de utilização:

• odata_abap: conexão com serviços OData a partir de um SAP Gateway;

• odata_gen: OData genérico;
• ui5_execute_abap: execução de aplicações SAPUI5 disponíveis em um SAP Gateway;
• dev_abap: acesso aos cenários de extensão e implantação em um repositório ABAP;
• bsp_execute_abap: para trabalhar com aplicações de ficha informativa;
• odata_xs: para serviços do HANA XS.

Realize o teste de conexão para confirmar se houve sucesso no cadastro. Se sim, uma mensagem
de conexão estabelecida será apresentada.

89
Obs.: um erro 400 pode ser apresentado, porém, ele não é indicador de que não houve sucesso
na tentativa de conexão.

Para que haja conexão com sucesso, tenha certeza que, no SAP Gateway, os nós abaixo devem
estar ativos na transação SICF:

• /sap/opu/odata – exposição de serviços OData

• /sap/bc/adt - importação de aplicações e extensões SAPUI5 para o Web IDE
• /sap/bc/ui5_ui5 - execução de aplicações publicadas
• /sap/bc/bsp e /sap/bc/ui2 - para aplicações Fact Sheet
• /sap/hba - para conexão ao servidor SAP HANA

SAP Cloud Connector

O SAP Cloud Connector é um servidor SAP lightweight que realiza a exposição de servidores on-
premise, isto é, instalações de software realizadas em servidores físicos localizados no cliente
(como um SAP ERP, por exemplo) para os serviços SAP disponíveis na nuvem (SAP Cloud
Platform).

O SAP Cloud Connector é um importante componente neste landscape híbrido de

desenvolvimento, sendo a peça-chave para conexão entre qualquer produto SAP disponível na
nuvem com as instalações on-premise.

Ele permite a configuração de uma ou mais contas do SAP Cloud Platform e descreve como será
a exposição dos serviços disponíveis nos servidores. Ele trabalha dentro da linha de firewall e
não precisa estar exposto na DMZ (zona desmilitarizada), como os web dispatchers tradicionais,
gerando um túnel seguro entre o serviço web e o servidor através de uma conexão proprietária
SAP.

Instalação
Para instalar o SAP Cloud Connector, são necessários os seguintes passos:

1. Instalação do JDK for Java SE 8 (disponível em

http://www.oracle.com/technetwork/java/javase/downloads/index.html);

2. Instalação e configuração da SAP JVM (disponível em

https://tools.hana.ondemand.com/#cloud). Buscar a versão compatível com o sistema
operacional utilizado;

90
3. Instalação do SAP Cloud Connector (disponíveis em
https://tools.hana.ondemand.com/#cloud). Buscar a versão compatível com o sistema
operacional utilizado;

Obs.: existe a versão portable que não exige instalação, porém, não é recomendada.

Ao iniciar a instalação, um wizard será demonstrado com os detalhes.

O endereço de instalação será requisitado na sequência.

Insira a porta na qual o servidor ficará disponível. A porta padrão sugerida é a 8443.

91
Indique, no próximo passo, o local de instalação da SAP JVM.

O último passo pergunta se você já quer inicializar o serviço do Cloud Connector assim
que a instalação for finalizada. Selecione o checkbox e prossiga.

92
4. Realizar o acesso ao Cloud Connector. Ele estará disponível a partir do endereço
https://localhost:8443 (ou na porta sugerida na instalação). Inicialmente, o servidor
assinará o certificado SSL necessário para uma conexão HTTPS, sendo seu emissor. Nos
navegadores mais modernos, este é um erro de segurança (self-signed). Caso o
navegador bloqueie a entrada, selecione a opção Avançado e prossiga com a conexão.

93
 5. Entrar com usuário e senha. A senha padrão para primeiro acesso é:
Usuário: Administrator
Senha: manage
Será requisitada a mudança de senha do usuário Administrator assim que realizado o
login. Guarde bem esta senha.

Para mais detalhes de instalação e configurações do certificado do SAP Cloud Connector, acesse
https://developers.sap.com/tutorials/cp-connectivity-install-cloud-connector.html.

Configuração
Uma vez instalado, o Cloud Connector estará pronto para ser configurado e permitir a exposição
dos servidores on-premise para os serviços da nuvem.

Para isso, os seguintes passos devem ser seguidos:

1. Ao iniciar o Cloud Connector, selecionar a adição de uma nova conta (Add Subaccount);

Na nova janela, preencher os dados para acesso à conta do SAP Cloud Platform.

94
o Região: local onde está hospedada a conta. Em cenários produtivos, pode estar
distribuído em qualquer datacenter do mundo. No caso da versão trial, sempre
estará hospedado na Europa (Europe (Rot) – Trial).
o Conta: a conta, em cenários produtivos, é uma combinação de números e letras,
podendo ser vista na área de administração. Para a versão trial, consiste no P-
User seguido do texto “trial” (exemplo: P-User P1417865058, conta
p1417865058trial);
o Usuário: P-User resultante do cadastro do SAP Cloud Platform;
o Senha: senha do P-User do SAP Cloud Platform.

95
 Obs.: caso não saiba seu P-User, é possível buscá-lo no cockpit do SAP Cloud Platform
(acessível em https://account.hanatrial.ondemand.com/cockpit/) no canto superior
direito, ao clicar no nome do usuário e selecionar User Information.

Após armazenar, se os dados estiverem corretos, uma conexão com a conta será criada.
Ela estará indicada em amarelo, pois nenhum servidor on-premise foi exposto.

2. Cadastrar os servidores. Para isso, selecionar a opção Cloud To On-Premise.

Em seguida, selecionar o botão de adição.

Uma nova janela será aberta para seleção do tipo de servidor que será conectado. Todos
os produtos SAP on-premise mais comuns são demonstrados. É possível selecionar
também produtos não-SAP. Para este exemplo, seguiremos com a configuração de um
sistema ABAP provedor de serviços oData.

96
Na sequência, será requisitado o protocolo de conexão que será utilizado. Seguiremos
com o protocolo HTTP.

Então, deve-se indicar o mapeamento interno. Preencher com nome do servidor e porta
para acesso ao protocolo indicado no passo anterior. Neste exemplo, utilizaremos o
servidor s4hana.ides.com na porta 9222.

Segue-se com o preenchimento do mapeamento virtual. Não existe obrigatoriedade de

indicar valores diferentes do mapeamento interno, porém, é uma boa prática para
esconder o endereço do servidor interno realizar uma troca. Este nome virtual será
utilizado nas configurações do SAP Cloud Platform. Indicamos o nome s4hana apenas
para o nome virtual, mantendo a porta.

97
Manter o Principal Type. Em casos de HTTPS, é necessário indicar um certificado. Para
HTTP, manter como None.

Adicione uma descrição para a conexão. A descrição é opcional, mas é indicada quando
há uma grande quantidade de sistemas cadastrados.

No último passo, deve-se indicar a verificação do host interno e selecionar o botão de

finalização.

98
 Se a configuração estiver correta, uma linha de mapeamento será gerada com status
“Sem recursos disponíveis” e com verificação Atingido (Reachable). O servidor está
pronto para ter recursos expostos.

3. Expor os serviços. Para isso, clicar no botão de adicionar na área de recursos do servidor
cadastrado no passo anterior.

Uma janela será demonstrada para cadastro do sufixo para os recursos. Indicar o sufixo
/ e selecionar Path and all sub-paths. Com esta configuração, todos os serviços
disponíveis a partir da raiz do servidor estarão disponíveis para consumo. Caso
selecionada a opção Path only, os sufixos subsequentes não seriam selecionados,
limitando o acesso apenas à raiz.

Obs.: em sistemas produtivos, não é comum a liberação de todos os recursos a partir da

raiz. Os recursos são liberados de acordo com a utilização, evitando uma exposição
desnecessária do servidor.

99
 Finalizada a configuração, o servidor passará a demonstrar a disponibilidade de
recursos.

4. Verificar servidor disponível no SAP Cloud Platform. Para isso, acessar o cockpit do SAP
Cloud Platform e selecionar a opção Cloud Connectors.

A conexão ocorreu com sucesso quando é indicada uma conexão com um Cloud
Connector (primeiro botão verde) seguido dos recursos expostos na tabela de hosts.
Com estas configurações feitas, é possível iniciar o uso dos recursos utilizando o virtual
host configurado.

100
Exercícios
1. Quais são os benefícios da computação em nuvem?
2. Quais os modelos básicos de comercialização da computação em nuvem? Explique cada
um deles.
3. Qual é a vantagem de se construir um protótipo? Qual a ferramenta utilizada para se
construir protótipos de aplicações SAP Fiori?
4. Você está participando de um projeto de migração para S/4HANA e é o responsável SAP
Fiori. O consultor funcional de SAP HCM requisitou a criação de uma aplicação onde os
colaboradores pudessem enxergar seus dados pessoais.

Em reunião, percebeu-se que a Object Page atenderia a visualização do perfil. O usuário

final, porém, veio de uma implementação anterior traumática e tem medo de que essa
nova aplicação não atinja os objetivos da organização.

Como sugestão, você levanta a possibilidade de gerar um protótipo para demonstrar

como seria a navegação na aplicação, tranquilizar o usuário e, finalmente, evitar
retrabalho. Como ferramenta, você utilizará o SAP BUILD.

Os requisitos levantados junto aos usuários são a apresentação dos seguintes dados:

• Cabeçalho da aplicação
o Foto do colaborador;
o No título, nome e sobrenome;
o No subtítulo, cargo;
o Telefone e e-mail corporativo como links;
• Informações gerais
o Empresa;
o Centro de custos;
o Unidade organizacional;
o Gestor;
• Colaborador
o Região;
o País;

101
 o Idioma.

Estruture uma entidade através do Data Explorer de forma que seja possível modificar
os dados apresentados de maneira fácil. Utilize o template de Object Page disponível
para facilitar a criação.

Após estruturar o protótipo, gere um estudo para encaminhar para feedback do usuário.

5. Qual é a atual ferramenta para desenvolvimento de aplicações SAP Fiori?

6. Qual é a função de um destino na área de conectividade do SAP Cloud Platform?
7. Qual é a função do Cloud Connector?

Conceitos do SAPUI5
O SAPUI5 é um conjunto de bibliotecas baseadas em JavaScript, HTML5 e CSS. As aplicações são
desenvolvidas para execução a partir de um navegador em qualquer tipo de dispositivo. O
SAPUI5 possui uma arquitetura que compreende os conceitos de MVC, data binding e
roteamento.

Componentes
Os componentes são partes reutilizáveis utilizados em aplicações SAPUI5. As aplicações fazem
uso de um ou mais componentes para demonstrar valores em tela e executar ações. Um
componente tem por característica o encapsulamento de sua lógica de programação, sendo
acessado por métodos bem definidos.

Existem duas categorias de componentes:

• Faceless component: componentes que não tem interface de usuário. São herdados da
classe sap.ui.core.Component e são utilizados para desenvolvimento de serviços;

102
 • UI component: componentes que possuem renderização. São herdados da classe
sap.ui.core.UIComponent e representam uma área de tela ou um elemento gráfico.

A estrutura de um componente é formada, basicamente, por um arquivo Component.js e um

arquivo manifest.json. O primeiro arquivo possui a lógica para execução do componente. O
segundo arquivo é um descritor de aplicação, não obrigatório, porém recomendável de se
utilizar. No descritor, existem metadados e configurações utilizados pelo componente para ser
executado. A referência ao descritor é declarada no arquivo do componente.

Quando uma aplicação SAP Fiori é criada, são gerados também arquivos para o componente e
para o descritor de aplicação (manifest.json).

Descritor de aplicação
O modelo de descritor de aplicação utilizado pelo SAPUI5 foi baseado no conceito da W3C. Ele
é responsável por providenciar informações de maneira centralizada e de fácil acesso para
metadados associados à execução da aplicação.

Os dados no descritor são armazenados no formato JSON, no arquivo manifest.json. Entre as

informações presentes no manifesto, podem ser encontradas configurações para aumento de
performance de uma aplicação, como a declaração das fontes e dos modelos de dados, a
utilização do preload, a localização dos arquivos de internacionalização etc.

Mais informações sobre o conteúdo dos descritores pode ser encontrada em

https://sapui5.hana.ondemand.com/#/topic/be0cf40f61184b358b5faedaec98b2da.

MVC
O SAPUI5, como outros desenvolvimentos web, utiliza-se do modelo de desenvolvimento MVC
(model, view and controller). Ele é amplamente utilizado por promover separação intuitiva de
modelo de dados, interface de usuário e lógica de aplicação.

103
 • Modelo: um modelo é uma representação de dados, geralmente similar à estrutura de
dados armazenada no banco de dados. Em uma aplicação web, é dividido em duas
partes, sendo uma representação no lado do cliente e uma no lado do servidor onde
está a lógica de negócio;
• Visão: interface com o usuário, responsável pela organização dos componentes na tela;
• Controlador: responsável por manipular as interações do usuário com a visão e
encaminhar requisições ao modelo.

Modelos SAPUI5
Na arquitetura do SAPUI5, existem modelos pré-definidos que atuam trabalham de maneiras
diferentes, sendo:

• oData model: modelo que está implementado no lado do servidor, trabalha com o
protocolo oData nas versões 2 e 4. Suporta one-way e two-way binding;
• JSON model: modelo do lado do cliente, trabalha os dados na notação de objeto
JavaScript (JSON - JavaScript Object Notation). Suporta one-way e two-way binding;
• XML model: modelo do lado do cliente utilizado para pequenas quantidades de dados.
Suporta one-way e two-way binding;
• Resource model: modelo para resource bundles, como internacionalização (i18n).
Suporta apenas one-time binding;

oData Model
Um modelo oData é instanciado passando-se o endereço da URL do serviço:

var oModel = new sap.ui.model.odata.v2.ODataModel("/sap/opu/odata/sap/zproject_srv");

Assim que instanciado, uma requisição é enviada ao sistema para busca dos metadados do
serviço (no exemplo, seria encaminhada uma requisição com endereço
/sap/opu/odata/sap/zproject_srv/$metadata).

104
As operações suportadas por um modelo oData são:

• Leitura: leitura de uma entidade. A leitura é feita pelo método read. Obrigatório o envio
da chave completa junto ao nome da entidade a ser lida. Deve-se encaminhar, na
requisição, duas funções de call-back, uma para o caso de sucesso e uma para o caso de
erro.

oModel.read(“/Material(‘10000090’)”, { success: handleSuccess, error : handleError });

• Consulta: leitura de uma ou mais entidades. A consulta também é feita pelo método
read e possui sintaxe similar. Não se deve encaminhar a chave, no entanto.

oModel.read(“/Material”, { success: handleSuccess, error : handleError });

• Criação: criação de uma entidade. Utiliza o método create. Na requisição, deve ser
encaminhado o conteúdo da entidade a ser criada.

var oNewMaterial = { id: “10000091”, description: “New iron bar” };

var oModel.create(“/Material”, oNewMaterial, { success: handleSuccess, error :
handleError });

• Atualização: atualização de uma entidade. Utiliza o método update. Como na criação,

também necessita que o novo conteúdo seja encaminhado pela requisição. É necessária
a especificação da chave, como em um processo de leitura.

var oUpdMaterial = { id: “10000091”, description: “Really new iron bar” };

var oModel.update(“/Material(‘10000091’)”, oUpdMaterial, { success: handleSuccess,
error : handleError });

• Exclusão: operação de remoção de uma entidade. Para isso, utiliza-se o método remove.
É obrigatória a passagem da chave.

oModel.remove(“/Material(‘10000090’)”, { success: handleSuccess, error : handleError

});

JSON Model
Um modelo JSON é instanciado a partir do código abaixo:

var oJSONModel = new sap.ui.model.json.JSONModel();

A atribuição de dados é feita através dos métodos setData ou loadData. É possível recuperar os
dados do modelo no mesmo formato com o método getData.

105
oJSONModel.setData({
“id” : “10000090”,
“description” : “Iron bar"
});

var oObject = oJSONModel.getData();

XML Model
Um modelo XML é instanciado a partir do código abaixo:

var oXMLModel = new sap.ui.model.xml.XMLModel();

A atribuição de dados é feita através do método setXML.

var sXML = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" +

“<data>” +
“<id>10000090</id>” +
“<description>Iron bar</description>” +
“</data>”;

oXMLModel.setXML(sXML);

Visões SAPUI5
As visões disponíveis no SAPUI5 estão disponíveis em 4 tipos: XML, JavaScript, HTML e JSON.

A visão em XML é a preferida para desenvolvimentos SAPUI5. Como as visões HTML e JSON, ela
tem caráter declarativo, porém, apresenta maior facilidade de leitura e organização do que os
outros tipos.

O modelo JavaScript, por sua vez, gera toda a visão a partir de script. Ela é útil quando se exige
a geração completamente dinâmica de uma visão.

O arquivo de uma visão é finalizado sempre por:

• XML: “.view.xml”;
• JavaScript: “.view.js”;
• HTML: “.view.html”;
• JSON: “.view.json”.

Controladores SAPUI5
Os controladores no SAPUI5 são sempre implementados utilizando JavaScript. Os arquivos de
controladores são sufixados por “.controller.js”.

Um controlador possui hooks no seu ciclo de vida que podem ser implementados, sendo:

106
 • onInit(): momento em que a visão e seus controles (elementos de tela) já foram criados.
Utilizado para modificar a visão antes da primeira apresentação em tela. Não tem ação
no resto do ciclo de vida da aplicação;
• onExit(): momento em que a visão é destruída. Utilizado para liberar recursos e finalizar
atividades;
• onAfterRendering(): momento após a renderização. Utilizado para manipular a visão
após ter sido renderizada;
• onBeforeRendering(): momento antes da renderização, chamado sempre que a visão
for renderizada.

Mapeamento de dados
O mapeamento de dados, ou data binding, é um dos conceitos mais importantes para um bom
desenvolvimento SAP Fiori. O data binding é uma maneira de manter os dados entre visão e
modelos de dados sincronizados, sem necessidade de repasse programático.

O data binding define o fluxo de movimento de dados, podendo ser dos tipos one-way, two-way
e one-time.

• One-way binding: modificações realizadas no modelo de dados são encaminhadas para

a visão e apresentadas nos componentes que tiverem conexão. Contudo, ao realizar
modificações nos componentes UI, os dados não são repassados de volta para o modelo;
• Two-way binding: modificação realizadas no modelo de dados são repassados para os
elementos da visão, e vice-versa. Útil em cenários de atualização, pois o modelo conta
sempre com os valores mais atualizados;
• One-way binding: os dados são carregados no modelo e repassados para a visão apenas
uma vez. Depois, é realizada a quebra da sincronização entre modelo e visão. Alterações
feitas na visão não são repassadas ao modelo, e vice-versa. Este modelo é utilizado para
o modelo de traduções do SAPUI5 (as traduções não sofrem alterações em tempo de
execução).

107
Abaixo se encontra a relação de cada tipo de mapeamento de dados em relação ao modelo de
dados utilizado.

Tipos de mapeamento
Dependendo do cenário, diferentes tipos de mapeamento podem atendê-lo. Os tipos de
mapeamento disponíveis são representados pela figura.

Mapeamento de propriedade (property binding)

Permite que propriedades de uma entidade sejam mapeadas automaticamente e atualizadas no
modelo de dados. Para mapear uma propriedade a um controle, é necessário que haja
compatibilidade de tipos. Caso não haja, é possível utilizar um formatador.

Um mapeamento de propriedade por ser feito diretamente na visão XML ou através de

JavaScript, utilizando o método bindProperty.

Imaginando o JSON abaixo:

108
{
“material” : {
“id” : “80009000”,
“description” : “Lenovo X250”
}
}

Caso seja desejável apresentar o código e a descrição em dois campos de entrada (Input) a partir
de uma visão XML, deve-se utilizar “{“ e “}” para indicar o caminho até a propriedade da
entidade. Cada nível que se desce no objeto é separado por uma “/”.

<mvc:View controllerName="sap.ui.sample.App" xmlns="sap.m xmlns:mvc="sap.ui.core.mvc">

<Input id=”inputMaterialId” value="{/material/id}"/>
<Input id=”inputMaterialDesc” value="{/material/description}"/>
</mvc:View>

A abordagem através do JavaScript utiliza a mesma ideia para acessar as propriedades da

entidade.

var oInput = this.getView().byId(“inputMaterialId”);

oInput.bindProperty(“value”, “/material/id”);

Mapeamento de contexto (context binding)

O mapeamento de contexto (ou mapeamento de elemento, element binding) permite a
atribuição de elementos para um objeto do modelo, gerando um contexto relativo. Este tipo de
abordagem é útil em cenários master-detail.

Imaginando o mesmo cenário descrito anterior, com um JSON no formato abaixo:

{
“material” : {
“id” : “80009000”,
“description” : “Lenovo X250”
}
}

Pode-se definir um contexto para o elemento de tela que demonstrará a descrição do material.
Para isso, utiliza-se a propriedade binding. No formato XML, a declaração seria:

<mvc:View controllerName="sap.ui.sample.App" xmlns="sap.m xmlns:mvc="sap.ui.core.mvc">

<Input id=”inputMaterialId” binding=”{/material}” value="{id}"/>
<Input id=”inputMaterialDesc” binding=”{/material}” value="{description}"/>
</mvc:View>

109
Percebe-se que, após a atribuição do contexto, não é necessário percorrer todo o caminho de
mapeamento para se atingir as propriedades, pois um caminho relativo passa a valer,
encurtando as atribuições.

A mesma atribuição pode ser feita através do JavaScript, utilizando o método bindElement.

var oInput = this.getView().byId(“inputMaterialId”);

oInput.bindElement(“/material”);
oInput.bindProperty(“value”, “id”);

Mapeamento de lista (list binding)

O mapeamento de lista (ou mapeamento de agregação, aggregation binding) pode ser usado
para criar controles filhos automaticamente de acordo com um modelo (clonagem de template
ou factory function). Este tipo de mapeamento funciona exclusivamente com listas, ou seja, com
arrays em modelos JSON ou coleções em modelos oData.

Imaginando agora uma lista de materiais disponíveis no formato JSON abaixo:

{
“material” : [
{
“id” : “80009000”,
“description” : “Lenovo X250”
}, {
“id” : “80009010”,
“description” : “HP Probook 440 G5”
}, {
“id” : “80009020”,
“description” : “Asus X509”
}]
}

Para se declarar uma lista demonstrando cada um dos materiais, pode-se utilizar a versão XML
abaixo. Na propriedade items, aponta-se o caminho até o princípio da lista.

<mvc:View controllerName="sap.ui.sample.App" xmlns="sap.m xmlns:mvc="sap.ui.core.mvc">

<List id=“materialList” items= “{path : ‘/material’, templateShareable : false}”>
<items>
<StandardListItem title="{id}" description="{description}"/>
</items>
</mvc:View>

A atribuição via JavaScript também pode ser feita. Imaginando um ComboBox (campo com
listagem para auxiliar seleção), podemos atribuir seus itens a partir da lista anterior.

110
var oItemTemplate = new sap.ui.core.ListItem({text:"{id} - {name}"});
var oComboBox = new sap.m.ComboBox();
oComboBox.bindAggregation("items", {
path: "/companies",
template: oItemTemplate,
templateShareable: false
});

Formatação
Muitas vezes a maneira como a informação em um modelo é tratada de forma técnica, não
podendo ser entendida pelos usuários finais. Por outro lado, a informação que é entrada por um
usuário muitas vezes precisa ser trabalhada antes de atingir o modelo de dados. Para resolver
este tipo de problema, existem os tipos de dados e os formatadores.

Tipos de dados são usados para validar e converter a entrada de um usuário. O tipo deve ser
especificado juntamente ao mapeamento da propriedade. Também podem ser especificadas
opções de formatação e regras para os valores inseridos.

<mvc:View controllerName="sap.ui.sample.App" xmlns="sap.m xmlns:mvc="sap.ui.core.mvc">

<Input value="{
path: '/quantity',
type: 'sap.ui.model.type.Integer',
formatOptions: {
minIntegerDigits: 3
},
constraints: {
maximum: 1000
}
}"/>
</mvc:View>

Os tipos simples são:

• sap.ui.model.type.Boolean;
• sap.ui.model.type.Date;

111
 • sap.ui.model.type.DateTime;
• sap.ui.model.type.Float;
• sap.ui.model.type.Integer;
• sap.ui.model.type.String;
• sap.ui.model.type.Time;
• sap.ui.model.type.DateTimeInterval.

Também é possível utilizar formatadores. Eles atuam nas duas direções da informação, da UI
para o modelo de dados e no sentido contrário. É possível escolher entre os formatadores
padrão ou customizados.

Entre os formatadores padrão, elencam-se:

• Date Format;
• Number Format;
• File Size Format;
• Unit Formatting;
• Currency Formatting.

Para construir um formatador customizado, é necessário gerar uma formatter function e

atribuir a propriedade formatter ao se mapear a entidade ao componente UI. Por exemplo,
imaginando o cenário dos materiais, onde temos a seguinte lista JSON:

{
“material” : [
{
“id” : “80009000”,
“description” : “Lenovo X250”,
“type” : “1”
}, {
“id” : “80009010”,
“description” : “HP Probook 440 G5”
“type” : “1”
}, {
“id” : “80009020”,
“description” : “Asus X509”
“type” : “1”
}, {
“id” : “90009000”,
“description” : “Microsoft Sculpt”
“type” : “2”
}]
}

112
A propriedade type é técnica, não dizendo nada ao usuário final. Imaginando que o valor 1 é
aplicado a notebooks enquanto o valor 2 é aplicado a periféricos, pode-se gerar uma função
formatadora para este caso.

formatType : function(sType) {
if (sType === “1”) {
return “Laptops”;
} else if (sType === “2”) {
return “Accessories”;
}
}

Assim, imaginando que se deseje mapear esta propriedade em um texto de saída, pode-se
utilizar a estrutura abaixo para indicar o formatador desenvolvido:

<Text text="{path: '/material/0/type', formatter: '.formatType'}"/>

<Text text="{path: '/material/3/type', formatter: '.formatType'}"/>

Mapeamento de expressão
Mapeamento de expressão ou expression binding é uma sintaxe que permite gerar expressões
simples no lugar de formatadores customizados.

Elas são definidas diretamente em uma visão XML e, por esta razão, devem ser triviais, para que
a visão não possua grande complexidade ou lógicas de negócio (quebra do padrão MVC). Utiliza-
se, geralmente, em comparações simples de valores.

Uma expressão tem a estrutura “{=expression}”. Na expressão, para referenciar um

mapeamento, é necessário utilizar a sintaxe ${binding}, onde binding define o caminho até a
propriedade que será avaliada.

Imaginando o mesmo caso da listagem de materiais, gerou-se um formatador para transformar

o tipo em um valor legível ao ser humano.

{
“material” : [
{
“id” : “80009000”,
“description” : “Lenovo X250”,
“type” : “1”
}, {
“id” : “80009010”,
“description” : “HP Probook 440 G5”
“type” : “1”
}, {
“id” : “80009020”,
“description” : “Asus X509”
“type” : “1”
}, {

113
 “id” : “90009000”,
“description” : “Microsoft Sculpt”
“type” : “2”
}]
}

Se existem apenas dois tipos de materiais que são comercializados, então, pode-se especificar
diretamente na visão XML a lógica.

<Text text="{= ${/material/o/type} === ‘1’ ? ‘Laptops’ : ‘Accessories’ }"/>

Atribuição de modelo à interface de usuário

Ao se utilizar um descritor, já existe a atribuição automática de um modelo ao componente e
ela atribuição é herdada para todos os elementos hierarquicamente inferiores. Porém, quando
desejado, é possível criar um ou mais modelos auxiliares e atribuí-los a elementos distintos, do
core a um elemento gráfico de tela.

Um elemento pode ter um ou mais modelos atribuídos, sendo diferenciados pelo nome. A
atribuição é feita a partir do método setModel.

Imaginando-se dois JSON como seguem:

material.json

{
“material” : {
“id” : “80009000”,
“description” : “Lenovo X250”,
}
}

materialDet.json

{
“materialDetail” : {
“id” : “80009000”,
“vendor” : “Lenovo”,
“processor” : “Intel Core i7-5600U”
}
}

Se é desejável que o mesmo componente apresente dados dos dois arquivos, pode-se gerar
atribuições múltiplas ao elemento UI e utilizá-los no mapeamento. Para isso, devem ser gerados
dois modelos, um para cada arquivo. Na sequência, deve-se atribui-los ao elemento.

114
var oModelMat = new sap.ui.model.json.JSONModel();
oModelMat.loadData(“local/material.json”);

var oModelMatDet = new sap.ui.model.json.JSONModel();

oModelMatDet.loadData(“local/materialDet.json”);

var oText = this.getView().byId(“textMaterial”);

oText.setModel(oModelMat); //atribuição de modelo padrão – sem nome
oText.setModel(oModelMatDet, “det”); //atribuição de modelo secundário

O elemento da visão será representado da seguinte maneira.

<Text id="textMaterial" text="{/material/description} by {det>/materialDet/vendor}"/>

Localização
Uma aplicação SAPUI5 possui uma série de literais que são dependentes de linguagem. Estes
literais estão presentes em componentes da interface de usuário, como mensagens, rótulos e
títulos.

O SAPUI5 se utiliza do mesmo conceito do Java para se tratar a localização de uma aplicação,
gerando arquivos de literais (i18n.properties), um para uma linguagem (e.g.
i18n_ptBR.properties). O arquivo que não contém a especificação de linguagem é considerado
o arquivo padrão. Os arquivos de localização contêm linhas no formato chave-valor.

Este padrão é especialmente importante pois ele facilita a tradução dos literais, não sendo
necessário buscar os valores em múltiplos arquivos.

Abaixo segue um exemplo de um resource bundle:

# SAPUI5 TRANSLATION-KEY <GUID>

#XMSG: A message to greet the world
helloWorld=Hello World
#XBUT,10: Save button text
buttonSave=Save
#XFLD,30: Greetings displayed in the upper right corner of the screen
welcome=Welcome {0}

Obs.: não se deve utilizar textos fixos diretamente em códigos produtivos. Sempre utilize os
arquivos de localização para armazenar literais que serão demonstrados na UI.

Existem códigos iniciados por # que são annotations para auxiliar futuras traduções sobre a
utilização do texto no conteúdo da página. Estes itens são padronizados e todas as utilizações
disponíveis podem ser verificadas no link: https://help.sap.com/doc/saphelp_tm92/9.2/en-
US/83/1039835e7c4da3a8a0b49567573afe/frameset.htm.

115
Mapeamento de dados
Pode-se utilizar o mapeamento de dados para acesso aos textos localizados. Há a classe wrapper
ResourceModel especificamente para acesso aos arquivos.

Abaixo descreve-se um exemplo de codificação para acesso aos recursos de localização de um

arquivo e atribui-lo a um controle de UI:

var oModel = new ResourceModel({

bundleName:"myBundle",
bundleLocale:"pt",
async: true
});

var oControl = new Button({

id : "myButton",
text : "{i18n>buttonSave}"
});

oControl.setModel(oModel, "i18n");

Roteamento e navegação
A navegação de um componente SAPUI5 é baseada em hash. Ela permite que uma sejam criadas
aplicações com uma página apenas e as reações de navegação incidam sobre as visões, que
reagirão de acordo com o hash inserido.

A navegação em aplicações web clássicas contém múltiplas páginas que são gerenciadas pelo
lado do servidor. A cada navegação, uma URL diferente é gerada e a página precisa ser
recarregada e passar pelo processo de renderização.

No caso do SAPUI5, a aplicação contém uma página. As modificações são mantidas no lado do
cliente, realizando dinamicamente a carga dos componentes UI5 na mesma página (URL única).
As diferenças ocorrem no hash, que é anexado ao fim da URL. Esta característica permite que a
URL possa ser armazenada como favorita (bookmarkable).

116
O router é o componente responsável por verificar o hash e ditar o comportamento das visões
a serem apresentadas. Ele também armazena o histórico de navegação, o que auxilia nos
avanços e retornos.

No arquivo de configuração de roteamento, são definidas rotas e alvos (routes e targets,

respectivamente).

Ao utilizar uma rota, o hash será modificado. Uma rota obrigatoriamente possui um padrão de
URL que será registrado no histórico de navegação. Uma rota pode possuir um ou mais alvos.

Ao utilizar um alvo diretamente, o hash persiste, porém, realizando a navegação para a visão.
Um alvo não armazena dados no histórico de navegação.

Os padrões de roteamento podem ser dos seguintes tipos:

• Padrões fixos: o padrão é exatamente igual ao hash. Por exemplo, ao utilizar o hash
#material/show, o padrão especificado na rota deve ser exatamente “material/show”;
• Rota com parâmetro obrigatório: existe um padrão fixo e um ou mais parâmetros que
são mandatórios. Na especificação da rota, deve-se utilizar o padrão “{parameter}” para
indicar que o parâmetro é obrigatório. Por exemplo, um padrão “material/{id}/show”
pode ser atingido pelo hash #material/80009000/show;
• Rota com parâmetro opcional: existe um padrão fixo e parâmetros que podem ou não
ser especificados, utilizando-se o padrão “:parameter:”. Por exemplo, um padrão
“material/{id}/show/:detail:” poderia ser atingido pelo hash
#material/80009000/show/vendor;
• Rota com parâmetro de consulta: padrão fixo com parâmetros para consulta. Esta
consulta pode ser obrigatória ou opcional, utilizando os padrões “{?query}” ou
“:?query:” respectivamente. O parâmetro será salvo como um objeto e passado ao
manipulador de eventos.

117
Fragmentos
Fragmentos são partes de interface de usuário (subárvores de UI) que são reutilizáveis. São
similares a visões, porém, não possuem um controlador ou qualquer codificação. Eles são
independentes e podem ser utilizados para modularizar a visão de uma aplicação.

Eles podem ser conectados ao controlador da visão que os contém, estando a parte do modelo
MVC. Ele não possui representação HTML quando são inseridos na árvore de UI. O conteúdo
deles é inserido, não apresentando overhead ao se fazer isso.

Fragmentos são muito utilizados em janelas de diálogo, pois estas costumam ser reaproveitadas
entre as visões.

Um fragmento pode ser representado em XML, HTML e JavaScript. Logo, os arquivos de um

fragmento podem ser representados por *.fragment.xml, *.fragment.html ou *.fragment.js,
respectivamente. O tipo mais utilizado, assim como nas visões, é o XML.

Abaixo está a definição de um fragmento para uma janela de diálogo no formato XML:

<core:FragmentDefinition xmlns="sap.m" xmlns:core="sap.ui.core">

<Dialog title="Material {/material/id}">
<content>
<Text text="{/material/description}"/>
</content>
</Dialog>
</core:FragmentDefinition>

Para que essa janela de diálogo seja invocada, deve-se programaticamente fazer:

_getDialog : function () {
if (!this._oDialog) {
this._oDialog = new
sap.ui.xmlfragment("zproject.fragments.MaterialDialog", this);
this.getView().addDependent(this._oDialog);
}

return this._oDialog;
},

onOpenDialog : function () {
this._getDialog().open();
}

Exercícios
1. Como são compostos os componentes SAPUI5?
2. Qual é o modelo de desenvolvimento adotado como padrão pelo SAPUI5? Por que ele
é importante?
3. Qual o tipo mais comum de visão utilizada no SAPUI5?
4. Quais são os tipos de mapeamento de dados? Explique cada um deles.

118
5. Qual a diferença entre um formatador e um tipo de dados?
6. Qual é o nome dos arquivos que armazenam literais que podem ser traduzidos?
7. O que é um hash no contexto de roteamento? Como funciona a navegação no SAPUI5?
8. Você está participando de um projeto de migração para o S/4HANA. Em um primeiro
momento, foi feita uma divisão de atividades onde você seria responsável pelo
desenvolvimento de um serviço OData para criação e leitura de parceiros de negócios,
enquanto um colega ficaria responsável pelo desenvolvimento da interface de usuário
da aplicação SAP Fiori. Contudo, por uma questão de doença, seu colega foi afastado
por 15 dias e desfalcará o time neste período. Por já ter conhecimento da estrutura do
serviço, você deverá, então, finalizar este desenvolvimento.
Espera-se que a aplicação se inicie com a listagem de todos os business partners
disponíveis.
As colunas disponíveis na primeira lista serão:
o ID do parceiro;
o Nome do parceiro;
o Tipo do parceiro (transformado de código para descritivo);
o Região;
o País.

A aplicação deverá permitir a criação de novos BPs a partir de um botão ou link de

criação. Também deverá permitir a exibição e edição de registros existentes, navegando
a partir de um clique na linha da tabela. As telas de exibição e edição devem ser as
mesmas, utilizando apenas controles de tela para habilitar os campos. Todos os campos,
exceção ao ID do parceiro, podem ser modificados. O tipo de parceiro não pode ser
apresentado com valor técnico e deve ser transformado da seguinte forma:
o Valor “1” – “Organização”;
o Valor “2” – “Pessoa”.

Obs.: utilize uma aplicação SAPUI5 pura, sem nenhum template aplicado, para exercitar
todos os conceitos.
9. Após encaminhar a aplicação anterior ao usuário para a primeira validação, ele relatou
a dificuldade em utilizar as siglas de país. Como solução, você pensa em desenvolver
uma nova entidade, Country, que será navegável a partir do código do país. Esta
entidade possuirá código e descrição do país, provenientes da tabela T005T. Para
auxiliar a entrada de valores no formulário, você desenvolverá uma ajuda de pesquisa
exibindo todos os valores possíveis para esta entidade. Considere um filtro para auxiliar
na busca dos valores, sendo possível a pesquisa por código ou descritivo. Na tabela, a
sigla será apresentada junto ao descritivo. A ajuda de pesquisa deverá prever um filtro
para busca a partir da descrição.
10. Após uma rodada de testes com uma massa de dados maior, o usuário relata que a
listagem de business partners está demorando muito tempo para ser carregada. Após
uma análise sobre o código, você percebe que o processamento da expansão gerada
pela leitura da tabela T005T está tomando um tempo considerável. Você constata que
a leitura unitária (GET_ENTITY) está sendo utilizada também para a consulta de mais de
uma entidade (GET_ENTITYSET), gerando um excesso de chamadas ao banco de dados
que oneram o processamento. Como solução, você propõe a reimplementação da
expansão, buscando dados da entidade do parceiro de negócios juntamente à expansão

119
 de país proposta. Implemente esta expansão, capturando quais são as propriedades de
navegação a serem expandidas e, caso identificada alguma, otimize a sua leitura.

Extensão de aplicações
Aplicações SAP Fiori são criadas levando em consideração determinados cenários de negócio,
muitas vezes de maneira genérica demais para aderir totalmente a um cenário do cliente. Sabe-
se que os cenários de negócio variam de inúmeras maneiras, até mesmo por requerimentos
legais de um país.

Por esta razão, é comum que os clientes demandem alterações em aplicações que são
disponibilizadas pela SAP. Contudo, assim como quando ocorrem alterações no SAP ERP, é
importante que essas alterações não bloqueiem a possibilidade de aplicar correções futuras
sobre essas aplicações. Ao se modificar diretamente o código de uma aplicação standard, ela
passa a não poder receber tais ajustes.

Pensando nisso, a SAP disponibilizou uma série de pontos de modificação que permitem
extensão de aplicação SAP Fiori. A extensão de componentes SAP Fiori é feita pela sobrescrita
de métodos dos componentes originais. O componente que foi estendido passa a ser chamado
antes da aplicação original. Quando existe codificação de extensão, este código é chamado. Do
contrário, o código original é o que será executado.

Existem duas abordagens básicas de extensão de aplicações, sendo:

• SAPUI5 Flexibility: esta é a maneira para se estender uma aplicação SAP Fiori baseada
em smart templates (SAP Fiori Elements). Deve ser utilizada a partir da versão 1.56.
Possui um editor visual que facilita a manipulação da aplicação. Pode ser utilizada por
desenvolvedores, usuários-chave ou usuários finais. O SAPUI5 Flexibility é acionado a
partir de um projeto de adaptação;

120
 • Configuração de componente: é a maneira tradicional de extensão. Em aplicações Fiori
Elements anteriores à versão 1.56 ou em aplicações freestyle, esta deve ser a
abordagem de extensão. Entre as possibilidades de extensão, estão:
o Extensão de visão;
o Modificação de visão;
o Substituição de visão;
o Substituição de controlador;
o Substituição de serviço;
o Substituição de textos localizados.

Estas extensões são feitas a partir do painel de extensibilidade, gerando-se um projeto

de extensão.

SAPUI5 Flexibility
O SAPUI5 Flexibility permite a modificação de aplicações baseadas em SAP Fiori Elements sem
modificação dos artefatos base. É possível fazer adaptações de visão ou de controlador.

O SAPUI5 Flexibility utiliza o conceito de camadas. Cada camada sobrepõe a anterior apenas
com as modificações em comparação à camada superior. Existem os seguintes níveis de camada
disponíveis para o SAPUI5 Flexibility:

121
 • USER: nível mais específico, é aplicado apenas a um usuário (personalização);
• CUSTOMER: aplicada a todos os usuários que compõem um cliente, sendo
disponibilizada por key users e power users que saibam manipular as aplicações;
• CUSTOMER_BASE: realizada por desenvolvedores através do Web IDE, através de um
projeto de adaptação;
• VENDOR: nível mais genérico, entregue pela SAP.

Configuração de componente
O SAPUI5 suporta a extensão do controlador base de um componente com um customizado,
realizando uma combinação de controladores no nível do JavaScript. Não existe o conceito de
herança, os métodos que possuem o mesmo nome representam sobrescrita do método original,
exceção feita aos métodos de ciclo de vida, podendo os originais ser chamados antes (onExit e
onBeforeHandling) ou depois (onInit e onAfterRendering).

As configurações de componente são registradas no arquivo descritor (manifest.json). Nele, são

descritos os pontos do componente original que serão estendidos, juntamente à extensão que
será realizada.

Extensão de visão
Pontos de extensão nas visões são lugares pré-definidos pela SAP para que os clientes adicionem
novos controles na tela.

Para encontrar os pontos de extensão, devemos verificar a documentação das aplicações a partir
do SAP Fiori apps library, um site onde todas as aplicações SAP Fiori são documentadas. Vide a
área de Sites para mais detalhes.

Na área de extensões, é possível verificar os pontos de extensão disponíveis em Implementation

Information, na seção Configuration > Extensibility. Abaixo um exemplo para o aplicativo
F0400A (My Inbox - Approve Purchase Contracts).

122
Após verificar a documentação, deve-se encontrar o ponto no painel de extensões e selecionar
a opção de estender a visão ou o fragmento.

Também é possível verificar pontos de extensão da visão a partir do código-fonte. A tag

<core:ExtensionPoint> é utilizada para indicar o ponto e pode conter uma implementação de
sugestão.

123
Ao se gerar a extensão, um fragmento é gerado para inserção dos novos componentes UI. Como
se trata de um fragmento, este tipo de extensão trata apenas os elementos da visão. Caso exista
algum requisito de tratamento de eventos deste novo fragmento, é preciso,
complementarmente, gerar uma substituição de controlador e inserção dos eventos e métodos
para completar o desenvolvimento.

Obs.: quando fechado o painel de extensibilidade, é possível ativá-lo novamente a partir do menu
Tools > Extensibility Pane.

124
Uma extensão deste tipo também pode ser realizada pelo wizard. Basta clicar o botão direito
sobre um projeto de extensão e escolher a opção New > Extension e selecionar a opção Extend
View/Fragment.

Modificação de visão
A modificação de visão é indicada quando se deseja alterar a propriedade de visibilidade de um
controle na UI. Uma premissa para que este tipo de modificação ocorra é que o controle a ter a
visibilidade modificada tenha um ID explícito. Caso o ID não seja especificado, não é possível
realizá-la.

É possível realizar esta extensão a partir do painel de extensibilidade ou através do wizard.

Após selecionar a visão, uma lista com todos os componentes que possuem ID explícito é
apresentada.

125
Após a confirmação, o arquivo de manifesto é atualizado. Nele, será apresentada uma nova
seção para as modificações de visão, o atributo que terá a visibilidade modificada e o novo valor
da propriedade.

Através do painel de extensibilidade, basta encontrar o componente a ser inibido, selecioná-lo

e selecionar a opção Hide Control.

126
Substituição de visão
Quando a modificação e a extensão de visão não são suficientes ou aplicáveis, é possível realizar
a completa substituição de uma visão por uma customizada.

A substituição de visão é um tipo invasivo de extensão: uma vez que estendida a aplicação, a
visão substituída não é passível de atualizações fornecidas pela SAP. Por esta razão, recomenda-
se, quando não houver contorno, realizar o máximo de aplicações de notas SAP antes de iniciar
este tipo de extensão.

Com a substituição de visão, ao contrário das anteriores, qualquer visão é passível de

substituição, não sendo necessária qualquer configuração no desenvolvimento.

Para realizá-la, pode-se utilizar o wizard, ao clicar o botão direito sobre o projeto e selecionar a
opção New > Extension, selecionando na sequência a opção Replace View. Então, deve-se
selecionar a visão a ser substituída e concluir o processo.

No caso do painel de extensão, basta selecionar a visão a ser substituída e escolher nas
possibilidades de extensão entre a reposição por uma visão em branco ou por uma cópia da
original (recomendada).

127
Assim como nas demais opções, o arquivo descritor é atualizado com a entrada da extensão,
mencionando qual visão está sendo substituída e por qual objeto.

Uma cópia da visão é gerada na pasta view. Por padrão, o nome da visão é o mesmo da original,
adicionando-se o sufixo Custom.

Substituição de controlador
O controlador padrão de uma visão pode ser completamente substituído ou levemente
estendido por uma versão customizada. É comum utilizar uma substituição de controlador em
conjunto com uma extensão ou uma substituição de visão.

Em tempo de execução, os controladores original e substituto são unificados. Logo, todos os

métodos e atributos que compõem os dois controladores ficam disponíveis. Quando uma
declaração com o mesmo nome é realizada no controlador substituto, este método sobrescreve
o controlador original, o qual passa a ser inacessível.

128
Para se gerar este tipo de extensão, pode-se utilizar o painel de extensibilidade ou o wizard de
extensões. No painel, deve-se buscar a área de controladores, selecionar o controlador a ser
estendido e selecionar entre a geração de um novo controlador ou de uma cópia do original.

Obs.: ao contrário da substituição de visão, onde se recomenda a cópia da visão original, no caso
dos controladores isso não se aplica, pois quanto mais métodos originais forem mantidos, menos
agressiva será a extensão, permitindo maior compatibilidade com atualizações. Deve-se lembrar
que os controladores são unificados durante a execução. Ao realizar uma cópia, todos os
métodos passam a ser chamados do controlador substituto.

No caso do wizard, deve-se selecionar a extensão de controlador e na sequência, na listagem,

escolher qual controlador será substituído assim como qual modelo de criação será utilizado
(novo ou cópia do original).

129
Ao finalizar, o novo controlador é criado. Se selecionada a versão em branco, o controlador é
apresentado com todo o código comentado.

O descritor da aplicação também é atualizado com uma seção de extensões de controlador,

especificando qual é o controlador original que está sofrendo a extensão e qual é o controlador
que está realizando sua substituição/extensão.

130
Ainda sobre a extensão de controladores, existem hooks (ganchos, em tradução livre). Eles são
locais definidos pelo desenvolvimento que permitem a extensão da lógica do controlador. São
comparáveis à extensão de visão em conceito. Assim como elas, os hooks são declarados na
biblioteca de referência de aplicações SAP Fiori, na área de extensões de uma aplicação. Uma
descrição de sua aplicação pode ser encontrada na coluna sobre a sua utilização.

Um hook pode ser implementado tanto pelo painel de extensibilidade quanto pelo wizard, como
as demais extensões. No painel, deve-se buscar por todos os elementos estensíveis, expandir a
visão na qual se deseja buscar o hook e seleciona a opção de estender o controlador.

131
No caso do wizard, deve-se selecionar a opção Implement UI Controller Hook.

Ao selecionar a visão no próximo passo, todos os hooks disponíveis são apresentados.

Um controlador é gerado com uma implementação de exemplo. Caso o controlador já exista, o

método do hook é adicionado.

132
Também é criada uma entrada no descritor caso um novo controlador seja criado. Como nos
outros casos, relaciona-se o objeto original e a extensão criada.

Substituição de serviço
Uma substituição de serviço permite que o serviço oData que é consumido por uma aplicação
SAP Fiori seja substituído por uma versão do cliente. Este tipo de substituição não é muito
comum, pois a aplicação muitas vezes é baseada no serviço para determinar seu
comportamento. Por esta razão, as substituições de serviço devem ser feitas com cópias do
serviço original e pequenas extensões nestes.

Para substituir o serviço, deve-se utilizar o wizard com a seleção Replace Service.

Deve-se, então, selecionar o serviço que tomará lugar do anterior.

133
Após a confirmação, atualiza-se o arquivo descritor, substituindo a uri da antiga fonte de dados
pela nova.

Substituição de textos localizados

A substituição de textos localizados visa adicionar ou modificar textos fixos que são utilizados
dentro das aplicações SAP Fiori.

Quando são geradas extensões ou substituições de visão, é pouco provável que não haja literais
que devam ser armazenados nos resource bundles da aplicação. Também é possível que as
traduções fornecidas pela SAP não estejam em acordo com os termos aos quais o cliente está
habituado.

Para ambos cenários, a extensão dos arquivos de internacionalização atende os requisitos.

Através do wizard, é possível criar esta substituição selecionando a opção i18n Resource Text
Customization.

134
Ao confirmar, os arquivos de texto localizado são gerados na pasta i18n e podem ser
modificados sem restrições. Caso um texto não seja encontrado nos arquivos customizados, o
texto original será buscado.

No descritor de aplicação, é gerada uma entrada de configuração dos arquivos de

internacionalização, indicando qual é a nova pasta e arquivo padrão que devem ser buscados os
textos localizados.

135
Exercícios
1. Durante um projeto de implementação do SAP S/4HANA, define-se a utilização da
aplicação “Administrar pedidos centralmente” (ID F3292 -
ui.s2p.mm.pur.central.po.manage.s1) para alguns usuários de MM. A aplicação
permite a criação e manutenção de pedidos de compras.
Contudo, funcionalidade de criação de novos pedidos é restrita a apenas alguns
membros da equipe. O consultor funcional sugere a criação de uma nova aplicação para
os usuários que não deverão criar pedidos. Sabendo da flexibilidade do SAPUI5, você
sugere a geração de uma extensão.
A aplicação também permite o compartilhamento das informações apresentadas na
tabela e este botão também não é desejado. Por fim, a nomenclatura “Grupo de
compradores” não é utilizada pela empresa e deve ser modificada para “Célula de
compras”.

Com estes requisitos em mãos, verifique:

o Qual método de extensão deve ser utilizado?
o Execute a extensão proposta.

Configuração do SAP Fiori Launchpad

O conteúdo disponível para um usuário final no SAP FLP é configurado a partir do perfil de
acesso. Os elementos que compõem um perfil de acesso SAP Fiori são:

• Aplicação: é um componente SAPUI5 que é relacionado por um ou mais target

mappings;
• Atribuição de destino: é um mapeamento (target mapping) que indica qual será a
aplicação que será executada para um objeto semântico e uma ação, através de uma
intenção. Também é responsável por estipular parâmetros e dispositivos compatíveis;
• Blocos: são as caixas (tiles) apresentadas no SAP Fiori Launchpad. Podem conter um
indicador dinâmico para o processo que aborda. Referenciam um target mapping, ou
seja, relacionam um objeto semântico e ação para serem executados caso sejam
clicadas;
• Catálogo: são conjuntos de aplicações e target mappings atribuídos a um perfil. Apenas
aplicações que estejam entre os catálogos contidos em um perfil de acesso podem ser
executados pelos usuários finais. Apesar de dar acesso às aplicações, nem todas elas

136
 estarão disponíveis diretamente na entrada do SAP FLP. A maioria estará disponível
apenas pelo App Finder ou após a execução de algum tipo de personalização;
• Grupos: grupos são conjuntos semânticos de aplicações. Quando um usuário tem acesso
a um grupo, ele já é carregado automaticamente na entrada do SAP FLP, sem a
necessidade de personalização prévia.
• Perfil PFCG: um perfil PFCG é um perfil clássico SAP ERP. Nele, são inseridos todos os
objetos de autorização, transações e menus que um usuário tem acesso no SAP ERP.
Eles também são utilizados para liberação de acessos ao SAP Fiori. Um perfil PFCG pode
possuir um ou mais catálogos e grupos. São eles que são atribuídos ao usuário final.

A configuração do SAP Fiori Launchpad é feita através do SAP Fiori Launchpad Designer,
disponível em dois contextos: CONF e CUST.

O contexto de configuração (CONF) é referência configurações cross-client. O conteúdo

disponibilizado pela SAP originalmente está entregue neste contexto. O contexto de cliente
(CUST) é específico de mandante, utilizado para customizações (escopo padrão). Para acessar
os escopos de trabalho descritos, existem as transações /UI2/FLPD_CONF e /UI2/FLPD_CUST,
respectivamente. Também é possível o acesso através do endereço
/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.hmtl?&scope=<CONF|CUST> (por exemplo
http://s4hana.ides.com:9222/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.html?scope=CUST&
sap-client=400&sap-language=PT).

O primeiro ponto a ser verificado antes da geração de qualquer configuração é a criação de uma
transport request. O tipo da request dependerá do contexto utilizado: workbench para CONF ou
customizing para CUST. A criação pode ser feita pelas transações SE09 ou SE10.

137
Criada a request, deve-se apontá-la no FLP Designer através da engrenagem no canto superior
direito da tela.

Obs.: se este passo não for realizado, todos os objetos criados ou modificados ficarão em
contexto local.

138
O FLP Designer é dividido em duas áreas, em layout Master-Detail. Na área central, é
apresentado o conteúdo do objeto que está sendo tratado. Na lateral, estão listados catálogos
e grupos. Eles são alternados pela aba no topo dessa área. Logo abaixo, existe a possibilidade de
armazenar catálogos mais utilizados. Na sequência, uma opção para buscar por descrição ou ID.
Um catálogo ou grupo pode ser criado a partir do botão + disponível na barra de ferramentas
do canto inferior esquerdo.

Um catálogo pode fazer referência a aplicações disponíveis no próprio sistema ou em sistemas

remotos. Quando selecionada a opção Remoto, parâmetros adicionais são abertos para
indicação do sistema que será consumido.

139
Catálogos são divididos entre blocos (tiles) e atribuições de destino (target mappings).

Um bloco aponta para um objeto semântico e uma ação. Ele pode estipular parâmetros
adicionais e, quando bloco dinâmico, a URL para serviço que indica o KPI demonstrado.

Um destino gera a combinação da intenção (objeto semântico e ação) e associa a uma aplicação.
Entre os tipos permitidos para aplicações SAP Fiori, estão a configuração de um componente
SAPUI5, uma transação tradicional do SAP ERP, uma URL e um Web Dynpro. Cada tipo de
aplicação possui parâmetros relativos para sua execução.

140
Grupos, por sua vez, possuem apenas a relação de blocos, podendo ser compostos de um ou
mais catálogos.

Para excluir um objeto, deve-se clicar e segurar o botão esquerdo do mouse e arrastá-lo à opção
Eliminar.

141
A atribuição de um catálogo e um grupo ao usuário final devem ser feitas a partir dos perfis
PFCG. Para isso, deve-se acessar a transação PFCG. Pode-se criar uma função individual ou abrir
uma pré-existente.

Na aba Menu, pode-se inserir um novo nó e adicionar catálogos e grupos do SAP Fiori.

Ao inserir um catálogo, é possível indicar catálogos locais ou remotos, de sistemas on-premise

ou SAP Cloud Platform. Para sistemas remotos, é necessária a indicação do destino RFC para
atingir o ambiente.

142
Grupos são mais simples em configuração, apontando apenas configurações locais.

Exercícios
1. Qual a diferença de um catálogo e um grupo SAP Fiori?
2. Onde são apontados os catálogos e os grupos que um usuário SAP Fiori tem acesso?
3. Você está participando de um projeto S/4HANA e precisa disponibilizar ao usuário a
nova aplicação para manutenção de parceiros de negócios que você desenvolveu (vide
exercícios anteriores).
Você deverá:
o Executar a implantação da aplicação ao SAP Fiori Launchpad. Utilizar como
nome de aplicação o formato ZFIOR_BP_XX (onde XX é o número do aluno);
o Em escopo customizing, criar um catálogo denominado ZFIOR_BC_BP_XX (onde
XX é o número do aluno) e com descrição “Business partner maintenance”,
adicionando a aplicação como tile e gerando uma atribuição de destino para ela;
o Em escopo customizing, criar um grupo denominado ZFIOR_BG_BP_XX (onde
XX é o número do aluno) e com descrição “Business partner maintenance”,
adicionando a aplicação recém-publicada;
o Gerar uma função PFCG (ZFIOR_BP_XX, onde XX é o número do aluno) e atribuir
a ela o catálogo e o grupo criados.

Ao final, atribuir esta função ao seu usuário e realizar o teste no SAP FLP, verificando a
atribuição e a navegação.

143
Sites úteis
Esta é a relação de alguns sites importantes para o desenvolvedor SAP Fiori. São documentações
e ferramentas que auxiliam no desenvolvimento.

SAP Fiori apps Library

https://fioriappslibrary.hana.ondemand.com/

Disponibiliza documentação de todas as aplicações standard disponíveis até o momento. Os

filtros permitem a busca por descrição, ID e até mesmo a transação legada que foi substituída
pela aplicação SAP Fiori. As guias de configuração e implementação dão indicações de pacotes
e serviços serem instalados e habilitados. Na guia de extensão, são listadas as possibilidades de
ampliação da aplicação.

SAPUI5 Documentation
https://sapui5.hana.ondemand.com/

Documentação para desenvolvimento SAPUI5. Trata de todos os aspectos do desenvolvimento,

com guidelines, tutoriais, documentação de controles e codificações de exemplo. É uma ampla
documentação disponível e totalmente gratuita, acessível a qualquer desenvolvedor.

Cockpit SCP Trial

http://cockpit.hanatrial.ondemand.com/

É o cockpit da versão de avaliação do SAP Cloud Platform. Além da possibilidade de desenvolver

aplicações SAP Fiori, permite também experimentar o portfólio de serviços em nuvem que a SAP
disponibiliza.

UI5 Inspector
https://chrome.google.com/webstore/detail/ui5-inspector/bebecogbafbighhaildooiibipcnbngo

Plugin do Google Chrome, disponibiliza acesso a ferramentas de diagnóstico para aplicações

SAPUI5. É muito útil para inspeção dos componentes, visualização de contextos e modelos.
Permite modificação dos controles e visualização dos resultados em tempo de execução.

BUILD
https://www.build.me/

Ferramenta SAP disponibilizada na nuvem, específica para desenvolvimento de aplicações SAP

Fiori. Deve ser integrada sempre que possível no processo de desenho de uma aplicação.

144
Permite o compartilhamento com demais integrantes do projeto e coleta de feedbacks sobre a
experiência com os protótipos.

Fiori Guidelines
https://experience.sap.com/fiori-design-web/

Documentação sobre as linhas gerais de desenvolvimento de aplicações SAP Fiori com foco na
experiência de usuário e como ela é atingida a partir dos múltiplos componentes disponíveis. As
diretrizes apresentadas são explicadas em alto nível, porém, existe a referência aos controles
necessários e/ou indicados para aquele uso.

SAP Development Tools

https://tools.hana.ondemand.com/

Ferramentas de desenvolvimento SAP. Todos os componentes necessários para

desenvolvimento de aplicações SAP Fiori e de landscape distribuído podem ser encontradas
aqui.

145
Resoluções

Experiência de usuário
1. Qual a nova estratégia de UX que a SAP vem utilizando? Explique cada um de seus
componentes.
R: A estratégia de experiência de usuário da SAP está baseada no conceito New, Renew
and Enable, onde:
New: neste pilar, estão todas as aplicações novas criadas pela SAP. Todas elas têm
grande foco na experiência de usuário. Exemplos são o SAP Cloud For Sales e o SAP Fraud
Management;
Renew: o segundo pilar se baseia na modernização de interfaces de usuário (UI) para
aplicações que já existem. Exemplos são as aplicações SAP Fiori voltadas para transações
clássicas do SAP ERP;
Enable: o último pilar apresenta as ferramentas para o cliente adotar e criar experiências
de usuário. Aqui, estão as ferramentas como SAPUI5 Dev Tools, SAP Screen Personas e
SAP Theme Designer.

2. Quais são os conceitos para se desenvolver uma aplicação SAP Fiori?

R: Os conceitos são:
Role-based apps (aplicações com foco em papéis): cada aplicação deve ter foco em um
papel específico (exemplo: comprador, agente de vendas). Com apenas um papel, as
telas tendem a ser mais claras e permitirão um foco maior por parte do usuário;
Adaptative (adaptativa): usuários podem acessar a aplicação com vários tamanhos de
tela e dispositivos, reduzindo a necessidade de desenvolver aplicações para cada um
dos dispositivos alvo.
Simple (simples): o mínimo de informação possível, sem botões e menus
desnecessários. Os novos usuários ficam sobrecarregados com muitas opções e
informações. Exemplo clássico são as GUI clássicas, como a tela para geração de um
pedido de compra ou de uma ordem de venda. O treinamento deve ser mínimo ou
nenhum.
Coherent (coerente): as aplicações devem possuir uma linguagem de design e interação
coerente, isto é, devem apresentar modos de utilização iguais ou próximos. Após
navegar em uma aplicação, o usuário deve se sentir confortável em navegar em outros,
pois eles aderem ao mesmo padrão de linguagem.
Delightful (agradável, encantador): o usuário deve ter uma sensação agradável ao
trabalhar, ao ponto de sentir prazer ao utilizar a aplicação. Ele deve experimentar uma
conexão emocional pelo uso de recursos visuais e animações.

3. Quais são os três pilares que são atendidos por uma solução inovadora? Qual deles é o
foco do Design Thinking?
R: Os três pilares são:
Desejos do cliente: entendimento das necessidades do cliente e seus desejos. Neste
ponto, são geradas entrevistas e enquetes para entender o que se deseja e quais são os
pontos de incômodo do cliente, caso existam;
Factibilidade técnica: quais são as tecnologias e ferramentas corretas para se executar
uma ideia;
Viabilidade financeira: verificação se a ideia é viável em análise financeira, encontrando
os objetivos da organização.
O foco do design thinking está nos desejos do cliente.

146
 4. Quais são os maiores problemas nas transações SAP clássicas quando levamos em conta
a experiência de usuário?
R: As transações clássicas podem ser grandes demais, necessitando o usuário final de
muito treinamento para correta manipulação, ou processualmente incompletas,
fazendo com que o usuário final necessite realizar passos sistêmicos que deveriam estar
agregados em uma única transação.

Arquitetura
1. Quais é a diferença entre o frontend server e o backend server em uma arquitetura SAP
Fiori? Eles podem ser, em algum momento, o mesmo servidor?
R: O frontend server é responsável por expor serviços e disponibilizar bibliotecas e
aplicações necessárias para a interface de usuário. O backend server, por sua vez, provê
os dados e regras de negócio, fazendo a comunicação com o banco de dados.

2. Cite as vantagens e desvantagens das arquiteturas mais conhecidas.

R: Hub
Vantagens:
Ponto central de acesso;
Melhor segurança e autenticação;
Separação do ciclo de vida de interface de usuário.

Desvantagens:
Necessário servidor adicional
Existe um overhead (comunicação “extra” entre o FES e o BES).

Embedded
Vantagens:
Menor latência de dados (não existe overhead entre BES e FES, pois são o mesmo
servidor);
Custo reduzido (apenas um servidor para tudo);

Desvantagens:
É impossível gerar um Fiori Launchpad como centralizador;
Mais difícil de manter atualizado;
Exposição a ataques aumentada.

Tipos de aplicação
1. Quais são os três tipos de aplicação que podem ser atualmente desenvolvidos no SAP
Fiori?
R: Aplicações transacionais, analíticas e de ficha informativa.

2. Qualquer banco de dados pode ser utilizado para os três tipos de aplicação? Explique.
R: Não. Algumas aplicações necessitam de banco de dados SAP HANA para execução,
pois possuem características que apenas um banco de dados em memória consegue
prover, como o processamento de grande quantidade de dados em um curto espaço de
tempo.

147
 3. Como é feita a comunicação de uma ficha informativa com o banco de dados em uma
instalação SAP Business Suite?
A comunicação é feita através do protocolo InA, tecnologia proprietária que se conecta
diretamente ao banco da dados SAP HANA.

SAP Fiori Launchpad

1. Qual o principal componente do SAP Fiori Launchpad?
É a home page.
2. Como se acessa o Fiori Launchpad?
O SAP FLP pode ser acessado pela transação /UI2/FLP ou diretamente por um
navegador, através do endereço <servidor>/sap/bc/ui2/flp.
3. O que é tile no SAP FLP?
Tile é uma representação gráfica em formato de ladrilho que redireciona o usuário para
uma aplicação SAP Fiori.

SAP Gateway
1. O que é o SAP Gateway e quais são suas vantagens?
R: O SAP Gateway é um framework disponível nos servidores SAP Business Suite e
S/4HANA. Ele é aberto ao consumo de qualquer dispositivo ou plataforma, com APIs
simples e baseado em padrões de mercado. Ele promove a diminuição da barreira do
consumo de dados: uma vez que o consumo de dados foi definido, qualquer interface
pode ser integrada. Além disso, esconde a complexidade técnica de um landscape SAP,
centralizando requisições. A codificação dos serviços disponibilizados no SAP Gateway
é realizada em ABAP.

2. O que é o protocolo OData?

R: Os serviços são baseados no padrão oData (Open Data Protocol). Este é um padrão
RESTful que não impõe restrições no formato da mensagem. Os formatos aceitos são
JSON, XML e ATOM. Geralmente, serviços desenhados neste protocolo são mais rápidos
se comparados a outros padrões, pois trabalham com o mínimo de informação (baixo
overhead). Os serviços oData possuem uma chamada específica para busca de
metadados ($metadata).

3. Qual é a facilidade trazida pelo SAP Gateway Service Builder?

R: O Service Builder permite a rápida criação de serviços OData a partir de uma IDE de
modelagem de metadados. Todos os artefatos que tomariam tempo para serem
gerados são automaticamente criados e atualizados por ele.

4. Quais são as 5 operações básicas que podem ser executadas em uma entidade do
protocolo OData?
R: CRUDQ – Create, Read, Update, Delete e Query. Compatíveis aos métodos
CreateEntity, GetEntity, UpdateEntity, DeleteEntity e GetEntity.

5. Qual a função de um alias de sistema?

148
 O alias de sistema tem a função de abstrair o destino que está sendo consumido por
uma aplicação SAP Fiori. Nessa estruturação, a aplicação não deve se preocupar em qual
rota deve ser chamada, e sim em qual alias. O próprio sistema faz o direcionamento
para o servidor correto.

6. Você foi recrutado para um projeto de implementação do S/4HANA e deve criar uma
aplicação SAP Fiori para manutenção dos parceiros de negócios do cliente.
Os business partners substituem a estrutura clássica do SAP, centralizando clientes e
fornecedores em um número e permitindo a criação de papéis.
Por possuir mais experiência no desenvolvimento ABAP, o gerente de projetos te deixa
encarregado da criação dos serviços no SAP Gateway, enquanto um colega fica
responsável pela criação da camada SAPUI5.

Os requisitos apresentados são:

o O serviço deve disponibilizar a leitura individual e em lista de parceiros de
negócios. A leitura individual será realizada pela chave do parceiro. A leitura em
lista permitirá os seguintes parâmetros de filtragem:
▪ ID do parceiro;
▪ Nome do parceiro;
▪ Termo de pesquisa 1 e 2;
▪ Cidade;

A entidade BusinessPartner deve conter as seguintes propriedades, passíveis de

exibição e modificação:

▪ ID do parceiro;
▪ Nome do parceiro (organização ou pessoa);
▪ Tipo do parceiro;
▪ Termo de pesquisa 1;
▪ Termo de pesquisa 2;
▪ Logradouro;
▪ Número;
▪ Bairro;
▪ Cidade;
▪ Estado;
▪ CEP;
▪ País;
▪ Idioma.

O serviço também deve permitir a ordenação por todas as propriedades

estruturadas na entidade de retorno.

o O serviço deve permitir a criação e atualização de um parceiro de negócios.

o A exclusão de um parceiro de negócios não deve ser permitida.
É desejável a exibição e manutenção de organizações e pessoas.

Após investigação, você descobriu que:

o Para buscar parceiros de negócios, você pode utilizar o módulo de função
BUPA_SEARCH (para buscar todos, passar * no ID do parceiro);

149
 o Para ler um parceiro, você pode utilizar os módulos de função
BAPI_BUPA_CENTRAL_GETDETAIL e BAPI_BUPA_ADDRESS_GETDETAIL com
base no parceiro selecionado;
o Para criar um parceiro, utilize a BAPI BAPI_BUPA_CREATE_FROM_DATA.

Com base nos dados acima, estruture o serviço OData na SEGW. Utilize como padrão o
nome do projeto ZBP_XX, onde XX é o número do aluno. O pacote a ser utilizado é o
ZFIORI_002. Os parceiros devem ser criados no agrupamento TCAG (PARTNERGROUP).
Gere uma estrutura DDIC para a modelagem dos dados.

R: Acessar transação SEGW e criar projeto ZBP_XX, onde XX é o número do aluno.

Acessar SE11. Gerar estrutura auxiliar.

150
Dados base para geração da estrutura

PARTNER_ID 1 Types BU_PARTNER

PARTNER_TYPE 1 Types BU_TYPE
PARTNER_NAME1 1 Types BU_MCNAME1
PARTNER_NAME2 1 Types BU_MCNAME2
SEARCH_TERM1 1 Types BU_SORT1
SEARCH_TERM2 1 Types BU_SORT2
STREET 1 Types AD_STREET
HOUSE_NUMBER 1 Types AD_HSNM1
DISTRICT 1 Types AD_CITY2
CITY 1 Types AD_CITY1
REGION 1 Types REGIO
ZIP_CODE 1 Types AD_PSTCD1
COUNTRY 1 Types LAND1

Na transação SEGW, gerar um novo modelo de dados baseado em estrutura DDIC.

151
Selecionar todas as propriedades. Marcar como chave a propriedade PartnerId.

152
Após a criação, verifique a geração da entidade e do seu conjunto.

Marque as propriedades de criação, atualização, filtragem e ordenação dos campos em

destaque. Estas marcações gerarão annotations compatíveis com aplicações SAP Fiori
Elements.

Marque as propriedades também para o conjunto BusinessPartnerSet.

Gere os artefatos.

Entre com os valores para geração. Por padrão, são inseridos os prefixos
correspondentes a cada tipo de objeto. Mude apenas se necessário.

153
Verifique a geração dos artefatos de runtime.

Nos artefatos, clique duas vezes na classe DPC_EXT para navegar para a implementação
do serviço.

Verifique a geração automática dos métodos para o modelo de dados gerado.

Marque o método de criação e selecione a redefinição.

154
 Ao abrir o editor ABAP, codifique o valor abaixo.
METHOD businesspartners_create_entity.
DATA: lt_return TYPE bapiret2_t,
ls_business_partner TYPE zcl_zbp_00_mpc=>ts_businesspartner,
ls_central_data TYPE bapibus1006_central,
ls_central_data_person TYPE bapibus1006_central_person,
ls_central_data_organization TYPE bapibus1006_central_organ,
ls_address_data TYPE bapibus1006_address,
ls_t100 TYPE scx_t100key.

"Read data from data provider

io_data_provider->read_entry_data(
IMPORTING
es_data = ls_business_partner ).

"Set data do central data

ls_central_data-searchterm1 = ls_business_partner-search_term1.
ls_central_data-searchterm2 = ls_business_partner-search_term2.

"Set data to address

ls_address_data-street = ls_business_partner-street.
ls_address_data-house_no = ls_business_partner-house_number.
ls_address_data-district = ls_business_partner-district.
ls_address_data-city = ls_business_partner-city.
ls_address_data-region = ls_business_partner-region.
ls_address_data-postl_cod1 = ls_business_partner-zip_code.
ls_address_data-country = ls_business_partner-country.

"Check which type will be created

CASE ls_business_partner-partner_type.
WHEN 1.
ls_central_data_person-firstname = ls_business_partner-partner_name1.
ls_central_data_person-lastname = ls_business_partner-partner_name2.

WHEN 2.
ls_central_data_organization-name1 = ls_business_partner-partner_name1.
ls_central_data_organization-name2 = ls_business_partner-partner_name2.

WHEN OTHERS.
RETURN.
ENDCASE.

"Create business partner

CALL FUNCTION 'BAPI_BUPA_CREATE_FROM_DATA'
EXPORTING
partnercategory = ls_business_partner-partner_type
partnergroup = 'TCAG'
centraldata = ls_central_data
centraldataperson = ls_central_data_person
centraldataorganization = ls_central_data_organization
addressdata = ls_address_data
IMPORTING
businesspartner = ls_business_partner-partner_id
TABLES
return = lt_return.

"Check if an error occured

READ TABLE lt_return ASSIGNING FIELD-SYMBOL(<return>) WITH KEY type = 'E'.
IF sy-subrc = 0.
ls_t100-msgid = <return>-id.
ls_t100-msgno = <return>-number.

155
 ls_t100-attr1 = <return>-message_v1.
ls_t100-attr2 = <return>-message_v2.
ls_t100-attr3 = <return>-message_v3.
ls_t100-attr4 = <return>-message_v4.

RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception

EXPORTING
textid = ls_t100
entity_type = iv_entity_name
message = <return>-message.
ENDIF.

er_entity = ls_business_partner.
ENDMETHOD.

Uma vez implementado, teste o serviço. Acesse a transação /IWFND/MAINT_SERVICE

para executar o registro antes do teste. Selecione o botão de adicionar serviço. Na
sequência, entre com o nome do projeto gerado seguido do final “_SRV” (padrão). Siga
os passos até o final do registro.

156
 Uma vez registrado, acesse a transação /IWFND/GW_CLIENT. Adicione o caminho do
serviço e execute a chamada aos seus metadados a partir da adição $metadata
(/sap/opu/odata/sap/ZBP_XX_SRV/$metadata).

Testado com sucesso, agora é a hora de executar a criação de uma entidade baseada no
serviço. Marque o método POST e a URL
/sap/opu/odata/sap/ZBP_XX_SRV/BusinessPartnerSet.

Adicione o tipo de conteúdo ao cabeçalho (botão + no HTTP Request) e adicione o

conteúdo JSON sugerido abaixo.
{
"PartnerType" : "2",
"PartnerName1" : "Organization Test",
"PartnerName2" : "Inc.",
"SearchTerm1" : "Fiori",

157
 "SearchTerm2" : "Trainning",
"Street" : "Avenida Paulista",
"HouseNumber" : "2200",
"District" : "Bela Vista",
"City" : "São Paulo",
"Region" : "SP",
"ZipCode" : "01310-932",
"Country" : "BR"
}

Execute o método e constate a criação. Verifique o ID do parceiro criado.

Na transação BP, selecione o ID criado e verifique os dados inseridos a partir do JSON

da requisição.

158
 Em seguida, implemente o método de seleção de entidade. Adicione o código na
sequência e ative a classe.

METHOD businesspartners_get_entity.
DATA: lt_return TYPE bapiret2_t,
ls_central_data TYPE bapibus1006_central,
ls_central_data_person TYPE bapibus1006_central_person,
ls_central_data_organization TYPE bapibus1006_central_organ,
ls_address_data TYPE bapibus1006_address,
ls_t100 TYPE scx_t100key,
lv_partner_id TYPE bu_partner.

TRY.
lv_partner_id = it_key_tab[ name = 'PartnerId' ]-value.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING
input = lv_partner_id
IMPORTING
output = lv_partner_id.

CATCH cx_sy_itab_line_not_found.
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
entity_type = iv_entity_name
message = TEXT-001. "Key not found in parameters
ENDTRY.

159
 "Get central data
CALL FUNCTION 'BAPI_BUPA_CENTRAL_GETDETAIL'
EXPORTING
businesspartner = lv_partner_id
IMPORTING
centraldata = ls_central_data
centraldataperson = ls_central_data_person
centraldataorganization = ls_central_data_organization
TABLES
return = lt_return.

READ TABLE lt_return ASSIGNING FIELD-SYMBOL(<return>) WITH KEY type = 'E'.

IF sy-subrc = 0.
ls_t100-msgid = <return>-id.
ls_t100-msgno = <return>-number.
ls_t100-attr1 = <return>-message_v1.
ls_t100-attr2 = <return>-message_v2.
ls_t100-attr3 = <return>-message_v3.
ls_t100-attr4 = <return>-message_v4.

RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception

EXPORTING
textid = ls_t100
entity_type = iv_entity_name
message = <return>-message.
ENDIF.

"Get address data

CALL FUNCTION 'BAPI_BUPA_ADDRESS_GETDETAIL'
EXPORTING
businesspartner = lv_partner_id
IMPORTING
addressdata = ls_address_data.

"Check if it's a person or an organization

IF ls_central_data_person IS NOT INITIAL.
er_entity-partner_name1 = ls_central_data_person-firstname.
er_entity-partner_name2 = ls_central_data_person-lastname.
er_entity-partner_type = '1'.
ELSEIF ls_central_data_organization IS NOT INITIAL.
er_entity-partner_name1 = ls_central_data_organization-name1.
er_entity-partner_name2 = ls_central_data_organization-name2.
er_entity-partner_type = '2'.
ENDIF.

"Map to entity
er_entity-partner_id = lv_partner_id.
er_entity-search_term1 = ls_central_data-searchterm1.
er_entity-search_term2 = ls_central_data-searchterm2.
er_entity-street = ls_address_data-street.
er_entity-house_number = ls_address_data-house_no.
er_entity-district = ls_address_data-district.
er_entity-city = ls_address_data-city.
er_entity-region = ls_address_data-region.
er_entity-zip_code = ls_address_data-postl_cod1.
er_entity-country = ls_address_data-country.
ENDMETHOD.

Na transação /IWFND/GW_CLIENT, teste o serviço. Dessa vez, utilize o método GET e a

chave da entidade criada no passo anterior. Ao executar, verifique os dados da entidade
carregados na área de resposta.

160
 Redefina o método de consulta. Adicione o código abaixo para implementar as
funcionalidades de consulta ($filter, $search, $top, $skip e $orderby).

METHOD businesspartners_get_entityset.
DATA: lt_result TYPE TABLE OF bus020_search_result,
lt_entityset TYPE zcl_zbp_00_mpc=>tt_businesspartner,
lt_tech_order TYPE /iwbep/t_mgw_tech_order,
lt_sort TYPE abap_sortorder_tab,
ls_address TYPE bupa_addr_search,
ls_central_data TYPE bapibus1006_central,
ls_central_data_person TYPE bapibus1006_central_person,
ls_central_data_organization TYPE bapibus1006_central_organ,
ls_address_data TYPE bapibus1006_address,
ls_entityset LIKE LINE OF lt_entityset,
lv_mc_name1 TYPE bu_mcname1,
lv_mc_name2 TYPE bu_mcname2,
lv_partner TYPE bu_partner,
lv_sort1 TYPE bu_sort1,
lv_sort2 TYPE bu_sort2,
lv_category TYPE bu_type,
lv_from TYPE i,
lv_to TYPE i.

IF iv_search_string IS NOT INITIAL.

"Map search string to parameters

lv_partner = lv_mc_name1 =
lv_mc_name2 = lv_sort1 =
lv_sort2 = lv_category =
ls_address-street = ls_address-house_num1 =
ls_address-city2 = ls_address-city1 =
ls_address-region = ls_address-post_code1 =
ls_address-country = iv_search_string.

ELSE.

"Map filter to parameters

LOOP AT it_filter_select_options ASSIGNING FIELD-SYMBOL(<filter>).
CASE <filter>-property.
WHEN 'PartnerId'.
lv_partner = <filter>-select_options[ 1 ]-low.
WHEN 'PartnerName1'.
lv_mc_name1 = <filter>-select_options[ 1 ]-low.

161
 WHEN 'PartnerName2'.
lv_mc_name2 = <filter>-select_options[ 1 ]-low.
WHEN 'SearchTerm1'.
lv_sort1 = <filter>-select_options[ 1 ]-low.
WHEN 'SearchTerm2'.
lv_sort2 = <filter>-select_options[ 1 ]-low.
WHEN 'PartnerType'.
lv_category = <filter>-select_options[ 1 ]-low.
WHEN 'Street'.
ls_address-street = <filter>-select_options[ 1 ]-low.
WHEN 'HouseNumber'.
ls_address-house_num1 = <filter>-select_options[ 1 ]-low.
WHEN 'District'.
ls_address-city2 = <filter>-select_options[ 1 ]-low.
WHEN 'City'.
ls_address-city1 = <filter>-select_options[ 1 ]-low.
WHEN 'Region'.
ls_address-region = <filter>-select_options[ 1 ]-low.
WHEN 'ZipCode'.
ls_address-post_code1 = <filter>-select_options[ 1 ]-low.
WHEN 'Country'.
ls_address-country = <filter>-select_options[ 1 ]-low.
ENDCASE.
ENDLOOP.
ENDIF.

"If nothing is supplied, set partner ID as *

IF lv_partner IS INITIAL AND lv_mc_name1 IS INITIAL
AND lv_mc_name2 IS INITIAL AND lv_sort1 IS INITIAL
AND lv_sort2 IS INITIAL AND lv_category IS INITIAL
AND ls_address-street IS INITIAL AND ls_address-house_num1 IS INITIAL
AND ls_address-city2 IS INITIAL AND ls_address-city1 IS INITIAL
AND ls_address-region IS INITIAL AND ls_address-post_code1 IS INITIAL
AND ls_address-country IS INITIAL.
lv_partner = '*'.
ENDIF.

"Search for BPs

CALL FUNCTION 'BUPA_SEARCH'
EXPORTING
iv_mc_name1 = lv_mc_name1
iv_mc_name2 = lv_mc_name2
is_address = ls_address
iv_partner = lv_partner
iv_sort1 = lv_sort1
iv_sort2 = lv_sort2
iv_category = lv_category
TABLES
et_search_result = lt_result.

"Paging
IF is_paging-top = 0.
lv_to = lines( lt_result ).
ELSE.
lv_to = is_paging-top.
ENDIF.

lv_from = is_paging-skip + 1.

"For each result, get details

LOOP AT lt_result ASSIGNING FIELD-SYMBOL(<result>) FROM lv_from
TO lv_to.
CLEAR: ls_central_data,
ls_central_data_person,
ls_central_data_organization,
ls_entityset.

CALL FUNCTION 'BAPI_BUPA_CENTRAL_GETDETAIL'

EXPORTING
businesspartner = <result>-partner
IMPORTING

162
 centraldata = ls_central_data
centraldataperson = ls_central_data_person
centraldataorganization = ls_central_data_organization.

"Get address data

CALL FUNCTION 'BAPI_BUPA_ADDRESS_GETDETAIL'
EXPORTING
businesspartner = <result>-partner
IMPORTING
addressdata = ls_address_data.

"Check if it's a person or an organization

IF ls_central_data_person IS NOT INITIAL.
ls_entityset-partner_name1 = ls_central_data_person-firstname.
ls_entityset-partner_name2 = ls_central_data_person-lastname.
ls_entityset-partner_type = '1'.
ELSEIF ls_central_data_organization IS NOT INITIAL.
ls_entityset-partner_name1 = ls_central_data_organization-name1.
ls_entityset-partner_name2 = ls_central_data_organization-name2.
ls_entityset-partner_type = '2'.
ELSE.
CONTINUE.
ENDIF.

"Map to entity
ls_entityset-partner_id = <result>-partner.
ls_entityset-search_term1 = ls_central_data-searchterm1.
ls_entityset-search_term2 = ls_central_data-searchterm2.
ls_entityset-street = ls_address_data-street.
ls_entityset-house_number = ls_address_data-house_no.
ls_entityset-district = ls_address_data-district.
ls_entityset-city = ls_address_data-city.
ls_entityset-region = ls_address_data-region.
ls_entityset-zip_code = ls_address_data-postl_cod1.
ls_entityset-country = ls_address_data-country.
APPEND ls_entityset TO lt_entityset.
ENDLOOP.

"Set sort conditions, if necessary

IF it_order IS NOT INITIAL.
lt_tech_order = io_tech_request_context->get_orderby( ).

LOOP AT lt_tech_order ASSIGNING FIELD-SYMBOL(<tech_order>).

APPEND INITIAL LINE TO lt_sort ASSIGNING FIELD-SYMBOL(<sort>).
<sort>-name = <tech_order>-property.

IF <tech_order>-order = 'desc'.
<sort>-descending = abap_true.
ENDIF.
ENDLOOP.

SORT lt_entityset BY (lt_sort).

ENDIF.

"Return entity set to parameter

et_entityset = lt_entityset.
ENDMETHOD.

Realize o teste inicial chamando apenas o conjunto BusinessPartnerSet, sem qualquer

adição, utilizando o método GET.

163
Na sequência, realize testes com adições para filtragem, ordenação e paginação. É
possível fazer composições para verificar o comportamento do serviço implementado.

Implemente o último método para atualização com o código da sequência.

164
METHOD businesspartners_update_entity.
DATA: lt_return TYPE bapiret2_t,
ls_central_data TYPE bapibus1006_central,
ls_central_data_person TYPE bapibus1006_central_person,
ls_central_data_organization TYPE bapibus1006_central_organ,
ls_address_data TYPE bapibus1006_address,
ls_central_data_x TYPE bapibus1006_central_x,
ls_central_data_person_x TYPE bapibus1006_central_person_x,
ls_central_data_organization_x TYPE bapibus1006_central_organ_x,
ls_address_data_x TYPE bapibus1006_address_x,
ls_t100 TYPE scx_t100key,
ls_business_partner TYPE zcl_zbp_00_mpc=>ts_businesspartner,
lv_partner_id TYPE bu_partner.

"Map key
TRY.
lv_partner_id = it_key_tab[ name = 'PartnerId' ]-value.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING
input = lv_partner_id
IMPORTING
output = lv_partner_id.

CATCH cx_sy_itab_line_not_found.
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
entity_type = iv_entity_name
message = TEXT-001. "Key not found in parameters
ENDTRY.

"Read data from data provider

io_data_provider->read_entry_data(
IMPORTING
es_data = ls_business_partner ).

"Set data do central data

ls_central_data-searchterm1 = ls_business_partner-search_term1.
ls_central_data-searchterm2 = ls_business_partner-search_term2.

ls_central_data_x-searchterm1 =
ls_central_data_x-searchterm2 = abap_true.

"Set data to address

ls_address_data-street
ls_address_data-house_no
ls_address_data-district
ls_address_data-city
ls_address_data-region
ls_address_data-postl_cod1
ls_address_data-country
= ls_business_partner-street.
= ls_business_partner-house_number.
= ls_business_partner-district.
= ls_business_partner-city.
= ls_business_partner-region.
= ls_business_partner-zip_code.
= ls_business_partner-country.

ls_address_data_x-street =
ls_address_data_x-house_no =
ls_address_data_x-district =
ls_address_data_x-city =

165
ls_address_data_x-region =
ls_address_data_x-postl_cod1 =
ls_address_data_x-country = abap_true.

"Check which type will be created

CASE ls_business_partner-partner_type.
WHEN 1.
ls_central_data_person-firstname = ls_business_partner-partner_name1.
ls_central_data_person-lastname = ls_business_partner-partner_name2.

ls_central_data_person_x-firstname =
ls_central_data_person_x-lastname = abap_true.

WHEN 2.
ls_central_data_organization-name1 = ls_business_partner-partner_name1.
ls_central_data_organization-name2 = ls_business_partner-partner_name2.

ls_central_data_organization_x-name1 =
ls_central_data_organization_x-name2 = abap_true.

WHEN OTHERS.
RETURN.
ENDCASE.

"Change central data

CALL FUNCTION 'BAPI_BUPA_CENTRAL_CHANGE'
EXPORTING
businesspartner = lv_partner_id
centraldata = ls_central_data
centraldataperson = ls_central_data_person
centraldataorganization = ls_central_data_organization
centraldata_x = ls_central_data_x
centraldataperson_x = ls_central_data_person_x
centraldataorganization_x = ls_central_data_organization_x
TABLES
return = lt_return.

READ TABLE lt_return ASSIGNING FIELD-SYMBOL(<return>) WITH KEY type = 'E'.

IF sy-subrc = 0.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

ls_t100-msgid = <return>-id.
ls_t100-msgno = <return>-number.
ls_t100-attr1 = <return>-message_v1.
ls_t100-attr2 = <return>-message_v2.
ls_t100-attr3 = <return>-message_v3.
ls_t100-attr4 = <return>-message_v4.

RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception

EXPORTING
textid = ls_t100
entity_type = iv_entity_name
message = <return>-message.
ENDIF.

"Change address data

CALL FUNCTION 'BAPI_BUPA_ADDRESS_CHANGE'
EXPORTING
businesspartner = lv_partner_id
addressdata = ls_address_data
addressdata_x = ls_address_data_x
TABLES
return = lt_return.

READ TABLE lt_return ASSIGNING <return> WITH KEY type = 'E'.

IF sy-subrc = 0.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

ls_t100-msgid = <return>-id.
ls_t100-msgno = <return>-number.
ls_t100-attr1 = <return>-message_v1.

166
 ls_t100-attr2 = <return>-message_v2.
ls_t100-attr3 = <return>-message_v3.
ls_t100-attr4 = <return>-message_v4.

RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception

EXPORTING
textid = ls_t100
entity_type = iv_entity_name
message = <return>-message.
ENDIF.

"Return changed data to entity

"Check if it's a person or an organization
IF ls_central_data_person IS NOT INITIAL.
er_entity-partner_name1 = ls_central_data_person-firstname.
er_entity-partner_name2 = ls_central_data_person-lastname.
er_entity-partner_type = '1'.
ELSEIF ls_central_data_organization IS NOT INITIAL.
er_entity-partner_name1 = ls_central_data_organization-name1.
er_entity-partner_name2 = ls_central_data_organization-name2.
er_entity-partner_type = '2'.
ENDIF.

"Map to entity
er_entity-partner_id = lv_partner_id.
er_entity-search_term1 = ls_central_data-searchterm1.
er_entity-search_term2 = ls_central_data-searchterm2.
er_entity-street = ls_address_data-street.
er_entity-house_number = ls_address_data-house_no.
er_entity-district = ls_address_data-district.
er_entity-city = ls_address_data-city.
er_entity-region = ls_address_data-region.
er_entity-zip_code = ls_address_data-postl_cod1.
er_entity-country = ls_address_data-country.
ENDMETHOD.

Deve-se utilizar o método PUT e definir a chave na chamada. Também deve ser passado
na requisição o conteúdo que atualizará a entidade e o tipo de conteúdo no cabeçalho.
Abaixo, está sugerido o JSON para teste.
{
"PartnerType" : "2",
"PartnerName1" : "Organization Test New",
"PartnerName2" : "Inc.",
"SearchTerm1" : "Fiori",
"SearchTerm2" : "Trainning",
"Street" : "Avenida Paulista",
"HouseNumber" : "2201",
"District" : "Bela Vista",
"City" : "São Paulo",
"Region" : "SP",
"ZipCode" : "01310-932",
"Country" : "BR"
}

Ao executar o método de atualização, nenhum conteúdo é retornado. É necessário

realizar nova busca para verificar as alterações.

167
Ferramentas para desenvolvimento
1. Quais são os benefícios da computação em nuvem?
R: As vantagens são:
Custo benefício: redução geral de custos com hardware e equipe;
Flexibilidade: dimensionamento flexível de recursos;
Confiabilidade: downtime mínimo;
Segurança: soluções sólidas com padrões de segurança.

2. Quais os modelos básicos de comercialização da computação em nuvem? Explique cada

um deles.
R: IaaS: Infrastructure As A Service, nível de abstração mais alto, onde a infraestrutura
(virtualização de recursos de armazenamento, servidores e outros tipos de hardware) é
provida através de um serviço em nuvem. Entre os serviços mais comum, estão os
provedores como o Microsoft Azure, o Google Cloud e o AWS;
PaaS: Platform As A Service, nível de abstração intermediário, onde não só a
infraestrutura é provida, como também recursos para aceleração do processo de
desenvolvimento. Aqui, podem ser disponibilizados bancos de dados, serviços para
conectividade e segurança, frameworks de desenvolvimento etc. O SAP Cloud Platform
se enquadra nesta categoria;
SaaS: Software As A Service, nível de abstração mais baixo, provavelmente o mais
comum dos modelos ao consumidor final, onde um software é totalmente entregue em
formato de serviço. Neste caso, a plataforma já é englobada, não havendo necessidade

168
 de hardware. Nesta categoria, entram softwares robustos como o SAP SuccessFactors e
SAP Ariba, até os pioneiros webmails.

3. Qual é a vantagem de se construir um protótipo? Qual a ferramenta utilizada para se

construir protótipos de aplicações SAP Fiori?
R: Os protótipos são maneiras de antecipar entregas, permitindo que o produto seja
visualizado antes que o desenvolvimento tenha se findado. A ferramenta principal para
criação de protótipos SAP Fiori é o SAP BUILD.

4. Você está participando de um projeto de migração para S/4HANA e é o responsável SAP

Fiori. O consultor funcional de SAP HCM requisitou a criação de uma aplicação onde os
colaboradores pudessem enxergar seus dados pessoais.

Em reunião, percebeu-se que a Object Page atenderia a visualização do perfil. O usuário

final, porém, veio de uma implementação anterior traumática e tem medo de que essa
nova aplicação não atinja os objetivos da organização.

Como sugestão, você levanta a possibilidade de gerar um protótipo para demonstrar

como seria a navegação na aplicação, tranquilizar o usuário e, finalmente, evitar
retrabalho. Como ferramenta, você utilizará o SAP BUILD.

Os requisitos levantados junto aos usuários são a apresentação dos seguintes dados:

• Cabeçalho da aplicação
o Foto do colaborador;
o No título, nome e sobrenome;
o No subtítulo, cargo;
o Telefone e e-mail corporativo como links;
• Informações gerais
o Empresa;
o Centro de custos;
o Unidade organizacional;
o Gestor;
• Colaborador
o Região;
o País;
o Idioma.

Estruture uma entidade através do Data Explorer de forma que seja possível modificar
os dados apresentados de maneira fácil. Utilize o template de Object Page disponível
para facilitar a criação.

Após estruturar o protótipo, gere um estudo para encaminhar para feedback do usuário.

R: Acesse o SAP BUILD e inicie a criação de um novo projeto.

169
O primeiro passo é a criação da persona. Esta é a representação de um papel com
objetivos, responsabilidades e pontos de incômodo. Estruturar a persona Colaborador
com um descritivo do papel desempenhado. Pode-se adicionar uma foto para
representação.

Após criação da persona, deve-se gerar o protótipo inicial. Utilize a criação a partir de
um template.

170
Descreva a aplicação que será criada. Em seguida, selecione o template para Object
Page.

Após a criação, edite a página inicialmente gerada.

Selecione a área de dados e acesse o editor.

171
Ao abri-lo, inicie a estruturação do objeto Colaborador. Adicione nessa estrutura as
propriedades que deverão ser apresentadas na aplicação.

172
Na sequência, entre no editor de amostras e adicione uma ou mais linhas do objeto
colaborador. É possível carregar dados por um arquivo Excel. No caso, utilize o editor
fornecido pela própria ferramenta e adicione dados para exemplificar a aplicação.

Retorne para a Object Page, selecione a página principal e marque qual será o objeto a
ser utilizado como contexto, no caso, Colaborador.

173
Em seguida, apresente a instância que será demonstrada no protótipo. Esta instância
pode ser trocada para exemplificar outros dados.

Então, comece as modificações na tela. Para modificar um elemento, deve-se clicar

sobre ele através da área central ou navegar através da árvore de objetos até atingi-lo
(recomendado). Clique no link com o telefone e altere a propriedade para Telefone.

Na página principal, selecione o elemento de cabeçalho. Altere a imagem para o ícone

disponível na biblioteca SAPUI5.

174
Ainda na página principal, no campo de título, modifique para NomeCompleto. No
subtítulo, insira Cargo.

Finaliza a alteração do cabeçalho adicionando o campo Email ao último link.

Exclua a mensagem de boas-vindas clicando sobre ela e selecionando a opção Delete.

Faça o mesmo com o texto da primeira subseção.

175
Modifique o título da primeira subseção para Informações Gerais. Adicione na área de
blocos um Form (representação de formulário no formato rótulo-campo).

Duplique a linha de formulário que possui rótulo e campo de texto. Repita o processo
até ter 4 linhas iguais. Remova as demais linhas do formulário.

Modifique as linhas do formulário. Inicie pelos rótulos (label). Para cada rótulo,
modifique para o descritivo da propriedade que será exibida. Por exemplo, “Empresa”.
Na sequência, altere o valor atribuído ao campo de texto para a propriedade
correspondente (Empresa).

176
Repita o processo para todos os campos da primeira subseção.

Realize o mesmo processo, agora para a segunda subseção. Adicione os campos que
faltantes em formato de formulário. Remova elementos que estejam em excesso e que
não serão utilizados, como o botão de ação no topo do cabeçalho e os títulos das
subseções. Uma vez finalizado, visualize o protótipo.

Verifique o comportamento em diferentes dispositivos para perceber a responsividade

das bibliotecas SAPUI5.

177
Ao finalizar a visualização, crie um estudo para coleta de feedbacks. Adicione uma
mensagem para descrever o estudo que será realizado.

Agora, modifique a pergunta padrão do estudo. Ao clicar, escolha o tipo de coleta que
será utilizada. Adicione um texto para auxiliar o participante a realizar o teste do
protótipo.

178
Finalizada a geração das perguntas, o estudo está pronto para ser publicado. Clique no
botão de publicação e verifique, em pré-visualização, como o estudo ocorrerá. Ajuste-
o, caso necessário. Compartilhe o link com os participantes ou indique-os na área de
mesmo nome.

179
5. Qual é a atual ferramenta para desenvolvimento de aplicações SAP Fiori?
SAP Web IDE, ferramenta disponível na nuvem a partir do SAP Cloud Platform

6. Qual é a função de um destino na área de conectividade do SAP Cloud Platform?

O destino faz o papel de abstração da conexão com o servidor provedor de dados. Esta
abordagem faz com que o desenvolvedor não tenha, necessariamente, o conhecimento
sobre o real destino das chamadas. A própria plataforma realiza o redirecionamento das
requisições de um destino para o servidor correto.

7. Qual é a função do Cloud Connector?

O SAP Cloud Connector é um servidor leve que permite a conexão da plataforma SAP
Cloud Platform com servidores on-premise, através de um túnel seguro em tecnologia
proprietária. Apesar de funcionar como um web dispatcher, ele não precisa estar
localizado em uma DMZ, podendo ser utilizado na rede interna da empresa.

8. Você está participando de um projeto de migração para o S/4HANA. Em um primeiro

momento, foi feita uma divisão de atividades onde você seria responsável pelo
desenvolvimento de um serviço OData para criação e leitura de parceiros de negócios,
enquanto um colega ficaria responsável pelo desenvolvimento da interface de usuária
da aplicação SAP Fiori. Contudo, por uma questão de doença, seu colega foi afastado
por 15 dias e desfalcará o time neste período. Por já ter conhecimento da estrutura do
serviço, você deverá, então, finalizar este desenvolvimento.
Espera-se que a aplicação se inicie com a listagem de todos os business partners
disponíveis.
As colunas disponíveis na primeira lista serão:
o ID do parceiro;
o Nome do parceiro;
o Tipo do parceiro (transformado de código para descritivo);
o Região;

180
 o País.

A aplicação deverá permitir a criação de novos BPs a partir de um botão ou link de

criação. Também deverá permitir a exibição edição de registros existentes, navegando
a partir de um clique na linha da tabela. As telas de exibição e edição devem ser as
mesmas, utilizando apenas controles de tela para habilitar os campos. Todos os campos,
exceção ao ID do parceiro, podem ser modificados. O tipo de parceiro não pode ser
apresentado com valor técnico e deve ser transformado da seguinte forma:
o Valor “1” – “Organização”;
o Valor “2” – “Pessoa”.

Obs.: utilize uma aplicação SAPUI5 pura, sem nenhum template aplicado, para exercitar
todos os conceitos.

R: A partir do Web IDE, crie um novo projeto e selecione SAPUI5 Application. Crie um
projeto com nome e namespace. No caso, utilizou-se o mesmo nome, mas esta não é
uma obrigação. Como primeira visão, sugere-se o nome “App” em “XML”.

Com o projeto gerado, gere agora um novo serviço OData. Para isso, clique com o botão
direito no nome do projeto e escolha New > OData Service.

181
Indique o destino criado (Trainning) e na seleção do serviço, digite “ZBP” para
apresentar o serviço ZBP_XX_SRV, onde XX é o número utilizado pelo aluno. Utilize o
modelo como padrão do componente.

Após a criação do modelo, inicie a modificação das visões. Inicialmente, visite a visão
App e modifique o seu conteúdo como abaixo. Isto é feito com o intuito de a primeira
visão ser a centralizadora (contendo o componente Shell) enquanto as demais entrem
como páginas na propriedade de agregação pages.
App.view.xml

<mvc:View controllerName="bpmaint.bpmaint.controller.App" xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

xmlns="sap.m">
<Shell id="shell">
<App id="app"/>
</Shell>
</mvc:View>

182
Gere uma nova visão. Para isso, clique com o botão direito sobre a pasta webapp e
selecione New > SAPUI5 View. A primeira visão a ser criada representará a lista de
parceiros de negócios e foi declarada como “BPList”.

Após a criação da visão, modifique seu conteúdo como abaixo, para que ela não tenha
mais o componente Shell. Ela será agregada pela visão App a partir do roteamento.
BPList.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPList"
xmlns:html="http://www.w3.org/1999/xhtml">
<Page title="{i18n>appTitle}" showNavButton="true" navButtonPress="onNavBack">
<content></content>
</Page>
</mvc:View>

Repita o processo de criação para a visão BPDetail, que comportará o formulário.

BPDetail.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPDetail"
xmlns:html="http://www.w3.org/1999/xhtml">
<Page title="{PartnerId} {PartnerName1}" showNavButton="true" navButtonPress="onNavBack">

183
 <content></content>
</Page>
</mvc:View>

Para iniciar o roteamento, é necessário gerar novas rotas e alvos. São necessárias 4
rotas, sendo:
o Visão App para visão BPList (inicial) - ToBPList;
o Visão BPList para visão BPDetail, para exibição - ToBPDisplay;
o Visão BPList para visão BPDetail, para criação - ToBPCreate;
o Visão BPList para visão BPDetail, para modificação - ToBPEdit.
Todas as rotas são atingíveis por dois alvos:
o TargetBPList, para visão BPList;
o TargetBPDetail, para visão BPDetail.
Gere esta estrutura. Se necessário, utilize o arquivo manifesto abaixo como exemplo.
Modifique apenas a seção routing.
manifest.json

…
"routing": {
"config": {
"routerClass": "sap.m.routing.Router",
"viewType": "XML",
"async": true,
"viewPath": "bpmaint.bpmaint.view",
"controlAggregation": "pages",
"controlId": "app",
"clearControlAggregation": false,
"bypassed": {
"target": ["TargetBPList"]
}
},
"routes": [{
"name": "ToBPList",
"pattern": "",
"titleTarget": "",
"greedy": false,
"target": ["TargetBPList"]
}, {
"name": "ToBPCreate",
"pattern": "/bpCreate",
"titleTarget": "",
"greedy": false,
"target": ["TargetBPDetail"]
}, {
"name": "ToBPDisplay",
"pattern": "/{PartnerId}/bpDisplay",
"titleTarget": "",
"greedy": false,
"target": ["TargetBPDetail"]
}, {
"name": "ToBPEdit",
"pattern": "/{PartnerId}/bpEdit",
"titleTarget": "",
"greedy": false,
"target": ["TargetBPDetail"]
}],
"targets": {
"TargetApp": {
"viewType": "XML",
"transition": "slide",
"clearControlAggregation": false,

184
 "viewId": "App",
"viewName": "App"
},
"TargetBPList": {
"viewType": "XML",
"transition": "slide",
"clearControlAggregation": false,
"viewName": "BPList",
"viewId": "BPList",
"viewLevel": 1
},
"TargetBPDetail": {
"viewType": "XML",
"transition": "slide",
"clearControlAggregation": false,
"viewName": "BPDetail",
"viewLevel": 2,
"viewId": "BPDetail"
}
}
}
…

Com as rotas configuradas, agora deve-se criar o conteúdo das visões. Para a visão
BPList, gere uma tabela tableBPList que utilizará o conjunto de entidades desenvolvido,
BusinessPartnerSet.
Obs.: os passos de criação de UI podem utilizar o Layout Editor. Para isso, clique com o
botão direito sobre a visão e escolha esta opção para utilizar o editor gráfico.
BPList.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPList"
xmlns:html="http://www.w3.org/1999/xhtml">
<Page title="{i18n>appTitle}" showNavButton="true" navButtonPress="onNavBack">
<content>
<Table id="tableBPList" width="100%" items="{/BusinessPartnerSet}">
<columns>

</columns>
<items>

</items>
</Table>
</content>
</Page>
</mvc:View>

Continuando a criação, declare as colunas que a tabela possuirá. Em cada coluna,

declare um componente que fará parte do cabeçalho. No caso, para cada coluna, foi
gerado um texto de cabeçalho com o componente Text.
BPList.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPList"
xmlns:html="http://www.w3.org/1999/xhtml">
<Page title="{i18n>appTitle}" showNavButton="true" navButtonPress="onNavBack">
<content>
<Table id="tableBPList" width="100%" items="{/BusinessPartnerSet}">
<columns>
<Column>
<Text text="{i18n>txtPartner}"/>
</Column>

185
 <Column>
<Text text="{i18n>txtPartnerType}"/>
</Column>
<Column>
<Text text="{i18n>txtRegion}"/>
</Column>
<Column>
<Text text="{i18n>txtCountry}"/>
</Column>
</columns>
<items>

</items>
</Table>
</content>
</Page>
</mvc:View>

Agora, é necessário gerar o conteúdo da tabela. Declare um template, no caso,

ColumnListItem, e na propriedade cells, adicione os componentes que farão parte das
células da tabela.
BPList.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPList"
xmlns:html="http://www.w3.org/1999/xhtml">
<Page title="{i18n>appTitle}" showNavButton="true" navButtonPress="onNavBack">
<content>
<Table id="tableBPList" width="100%" items="{/BusinessPartnerSet}">
<columns>
<Column>
<Text text="{i18n>txtPartner}"/>
</Column>
<Column>
<Text text="{i18n>txtPartnerType}"/>
</Column>
<Column>
<Text text="{i18n>txtRegion}"/>
</Column>
<Column>
<Text text="{i18n>txtCountry}"/>
</Column>
</columns>
<items>
<ColumnListItem>
<cells>
<ObjectIdentifier title="{PartnerId}"
text="{PartnerName1} {PartnerName2}"/>
<Text text="{PartnerType}"/>
<Text text="{Region}"/>
<Text text="{Country}"/>
</cells>
</ColumnListItem>
</items>
</Table>
</content>
</Page>
</mvc:View>

Alguns métodos que serão gerados são comuns às visões do projeto. Para evitar
repetição de código, será criado um controlador de base e os demais controladores
farão referência a ele.

186
Para gerar um controlador de base, na pasta controller, selecione a criação de um novo
arquivo. Nomeie-o como BaseController.js. Adicione o código do controlador de base.
Ele será o responsável por executar a navegação para trás (“Voltar”) e também fará a
atribuição de uma rota a uma visão.

BaseController.js

sap.ui.define([
"sap/ui/core/mvc/Controller",
"sap/ui/core/routing/History"
], function (Controller, History) {
"use strict";

return Controller.extend("bpmaint.bpmaint.controller.BaseController", {
getRouter: function () {
return sap.ui.core.UIComponent.getRouterFor(this);
},

onNavBack: function (oEvent) {

var oHistory, sPreviousHash;
oHistory = History.getInstance();
sPreviousHash = oHistory.getPreviousHash();

if (sPreviousHash !== undefined) {

window.history.go(-1);
} else {
this.getRouter().navTo("ToBPList", {}, true);
}
},

attachRoute: function(sRoute, fRouteMatched) {

this.getRouter().getRoute(sRoute).attachPatternMatched(fRouteMatched, this);
}
});
});

Após esta modificação, revisite o controlador BPList e adicione o BaseController como

o controlador de base. Também atribua a rota “ToBPList” na sua inicialização e gere o
método onRouteMatched. Este método será ativado toda vez que a rota “ToBPList” for
atingida.
BPList.controller.js

187
sap.ui.define([
"bpmaint/bpmaint/controller/BaseController"
], function (BaseController) {
"use strict";

return BaseController.extend("bpmaint.bpmaint.controller.BPList", {

/**
* Called when a controller is instantiated and its View controls (if available) are already created.
* Can be used to modify the View before it is displayed, to bind event handlers and do other one-
time initialization.
* @memberOf bpmaint.bpmaint.view.BPList
*/
onInit: function () {
this.attachRoute("ToBPList", this.onRouteMatched);
},

onRouteMatched: function () {
this.getView().getModel().refresh(true, false);
}
});
});

Verifique o desenvolvimento até o momento.

Agora, os textos de tradução devem ser mantidos. Gere o arquivo i18n abaixo.
i18n.properties

#XTXT: Title
title=Business partner maintenance

#XTXT: Title
appTitle=Business partner maintenance

#XTXT: App description

appDescription=Business partner maintenance (create, update e display)

#XHED: Partner header column

txtPartner=Partner

#XHED: Partner type column

txtPartnerType=Partner type

#XHED: Region column

txtRegion=Region

#XHED: Country column

txtCountry=Country

#XHED: Options column

txtOptions=Options

188
#XBUT: Edit button
btnEdit=Edit

#XBUT: Display button

btnDisplay=Display

#XBUT: Create button

btnCreate=Create

Verifique novamente o desenvolvimento, agora apresentando os literais de idioma.

Na visão da listagem, adicione uma nova coluna para a criação dos botões de
visualização e edição da entidade. Adicione também no rodapé da página uma barra de
ferramentas com o botão de criação.
BPList.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPList"
xmlns:html="http://www.w3.org/1999/xhtml" xmlns:layout="sap.ui.layout">
<Page title="{i18n>appTitle}" showNavButton="true" navButtonPress="onNavBack">
<content>
<Table id="tableBPList" width="100%" items="{/BusinessPartnerSet}">
<columns>
<Column>
<Text text="{i18n>txtPartner}"/>
</Column>
<Column>
<Text text="{i18n>txtPartnerType}"/>
</Column>
<Column>
<Text text="{i18n>txtRegion}"/>
</Column>
<Column>
<Text text="{i18n>txtCountry}"/>
</Column>
<Column hAlign="Center">
<Text text="{i18n>txtOptions}"/>
</Column>
</columns>
<items>
<ColumnListItem>
<cells>
<ObjectIdentifier title="{PartnerId}"
text="{PartnerName1} {PartnerName2}"/>
<Text text="{PartnerType}"/>
<Text text="{Region}"/>
<Text text="{Country}"/>
<layout:HorizontalLayout>

189
 <Button id="buttonDisplay"
icon="sap-icon://display" press="onDisplayPress" tooltip="{i18n>buttonDisplay}"/>
<Button id="buttonEdit"
icon="sap-icon://edit" press="onEditPress" tooltip="{i18n>buttonEdit}"/>
</layout:HorizontalLayout>
</cells>
</ColumnListItem>
</items>
</Table>
</content>
<footer>
<OverflowToolbar>
<ToolbarSpacer/>
<Button id="buttonCreate" text="{i18n>buttonCreate}" type="Accept"
press="onCreatePress"/>
</OverflowToolbar>
</footer>
</Page>
</mvc:View>

Agora, no arquivo manifesto, modifique o modelo padrão (“”) para que ele comporte
modificações em ambos os sentidos. Esta propriedade é particularmente útil para
facilitar o envio de valores para o servidor SAP.
manifest.json

...
"models": {
"i18n": {
"type": "sap.ui.model.resource.ResourceModel",
"settings": {
"bundleName": "Customers.Customers.i18n.i18n"
}
},
"": {
"uri": "/sap/opu/odata/sap/ZUI5_SRV_01/",
"type": "sap.ui.model.odata.v2.ODataModel",
"settings": {
"defaultOperationMode": "Server",
"defaultBindingMode": "TwoWay",
"defaultCountMode": "Request"
},
"dataSource": "ZUI5_SRV_01",
"preload": true
}
},
...

Verifique novamente a aplicação e constate a inserção dos botões na tela.

190
Agora, serão codificados os eventos dos botões. Eles dispararão as navegações
necessárias.
Os botões de visualização e edição utilizarão o contexto em que eles estão inseridos
(isto é, a linha da entidade) para buscar o ID do parceiro e propagá-lo para a visão de
detalhe.
O botão de criação, por sua vez, fará apenas o encaminhamento à próxima visão.
BPList.controller.js

sap.ui.define([
"bpmaint/bpmaint/controller/BaseController"
], function (BaseController) {
"use strict";

return BaseController.extend("bpmaint.bpmaint.controller.BPList", {

/**
* Called when a controller is instantiated and its View controls (if available) are already created.
* Can be used to modify the View before it is displayed, to bind event handlers and do other one-
time initialization.
* @memberOf bpmaint.bpmaint.view.BPList
*/
onInit: function () {
this.attachRoute("ToBPList", this.onRouteMatched);
},

onRouteMatched: function () {
this.getView().getModel().refresh(true, false);
},

onDisplayPress: function (oEvent) {

var oSource = oEvent.getSource();
var oBindingContext = oSource.getBindingContext();

this.getRouter().navTo("ToBPDisplay", {
PartnerId: oBindingContext.getObject().PartnerId
});
},

onEditPress: function (oEvent) {

var oSource = oEvent.getSource();
var oBindingContext = oSource.getBindingContext();

this.getRouter().navTo("ToBPDisplay", {
PartnerId: oBindingContext.getObject().PartnerId
});
},

onCreatePress: function (oEvent) {

this.getRouter().navTo("ToBPCreate");
}
});
});

Na visão de detalhe, codifique o formulário. Utilize o Form para que haja responsividade
no redimensionamento de tela. Cada FormElement representa um ou mais campos
(quando especificado mais de um campo, eles serão agregados na mesma linha),
possuindo um rótulo apenas. Utilizou-se, como padrão, o campo Input para apresentar
cada uma das propriedades.

191
Obs: note que as propriedades estão sendo diretamente declaradas. Isto quer dizer que
utilizaremos o mapeamento de contexto nesta página. No caso, demonstraremos o
contexto selecionado na tela de listagem.
BPDetail.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

controllerName="bpmaint.bpmaint.controller.BPDetail"
xmlns:html="http://www.w3.org/1999/xhtml" xmlns:form="sap.ui.layout.form">
<Page title="{PartnerId} {PartnerName1}" showNavButton="true" navButtonPress="onNavBack">
<content>
<form:Form id="formBPDetail" width="100%">
<form:title>
<core:Title text="{i18n>txtBPDetail}" level="Auto"/>
</form:title>
<form:layout>
<form:ResponsiveGridLayout/>
</form:layout>
<form:formContainers>
<form:FormContainer title="{i18n>txtCentralData}">
<form:FormElement label="{i18n>txtPartnerId}">
<form:fields>
<Input value="{PartnerId}"
editable="false"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtPartnerType}">
<form:fields>
<Input value="{PartnerType}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtPartnerName}">
<form:fields>
<Input
value="{PartnerName1}"/>
<Input
value="{PartnerName2}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtSearchTerm}">
<form:fields>
<Input value="{SearchTerm1}"/>
<Input value="{SearchTerm2}"/>
</form:fields>
</form:FormElement>
</form:FormContainer>
<form:FormContainer title="{i18n>txtAddressData}">
<form:FormElement label="{i18n>txtStreet}">
<form:fields>
<Input value="{Street}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtHouseNumber}">
<form:fields>
<Input
value="{HouseNumber}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtDistrict}">
<form:fields>
<Input value="{District}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtCity}">
<form:fields>
<Input value="{City}"/>

192
 </form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtRegion}">
<form:fields>
<Input value="{Region}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtCountry}">
<form:fields>
<Input value="{Country}"/>
</form:fields>
</form:FormElement>
</form:FormContainer>
</form:formContainers>
</form:Form>
</content>
</Page>
</mvc:View>

Execute a aplicação e verifique a estrutura do formulário, ainda em branco.

Como o mesmo formulário será utilizado para múltiplas funções, utilizaremos arquivos
de configuração para que esta informação seja aberta ou bloqueada para edição. Para
isto, gere dois arquivos na pasta model, sendo controlsOpened.json e
controlsClosed.json.

Estes arquivos estarão em formato JSON e o objeto possuirá apenas uma propriedade,
denominada edit. Cada arquivo representará um estado na aplicação.
controlsOpened.json

193
{
"edit": true
}

controlsClosed.json

{
"edit": false
}

Na visão do formulário, adicione a propriedade editable referenciando um novo modelo

a ser criado, denominado control. Este modelo fará a leitura dos arquivos anteriores de
acordo com a operação a ser executada e ditará para a visão qual é o comportamento
dos campos.
<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"
controllerName="bpmaint.bpmaint.controller.BPDetail"
xmlns:html="http://www.w3.org/1999/xhtml" xmlns:form="sap.ui.layout.form">
<Page title="{PartnerId} {PartnerName1}" showNavButton="true" navButtonPress="onNavBack">
<content>
<form:Form id="formBPDetail" width="100%" editable="{control>/edit}">
<form:title>
<core:Title text="{i18n>txtBPDetail}" level="Auto"/>
</form:title>
<form:layout>
<form:ResponsiveGridLayout/>
</form:layout>
<form:formContainers>
<form:FormContainer title="{i18n>txtCentralData}">
<form:FormElement label="{i18n>txtPartnerId}">
<form:fields>
<Input value="{PartnerId}"
editable="false"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtPartnerType}">
<form:fields>
<Input value="{PartnerType}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtPartnerName}">
<form:fields>
<Input value="{PartnerName1}"
editable="{control>/edit}"/>
<Input value="{PartnerName2}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtSearchTerm}">
<form:fields>
<Input value="{SearchTerm1}"
editable="{control>/edit}"/>
<Input value="{SearchTerm2}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
</form:FormContainer>
<form:FormContainer title="{i18n>txtAddressData}">
<form:FormElement label="{i18n>txtStreet}">
<form:fields>
<Input value="{Street}"
editable="{control>/edit}"/>

194
 </form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtHouseNumber}">
<form:fields>
<Input value="{HouseNumber}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtDistrict}">
<form:fields>
<Input value="{District}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtCity}">
<form:fields>
<Input value="{City}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtRegion}">
<form:fields>
<Input value="{Region}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtZipCode}">
<form:fields>
<Input value="{ZipCode}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtCountry}">
<form:fields>
<Input value="{Country}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
</form:FormContainer>
</form:formContainers>
</form:Form>
</content>
<footer>
<OverflowToolbar id="toolbarDetail" visible="{control>/edit}">
<ToolbarSpacer/>
<Button id="buttonSave" text="{i18n>btnSave}" type="Accept"
press="onSavePress"/>
<Button id="buttonCancel" text="{i18n>btnCancel}" type="Reject"
press="onCancelPress"/>
</OverflowToolbar>
</footer>
</Page>
</mvc:View>

Atualize o arquivo de traduções com as entradas destacadas.

#XTXT: Title
title=Business partner maintenance

#XTXT: Title
appTitle=Business partner maintenance

#XTXT: App description

appDescription=Business partner maintenance (create, update e display)

#XHED: Partner header column

195
txtPartner=Partner

#XHED: Partner type column

txtPartnerType=Partner type

#XHED: Region column

txtRegion=Region

#XHED: Country column

txtCountry=Country

#XHED: Options column

txtOptions=Options

#XBUT: Edit button

btnEdit=Edit

#XBUT: Display button

btnDisplay=Display

#XBUT: Create button

btnCreate=Create

#XGRP: Detail form title

txtBPDetail=Partner details

#XFLD: Form - ID field

txtPartnerId=Partner ID

#XFLD: Form - name field

txtPartnerName=Partner name

#XFLD: Form - search field

txtSearchTerm=Search term

#XFLD: Form - street field

txtStreet=Street

#XFLD: Form - house number field

txtHouseNumber=House number

#XFLD: Form - district field

txtDistrict=District

#XFLD: Form - city field

txtCity=City

#XFLD: Form - zip code field

txtZipCode=Zip code

#XGRP: Form title - Central data

txtCentralData=Central data

#XGRP: Form title - Address data

txtAddressData=Address

#XBTN: Save button

btnSave=Save

#XBTN: Cancel button

btnCancel=Cancel

Verifique novamente o comportamento da visão de detalhe, agora com os

componentes apresentando os textos corretos.

196
Será iniciada agora a atribuição de rotas. Adicione a inscrição nas rotas ToBPDisplay,
ToBPEdit e ToBPCreate. Ao se encontrar uma rota de visualização ou de edição, o ID do
parceiro deve ser recuperado. Caso seja uma criação, uma nova entidade deve ser criada
no modelo com todas as propriedades em estado inicial.
Para controle do estado dos campos, gerou-se o método setEditableControls, que faz a
leitura do arquivo de controle correspondente e atribui o modelo control à visão.
BPDetail.controller.js

sap.ui.define([
"bpmaint/bpmaint/controller/BaseController"
], function (BaseController) {
"use strict";

return BaseController.extend("bpmaint.bpmaint.controller.BPDetail", {

/**
* Called when a controller is instantiated and its View controls (if available) are already created.
* Can be used to modify the View before it is displayed, to bind event handlers and do other one-
time initialization.
* @memberOf bpmaint.bpmaint.view.BPDetail
*/
onInit: function () {
this.attachRoute("ToBPDisplay", this.onRouteMatched);
this.attachRoute("ToBPEdit", this.onRouteMatched);
this.attachRoute("ToBPCreate", this.onRouteMatched);
},

onRouteMatched: function (oEvent) {

var sRoute = oEvent.getParameter("name");
var oView = this.getView();

if (sRoute === "ToBPEdit" || sRoute === "ToBPDisplay") {

var sPartnerId = oEvent.getParameter("arguments").PartnerId;

oView.bindElement("/BusinessPartnerSet('" + sPartnerId + "')");

} else if (sRoute === "ToBPCreate") {
oView.unbindingContext();

var oModel = oView.getModel();

var oContext = oModel.createEntry("/BusinessPartnerSet", {
properties: {
PartnerId: "",
PartnerType: "",
PartnerName1: "",
PartnerName2: "",
SearchTerm1: "",
SearchTerm2: "",
Street: "",
HouseNumber: "",

197
 District: "",
City: "",
Region: "",
ZipCode: "",
Country: ""
}
});

oView.setBindingContext(oContext);
}

if (sRoute === "ToBPEdit" || sRoute === "ToBPCreate") {

this.setEditableControls(true);
} else {
this.setEditableControls(false);
}
},

setEditableControls: function (bEdit) {

var oEditModel = new sap.ui.model.json.JSONModel();

if (bEdit) {
oEditModel.loadData("model/controlsOpened.json");
} else {
oEditModel.loadData("model/controlsClosed.json");
}

var oView = this.getView();

oView.setModel(oEditModel, "control");
}
});
});

Verifique agora a navegação de uma entidade em modo de edição ou exibição e perceba

a atribuição do contexto para a segunda visão. Também verifique o botão de criação e
perceba a geração de uma nova entidade em branco.

Para finalizar a codificação do core, deve-se implementar os métodos de

armazenamento e cancelamento. Ainda na visão de detalhe, gere dois novos métodos,
onSavePress e onCancelPress. Para o armazenamento, deve-se verificar o tipo de
operação (que fora atribuído ao atingir a rota) e gerar a reação correta para o modelo.
No caso de uma edição, como a entidade já existe, basta requisitar ao modelo que as
modificações sejam encaminhadas ao servidor SAP com o método submitChanges. No
caso de uma nova entrada, é necessário gerar uma chamada de criação ao modelo
utilizando o método create e passando o conjunto de entidades que desejamos,
juntamente ao objeto que será utilizado.

198
O retorno de ambas operações é capturado e demonstrado em uma caixa de mensagem
que interrompe a execução do programa (requer ação do usuário).
Para o botão de cancelamento, uma mensagem é encaminhada, interrompendo a
execução e requisitando a decisão do usuário.
BPDetail.view.xml

sap.ui.define([
"bpmaint/bpmaint/controller/BaseController",
"sap/m/MessageBox"
], function (BaseController, MessageBox) {
"use strict";

return BaseController.extend("bpmaint.bpmaint.controller.BPDetail", {

/**
* Called when a controller is instantiated and its View controls (if available) are already created.
* Can be used to modify the View before it is displayed, to bind event handlers and do other one-
time initialization.
* @memberOf bpmaint.bpmaint.view.BPDetail
*/
onInit: function () {
this.attachRoute("ToBPDisplay", this.onRouteMatched);
this.attachRoute("ToBPEdit", this.onRouteMatched);
this.attachRoute("ToBPCreate", this.onRouteMatched);
},

onRouteMatched: function (oEvent) {

var sRoute = oEvent.getParameter("name");
var oView = this.getView();

if (sRoute === "ToBPEdit" || sRoute === "ToBPDisplay") {

var sPartnerId = oEvent.getParameter("arguments").PartnerId;

oView.bindElement("/BusinessPartnerSet('" + sPartnerId + "')");

} else if (sRoute === "ToBPCreate") {
oView.unbindContext();

var oModel = oView.getModel();

var oContext = oModel.createEntry("/BusinessPartnerSet", {
properties: {
PartnerId: "",
PartnerType: "",
PartnerName1: "",
PartnerName2: "",
SearchTerm1: "",
SearchTerm2: "",
Street: "",
HouseNumber: "",
District: "",
City: "",
Region: "",
ZipCode: "",
Country: ""
}
});

oView.setBindingContext(oContext);
}

if (sRoute === "ToBPEdit" || sRoute === "ToBPCreate") {

this.setEditableControls(true);
} else {
this.setEditableControls(false);
}

199
 switch (sRoute) {
case "ToBPEdit":
this._sOperation = "Edit";
break;
case "ToBPDisplay":
this._sOperation = "Display";
break;
case "ToBPCreate":
this._sOperation = "Create";
break;
}
},

setEditableControls: function (bEdit) {

var oEditModel = new sap.ui.model.json.JSONModel();

if (bEdit) {
oEditModel.loadData("model/controlsOpened.json");
} else {
oEditModel.loadData("model/controlsClosed.json");
}

var oView = this.getView();

oView.setModel(oEditModel, "control");
},

onSavePress: function (oEvent) {

var that = this;
var oView = this.getView();
var oModel = oView.getModel();

switch (this._sOperation) {
case "Edit":
oModel.submitChanges({
success: function (oData, response) {
MessageBox.success("Business partner updated
successfully", {
title: "Successful update",
onClose: function (oAction) {

that.getRouter().navTo("ToBPList");
}
});
},

error: function (oError) {

MessageBox.error("Error when updating business
partner", {
title: "Update error"
});
}
});

break;

case "Create":
var oObject = oView.getBindingContext().getObject();

oModel.create("/BusinessPartnerSet", oObject, {
success: function (oData, response) {
MessageBox.success("Business partner " +
oData.PartnerId + " created successfully", {
title: "Successful create",
onClose: function (oAction) {

200
 that.getRouter().navTo("ToBPList");
}
});
},

error: function (oError) {

MessageBox.error("Error creating business partner", {
title: "Create error"
});
}
});

break;
}
},

onCancelPress: function (oEvent) {

var oView = this.getView();
var that = this;

MessageBox.show("Do you want to cancel? All unsaved data will be lost.", {

title: "Cancel",
actions: [MessageBox.Action.YES, MessageBox.Action.NO],
onClose: function (oAction) {
if (oAction === MessageBox.Action.YES)

oView.getModel().resetChanges([oView.getBindingContext().getPath()]);
that.getRouter().navTo("ToBPList");
}
});
}
});
});

Verifique o comportamento da aplicação, com criações e edições.

201
O que foi feito anteriormente, porém, não está correto. Foram inseridos literais
diretamente no código JavaScript, o que não é recomendável, pois gera esforço de
codificação para traduções.
Será gerado um método no controlador base para busca dos textos provenientes dos
arquivos de tradução.
Este método, denominado getText, receberá o ID do texto e os argumentos de
substituição (array) e retornará uma string proveniente do arquivo de tradução
correspondente à linguagem do usuário.
BaseController.js

sap.ui.define([
"sap/ui/core/mvc/Controller",
"sap/ui/core/routing/History"
], function (Controller, History) {
"use strict";

return Controller.extend("bpmaint.bpmaint.controller.BaseController", {
getRouter: function () {
return sap.ui.core.UIComponent.getRouterFor(this);
},

onNavBack: function (oEvent) {

var oHistory, sPreviousHash;
oHistory = History.getInstance();
sPreviousHash = oHistory.getPreviousHash();

if (sPreviousHash !== undefined) {

window.history.go(-1);
} else {
this.getRouter().navTo("ToBPList", {}, true);
}
},

attachRoute: function (sRoute, fRouteMatched) {

this.getRouter().getRoute(sRoute).attachPatternMatched(fRouteMatched, this);
},

getText: function (sTextId, aArgs) {

var oView = this.getView();
var oModel = oView.getModel("i18n");

if (!oModel) {
oModel = sap.ui.model.resource.ResourceModel({
bundleName: "bpmaint.bpmaint.i18n.i18n"
});

oView.setModel(oModel, "i18n");
}

202
 return oModel.getResourceBundle().getText(sTextId, aArgs);
}
});
});

No arquivo de tradução, adicione os valores que estão faltando.

i18n.properties
…

#XMSG: BP create message

msgBPCreated=Business partner {0} created successfully

#XHED: BP create title

txtBPCreated=Successful create

#XMSG: BP update message

msgBPUpdated=Business partner updated successfully

#XHED: BP update title

txtBPUpdated=Successful update

#XMSG: BP create error

msgBPCrtError=Error when creating business partner

#XHED: BP create title

txtBPCrtError=Create error

#XMSG: BP update error

msgBPUpdError=Error when updating business partner

#XHED: BP update title

txtBPUpdError=Update error

#XMSG: BP cancel edit

msgBPCancel=Do you want to cancel? All unsaved data will be lost.

#XHED: BP cancel title

txtBPCancel=Cancel

#XTXT Organization
txtOrganization=Organization

#XTXT Person
txtPerson=Person

Agora, no controlador da visão de detalhe, utilize o novo método em vez da utilização

dos literais.
BPDetail.controller.js

…
onSavePress: function (oEvent) {
var that = this;
var oView = this.getView();
var oModel = oView.getModel();

switch (this._sOperation) {
case "Edit":
oModel.submitChanges({
success: function (oData, response) {
MessageBox.success(that.getText("msgBPUpdated"), {
title: that.getText("txtBPUpdated"),
onClose: function (oAction) {

that.getRouter().navTo("ToBPList");

203
 }
});
},

error: function (oError) {

MessageBox.error(that.getText("msgBPUpdError"), {
title: that.getText("txtBPUpdError")
});
}
});

break;

case "Create":
var oObject = oView.getBindingContext().getObject();

oModel.create("/BusinessPartner", oObject, {
success: function (oData, response) {
MessageBox.success(that.getText("msgBPCreated",
[oObject.PartnerId]), {
title: that.getText("txtBPCreated"),
onClose: function (oAction) {

that.getRouter().navTo("ToBPList");
}
});
},

error: function (oError) {

MessageBox.error(that.getText("msgBPCrtError"), {
title: that.getText("txtBPCrtError")
});
}
});

break;
}
},

onCancelPress: function (oEvent) {

var oView = this.getView();
var that = this;

MessageBox.show(this.getText("msgBPCancel"), {
title: this.getText("txtBPCancel"),
actions: [MessageBox.Action.YES, MessageBox.Action.NO],
onClose: function (oAction) {
if (oAction === MessageBox.Action.YES)

oView.getModel().resetChanges([oView.getBindingContext().getPath()]);
that.getRouter().navTo("ToBPList");
}
});
}

Finalmente, deve-se transformar os valores 1 e 2 provenientes do campo de tipo de

parceiro para valores reconhecidos pelo ser humano. Será utilizado um formatter para
a visão de lista.
BPList.view.xml

<items>
<ColumnListItem>
<cells>

204
 <ObjectIdentifier title="{PartnerId}"
text="{PartnerName1} {PartnerName2}"/>
<Text text="{path: 'PartnerType',
formatter: '.formatPartnerType'}"/>
<Text text="{Region}"/>
<Text text="{Country}"/>
<layout:HorizontalLayout>
<Button id="buttonDisplay"
icon="sap-icon://display" press="onDisplayPress" tooltip="{i18n>btnDisplay}"/>
<Button id="buttonEdit"
icon="sap-icon://edit" press="onEditPress" tooltip="{i18n>btnEdit}"/>
</layout:HorizontalLayout>
</cells>
</ColumnListItem>
</items>

O formatador deve ser codificado na visão que está sendo utilizado. No caso, gerou-se
o código abaixo no controlador da visão da lista.
BPList.controller.js

…
formatPartnerType: function(sPartnerType) {
switch(sPartnerType) {
case "1":
return this.getText("txtOrganization");
case "2":
return this.getText("txtPerson");
default:
return "";
}
}
…

Na visão de detalhe, será utilizada um mapeamento por expressão. Modifique a visão

conforme abaixo.
BPDetail.view.xml

…
<form:FormElement label="{i18n>txtPartnerType}">
<form:fields>
<Input value="{PartnerType}"
description="{= ${PartnerType} === '1' ? ${i18n>txtOrganization} : ( ${PartnerType} ===
'2' ? ${i18n>txtPerson} : '')}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
...

Verifique, na sequência, os valores transformados em ambas visões.

205
9. Após encaminhar a aplicação anterior ao usuário para a primeira validação, ele relatou
a dificuldade em utilizar as siglas de país. Como solução, você pensa em desenvolver
uma nova entidade, Country, que será navegável a partir do código do país. Esta
entidade possuirá código e descrição do país, provenientes da tabela T005T. Para
auxiliar a entrada de valores no formulário, você desenvolverá uma ajuda de pesquisa
exibindo todos os valores possíveis para esta entidade. Considere um filtro para auxiliar
na busca dos valores, sendo possível a pesquisa por código ou descritivo. Na tabela, a
sigla deixará de ser apresentada e demonstrará apenas o descritivo.

R: Inicialmente, deve-se criar a entidade Country a partir da transação SEGW.

Especifique a tabela T005T como base para criação da entidade. Também mantenha
marcado o checkbox para criação do conjunto de entidades.

206
Especifique apenas os campos LAND1 e LANDX50 como retorno.

Renomeie os campos para Land (código) e LandName (descrição). Marque o campo Land
como chave da entidade.

Verifique a criação da entidade e do conjunto de entidades e gere os artefatos de

runtime.

Após a geração, acesse a classe *DPC_EXT para iniciar a implementação da entidade.

207
Acesse o método COUNTRYSET_GET_ENTITY e faça a redefinição com o código abaixo.

METHOD countryset_get_entity.
DATA lv_land1 TYPE land1.

"Get key
TRY.
lv_land1 = it_key_tab[ name = 'Land' ]-value.
CATCH cx_sy_itab_line_not_found.
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
entity_type = iv_entity_name
message = TEXT-001. "Key not found in parameters
ENDTRY.

"Get corresponding country

SELECT SINGLE land1, landx50
FROM t005t
INTO @DATA(ls_t005t)
WHERE spras = @sy-langu
AND land1 = @lv_land1.

IF sy-subrc = 0.
er_entity-land1 = ls_t005t-land1.
er_entity-landx50 = ls_t005t-landx50.
ENDIF.
ENDMETHOD.

Repita o processo para o método COUNTRYSET_GET_ENTITYSET.

208
 METHOD countryset_get_entityset.
DATA: lt_entityset TYPE zcl_zbp_00_mpc=>tt_country,
lt_tech_order TYPE /iwbep/t_mgw_tech_order,
lt_sort TYPE abap_sortorder_tab,
ls_entityset LIKE LINE OF lt_entityset,
lt_land TYPE RANGE OF land1,
lt_landname TYPE RANGE OF landx50,
lv_from TYPE i,
lv_to TYPE i.

IF iv_search_string IS NOT INITIAL.

"Map search string to ranges

APPEND INITIAL LINE TO lt_land ASSIGNING FIELD-SYMBOL(<land>).
<land>-sign = 'I'.
<land>-low = iv_search_string.

IF iv_search_string CA '*'.
<land>-option = 'CP'.
ELSE.
<land>-option = 'EQ'.
ENDIF.

APPEND INITIAL LINE TO lt_landname ASSIGNING FIELD-SYMBOL(<landname>).

<landname>-sign = 'I'.
<landname>-low = iv_search_string.

IF iv_search_string CA '*'.
<landname>-option = 'CP'.
ELSE.
<landname>-option = 'EQ'.
ENDIF.

ELSE.

"Map filter to parameters

LOOP AT it_filter_select_options ASSIGNING FIELD-SYMBOL(<filter>).
CASE <filter>-property.
WHEN 'Land'.
LOOP AT <filter>-select_options ASSIGNING FIELD-
SYMBOL(<select_options>).
APPEND INITIAL LINE TO lt_land ASSIGNING <land>.
MOVE-CORRESPONDING <select_options> TO <land>.
ENDLOOP.
WHEN 'LandName'.
LOOP AT <filter>-select_options ASSIGNING <select_options>.
APPEND INITIAL LINE TO lt_landname ASSIGNING <landname>.
MOVE-CORRESPONDING <select_options> TO <landname>.
ENDLOOP.
ENDCASE.
ENDLOOP.
ENDIF.

"Get values

209
 SELECT land1, landx50
FROM t005t
INTO CORRESPONDING FIELDS OF TABLE @lt_entityset
WHERE spras = @sy-langu
AND land1 IN @lt_land
AND landx50 IN @lt_landname.

"Paging
lv_from = is_paging-skip + 1.
IF is_paging-top = 0.
lv_to = lines( lt_entityset ).
ELSE.
lv_to = is_paging-top + lv_from.
ENDIF.

"Set sort conditions, if necessary

IF it_order IS NOT INITIAL.
lt_tech_order = io_tech_request_context->get_orderby( ).

LOOP AT lt_tech_order ASSIGNING FIELD-SYMBOL(<tech_order>).

APPEND INITIAL LINE TO lt_sort ASSIGNING FIELD-SYMBOL(<sort>).
<sort>-name = <tech_order>-property.

IF <tech_order>-order = 'desc'.
<sort>-descending = abap_true.
ENDIF.
ENDLOOP.

SORT lt_entityset BY (lt_sort).

ENDIF.

"Return entity set to parameter

LOOP AT lt_entityset INTO ls_entityset FROM lv_from
TO lv_to.
APPEND ls_entityset TO et_entityset.
ENDLOOP.
ENDMETHOD.

Verifique a chamada dos metadados através da transação /IWFND/GW_CLIENT. Utilize

o método GET e a adição $metadata após a URL do serviço. Se tudo estiver correto, a
nova entidade será demonstrada.

Realize testes com as operações GET_ENTITY e GET_ENTITYSET para verificar se os

valores estão sendo corretamente trazidos.

210
Agora será criada a associação entre o parceiro de negócios e o país. Na SEGW, crie uma
associação.

Defina a associação como ToCountryDetail. Marque na entidade principal

BusinessPartner, cardinalidade 0 e propriedade de navegação CountryDetail (esta
propriedade será utilizada nas visões).
Na dependência, adicione a entidade Country e cardinalidade 0.

211
 Remova todas as chaves do próximo passo. Não há interdependência da chave da
primeira entidade com a segunda. Ela é feita por outro campo que não constitui a chave
e que deverá ser programaticamente realizada.

No último passo, gere Association Set Name, gerando a relação entre os entity sets.

Verifique a criação da associação.

Uma modificação deve ser feita no serviço. A entidade Country prevê apenas a leitura
através da chave de sua própria entidade, porém, quando vindo pela associação, a lógica
não funcionará. Abaixo, está descrito o código para considerar a associação. Devemos
buscar a chave do parceiro e encontrar o detalhe do endereço para então realizar a
seleção do país.
METHOD countryset_get_entity.
DATA: ls_address_data TYPE bapibus1006_address,
lv_land1 TYPE land1,
lv_partner TYPE bu_partner.

"Direct call to entity?

IF iv_entity_name = iv_source_name.

"Get key
TRY.
lv_land1 = it_key_tab[ name = 'Land' ]-value.

212
 CATCH cx_sy_itab_line_not_found.
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
entity_type = iv_entity_name
message = TEXT-001. "Key not found in parameters
ENDTRY.

ELSE.

"Navigation
READ TABLE it_navigation_path INTO DATA(ls_navigation_path) INDEX 1.
IF sy-subrc = 0.

CASE ls_navigation_path-nav_prop.
WHEN 'CountryDetail'.

"Get key
TRY.
lv_partner = it_key_tab[ name = 'PartnerId' ]-value.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING
input = lv_partner
IMPORTING
output = lv_partner.

CATCH cx_sy_itab_line_not_found.
ENDTRY.

CALL FUNCTION 'BAPI_BUPA_ADDRESS_GETDETAIL'

EXPORTING
businesspartner = lv_partner
IMPORTING
addressdata = ls_address_data.

lv_land1 = ls_address_data-country.
ENDCASE.
ENDIF.
ENDIF.

CHECK lv_land1 IS NOT INITIAL.

"Get corresponding country

SELECT SINGLE land1, landx50
FROM t005t
INTO @DATA(ls_t005t)
WHERE spras = @sy-langu
AND land1 = @lv_land1.

IF sy-subrc = 0.
er_entity-land1 = ls_t005t-land1.
er_entity-landx50 = ls_t005t-landx50.
ENDIF.
ENDMETHOD.

Execute o comando de expansão para verificar o drilldown para a propriedade de

navegação CountryDetail (por exemplo,
/sap/opu/odata/sap/ZBP_00_SRV/BusinessPartnerSet?$skip=0&$top=100&$expand=C
ountryDetail) .

213
Na visão da lista, deve-se agora realizar a expansão da propriedade CountryDetail. Para
isso, adicionar na propriedade items da tabela o parâmetro de requisição expand. Na
propriedade que descreve o campo Country, adicionar o nome do a partir da
propriedade de navegação.
BPList.view.xml

<mvc:View xmlns:core="sap.ui.core" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"

xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:layout="sap.ui.layout" controllerName="bpmaint.bpmaint.controller.BPList">
<Page title="{i18n>appTitle}" showNavButton="true" navButtonPress="onNavBack">
<content>
<Table id="tableBPList" width="100%" items="{ path: '/BusinessPartnerSet',
parameters: { expand: 'CountryDetail' } }">
<columns>
<Column>
<Text text="{i18n>txtPartner}"/>
</Column>
<Column>
<Text text="{i18n>txtPartnerType}"/>
</Column>
<Column>
<Text text="{i18n>txtRegion}"/>
</Column>
<Column>
<Text text="{i18n>txtCountry}"/>
</Column>
<Column hAlign="Center">
<Text text="{i18n>txtOptions}"/>
</Column>
</columns>
<items>
<ColumnListItem>
<cells>

214
 <ObjectIdentifier title="{PartnerId}"
text="{PartnerName1} {PartnerName2}"/>
<Text text="{path: 'PartnerType',
formatter: '.formatPartnerType'}"/>
<Text text="{Region}"/>
<Text text="{Country} -
{CountryDetail/LandName}"/>
<layout:HorizontalLayout>
<Button id="buttonDisplay"
icon="sap-icon://display" press="onDisplayPress" tooltip="{i18n>btnDisplay}"/>
<Button id="buttonEdit"
icon="sap-icon://edit" press="onEditPress" tooltip="{i18n>btnEdit}"/>
</layout:HorizontalLayout>
</cells>
</ColumnListItem>
</items>
</Table>
</content>
<footer>
<OverflowToolbar>
<ToolbarSpacer/>
<Button id="buttonCreate" text="{i18n>btnCreate}" type="Accept"
press="onCreatePress"/>
</OverflowToolbar>
</footer>
</Page>
</mvc:View>

Na visão de detalhe, para o campo de entrada da propriedade Country, gere um

identificador (propriedade id). Deve-se também habilitar o value help e mapear a
propriedade CountryDetail/LandName para o campo de descrição.
BPDetail.view.xml

…
<form:FormElement label="{i18n>txtZipCode}">
<form:fields>
<Input value="{ZipCode}"
editable="{control>/edit}"/>
</form:fields>
</form:FormElement>
<form:FormElement label="{i18n>txtCountry}">
<form:fields>
<Input id="inputCountry"
value="{Country}" description="{CountryDetail/LandName}" editable="{control>/edit}" showValueHelp="true"
valueHelpRequest="openCountryDialog"/>
</form:fields>
</form:FormElement>
</form:FormContainer>
</form:formContainers>
…

Verifique os novos campos de descrição do país mapeados nas duas visões.

215
Deve-se, então, gerar o diálogo para seleção do país para auxiliar a inserção do usuário.
Para isso, gere um novo diretório, denominado fragments. Nele, estarão todos os
fragmentos de visão que podem ser agregados. Nesse novo diretório, gere o arquivo
CountryDialog.fragment.xml. Adicione o conteúdo ao arquivo.

CountryDialog.fragment.xml

<core:FragmentDefinition
xmlns="sap.m"
xmlns:core="sap.ui.core">
<SelectDialog
title="{i18n>txtCountry}"
search="onSearchCountryDialog"
confirm="onCloseCountryDialog"
items="{
path: '/CountrySet'

216
 }" >
<StandardListItem
title="{Land}"
description="{LandName}"
type="Active" />
</SelectDialog>
</core:FragmentDefinition>

No controlador da visão de detalhe, adicione o código para abertura do diálogo, inserção

do filtro na busca de dados pelo campo de descrição e retorno da seleção para o campo
da visão.
BPDetail.controller.js
…

onCancelPress: function (oEvent) {

var oView = this.getView();
var that = this;

MessageBox.show(this.getText("msgBPCancel"), {
title: this.getText("txtBPCancel"),
actions: [MessageBox.Action.YES, MessageBox.Action.NO],
onClose: function (oAction) {
if (oAction === MessageBox.Action.YES)

oView.getModel().resetChanges([oView.getBindingContext().getPath()]);
that.getRouter().navTo("ToBPList");
}
});
},

openCountryDialog: function (oEvent) {

if (!this._oCountryDialog) {
this._oCountryDialog =
sap.ui.xmlfragment("bpmaint.bpmaint.fragments.CountryDialog", this);
this.getView().addDependent(this._oCountryDialog);
}

this._oCountryDialog.open();
},

onSearchCountryDialog: function (oEvent) {

var sValue = oEvent.getParameter("value");
var oFilter = new Filter("LandName", FilterOperator.Contains, sValue);
var oBinding = oEvent.getSource().getBinding("items");
oBinding.filter([oFilter]);
},

onCloseCountryDialog: function (oEvent) {

var oSelectedItem = oEvent.getParameter("selectedItem"),
oInput = this.byId("inputCountry");

if (oSelectedItem) {
oInput.setValue(oSelectedItem.getTitle());
oInput.setDescription(oSelectedItem.getDescription());
} else {
oInput.resetProperty("value");
oInput.resetProperty("description");
}
}

217
Verifique o novo comportamento para o campo. Ao se navegar para a visão de detalhe,
clique no símbolo de value help.

Verifique a abertura do diálogo de seleção e faça testes com a busca.

Verifique o retorno nas propriedades de valor e descrição do campo.

218
10. Após uma rodada de testes com uma massa de dados maior, o usuário relata que a
listagem de business partners está demorando muito tempo para ser carregada. Após
uma análise sobre o código, você percebe que o processamento da expansão gerada
pela leitura da tabela T005T está tomando um tempo considerável. Você constata que
a leitura unitária (GET_ENTITY) está sendo utilizada também para a consulta de mais de
uma entidade (GET_ENTITYSET), gerando um excesso de chamadas ao banco de dados
que oneram o processamento. Como solução, você propõe a reimplementação da
expansão, buscando dados da entidade do parceiro de negócios juntamente à expansão
de país proposta. Implemente esta expansão, capturando quais são as propriedades de
navegação a serem expandidas e, caso identificada alguma, otimize a sua leitura.

R: Acesse a classe de extensão de modelo. Nela, será criado o tipo de dados expandido,
que agregará simultaneamente as propriedades do parceiro de negócios e a expansão
do país. Para isso, acesse a transação SEGW e identifique nos artefatos de runtime a
classe sufixada em *MPC_EXT.

Na aba de tipos, crie um novo tipo declarando a estrutura

TS_EXPANDED_BUSINESSPARTNER na área pública da classe. Este tipo será referenciado
na implementação. Clique no ícone ao lado da coluna de tipo associado para abrir o
editor. Salve as alterações da classe, caso seja questionado.

219
Exclua o código gerado para o tipo e redefina com o código abaixo. Este tipo conterá
todos os valores da propriedade BusinessPartner, bem como uma representação ABAP
para a expansão CountryDetail, denominada COUNTRYDETAIL.

PUBLIC SECTION.

TYPES: BEGIN OF ts_expanded_businesspartner.

INCLUDE TYPE ts_businesspartner.
TYPES: countrydetail TYPE ts_country,
END OF ts_expanded_businesspartner.

Ative a classe. Agora, deve-se partir para a implementação do código da expansão. Para
isso, retorne à transação SEGW e acesse novamente os artefatos de runtime. Dessa vez,
selecione a classe sufixada em *DPC_EXT.

Em modo de edição, encontre o método

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET e redefina-o.

Insira o código abaixo. Nele, é realizada a chamada já implementada para busca de

entidades e, na sequência, é realizada uma tratativa para as expansões. Caso haja uma
expansão, ela é tratada e mapeada para o respectivo campo na estrutura expandida da
entidade.
METHOD /iwbep/if_mgw_appl_srv_runtime~get_expanded_entityset.
DATA: lt_t005t TYPE TABLE OF t005t,
lt_expanded_bp TYPE TABLE OF zcl_zbp_000_mpc_ext=>ts_expanded_businessp
artner.

CASE iv_entity_name.
WHEN 'BusinessPartner'.

220
 "Get entity set as coded
businesspartners_get_entityset(
EXPORTING
iv_entity_name = iv_entity_name
iv_entity_set_name = iv_entity_set_name
iv_source_name = iv_source_name
it_filter_select_options = it_filter_select_options
is_paging = is_paging
it_key_tab = it_key_tab
it_navigation_path = it_navigation_path
it_order = it_order
iv_filter_string = iv_filter_string
iv_search_string = iv_search_string
io_tech_request_context = io_tech_request_context
IMPORTING
et_entityset = DATA(lt_businesspartners)
es_response_context = es_response_context ).

"For each entry, get the requested expansions

IF io_expand IS BOUND AND lt_businesspartners IS NOT INITIAL.
DATA(lt_expand) = io_expand->get_children( ).

"Expand each property

LOOP AT lt_expand ASSIGNING FIELD-SYMBOL(<expand>).
CASE <expand>-tech_nav_prop_name.
WHEN 'COUNTRYDETAIL'.

"Get country details

SELECT land1, landx50 FROM t005t
INTO CORRESPONDING FIELDS OF TABLE @lt_t005t
FOR ALL ENTRIES IN @lt_businesspartners
WHERE spras = @sy-langu
AND land1 = @lt_businesspartners-country.
SORT lt_t005t BY land1.

"Map country details to expanded structure

LOOP AT lt_businesspartners ASSIGNING FIELD-
SYMBOL(<businesspartner>).
APPEND INITIAL LINE TO lt_expanded_bp ASSIGNING FIELD-
SYMBOL(<expanded_bp>).
MOVE-CORRESPONDING <businesspartner> TO <expanded_bp>.

READ TABLE lt_t005t ASSIGNING FIELD-

SYMBOL(<t005t>) WITH KEY land1 = <expanded_bp>-country BINARY SEARCH.
CHECK sy-subrc = 0.

MOVE-CORRESPONDING <t005t> TO <expanded_bp>-countrydetail.

ENDLOOP.
ENDCASE.
ENDLOOP.

"Copy data to returning reference

copy_data_to_ref(
EXPORTING
is_data = lt_expanded_bp
CHANGING
cr_data = er_entityset ).

ENDIF.

WHEN OTHERS.
"Other entities
super->/iwbep/if_mgw_appl_srv_runtime~get_expanded_entityset(
EXPORTING
iv_entity_name = iv_entity_name
iv_entity_set_name = iv_entity_set_name
iv_source_name = iv_source_name
it_filter_select_options = it_filter_select_options
it_order = it_order
is_paging = is_paging
it_navigation_path = it_navigation_path

221
 it_key_tab
iv_filter_string
iv_search_string
io_expand
io_tech_request_context
IMPORTING
er_entityset
et_expanded_clauses
et_expanded_tech_clauses
es_response_context
ENDCASE.
= it_key_tab
= iv_filter_string
= iv_search_string
= io_expand
= io_tech_request_context
= er_entityset
= et_expanded_clauses
= et_expanded_tech_clauses
= es_response_context ).

ENDMETHOD.

Ative o método e a classe e verifique o resultado das expansões a partir da query

/sap/opu/odata/sap/ZBP_00_SRV/BusinessPartnerSet?$expand=CountryDetail na
transação /IWFND/GW_CLIENT.

Extensão de aplicações
1. Durante um projeto de implementação do SAP S/4HANA, define-se a utilização da
aplicação “Administrar pedidos centralmente” (ID F3292 -
ui.s2p.mm.pur.central.po.manage.s1) para alguns usuários de MM. A aplicação
permite a criação e manutenção de pedidos de compras.
Contudo, funcionalidade de criação de novos pedidos é restrita a apenas alguns
membros da equipe. O consultor funcional sugere a criação de uma nova aplicação para
os usuários que não deverão criar pedidos. Sabendo da flexibilidade do SAPUI5, você
sugere a geração de uma extensão.
A aplicação também permite o compartilhamento das informações apresentadas na
tabela e este botão também não é desejado. Por fim, a nomenclatura “Grupo de
compradores” não é utilizada pela empresa e deve ser modificada para “Célula de
compras”.
Com estes requisitos em mãos, verifique:
o Qual método de extensão deve ser utilizado?
o Execute a extensão proposta.

R: O método a ser utilizado é o SAPUI5 Flexibility, pois a aplicação é feita a partir de

Fiori Elements em versão superior a 1.56.

222
Acesse o Web IDE e crie um projeto de adaptação.

Preencha com os valores de nome e descrição do projeto.

Selecione a aplicação que será estendida.

223
Com o projeto criado, abra o editor visual.

Selecione o modo de edição.

Clique sobre o botão de compartilhamento com o botão direito. Selecione a opção de

remover o componente.

Remova também a ação de criação.

224
Para concluir o último requisito, de modificação do nome da coluna, desative o modo
seguro clicando em Safe Mode.

Clique sobre a coluna “Grupo de compradores”.

Depois, no painel à direita, procure pela propriedade Text e faça a substituição.

Verifique o resultado final das modificações.

225
Configuração do SAP Fiori Launchpad
1. Qual a diferença de um catálogo e um grupo SAP Fiori?
R: Um catálogo representa um conjunto de aplicações e atribuições de destino que um
usuário pode ter acesso. Ele pode ter um caráter genérico (technical catalog) ou de
negócio (business catalog). Pode ser visto como um agrupamento de permissões. Um
grupo possui um caráter semântico, é uma organização gráfica de tiles, geralmente
levando em consideração uma linha de negócio.
2. Onde são apontados os catálogos e os grupos que um usuário SAP Fiori tem acesso?
R: Nas funções disponíveis na PFCG.
3. Você está participando de um projeto S/4HANA e precisa disponibilizar ao usuário a
nova aplicação para manutenção de parceiros de negócios que você desenvolveu (vide
exercícios anteriores).
Você deverá:
o Executar a implantação da aplicação ao SAP Fiori Launchpad. Utilizar como
nome de aplicação o formato ZFIOR_BP_XX (onde XX é o número do aluno);
o Em escopo customizing, criar um catálogo denominado ZFIOR_BC_BP_XX (onde
XX é o número do aluno) e com descrição “Business partner maintenance”,
adicionando a aplicação como tile e gerando uma atribuição de destino para ela;
o Em escopo customizing, criar um grupo denominado ZFIOR_BG_BP_XX (onde
XX é o número do aluno) e com descrição “Business partner maintenance”,
adicionando a aplicação recém-publicada;
o Gerar uma função PFCG (ZFIOR_BP_XX, onde XX é o número do aluno) e atribuir
a ela o catálogo e o grupo criados.

Ao final, atribuir esta função ao seu usuário e realizar o teste no SAP FLP, verificando a
atribuição e a navegação.

R: Realize o deploy da aplicação como descrito na seção Implantando um projeto. Então,

acesse a transação /UI2/FLPD_CUST para acessar o FLP Designer.

Inicialmente, verifique se existe request atribuída ao seu usuário. Clique na engrenagem

no canto superior direito para verificar.

226
Ao acessar o FLP Designer, clique no botão de adição na área de catálogos.

Insira o nome e o ID do catálogo.

Agora, deve-se criar os target mappings. Clique no botão de atribuição de destino e

depois na opção de criar atribuição.

227
Preenchar os valores de objeto semântico e ação. Estes valores são livres, mas deverão
ser lembrados na criação dos blocos. Indique também o nome do componente que foi
gerado (veja o nome do componente no arquivo Component.js do seu projeto). Indique
também a URL que será consumida.

Verifique a criação do target mapping.

Prossiga para a criação de um bloco. Clique na área de blocos e adicione um bloco

estático.

Preencha o título, descrição e ícone do bloco. No objeto semântico e ação, aponte os

valores que foram gerados para o target mapping do passo anterior.

228
Verifique a criação do bloco.

Agora, deve-se partir para a criação do grupo. Clique na seção de grupos e gere um novo
grupo no botão de adição.

Adicione título e ID para o novo grupo gerado.

Na sequência, adicione um novo bloco. Selecione o catálogo gerado no passo anterior.

229
Selecione o bloco da aplicação.

Verifique o bloco adicionado.v

Por fim, gere a função PFCG. Para isso, acesse a transação PFCG. Selecione a criação de
uma nova função individual.

Adicione um descritivo e selecione Menu.

230
Adicione um catálogo do SAP Fiori e insira o nome dado ao catálogo gerado nos passos
anteriores.

Faça o mesmo para o grupo.

Ao final, selecione a aba de usuários para atribuir sua função ao seu usuário.

231
Acesse o FLP (/UI2/FLP) e verifique o novo grupo.

232