Rievo_Curso_SAPPO75_Basico

SAP PI / PO 7.
5
Single Stack
Juliana - [email protected] - IP: 200.185.183.140

Olá
Danilo Oliveira
Consultor SAP PI-PO / HCI-CPI / GRC / Mobile
[email protected]

Agenda
Apresentacão e Objetivo
Introdução e Overview do SAP PO
Ferramentas
Conceitos para Integração de Sistemas
Exercícios

Apresentação e Objetivo
Promover uma visão teórica e prática do SAP PI/PO 7.5 Single Stack, através
de sua arquitetura, principais funcionalidades e ferramentas de construção,
configuração e monitoramento de interfaces.
Resumo:
Transformá-los em Consultores SAP PI/PO

Introdução
História e Evolução
Componentes
Arquitetura
Opções de Instalação

Introdução
Como parte da família de produtos Netweaver, SAP criou um combo de produtos chamado SAP
Process Orchestration (SAP PO), para ajudar empresas e organizações a atingirem seus objetos em
relação a integração de sistemas, plataformas e pessoas.
SAP PO é composto por três diferentes produtos:
● SAP Process Integration (PI)*

● SAP Business Rules Management (BRM)
● SAP Business Process Management (BPM)
A partir de agora, quando falarmos SAP PO, estamos nos referindo aos três produtos acima. Como o
foco do treinamento é o produto SAP Process Integration, falaremos SAP PI.
* foco do nosso treinamento

A origem do SAP PO, foi a junção do SAP PI + SAP Composition Environment (que era composto pelo
SAP BRM e BPM), logo, veremos a evolução histórica destes três produtos separadamente, na
sequência:
● SAP Process Integration (PI)

● SAP Composition Environment (CE)
● SAP Process Orchestration (PO)

SAP Process Integration (PI):
● Em 2002 a SAP lançou o SAP XI (SAP eXchange Infrastructure) 1.0, como parte dos produtos
SAP Netweaver e evoluiu o XI para a versão 2.0 e 3.0
● Arquitetura dual-stack (SAP Application Server ABAP e Java)

● Após melhorias e novos recursos, o produto foi renomeado para SAP Netweaver Process Integration (PI)
● Evoluiu para as versões 7.01, 7.1 e 7.11
● Na versão 7.11 já ganhou uma stack java mais poderosa, chamada de Advances Adapter Engine (AAE),
onde podia-se criar interfaces utilizando apenas a stack java, mas nem todas as conexões e funcionalidades
eram suportadas e para essas, ainda era preciso recorrer a stack abap
● Em 2010 a SAP lançou uma stack java mais poderosa, chamada SAP Advanced Adapter Engine Extended (AEX)
● AEX é um ESB Robusto, java only, que cobria praticamente todas as funcionalidades e conexões, exceto a parte do
ccBPM
● A funcionalidade de automação de processos agora é fornecida pela SAP através do SAP Composition Environment
(CE)
SAP Composition Environment (CE):
● SAP Composition Environment faz parte do pacote SAP Netweaver Suite e sua primeira versão foi em 2007 com a
versão 7.1, que incluia produtos como Visual Composer, Portal, Composite Application Framework, dentre outros e
não existia ainda o SAP BPM e o BRM. Eles surgiram em 2008, com a versão 7.11.
● A partir de 2012 era possível instalar o SAP CE separadamente ou como parte do pacote SAP Process Orchestration
(PO)

SAP Process Orchestration (PO):
● Em 2012 o SAP PO foi criado com ESB, BPM e BRM, todos rodando apenas java
● É um pacote que combina o SAP PI com o SAP CE
● Com o SAP PO, as organizações podem entregar facilmente mensagens confiáveis nos diferentes sistemas
internos e externos, usando um conjunto bem estabelecido de padrões e protocolos de integração

● Além disso, o SAP PO fornece um conjunto completo de ferramentas de gerenciamento de processos de negócios
(BPM) e gerenciamento de regras de negócios (BRM) para ajudar as organizações a projetar, modelar, executar,
monitorar, gerenciar e analisar processos e regras de negócios usando uma plataforma

● Maior eficiência e custo total de propriedade (TCO*) reduzido
* TCO (Total Cost of Ownership) ou custo total da posse, é uma estimativa financeira projetada para consumidores e gerentes de empresas a avaliar os custos diretos
e indiretos relacionados à compra de todo o investimento importante, tal como software e hardware, além do gasto inerente de tais produtos para mantê-los em
funcionamento, ou seja, os gastos para que se continue proprietário daquilo que foi adquirido.

Componentes
Para entender melhor por que o SAP Process Orchestration pode ser útil, agora vamos explorar o
SAP PI, o SAP BPM e o SAP BRM individualmente e detalhar como eles podem dar suporte às
organizações

Componentes
É muito comum em nossas vidas diárias encontrar situações em que dois ou mais sistemas precisam ser conectados para
trocar dados. No mundo digital em que vivemos, uma organização típica exigirá vários sistemas para realizar suas tarefas
diárias de negócios. Os dados de recursos humanos ou funcionários da organização serão armazenados em um aplicativo
de RH, enquanto os dados financeiros serão armazenados em um aplicativo financeiro. As escolhas de quais pacotes de
software, aplicativos e fornecedores se ajustam melhor para a tarefa em questão variam de organização para organização.
No entanto, é comum que os diferentes sistemas de uma organização precisem trocar dados e trabalhar em conjunto para
dar suporte a um determinado processo de negócios ou necessidade.
Os sistemas ou aplicativos envolvidos na troca de dados não precisam necessariamente pertencer à mesma organização
ou fazer parte da mesma rede. Duas empresas que fazem negócios juntas podem precisar trocar informações por meio de
seus respectivos aplicativos. Esses aplicativos vêm em todos os tamanhos e formas. Eles também geralmente não falam a
mesma língua e cobrem processos de negócios que pertencem a diferentes indústrias. Eles estão localizados em
diferentes fusos horários e continentes e não possuem os mesmos requisitos de segurança. Todos esses fatores
aumentam a complexidade e o desafio de alcançar uma integração perfeita entre todos os sistemas envolvidos.

Componentes
Integração Point-to-point
Algumas organizações optam pelo caminho mais fácil e escolhem a comunicação ponto-a-ponto.
Em uma comunicação ponto-a-ponto, cada comunicação envolve dois sistemas: o sistema de origem
envia ou solicita informações do sistema de destino.
Existe uma linha de conexão dedicada entre os dois sistemas envolvidos na comunicação.

Componentes

Componentes
À primeira vista, essa abordagem parece simples e rápida de implementar, especialmente com menos
aplicativos para se conectar. No entanto, suas desvantagens se tornam visíveis muito rapidamente à
medida que o panorama de integração da organização se torna mais complexo e maior. A abordagem
ponto-a-ponto forma uma teia de conexões de aplicativos, que continua crescendo exponencialmente
à medida que mais sistemas são introduzidos na paisagem.
Cada sistema está ciente da conexão e detalhes da mensagem do sistema no outro lado da troca.
Toda vez que um determinado sistema muda ou precisa ser substituído, o impacto será sentido por
todos os outros sistemas que estiverem se comunicando com ele. Se uma conexão de segurança
vulnerável for descoberta em um dos sistemas, todas as aplicações que estiverem se conectando a ela
precisarão ser alteradas, adaptadas e, potencialmente, indisponíveis por um longo tempo, o que
resulta em custos mais altos de desenvolvimento. desenvolvimento e manutenção a longo prazo.

Componentes
Integração utilizando Enterprise Service Bus
A fim de evitar alguns dos problemas resultantes de uma estratégia ponto-a-ponto, poderíamos optar
por uma estratégia de arquitetura orientada a serviços. SOA é um padrão de design que se concentra
em expor as funcionalidades de um aplicativo de negócios como serviços.
Esses serviços podem ser vistos como componentes independentes que fornecem uma
funcionalidade específica. Essa abordagem incentiva o baixo acoplamento de funcionalidade e,
portanto, permite a reutilização e a economia de custos.
Um ESB pode permitir que você suporte uma arquitetura SOA no ecossistema da sua organização. É
aqui que o SAP PI ou o SAP AEX.

Componentes

Componentes
O SAP AEX desempenha os papéis de intermediário, mensageiro e tradutor ( middleware).
O SAP AEX é um ESB, e cuida da implementação da comunicação e interação entre os aplicativos de software que
estão participando da troca de dados e interagindo. Está no centro da sua estratégia de implementação de SOA.
Algumas de suas funções incluem o seguinte:
● Controlando o roteamento de troca de mensagens entre aplicativos

● Lidar com a transformação e mapeamento dos dados e mensagens transferidos da origem para o sistema de
destino e vice-versa
● Lidar com a segurança e conversão de protocolo entre o provedor de serviços e o consumidor
● Monitorar a troca de mensagens entre os sistemas envolvidos
● Gerenciamento de várias versões dos serviços fornecidos pelo ESB
O ESB elimina a necessidade de uma conexão ponto-a-ponto

Componentes
SAP Business Process Management (BPM):
Uma organização típica tem um processo de negócios claramente definido que descreve as
ações e etapas a serem executadas para concluir uma tarefa específica. Você provavelmente
encontra esses processos de negócios todos os dias.
Por exemplo, quando um novo funcionário entra em uma organização, ele precisa enviar seus
detalhes para o departamento de RH para concluir o processo de negócios da contratação de
um novo funcionário. Ou quando um funcionário precisa pedir um novo computador, seu gerente
pode precisar aprovar a ordem do computador como parte do processo definido dentro da
organização.
Uma organização pode decidir automatizar e dar suporte a esse processo usando um
mecanismo de fluxo de trabalho de processo de negócios.

Componentes
Comprando um computador utilizando BPM:

Componentes
O conjunto de ferramentas SAP BPM oferece vários benefícios, dentre eles:
● Permite que sua organização ofereça suporte a processos centralizados em ações humanos e em
sistemas
● Melhora a visibilidade e o controle nos processos de sua organização
● Proporciona flexibilidade para adaptar rapidamente seus processos às necessidades atuais de
seu negócio

Componentes
SAP Business Rules Management (BRM):
O mundo dos negócios está mudando constantemente. Essas mudanças são devidas a muitos
fatores que são influenciados internamente por uma organização ou devido a influências externas.
Mudanças externas podem ser influenciadas por muitos aspectos, desde uma nova lei trabalhista até
uma mudança no comportamento do consumidor.
Uma organização típica quer se adaptar rapidamente a essas mudanças no ambiente de negócios
para manter sua vantagem competitiva. Essa adaptação pode resultar em uma alteração das regras
de negócios existentes. As empresas podem projetar e definir suas decisões e regras de negócios em
um sistema de gerenciamento de regras de negócios. Como essas regras estão sujeitas a mudanças
constantes, faz sentido mantê-las separadas dos aplicativos de negócios reais. Essa externalização
de regras de negócios cria a flexibilidade de alterar essas regras sem ter que alterar os aplicativos de
negócios.

Componentes
Por exemplo, considere uma aplicação de RH. Este aplicativo é usado para manter todos os detalhes
dos funcionários, incluindo sua posição na estrutura organizacional. Vamos considerar uma regra
comercial hipotética dentro da organização que estipula que se um funcionário tiver um mínimo de
dez colegas subordinados a ele, ele precisará ser promovido a gerente. Tal requisito é melhor mantido
em uma regra de negócios, em vez de ser codificado no próprio aplicativo de RH.
Ter a regra fora do aplicativo de RH permitirá que outros aplicativos reutilizem o aplicativo. Além disso,
a regra pode ser adaptada rapidamente sem a necessidade de alterar o aplicativo de RH real.

Componentes

Componentes
Alguns dos benefícios oferecidos pelo SAP BRM:
● Separação de lógica e dados: os dados são mantidos no aplicativo de negócios, enquanto a lógica
é mantida no mecanismo de regras
● Repositório central de regras e conhecimento.
● As organizações estão habilitadas para automatizar as decisões de negócios.
● Os usuários funcionais e de negócios podem se envolver na definição, desenvolvimento,
modelagem e modificação de regras de negócios por meio de uma interface amigável. Partes das
regras de negócios automatizadas podem ser atualizadas pelos próprios usuários de negócios
sem a participação de desenvolvedores e sem a necessidade de reimplementação (atualizações
em tempo real).

Arquitetura

Como o SAP Process Orchestration (SAP PO) é um pacote consolidado com SAP AEX, SAP BPM e
SAP BRM em uma única stack Java, é interessante considerar a migração para uma instalação do SAP
PO para reduzir sua utilização de hardware, remover sobrecarga, e economizar custos.
O SAP PO está disponível no release do SAP NetWeaver 7.31 como uma das opções de instalação.
Consideraremos outras possíveis opções de instalação e exploraremos as vantagens e desvantagens

de cada uma delas.
É importante mencionar que a pilha ABAP continuará sendo suportada, mas todos os novos
desenvolvimentos serão focados na nova stack somente Java. Como resultado, você deve considerar a
mudança para uma instalação de stack única.
Vamos discutir as diferentes opções de instalação caso a caso.

Case 1: SAP Process Integration Dual Stack

Case 1: SAP Process Integration Dual Stack
Isto implica que você pode fazer uso do lado ABAP se melhor atende às suas necessidades. Algumas
das desvantagens dessa abordagem incluem o seguinte:
● Falta de um gerenciamento de regras de negócios (que normalmente faz parte da instalação do

SAP PO ou SAP Configuration Environment)
● Os processos de negócios só podem ser implementados usando o ccBPM e, portanto, não
aproveitam o SAP BPM
● Esta opção de instalação pode ser útil para organizações que já investiram pesadamente em sua
instalação ABAP ( mecanismo de integração e ccBPM) e ainda não estão prontas para fazer a
migração para um ambiente totalmente em Java
● Se você tiver essa opção de instalação, é importante considerar o desenvolvimento de novas
interfaces usando interfaces baseadas em Java (sempre que possível), porque você tem uma
stack Java incluída em sua pilha dupla

Case 2: SAP PI Dual Stack e SAP CE em Instalações Separadas

Case 2: SAP PI Dual Stack e SAP CE em Instalações Separadas
Algumas das desvantagens dessa opção incluem o seguinte:
● Uma sobrecarga de comunicação é introduzida com o SAP PI e o SAP CE em instalações

separadas. As duas instalações têm que enviar mensagens umas às outras constantemente
● Mais hardware é usado devido a ter duas instalações separadas e, portanto, custos adicionais são
introduzidos
● Tanto o ccBPM quanto o SAP BPM podem ser usados para implementar processos de negócios,
portanto, criando uma situação confusa na qual você precisa adivinhar qual processo de negócios
está implementado em qual instalação
Devido a essas desvantagens, recomendamos a escolha de implementações baseadas em Java, tanto

quanto possível. Isso significa que é melhor escolher o mecanismo de adaptador avançado e o SAP
BPM.

Case 3: SAP PI Single Stack e SAP CE em Instalações Separadas

Case 3: SAP PI Single Stack e SAP CE em Instalações Separadas
Algumas das desvantagens dessa opção incluem o seguinte:
Uma clara desvantagem dessa opção é a sobrecarga de comunicação de rede criada entre as duas
instalações separadas. No entanto, é importante mencionar que essa dissociação do sistema pode
trazer uma vantagem: Se a instalação do SAP Composition Environment estiver inativa, todo o tráfego
relacionado à integração ainda poderá continuar, porque é separado da instalação do SAP PI.

Case 4: SAP PI e SAP CE em uma Instalação Única

Case 4: SAP PI e SAP CE em uma Instalação Única
O SAP PO é um pacote consolidado e fornece uma forte integração entre o SAP AEX, o SAP BPM e o SAP
BRM.
Algumas das vantagens do SAP PO incluem as seguintes:
● Instalação consolidada, que elimina a sobrecarga de comunicação (como observado nos Casos 2 e 3)
● Menor custo de propriedade, com necessidades reduzidas de hardware e custos de licença com base
na CPU
● A mesma tecnologia (Java) é usada em toda a linha, o que, por sua vez, significa que você pode usar as
mesmas ferramentas de desenvolvimento baseadas em Java, como o NWDS
● Monitoramento consolidado e simplificado do landscape
Por causa desses benefícios, recomendamos escolher este pacote simplificado.

Ferramentas
System Landscape Directory

Enterprise Services Builder
Integration Directory
Configuração e Monitoramento
SAP Netweaver Administrator

Ferramentas
Home page do SAP PI na qual os administradores e desenvolvedores encontram o caminho para os componentes mais importantes do
SAP PO.
Para acessar o PI Tools, acesse http://<server>.<dominio>:<porta>/dir
Exemplo: http://srvhdb01.4hana.com.br:54000/dir/start/index.jsp

Ferramentas
System Landscape Directory
O SLD é o repositório central para informações de softwares e sistemas (ambientes). É uma aplicação servidora, que promove
informações para as aplicações Netweaver, da qual o PI é um cliente técnico. O SLD usa o padrão CIM (Common Information
Model) para estruturar as informações de todo o landscape do cliente / empresa / companhia. E é a base para se construir os
objetos no Enterprise Services Repository (Design) e Integration Directory (Configuration)

Ferramentas
Enterprise Services Builder (Design)
Ferramenta onde se constrói e desenvolve os objetos de integração, dentre eles as interfaces, tipos de dados e objetos de
mapeamento que são utilizados para implementar um cenário de integração.

Ferramentas
Integration Directory (Configuration)
Ferramenta onde é feita a configuração dos cenários de integração para os objetos construídos no Design, representando o
cenário do cliente. Uma vez que o conteúdo da integração foi criado no Design, o cenário é configurado no ID para os sistemas
que vão se integrar e trocar mensagens.

Ferramentas
Configuração e Monitoramento
O Configuration and Monitoring Home (também conhecido como “pimon”) é um novo local no qual você pode monitorar e
gerenciar diferentes áreas do seu AEX. Ele vem repleto de diferentes tipos de funções administrativas e de monitoramento que
facilitam o acesso a diferentes áreas administrativas do SAP PO.

Ferramentas
SAP Netweaver Administrator (NWA)
O SAP NetWeaver Administrator (NWA) fornece um balcão único consolidado, no qual você pode executar tarefas
administrativas, de monitoramento e de solução de problemas.

Conceitos de Integração de Sistemas
XML
XSD
XSLT
JSON
HTTP
SOAP
Web Service
WSDL
REST
IDOC
Abap Proxy

XML
XML, do inglês eXtensible Markup Language, é uma linguagem de marcação recomendada pela W3C* para a criação de
documentos com dados organizados hierarquicamente.
O XML traz uma sintaxe básica que pode ser utilizada para compartilhar informações entre diferentes computadores e
aplicações.
Uma das suas principais características é sua portabilidade, pois, por exemplo, um banco de dados pode escrever um
arquivo XML para que outro banco consiga lê-lo, ou seja, o XML auxilia os sistemas de informação no compartilhamento
de dados (especialmente via internet).
*W3C, ou World Wide Web Consortium, é um consórcio de empresas de tecnologia que visa padronizar a criação e interpretação de conteúdos para websites. Foi
fundada em 1994 por Tim Berners-Lee, o criador da internet, para extrair o máximo que a rede pode oferecer.

XML
<?xml version="1.0" encoding="utf-8"?>
<filmes>
<filme id="1">
<titulo>O XML veste prada</titulo>
<resumo>O filme mostra a elegância da XML na representação de dados estruturados.</resumo>
<genero>Aventura</genero>
<elenco>
<ator>Mark UPlanguage</ator>
<ator>Mary well-Formed</ator>
<ator>Sedna D. Atabase</ator>
</elenco>
</filme>
<filme id="2">
<titulo>Titanic</titulo>
<resumo>O filme mostra um barquinho que bateu no gelo e afundou.</resumo>
<genero>Suspense e Aventura</genero>
<elenco>
<ator>O bonitinho lá</ator>
<ator>Aquela outra bonitinha</ator>
</elenco>
</filme>
</filmes>

XSD
XML Schema é uma linguagem baseada no formato XML, recomendada pelo W3C, para definição de regras de validação
("esquemas") em documentos no formato XML.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="filmes">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="filme"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="filme">
<xs:complexType>
<xs:sequence>
<xs:element ref="titulo"/>
<xs:element ref="resumo"/>
<xs:element maxOccurs="unbounded" ref="genero"/>
<xs:element ref="elenco"/>
</xs:sequence>
<xs:attribute name="id" use="required" type="xs:integer"/>
</xs:complexType>
</xs:element>
<xs:element name="titulo" type="xs:string"/>
<xs:element name="resumo" type="xs:string"/>
<xs:element name="genero" type="xs:string"/>
<xs:element name="elenco">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="ator"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ator" type="xs:string"/>
</xs:schema>

XSLT
XSL Transformations, ou XSLT (eXtensible Stylesheet Language for Transformation - linguagem extensível para folhas de estilo de
transformações), é uma linguagem de marcação XML usada para criar documentos XSL que, por sua vez, definem a apresentação dos
documentos XML nos browsers e outros aplicativos que a suportem.
1. XML de um Empregado 3. XSLT
<?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl="">

<employee id="03432"> <xsl:template match="/">
<name>Joe Shmo</name>
<title>Manager</title>
<html>
</employee> <body>


2. Objetivo é gerar este HTML <xsl:value-of select="employee/name"/>

<html>
<body> <xsl:text>: </xsl:text>
 <xsl:value-of select="employee/title"/>
Joe Shmo: Manager 
 </body>
</body>
</html>
</html>
</xsl:template>
</xsl:stylesheet>

JSON
Acrônimo de JavaScript Object Notation, é um formato compacto, de padrão aberto independente, de
troca de dados simples e rápida ( parsing) entre sistemas, especificado por Douglas Crockford em 2000,
que utiliza texto legível a humanos, no formato atributo-valor. Isto é, um modelo de transmissão de
informações no formato texto, muito usado em web services que usa transferência de estado
representacional (REST), substituindo o uso do XML.
Exemplo:
{"Alunos":[
2 { "nome": "Henrique", "notas": [ 8, 9, 5 ] },
3 { "nome": "Chris", "notas": [ 8, 10, 7 ] },
4 { "nome": "Martin", "notas": [ 10, 10, 9 ] }
5 ]}

JSON
JSON (JavaScript Object Notation) é um modelo para armazenamento e transmissão de informações no
formato texto. Apesar de muito simples, tem sido bastante utilizado por aplicações Web devido a sua
capacidade de estruturar informações de uma forma bem mais compacta do que a conseguida pelo
modelo XML, tornando mais rápido o parsing dessas informações. Isto explica o fato de o JSON ter sido
adotado por empresas como Google e Yahoo, cujas aplicações precisam transmitir grandes volumes de
dados.
Exemplo:
{"Alunos":[
2 { "nome": "Henrique", "notas": [ 8, 9, 5 ] },
3 { "nome": "Chris", "notas": [ 8, 10, 7 ] },
4 { "nome": "Martin", "notas": [ 10, 10, 9 ] }
5 ]}

JSON vs XML
Exemplo JSON:
{"employees": [{ "firstName":"John", "lastName":"Doe" },
{ "firstName":"Anna", "lastName":"Smith" },
{ "firstName":"Peter", "lastName":"Jones" }
]}
Exemplo XML:
<employees>
<employee>
<firstName>John</firstName>
<lastName>Doe</lastName>
</employee>
<employee>
<firstName>Anna</firstName>
<lastName>Smith</lastName>
</employee>
<employee>
<firstName>Peter</firstName>
<lastName>Jones</lastName>
</employee>
</employees>

HTTP
HTTP é sigla de HyperText Transfer Protocol que em português significa "Protocolo de Transferência de Hipertexto". É um protocolo
de comunicação entre sistemas de informação que permite a transferência de dados entre redes de computadores, principalmente na
World Wide Web (Internet).
O HTTP é o protocolo utilizado para transferência de páginas HTML do computador para a Internet. Por isso, os
endereços dos websites (URL) utilizam no início a expressão "http://", definindo o protocolo usado. Esta informação é
necessária para estabelecer a comunicação entre a URL e o servidor Web que armazena os dados, enviando então a
página HTML solicitada pelo usuário.
Para que a transferência de dados na Internet seja realizada, o protocolo HTTP necessita estar agregado a outros dois
protocolos de rede: TCP (Transmission Control Protocol) e IP (Internet Protocol). Esses dois últimos protocolos formam o
modelo TCP/IP, necessário para a conexão entre computadores clientes-servidores.

SOAP
SOAP (Simple Object Access Protocol, em português Protocolo Simples de Acesso a Objetos) é um
protocolo para troca de informações estruturadas em uma plataforma descentralizada e distribuída. Ele se
baseia na Linguagem de Marcação Extensível (XML) para seu formato de mensagem, e normalmente
baseia-se em outros protocolos da camada de aplicação, mais notavelmente em Protocolo de transferência
de hipertexto (HTTP), para negociação e transmissão de mensagens.
Geralmente servidores SOAP são implementados utilizando-se servidores HTTP, embora isto não seja
uma restrição para funcionamento do protocolo. As mensagens SOAP são documentos XML que aderem a
uma especificação W3C.

SOAP

Web Service
Web Service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações
diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já
existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web Services são
componentes que permitem às aplicações enviar e receber dados. Cada aplicação pode ter a sua própria
"linguagem", que é traduzida para uma linguagem universal, um formato intermediário como XML, Json,
CSV, etc.
Um dos motivos que tornam os Web Services atrativos é o fato deste modelo ser baseado em tecnologias
standards, em particular XML e HTTP (Hypertext Transfer Protocol). Os Web Services são utilizados para
disponibilizar serviços interativos na Web, podendo ser acessados por outras aplicações usando, por
exemplo, o protocolo SOAP (Simple Object Access Protocol).

WSDL
WSDL é um a descrição em formato XML de um Web Service que utilizará SOAP / RPC como protocolo. É o
acrônimo de Web Services Description Language (Linguagem de Descrição de Serviços Web).
RPC – Remote Procedure Calls (em português, chamada de procedimentos remotos) é um modelo que define a
forma como são realizadas as chamadas a operações remotas através de web services.
Por meio de um WSDL você informa ao cliente como cada serviço em um end-point deve ser invocado: quais os
parâmetros e tipo de dados de cada parâmetro é esperado, e qual o tipo de dado do retorno será enviado como
resposta.
Além de descrever cada serviço (que pode ser comparado analogamente à um método a ser executado no programa
servidor), também descreve como podem ser encontrados. Seus elementos básicos são:

WSDL
O trecho abaixo é o ponto onde define-se os serviços:

WSDL
O trecho abaixo descreve como cada serviço deve ser chamado:

REST
Representational State Transfer, abreviado como REST, não é uma tecnologia, uma biblioteca, e nem tampouco uma arquitetura, mas
sim um modelo a ser utilizado para se projetar arquiteturas de software distribuído, baseadas em comunicação via rede.
REST é um dos modelos de arquitetura que foi descrito por Roy Fielding, um dos principais criadores do protocolo HTTP, em sua tese
de doutorado e que foi adotado como o modelo a ser utilizado na evolução da arquitetura do protocolo HTTP.
Muitos desenvolvedores perceberam que também poderiam utilizar o modelo REST para a implementação de Web Services, com o
objetivo de se integrar aplicações pela Web, e passaram a utilizá-lo como uma alternativa ao SOAP.
REST na verdade pode ser considerado como um conjunto de princípios, que quando aplicados de maneira correta em uma aplicação,
a beneficia com a arquitetura e padrões da própria Web.

REST
Imagine a seguinte situação: Você desenvolveu um Web Service REST que gerencia seis tipos de recursos. Os clientes desse Web
Service manipulam esses recursos via requisições HTTP. Ao chegar uma requisição para o Web Service, como ele saberá qual dos
recursos deve ser manipulado? É justamente por isso que os recursos devem possuir uma identificação única, que deve ser
informada nas requisições.
A identificação do recurso deve ser feita utilizando-se o conceito de URI (Uniform Resource Identifier), que é um dos padrões
utilizados pela Web. Alguns exemplos de URI’s:
●http://servicorest.com.br/produtos;
●http://servicorest.com.br/clientes;
●http://servicorest.com.br/clientes/57;
●http://servicorest.com.br/vendas.
As URI’s são a interface de utilização dos seus serviços e funcionam como um contrato que será utilizado pelos clientes para
acessá-los. Vejamos agora algumas boas práticas no uso de URI’s.

REST
Os recursos gerenciados por uma aplicação, e identificados unicamente por meio de sua URI, geralmente podem ser
manipulados de diversas maneiras. É possível criá-los, atualizá-los, excluí-los, dentre outras operações.
Quando um cliente dispara uma requisição HTTP para um serviço, além da URI que identifica quais recursos ele pretende
manipular, é necessário que ele também informe o tipo de manipulação que deseja realizar no recurso. É justamente aí que
entra um outro conceito da Web, que são os métodos do protocolo HTTP.
Vejamos agora os principais métodos do protocolo HTTP e o cenário de utilização de cada um deles:
● GET: Obter os dados de um recurso
● POST: Criar um novo recurso
● PUT: Substituir os dados de um determinado recurso
● DELETE: Excluir um determinado recurso.

IDOC
Tecnologia da SAP baseada em um documento intermediário que permite a comunicação entre SAP à SAP, SAP à Não SAP.
Mecanismos inteligentes para que a empresa atinja esta integração e distribuição de dados, diminuindo o tempo de
implementação e facilitando a construção das aplicações.
Os componentes são integrados com as aplicações do SAP e portanto asseguram uma maior confiabilidade junto ao
sistema.
Existem Tipos de IDOC standard para vários processos do SAP.
Os IDOC’s são chamados de documentos intermediários por 2 razões:
1. Orientado a mensagem: O IDoc faz a comunicação entre dois documentos de aplicações como se fosse a linguagem
utilizada por elas. Não importa se a aplicação é do R/3 ou de um sistema externo. O que indica o tipo de negócio a ser
tratado, ou seja, que aplicações estão se comunicando, é o tipo de mensagem.
2. Assíncrono: Os dados são armazenados em um IDOC antes que o documento de aplicação seja criado (gravado). Isto é
importante, pois se alguma informação incorreta for transferida, o documento de aplicação não será criado.

IDOC
Vantagens:
● Rapidez na construção das aplicações

● Redução nos esforços de desenvolvimento
● Implementação rápida
● Maior confiabilidade em relação aos processos
tradicionais para carga de informações
Arquitetura:
● Reg. Controle
● Reg. Dados (Segmentos)
● Reg. Status
Direção no Processamento:
● OUTBOUND (IDOC de saída do SAP)

● INBOUND (IDOC de entrada no SAP)

ABAP Proxy
Proxies de desenvolvimento são funcionalidades geradas que fornecem uma interface padronizada e bem conhecida para os serviços
subjacentes.
Vamos pegar o exemplo de serviços da web. Cada serviço web tem requisitos diferentes, mas pode ser chamado usando padrões
bem conhecidos e comumente acordados, como HTTP, SOAP, etc. Então, em um nível fundamental, o desenvolvedor precisa codificar
uma chamada de serviço web para cada serviço que ele deseja consumir, modificando o estruturas de dados de entrada e saída para
se adequarem a cada uma delas e também definir o ponto final de destino para cada uma delas.
Os serviços da Web são auto-descritivos. Isso significa que eles normalmente têm um documento XML (WSDL) que descreve sua
interface específica, como chamá-lo etc.
Portanto, em vez de ter o código do desenvolvedor especificamente para cada serviço da Web, podemos usar um "assistente" para
ler o arquivo WSDL e gerar a codificação necessária para chamar o serviço para nós.

ABAP Proxy
Configurando Comunicação Abap Proxy entre SAP ECC ou S/4HANA On-Premise com PI:
Comunicação SAP ECC/S/4 → PI:
1. Conexão SAP_PROXY_ESR:
Esta RFC Destination habilita a conexão da transação SPROXY com o PI, podendo navegar pelos objetos criados no Repository para criação e
testes dos Proxies
● Acessar Transação SM59

● Criar uma RFC-Destination do tipo G (HTTP-Connection to external server)
● Adicionar uma conexão chamada SAP_PROXY_ESR
● Adicione server host name e porta do PI
● Adicione o Path Prefix = "/rep"
● Na tab Logon & Security, adicione usuário e senha (com role SAP_XI_REP_SERV_USER)

ABAP Proxy

ABAP Proxy
2. RFC Connection com SAP PI (AEX):
Esta RFC Destination é quem executa toda a comunicação entre o SAP ECC/S4 com o PI AEX:
● Acessar Transação SM59

● Criar uma RFC-Destination do tipo G (HTTP-Connection to external server)
● Adicionar uma conexão com o nome que desejar
● Adicione server host name e porta do PI
● Adicione o Path Prefix = "/XISOAPAdapter/MessageServlet?ximessage=true"
● Na tab Logon & Security, adicione usuário e senha (com role SAP_XI_APPL_SERV_USER)

ABAP Proxy
Configurando Comunicação Abap Proxy entre SAP ECC ou S/4HANA On-Premise com PI:

Exercício 001 a 004 - Proxy_2_SOAP
Objetivo
Construir 4 interfaces que, partindo do S/4HANA, execute as 4 operações matemáticas através de um
web service de Calculadora.
No S/4HANA deve-se executar Abap Proxy para se comunicar com o PI e entre o PI e o DNE ONLINE,
executar um Web Service SOAP.
● Exercício 001: Adicionar

● Exercício 002: Subtrair
● Exercício 003: Multiplicar
● Exercício 004: Dividir
DNE
S/4HANA
ONLINE

Etapas no SLD (System Landscape Directory)

1. Acessar o SLD através do endereço http://servidor.dominio:porta/sld
2. O Technical System do S/4HANA é criado por Basis (e já esta criado no nosso ambiente, não precisa
criar na mão), automaticamente ao rodar a transação RZ70.
3. Criação do Business System S4HCLNT100 (que também já esta criado, apenas acesse para ver as
informações dele):
a. Em estruturas, clique em Business Systems
b. Clique em Novo Business System
c. Selecione o tipo As Abap e clique em Continuar
d. Selecione o Sistema S4H on sappl05, client 100 e clique em Continuar
e. Informe o Nome do Business System S4HCLNT100

Etapas no SLD (System Landscape Directory)

4. Criaçao do Produto PD_ALUNOXX e SWC SWC_ALUNOXX
a. No Catálogo de Software, clique em Produtos
b. Clique em Novo
c. Selecione Criar Novo Produto e Versão
d. Informe o nome do produto PD_ALUNOXX
e. Informe o fornecedor do produto, exemplo: alunoxx.com
f. Informe a versão do produto 1.0 e clique em Continuar
g. Informe o nome da Instancia PD_ALUNOXX e clique em Continuar
h. Informa o nome do Software Component SWC_ALUNOXX
i. Informe a versão 1.0 e clique em completar

Etapas no Enterprise Service Builder (Design)

1. Acesse o endereço http://servidor.dominio:porta/dir e clique em Enterprise Services Builder
2. Importação do Software Component criado no SLD:

a. Clique em Novo → Work Areas → Software Component Version
b. Selecione Import from SLD
c. Clique em Display e na lista selecione o Software Component SWC_ALUNOXX e confirme
3. Criação do Namespace da interface:

d. Dentro do seu respectivo Software Component Version, clique em Novo → Work Areas →
Namespace
e. Informe http://alunoxx.com/exercicio001/Proxy2SOAP/Calculadora:Operacao
f. Clique em Create


Desenho da Interface:
S/4HANA PI WS Calculadora
Sender Receiver
8 OM_Operacao
4 SI_Operacao_Out_Sync 5 SI_Operacao_Inb_Sync
6 MM_Operacao_Request Target
Source
1 DT_Operacao_Request 3 AddSoapIn
MT_Operacao_Request
Target
7 MM_Operacao_Response Source
2 DT_Operacao_Response 3 AddSoapOut
MT_Operacao_Response


Executar as etapas definidas no Desenho da Interface (slide anterior):
1. Criar DataType e MessageType de Request

2. Criar DataType e MessageType de Response
3. Importar WSDL do Web Service da Calculadora
4. Criar Service Interface Outbound Síncrono, utilizando Message Types de Request e Response
5. Criar Service Interface Inbound Síncrono, utilizando External Definition OperacaoSoapIN e
OperacaoSoapOut, criados no item 3
6. Criar Message Mapping de Request, ligando Message Type de Request com External Definition
OperationSoapIN
DE
7. Criar Message Mapping de Response, ligando External Definition OperationSoapOut com Message
Type de Response
ONLINE
8. Criar Operation Mapping, onde no Source utiliza-se a Service Interface de Outbound, no target
utiliza-se a Service Interface de Inbound e no Request e Response, selecionar os respectivos
Mapeamentos

Etapas no Integration Builder (Configuration)

1. Criar Party PA_ALUNOXX e Business Component BC_ALUNOXX
2. Importar o Business System do S/4HANA criado no SLD (ele já criado, esse passo estou apenas
detalhando como vocês importariam um novo):
a) Em Communication Component Without Party, clique com o botão direito em Business System
b) Selecione Assign Business System, selecione o Business System S4HCLNT100 e confirme
DE
ONLINE

Etapas no Integration (Configuration)

3. Criar Canal de Comunicação SOAP Receiver
a) Navegue para a Party PA_ALUNOXX → Communication Component → Business Component
BC_ALUNOXX → Communication Channel
b) Criar o Canal de Comunicação SOAP Receiver, sugestão de nome:
CC_Calculadora_Operacao_SOAP_Receiver
Na Aba
i) Informe Target URL: http://www.dneonline.com/calculator.asmx
ii) Informe SOAP Action da operação matemática em questão, exemplo: http://tempuri.org/Add
(este valor encontra-se dentro do WSDL importado no Design)
DE
3. Criar Cenário CS_ALUNOXX_EX001_Proxy2SOAP_Calculadora_Operacao
4. Criar Integrated Configuration (ICO): ONLINE
a) O Sender é o Business System do S/4HANA com a Service Interface Outbound e Canal de
Comunicação SOAP Sender
b) Receiver é a Party e Business Component com a Service Interface de Inbound e Canal de
Comunicação SOAP Receiver

Etapas no S/4HANA
1. Acessar a Transação SPROXY
2. Gerar o Proxy Abap para a Service Interface Outbound
3. Testar a execução da Interface
DE
ONLINE

Rievo_Curso_SAPPO75_Basico

Enviado por

Direitos autorais:

Formatos disponíveis

Rievo_Curso_SAPPO75_Basico

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Rievo_Curso_SAPPO75_Basico

Enviado por

Direitos autorais:

Formatos disponíveis

SAP PI / PO 7.

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

SAP PO é composto por três diferentes produtos:

● SAP Process Integration (PI)*

* foco do nosso treinamento

● SAP Process Integration (PI)

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

● Maior eficiência e custo total de propriedade (TCO*) reduzido

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Integração utilizando Enterprise Service Bus

Juliana - [email protected] - IP: 200.185.183.140

Integração utilizando Enterprise Service Bus

Juliana - [email protected] - IP: 200.185.183.140

Integração utilizando Enterprise Service Bus

O SAP AEX desempenha os papéis de intermediário, mensageiro e tradutor ( middleware).

● Controlando o roteamento de troca de mensagens entre aplicativos

O ESB elimina a necessidade de uma conexão ponto-a-ponto

Juliana - [email protected] - IP: 200.185.183.140

Comprando um computador utilizando BPM:

Juliana - [email protected] - IP: 200.185.183.140

O conjunto de ferramentas SAP BPM oferece vários benefícios, dentre eles:

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Alguns dos benefícios oferecidos pelo SAP BRM:

Juliana - [email protected] - IP: 200.185.183.140

Juliana - [email protected] - IP: 200.185.183.140

Consideraremos outras possíveis opções de instalação e exploraremos as vantagens e desvantagens

Vamos discutir as diferentes opções de instalação caso a caso.

Juliana - [email protected] - IP: 200.185.183.140

Case 1: SAP Process Integration Dual Stack

Juliana - [email protected] - IP: 200.185.183.140

Case 1: SAP Process Integration Dual Stack

● Falta de um gerenciamento de regras de negócios (que normalmente faz parte da instalação do

Juliana - [email protected] - IP: 200.185.183.140

Case 2: SAP PI Dual Stack e SAP CE em Instalações Separadas

Juliana - [email protected] - IP: 200.185.183.140

Case 2: SAP PI Dual Stack e SAP CE em Instalações Separadas

Algumas das desvantagens dessa opção incluem o seguinte:

● Uma sobrecarga de comunicação é introduzida com o SAP PI e o SAP CE em instalações

Devido a essas desvantagens, recomendamos a escolha de implementações baseadas em Java, tanto

Juliana - [email protected] - IP: 200.185.183.140

Case 3: SAP PI Single Stack e SAP CE em Instalações Separadas

Juliana - [email protected] - IP: 200.185.183.140

Case 3: SAP PI Single Stack e SAP CE em Instalações Separadas

Algumas das desvantagens dessa opção incluem o seguinte: