Este documento destina-se a ajudar como treinamento na criação de in

SAP PI 7.3 Parte I de II

Integrações simples para um ambiente

complexo

Carlos Pereira
Sumário
Fundamentos...............................................................................................................................................2
Oque é o SAP PI?.....................................................................................................................................2
Cronologia...............................................................................................................................................2
Metodologias..............................................................................................................................................3
ETL ( Extract / Transformation / Load )....................................................................................................3
RPC ( Remote Process Call ).....................................................................................................................3
MOM (Message Oriented Middleware)...................................................................................................5
Integration Brokers..................................................................................................................................6
SOA..........................................................................................................................................................6
SAP PI Ambiente e Desenvolvimento de Interfaces.....................................................................................8
Arquitetura..............................................................................................................................................8
SLD.........................................................................................................................................................10
Trabalhando com o SLD.....................................................................................................................11
ESR – Enterprise Service Repository......................................................................................................20
Software Component Version............................................................................................................20
Namespaces......................................................................................................................................25
Data Type...........................................................................................................................................28
Message Type....................................................................................................................................33
Service Interface................................................................................................................................35
Mapping Objects...............................................................................................................................38
Message mapping..............................................................................................................................38
Funções.............................................................................................................................................40
User Defined Functions.....................................................................................................................41
Operation Mapping...........................................................................................................................43
Process Integration Scenarios............................................................................................................46
Curso SAP PI 7.3
Fundamentos

Oque é o SAP PI?

O SAP PI Netweaver é um sistema do tipo middleware, que disponibiliza ferramentas para o
desenvolvimento de interfaces para integração de aplicações utilizando o conceito da arquitetura SOA
( Service Oriented Architeture – Arquitetura Orientada de Serviços ) definida pela World Wide Web
Consortium ( https://www.w3.org/ ).

O SAP PI é atualmente uma das principais soluções para o desenvolvimento de aplicações cross-client
existente nos ambientes empresariais de grande porte.

A vantagem de se utilizar o SAP PI se torna mais evidente em um ambiente onde parte dos sistemas que
serão integrados fazem parte dos pacotes distribuídos pela SAP onde a desempenho de cada integração
se torna evidentemente mais otimizada com a utilização dos adaptadores proprietários da plataforma
SAP ( IDOC, RFC e PROXY ).

Como um sistema que segue o padrão SOA as mensagens que trafegam pelo ambiente de PI são
basicamente arquivos de texto no padrão XML.

Cronologia
O SAP PI surgiu com o nome de SAP XI em meados de 2002 tendo o seu ambiente bem simples com
poucos adaptadores disponibilizados para as integrações ( basicamente RFC e IDOC ), em 2004 ocorreu a
primeira mudança de impacto com o SAP XI 3.0 onde foram acrescentado os demais adaptadores de
protocolos comumente utilizados em uma integração como o SOAP ( WebServices ), ABAP PROXY
( Adaptador Xi ), etc.

Em 2005, praticamente 1 ano após o lançamento do SAP XI 3.0, devido à quantidade versões lançadas
nesse período a SAP optou comercialmente de mudar a nomenclatura para SAP PI ( Process Integration )
e começando o versionamento a partir da 6.0, atualmente a versão mais amplamente utilizada do SAP PI
é a 7.0, 7.01 e 7.1 que contemplam apenas as instalações dual stack ( ABAP e Java ) e as versões mais
novas 7.3x, 7.4x e 7.5x que possibilitam a instalação mais eficiente usando a camada Java apenas
( contudo a opção de instalação dual stack ainda está disponível mesmo para essas versões.

Após a versão 7.1x a SAP começou a remodelar drasticamente a arquitetura do ambiente de integração
adicionando maior agilidade nas trocas de dados com objetos AAE ( Advanced Adapter Engine ) e
atualmente com uma nova versão desses objetos chamados de AEX (Advenced Adapter Engine
Extended ) que possibilitam uma interação diretamente com o stack java do ambiente de integração
sem mais ser necessário a utilização do módulo ABAP amplamente usado pelas outras plataformas SAP.
Metodologias

Não podemos começar a falar de integração de sistemas utilizando o SAP PI sem entendermos o
desenvolvimento e amadurecimento das metodologias de integração de sistemas utilizadas pelas
empresas desde a década de 80 até os dias de hoje.

ETL ( Extract / Transformation / Load )

Trata-se basicamente de uma extração de dados do sistema fonte onde é geralmente gerado um
arquivo de texto formato ASCII separado por virgulas ou com tamanho de cada campo de dados
definidos previamente entre o emissor dos dados e o recebedor dos mesmos.

Embora seja uma metodologia antiga é um dos métodos mais comuns, afinal, para as empresas que não
possuem conhecimento técnico suficiente, esse método de integração é o mais óbvio e mais simples a
ser utilizado, porém ele possui diversos problemas técnicos entre eles podemos destacar:

 Falta de flexibilidade
 Disponibilidade de recursos (banda de transmissão, tempo de processamento, etc.…)
 Rastreabilidade e redundância de dados

RPC (Remote Process Call )

O RPC surgiu com a visão das empresas da necessidade de não se utilizar mais arquivos de texto para o
transporte dos dados entre os seus ambientes internos onde a própria rede conectaria diretamente um
sistema ao outro podendo dessa forma, ambos os sistemas, acessarem funções/processos remotos
existentes e disponibilizados pelas equipes de desenvolvimento em cada um dos sistemas.
No mundo SAP esse tipo de comunicação é conhecido por RFC, onde criamos uma função que através de
definições de comunicação pode ser disparada por sistemas externos para que sejam disponibilizados
dados aos mesmos ou para que eles enviem os dados para processamento pelo ambiente SAP.

Embora seja efetiva uma comunicação de integração dessa forma ela também possui uma série de
problemas técnicos, os principais que podemos citar são os seguintes:

 Complexidade de integrações com mais de dois sistemas (protocolos não amigáveis e muitas vezes
desconhecidos por exemplo), gerando problemas de manutenção
 Problemas de recursos para processamento
 Redundância da conexão e tratamento de exceções durante o processamento
 Rastreabilidade dos dados

MOM (Message Oriented Middleware)

O MOM surgiu como uma evolução do RPC, onde, as aplicações de origem e destino dos dados passam a
não mais comunicarem entre si, mas apenas com um servidor de mensagens que passa ser um
centralizador responsável pelo recebimento e entrega de mensagens entre os dois sistemas.

Ele suporta dois tipos de metodologias de conexão:

 Pub-Sub: uma mensagem é enviada ao centralizador (MOM) para 1 ou mais destinatários, os sistemas
interessados em receber esse tipo de mensagem que está sendo enviada, se registra nesse “serviço” de
mensagem e passam a receber os dados que são enviados pelo emissor.
 P2P: os dois sistemas são comunicados diretamente utilizando o MOM apenas como um intermediador
dos dados.

O MOM começa a introduzir um conceito mais apurado de log e rastreabilidade de mensagens porém
trata-se de um conceito primitivo baseado no RPC mantendo praticamente os mesmos problemas
técnicos de topologia e recursos de processamento.
Problema de uma arquitetura MOM robusta:

Integration Brokers
Em um aprimoramento do MOM surgiu o conceito de Integration Broker, onde existe um serviço central
que faz o roteamento das mensagens para outros Integrations Brokers e ou sistemas que necessitam se
integrar, como podemos ver é um conceito mais maduro e bem mais perto dos conceitos atualmente
utilizados.

Nesse tipo de integração o sistema que deseja se integrar aos demais se conecta diretamente no
integration broker utilizando um protocolo previamente definido, onde, depois de realizada a conexão
com sucesso, ele pode enviar a mensagem para qualquer outro sistema conectado ao IB como também
receber as mensagens de qualquer outro sistema.

Esse sistema foi criado a partir de observação dos arquitetos de sistemas dos sistemas de logísticas das
empresas aéreas norte americano para o transporte de passageiros, onde, um passageiro que desejava
partir de um ponto sem conexão com um aeroporto maior utilizasse aeroportos menores até atingir a
rede onde se encontrava a localidade que ele desejava desembarcar.
SOA
Com a popularização dos IB, muitas empresas desenvolveram uma gama enorme de protocolos próprios
bem como de adaptadores, tornando a tarefa de integração entre IB distintos ou com mais de IB
praticamente impossível de ser administrada e ou construída para novas aplicações.

O problema gerado pela pluralidade de protocolos levou os arquitetos de sistemas pensarem em um

approuch diferente chamado SOA (Service Oriented Architeture).

Ao contrário do que muitas empresas e pessoas afirmam, SOA não é um produto e sim uma
metodologia, praticamente um ideal, de desenvolvimento. Essa metodologia, bem aplicada, possibilita
que criemos módulos de integração dinâmicos nos permitindo conectar qualquer sistema que seja.

Cada módulo (ou serviço) criado seguindo os preceitos do SOA possuí as seguintes características:

 Acessibilidade: os módulos e ou serviços devem estar disponíveis para serem acessados facilmente pelos
sistemas envolvidos na integração.
 Autonomia: em situação ideal, o serviço deve se manter ativo por sua própria conta, independente da
disponibilidade dos sistemas envolvidos na integração.
 Instintividade: o serviço deve ter um proposito claro, intuitivo, provendo a solução para tarefas
previamente definidas com interfaces mais simples e limpas com o seu entendimento facilitado.
 Estabilidade: o serviço precisa ser o mais estável possível, bem como seguro, estabelecendo assim uma
relação de confiabilidade entre os sistemas que estão sendo integrados e o próprio serviço que está sendo
acessado
 Neste capitulo abordamos os conceitos de integrações e suas evoluções até o
amplamente usado hoje em dia, o SOA, é esperado que o aluno tenha absorvido
excelentes conceitos a serem utilizados na compreensão do ambiente de integração
do SAP PI
SAP PI Ambiente e Desenvolvimento de Interfaces
Arquitetura

Vamos definir cada um dos módulos que compõe o SAP PI:

 Enterprise Serivces Repository: composto pelos módulos abaixo:

o Integration Repository: onde são armazenados todo o desenho da solução de integração
( Integration Scenarios ) como definições de data types, message mappings, java mappings,
integration processes, etc ... Aqui é possível desenvolver e modelar a mensagem ou serviço de
integração como demonstrado na figura abaixo.
 o Services Registry: É uma parte do SAP Netweaver Composition Environment 7.1 (CE), uma
complacência UDDI para definições de registro de serviço disponível em um repositório. Ele provê
API para busca e descoberta de serviços tal qual para publicação de serviços customizados e
suporta o padrão WSDL (Web Service Definition Language) .
 Integration Directory: Utilizado para as configurações de cenários propriamente ditas, basicamente onde
são configurados todas as informações necessárias para realizar uma conexão com ambas as partes da
integração, ou seja, com o sistema que envia a mensagem ( sender ) e o sistema que recebe a mensagem
processada ( receiver ).
 System Landscape Directory (SLD): trata-se de um repositório central de informações onde são realizados
os cadastros com informações dos sistemas/serviços que serão integrados.
 Central Monitoring: Oferece uma visão objetiva de todos os componentes e processos emtempo de
execução. É essencial para:
o monitorar mensagens trafegadas por diferentes partes do Integration Process;
o reprocessar mensagens direto pelo Engine;
o visualizar payload de mensagens etc.
SLD

O SLD é onde começamos a nossa construção de uma interface, cada interface que construímos no
repositor e cenários que configuramos no directory são vinculados aos dados que são previamente
cadastrados no SLD, ou seja, eles são vinculados à um produto que é vinculado à um software
componente e que por sua vez esta contido em um techinical system e esse ultimo está vinculado ao um
business system que é o responsável pelo provimento do serviço de comunicação.
Mesmo interfaces com sistemas que compõe a gama de pacotes de produtos SAP precisam ser
cadastrados no SLD, com a ressalva de que para esses tipos de produtos o software componente já vem
previamente cadastrado necessitando apenas que o profissional SAP PI faça o cadastro do techinical
system e do business system respeitando as configurações de ambiente necessárias que iremos discutir
um pouco mais a frente.

Trabalhando com o SLD

Produto/Software Component
A primeira atividade ao se construir uma interface no SAP PI é criar no SLD os produtos referentes aos
sistemas que irão interagir em nossa interface propriamente dita, caso seja um produto SAP,
provavelmente ele já se encontra cadastrado previamente no SLD.

A finalidade do cadastro do produto é puramente simbólica sendo que para nós o mais importante é o
software componente.

Para se iniciar o cadastro/configuração de um produto, na tela que se abriu no browser do SLD, deve-se
selecionar a opção “Products” que imediatamente irá direcionar o cadastro para a primeira tela de
informações.
Nessa tela podemos verificar todos os produtos criados/configurados em nosso ambiente, inclusive os
que já são instalados automaticamente pela SAP. Para criar um novo produto basta clicar no botão
“New” abrindo em seguida a tela abaixo.

Para criarmos um NOVO produto e software componente apenas selecionamos a opção pertinente a
nossa ação e clicamos em "Next" onde a tela inicial dos dados de cadastro aparecerão.
Nessa tela é selecionado o “Nome” do produto, o url do “fabricante” e a versão, esta ultima, pode
acompanhar a versão do fabricante ou então pode seguir um controle interno de versão da empresa
para qual está sendo desenvolvida a interface.

Preenchendo todos esses campos ( que são obrigatórios ) passamos para a etapa automaticamente de
fornecer os dados para um ProductInstance que servirá de base para o nosso Software Component
basta preencher com o mesmo nome do produto e ou adicionar um outro nome que respeite os seus
padrões de desenvolvimento ou da empresa e clicar prosseguir onde sera encaminhado para tela
abaixo.

No campo “Name” deve ser informado o nome do software componente que será utilizado para
armazenar os objetos das interfaces no repositor, no campo “Version” uma versão do software
componente e o campo Production State pose ser selecionado dentre as seguintes opções:

 Planned ( planejado );
 Defined ( definido );
  Started ( iniciado );
 Locked ( fechado );
 Developed ( desenvolvido );
 Published ( publicado );
 Released ( atualizado );
 Restricted ( restrito );
 Reverted ( retornado );
 Archeived ( arquivado ) (default);

Com exceção do Locked, os demais estados só possuem caráter informativo e devendo ser utilizado de
acordo com a sua necessidade.

Ao final basta clicar em “Finish” que finalizamos essa etapa da criação dos dados no SLD.

Com o Software Component criado já podemos iniciar a construção dos nossos objetos de Integração no
Repository, bastando importa-lo pela IDE ( demonstraremos isso no tópico Repository Objects).

Techinical System
Quando iniciamos a configuração do nosso cenário completo de comunicação no ESD ( Enterprise
Service Directory ) precisamos antes ter configurado um Business System que será no PI o provedor do
serviço de comunicação a ser utilizado pelo PI, esse Business System é vinculado a um Technical System,
onde são especificados os dados técnicos para acesso aos serviços.

No caso de uma conexão com um serviço NÃO SAP, essa configuração será utilizada apenas como um
cadastro simples para ser utilizado nas “amarrações” das interfaces do PI, contudo, quando trata-se do
contrário, ou seja sistemas SAP, essa configuração SAP é de suma importância onde é necessário que
seja configurado todos os endereços de acesso aos devidos serviços, portas e clientes de acordo com o
respectivo pacote SAP.

Nosso curso tem por finalidade dar base de conhecimento na construção de interfaces por esse motivo
iremos nos ater as configurações para sistemas NÃO SAP, onde normalmente é feito pelo profissional
SAP PI, em sistemas SAP essas configurações são realizadas pelo responsável BASIS e portanto não são
nosso foco.

Para iniciarmos a configuração de um Technical System primeiramente devemos acessar o ambiente do

SLD.
Após entrarmos na tela principal do cadastro de nosso Technical Systems basta clicar no botão “New
technical system” começar a configurar os dados.

Selecione a opção “Third-Party” e clique em prosseguir.

Preencha o nome que deseja para o TechnicalSystem e se possível o nome do hostname do servidor
onde o mesmo se encontra.

Selecione os Produtos que cadastrou no SLD anteriormente e vincule a esse Technical System, essa
amarração irá mais para frente nos ajudar nas configurações de nossos cenários de integração no ESD.

Ao final clique no botão “Finish”e pronto, nosso TS esta configurado, agora precisamos vincular o
mesmo a algum Business System.

Business System
O Business System é o cadastro/configuração que representa um provedor de serviço de aplicação,
entende-se por exemplo que no caso de integração de um ambiente SAP ERP e um ambiente SAP BW,
ambos seriam um business system separado onde ainda, cada cliente dos ambientes seria único em
cada BS.
No caso de um BS do tipo “Third Party” ele pode ser utilizado para varias aplicações pois ele não tem a
necessidade de estar vinculado exatamente a uma instalação especifica agindo apenas como um
cadastro de amarração das interfaces para sua configuração.

Para se iniciar o cadastro/configuração de um BS basta entrarmos no SLD e no menu principal selecionar

a opção “Business System”.

Quando entrarmos na tela de administração de Business System cadastrados no nosso SLD veremos a
seguinte tela com todos os disponíveis.

Para criar um novo Business System basta clicar no botão “New Business System” e seguir as instruções
dadas pelo SLD.
Selecione o tipo pertinente ao Business System, no nosso caso “Third Party” e em seguida clique no
botão continuar.

Selecione o TS que se deseja que esse BS seja vinculado e logo em seguida coloque um nome para o
sistema que seja único em seguida clique em continuar.
Insira o nome do BS que deseja usar para futuramente configurar o seu cenário e clique em prosseguir.

Automaticamente sera exibida uma lista com os produtos já instalados no seu TS, selecione todos ou
apenas os que deseja que sejam usados por esse BS. Após selecionar como deseja clique em prosseguir.
Como já temos um BS com a regra de servidor de integração apenas a regra de servidor de aplicação
estará disponível e automaticamente selecionada, portanto só nos resta selecionar qual o BS que iremos
usar como integrador para o nosso serviço e depois clicar em Finish.

ESR – Enterprise Service Repository

A definição usada pela SAP para esse módulo é “repositório central onde definimos, acessamos e
gerenciamos objetos SOA através de serviços”.

No ESR é onde construímos as interfaces de conexão entre os sistemas que farão parte do nosso cenário
de integração definindo desde sua estrutura de dados até a direção da comunicação de cada uma das
interfaces, ou seja, definindo os dados que serão trafegados, se a mensagem que estaremos tratando é
de entrada ( input ) ou saída ( output ) bem como se possui sincronismos ou não, construímos também
nesse módulo as regras de transformação das mensagens através de Message Mapping, Java Mapping,
XSLT Mapping ou ainda usando ABAP Mapping.,

No ESR também são definidos os workflows de processos de integração conhecidos como Integration
Process ou BPM.

Software Component Version

Todos os objetos de uma interface são geralmente armazenados no “Software Component Version” que
estaria para nós como um projeto de desenvolvimento. O FWSCV é baseado no Software Component
que criamos anteriormente no SLD ( System Landscape Directory ).

O SFWCV precisa ser importado diretamente do SLD no ESR para darmos inicio à qualquer
desenvolvimento de uma interface ou de grupos de interfaces.

Para se importar um SCV basta acessar o ambiente do ESR.

Após logar aparecera a IDE ( Interface Developer Environment ) do SAP PI para os objetos de integração.

Clique no botão NEW no menu toolbar ou selecione a opção do menu Object->New.

No menu a esquerda, seleicione a opção Work Areas e depois a opção Software Component Version,
alguns campos aparecerão do lado direito da tela, escolha a opção “import from SLD” e logo em seguida
no botão “Display”, será exibida uma tela com todos os SFWC cadastrados no SLD em ordem alfabética,
selecione o que deseja importar e clique em OK.
Automaticamente ele aparecera disponível na IDE e podemos dessa maneira prosseguir com a
construção da nossa interface.
Após clicarmos em “Create” o software componente é criado mas ainda não está salvo, antes de realizar
essa etapa podemos fazer algumas configurações.
A primeira configuração obrigatória que devemos realizar é a de linguagem nativa da nossa interface,
normalmente opte pela língua inglesa, mas poderá escolher outras linguagens dependendo do pacote
instalado pela equipe BASIS. ( configuração em vermelho )

A outra configuração importante que podemos realizar são os parâmetros de conexão com o ambiente
SAP, claro que essa opção será usada se você necessitar importar estruturas de RFCs ou IDOCs.
( configuração em verde )

Após configurados os valores desejados basta clicar no ícone de salvar no menu toolbar e pronto já
temos nosso software componente preparado para receber o primeiro objeto de integração, o
namespace.

Namespaces
Para iniciarmos um projeto de construção de uma interface não basta apenas importarmos o SFWC
dentro do ESR Builder, precisamos também criar um namespace.

Dentro do SFWC os objetos são organizados em namespaces, esses namespaces possuem a mesma
sintaxe do que os que são usados para construção dos arquivos XMLs ( para maiores informações
pesquise sobre XML no www.w3c.org ) porém a similaridade entre o XML e o namespace para ai. No
ESR, o namespace serve de qualificador de um objeto de interface como uma espécie de identificador
único. Um objeto criado no ESR possui 3 chaves que garantem a sua unicidade no sistema:

1) Software Component Version ( SFWCV )

2) Namespace
3) Nome propriamente dito do objeto

Ou seja, podemos ter o objeto exatamente com o mesmo nome mas em SFWCV diferente ou em
namespace diferente, mas isso não é aconselhável.
A definição de um namespace segue como padrão como se fosse um endereço de URL. Por exemplo, a
SAP utiliza o domínio sap.com para definir os namespaces das interfaces que são standart e ou p/
objetos standart. Logo em seguida, é inserido um qualificador de interface “/nome_da_interface/” ou
um subdomínio que qualifica o tipo de interface “/sub_dominio/nome_da_interface”. Isso não é regra,
mas a maioria dos desenvolvedores utiliza essa conotação e é o que usaremos durante o nosso curso.

Existe mais de uma maneira de se criar um namespace como qualquer outro objeto dentro do nosso
software componente, a mais trabalhosa seria clicar no botão new como fizemos anteriormente ,
escolher o tipo de objeto e em seguida vincula-lo a um software componente para proceder com as
demais configurações, a maneira mais “fácil” e intuitiva que vamos explicar seria clicar com o botão
direito sobre o software componente e escolher a opção “New”.

Após essa ação a tela abaixo será mostrada.

Selecione a opção Work Areas/Namespace, a tela irá exibir o campo para incluirmos o
endereço/namespace que iremos criar e já virá com o Software Component preenchido.

O namespace deve ser criado no seguinte formato <prefixo>:<produto>.<especialização>/<derivação>,

muita gente confunde o namespace com um endereço de internet mas esse é um pensament errôneo.
Tomando o formato SUGERIDO como exemplo poderíamos criar um namespace da seguinte maneira:

prefixo Pode-se usar as seguintes variantes : urn, url e http

produto Normalmente usamos o nome do produto que cadastramos no SLD.Exemplo: SAP ECC
Especialização Podemos especificar um conjunto de objetos distintos do nosso produto, como por
exemplo o módulo de MM
Derivação Podemos especificar um tipo de objeto mais primário como por exemplo PRODUTO

Usando os dados que sugerimos como exemplo o nosso namespace ficaria da seguinte maneira:

urn:sap.ecc.mm/Produto
Veja como fica mais facil de visualizar que as interfaces de integracao dentro desse namespace são
facilmente interpretadas como cadastro de produto da empresa existente entre o SAP ECC e um sistema
legado por exemplo.

Nunca use um endereço de internet

comum como o da empresa do
cliente como namespace

Após preenchido o nome do namespace basta clicar em “Create” e o mesmo será criado efetivamente
em nosso software componente.
Basta agora que vc clique em “Salvar” no menu toolbar e concluímos essa etapa restando apenas que
selecionemos a aba Standar Change List na nossa IDE e clicar com o botão direito sobre a change list que
aparece para o nosso software componente e clicar na opção ativar.

Data Type
Após criada as work áreas ( Software Component e Namespace ) podemos começar a construção
propriamente dita de nossos objetos de integração, começando com o objeto primeitivo de definição da
estrutra que será passada ou recebida pelas partes da integração.
Para criarmos os data types basta clicarmos com o botão direito sobre o namespace do software
componente onde desejamos agrupor determinados objetos de integração e a tela a seguir será exibida.
Escolha a opção Interface Objects/Data Type, com esse procedimento os campos Namespace e Software
Component já estarão automaticamente preenchidos facilitando o nosso trabalho, basta colocarmos o
nome do nosso data type, normalmente usamos o prefixo “DT_” antes do nome que desejamos usar
para o nosso objeto e logo após clicamos em “Create”.

A tela abaixo é a interface da IDE para a criação visual do data type.

O primeiro elemento que vemos selecionado é o que denominamos elemento primário ou de cabeçalho,
ele só é importante como referencia do tipo de estrutura que iremos utilizar, como o nome da classe em
Java. Para incluirmos elementos e ou atributos basta clicar com o botão direito do mouse sobre esse
elemento e adiciona-los conforme a necessidade.
Podemos criar abaixo do elemento raiz estruturas complexas de maneira que podemos detalhar
bastante os dados que são repassados de uma ponta a outra da integração.

A diferença entre elemento e atributo é que o elemento é uma campo de dado propriamente dito,
quanto o atributo é um qualificador do elemento a qual ele é atribuído.

A primeira coluna é onde colocamos o nome do elemento de dados que será utilizado durante a
integração, geralmente esse nome é definido em comum acordo entre as partes da integração para que
seja compreensível para os desenvolvedores que irão interagir com ela, ou ainda, em interfaces do tipo
ODBC/JDBC que irão fazer acesso ao banco de dados, os elementos tem que ter exatamente o mesmo
nome dos campos das tabelas que irão receber ou enviar os dados.

A coluna de categoria define se esse campo é um elemento ou atributo ( falamos disso anteriormente ),
enquanto a coluna type é o que é o mais importante nesse momento, dentro dessa coluna podemos
definir entre vários tipos primitivos ( string, integer, float, boolean, char, etc ... ) definidos pelo W3C para
a criação de interfaces XML, cada um desses tipos é precedido por um prefixos “xsd:”:

Logo em seguida ao Type temos uma coluna denominada “Ocorrence”, nessa coluna definimos a
quantidade de dados que podemos repetir desse dado na nossa estrutura, 0,1, n ou unbouded.
Quando definimos que no campo de mínima ocorrência “minOccurs” o valor 0 (ZERO), estamos
informando que esse campo não é obrigatório, ou seja, ele pode ser nulo ou simplesmente não ser
enviado na interface, quando acrescentamos o valor 1, ele se torna obrigatório e o não envio do mesmo
ou com valor nulo nos gerará erro na interface.

Quando definimos o campo de máxima ocorrência com o valor 1 ou qualquer outro número, definimos
que é a quantidade de vezes que esse campo pode vir repetido em nossa estrutura, ou seja, se
definimos um campo com o valor nome, esse campo pode aparecer de 1 vez até N vezes conforme o
configurado, contendo o mesmo valor ou diferentes valores, quando definimos o valor “unbouded”
estamos definindo que esse campo é uma sub tabela de dados e que abaixo dela virão varias linhas de
dados com elementos distintos. Conforme o caso de uma interface esses parâmetros são configurados
para melhor atender uma integração de dados.

Após definido o seu data type, basta salva-lo e ativa-lo como foi feito no namespace através da aba
“change lists” ou apenas clicando com o botão direito sobre a referencia ao seu data type ao lado
esquerdo da tela e clicando na opção activate.

Message Type
Um message type é um objeto onde é instanciada a estrutura primário do objeto data type para o uso
na atribuição de valores.

Para criarmos um novo message type basta clicarmos com o botão direito sobre o namespace onde
desejamos que ele seja agrupado e escolher a opção “New”.
Escolha a opção Interface Objects / Message Type no menu a esquerda e como ocorreu com o data type
anteriormente alguns dados mandatórios serão preenchidos automaticamente, basta nomearmos nosso
objeto apenas, normalmente usamos o prefixo “MT_” antes do nome que desejamos usar. Após
escolhido o nome clicamos no botão “Create”.
Uma tela com as opções em branco será apresentada, selecione o seu data type que deseja de duas
maneiras, clicando no objeto propriamente dito no menu do tipo “arvore de diretórios” que aparece ao
lado esquerdo de nossa IDE e arrastando o mesmo até o ícone no formato de uma mão aberta ou
clicando-se no “march code” onde serão apresentados todos os objetos possíveis de seleção dentro do
nosso software componente.

Após essa etapa basta clicar em salvar.

Service Interface
Quando criamos uma integração falamos muito em interface de integração, uma interface é a definição
do tipo de mensagem que iremos trafegar tendo em vista, direção, se é síncrona ou assíncrona e
estruturas.

No ESR Builder as mensagens que chegam são tratadas como “outbound”, ou seja, mensagens de saído
do serviço que está enviando a mensagem, e “inbound” mensagem que esta sendo enviada para o
sistema de destino da mensagem.

Temos ainda o tipo abstract, esse tipo é utilizado para a entrada em um integration process ( ccBPM )
que veremos mais a frente do que se trata.

Definida a direção da mensagem ( outbound ou inbound ) devemos definir se ela é síncrona ou

assíncrona. Entende-se por interface síncrona, toda aquela que quando é “disparada” aguarda enquanto
o sistema de destino processa e que ele devolva uma outra mensagem de conclusão do processo e ou
confirmação do recebimento, enquanto interface assíncrona é toda aquela interface que apenas recebe
e envia os dados sem ficar aguardando o final da entrega da mensagem.
Em uma integração temos sempre os dois tipos de direção de interfaces, o outbound e o inbound, sendo
trabalhado cada qual em seu momento, com exceção de interfaces com RFCs e IDOCs, tipos SAP de
interfaces que estão previamente configurados, todas as outras integrações necessita de um service
interface. Isso ocorre pois os próprios formatos IDOC e RFC já possuem sua definição como processo
síncrono ou assíncrono pela própria SAP.

Para criarmos um service interface basta clicarmos com o botão direito do mouse sobre o namespace
onde desejamos que ele seja criado e a tela abaixo será exibida.

Selecione a opção Interface Objects / Service Interface no menu a esquerda e preencha o nome do
Service Interface que deseja criar, normalmente colocamos o prefixo “si_” antes do nome desejado, logo
em seguida clieque em “Create” para irmos para a interface da IDE para configuração da nossa interface.
No grid com o nome Messages, na linha onde esta a regra (Role) do tipo da mensagem selecione o tipo
“Mesage Type” e na coluna “name” clique no botão a direita do campo editável para que uma tela com
os message types disponíveis seja disponibilizada para que vc selecione a estrutura a ser usada nessa
interface.

Nas opções de atributos ( “Attributes” ) temos as seguintes opções:

 Categorias:
o Inbound: mensagem que será enviada para uma interface externa ao PI, pou seja, mensagem que
será enviada para um sistema “Receiver” no nosso cenário.
o Outbound: mensagem que o PI esta recebendo para o processamento, ou seja, que está sendo
enviada pelo sistema “Sender” do nosso cenário.
o Abastract: tipo de interface de entrada para ccBPM ou Integration Process.
 Interface pattern:
o Stateless: pattern para utilização de mensagens ponto a ponto usando WebSercices quando
usamos o adapter WS ( WebService)
o Stateful: pattern usado para chamadas sucessivas, requerido em cenários especiais de
integração. Não possui garantia que os dados sejam efetivamente enviados ao destinatário.
NUNCA USADO QUANDO ENVIADO VIA INTEGRATION SERVER
o Stateless ( XI30 – Compatible ): como o próprio nome já dis tem a mesma característica do
Stateless mas riado para ompatibilidade com o XI 3.0
o TU&CC:pattern para envio de mensagens síncronas e assíncronas com controle de transação
( COMMIT e ROLLBACK). Muito pouco usado.
 Security Profile: definição de regras de segurança.
Caso você tenha optado por criar uma interface síncrona é necessário que vc vincule um segundo
message Type na linha com a regra ( Role ) de “resonse”, para isso basta vc realizar o mesmo
procedimento para se vincular o message type da primeira vez para o campo que aparece
imediatamente abaixo do primeiro.

Ao final, clique em salvar e ative a sua interface para concluir a configuração.

Mapping Objects
Após criarmos os objetos de interfaces partimos para a parte mais importante do processo de
construção da transformação das mensagens que chegam para o nosso integrador de sistemas.

A transformação das mensagens ocorrem dentro do SAP PI podem ser feitas das seguintes maneiras:

 ABAP Mapping ( totalmente em desuso e provavelmente não estará mais disponível no PI 7.3 )

 XSLT Mapping : mapeando baseado em linguagem XML padrão W3C, simples e poderosa
ferramenta.

 Message Mapping: ferramenta de manipulação das estruturas de dados para sua transformação
totalmente visual e mais utilizada no ambiente SAP PI.

 Java Mapping: mais poderosa ferramenta de transformação de dados disponibilizada no

ambiente SAP PI Netweaver.

No nosso curso iremos nos atentar apenas a dois tipos de mapeamento: Message Mapping e Java
Mapping, os demais tipos é aconselhado pelo instrutor que sejam pesquisados fora da classe para que
seja adicionado ao conhecimento que esta sendo passado.

Cada transformação, ou grupos de transformação ( no caso de mensagens síncronas ) é agrupada em

interfaces de mapeamento “Operation Mapping ). Os objetos de transformação ( message mapping,
javammapping e operation mapping ) serão discutidos separadamente à partir desse momento.

Message mapping
O message Mapping é a ferramenta mais utilizada e simples para se criar uma transformação de dados
dentro do ambiente PI e além do que, oferece uma grande quantidade de ferramentas que aumentam a
produtividade de desenvolvimento das interfaces.

Para criarmos um message mapping prosseguimos com o que foi falado anteriormente, clicamos com o
botão direito sobre o namespace que desejamos criar esse objeto e a tela abaixo será exibida.
Basta preenchermos o nome do message mapping que desejamos criar e clicar em “Create” que a
interface de configuração desse objeto sera exibida em nossa IDE.
Em vermelho, na parte superior da tela, temos o cabeçalho do nosso objeto com as informações do
nome, status, namespace e SFWCV que ele pertence, alé da descrição obviamente.

Em roxo, do lado direito, temos a estrutura ( message type ) que dará origem aos dados que serão
transformados, ou seja, será a estrutura que receberemos do sistema que está enviando a mensagem ao
PI, em amarelo teremos a estrutura ( message type ) que deveremos gerar para ser enviado ao sistema
que receberá a mensagem ao final do processo.

Em azul, na parte inferior da tela, temos a área de desenvolvimento/relacionamento da integração

propriamente dita onde adicionamos a lógica para cada campo mapeado, simplesmente legando um
campo ao outro, ou inserindo “steps lógicos” para que a mensagem seja convertida no formato
esperado na estrutura de saída dos dados.

E finalmente, em verde, na parte mais inferior da tela, temos as funções que podemos utilizar na área de
desenvolvimento, essas funções podem ser as “default” da SAP ou podemos criar nossas próprias
utilizando a linguagem java, essas funções customizadas são chamadas de UDFs ( User Defined Functions
) e iremos aborda-las mais a frente no curso.

Para começarmos realmente a “meter a mão na massa” e criar um mapeamento para a transformação
dos dados basta selecionar o “message type” da estrutura que será enviada pelo sistema de origem da
mensagem e arrasta-lo até o cabeçalho da área roxa da figura, logo em seguida devemos prosseguir
arrastando o “message type” referente à estrutura que será enviada ao sistema de destino da
mensagem para o cabeçalho da área em amarelo da figura, dessa maneira teremos disponível os
campos de cada uma das estruturas.

Basicamente, para se passar o valor de um campo de uma estrutura para o outro, basta selecionar o
campo e arrasta-lo até ele se posicionar sobre o campo que ele deve enviar ou receber os dados e
soltar, automaticamente eles aparecerão ligados na área em azul. Dessa maneira, o dado que está
chegando no lado esquerdo da tela e que está sendo enviado pelo sistema de origem da mensagem
será encaminhado automaticamente ao campo que ele está ligado do lado direito da mensagem e será
enviado ao ambiente de destino do processo.

Caso os campos apenas precisem ser passados sem nenhum tratamento aos respectivos campos do lado
direito ( receiver ), basta liga-los salvar e ativar o message mapping, dessa maneira a transformação dos
nossos dados estará concluída.

Funções
A interface de desenvolvimento do message mapping possibilita que façamos um tratamento mais
avançado das mensagens campo a campo que chegam em nosso ambiente de PI utilizando funções ( as
standarts ou as customizadas conhecidas como UDF ).

As funções standart são dividas em alguns grupos específicos:

  Text: funções para o tratamento de texto nesse grupo podemos encontrar ferramentas para
obter uma parte especifica de um string ( substring ), juntar 1 ou mais campos em um único
( concatenate), compara strings para verificar se são iguais ( equalsS), etc ...

 Arithmetic: funções para cálculos matemáticos como adição, subtração, divisão, expoenciação,
raiz quadrada, etc ...

 Statistic: funções para cálculos estatiscos como totalização, média, contagem e índice.

 Conversions: funções de conversão, basicamente, dado um valor de entrada, ele busca em uma
tabela de sistema ou uma pré-determinada o equivalente em valor.

 Date: funções para tratamento de data, como por exemplo, obter a data corrente
( currentDate ), transformação de data ( DateTrans), calculo de dias antes ( DateBefore ) e de
depois ( DateAfter), comparação entre duas datas ( CompareDates ).

 Node Functions: tratamento especifico para cada node, verificação da existência dele no xml de
entrada, validação de formatos, etc ...

 Constants: Inclusao de constantes na lógica e ou obtenção de constantes do sistema.

 Boolean: funções de tratamento lógicos incluindo tomadas de decisões tipo IF, AND, NOT, etc ...

User Defined Functions

UDFs são funções construidas utilizando-se da linguagem Java pelo próprio usuário e que são somente
disponíveis para o message mapping que estivermos trabalhando. Basicamente ela recebe um
quantidade X de parâmetros que são sempre no formato String e retorna um único parâmetro String
para o nosso mapeamento.

Como se trata de uma inserção ( injection ) de um código java no nosso processo, podemos utilizar
QUASE todas as ferramentas da versão JSDK 1.4 para interagir com sistemas externos ( chamar uma RFC
por exemplo ou um WebService ) para obter parâmetros para o tratamento dos dados, podemos utilizar
lógicas mais robustas e acessar variáveis de ambiente.

Como se trata de uma das ferramentas mais poderosas e que a SAP disponibiliza na construção de
interfaces de integração devemos utiliza-la com cautela, até porque, não existe maneira de debugar e
não temos como verificar possíveis erros lógicos em tempo de execução e dessa maneira, quando a
utilizamos, devemos criar processos de testes mais completos afim de verificar todas as possibilidades
antes de liberarmos para o uso em produção.

Para de criar uma UDF basta se clicar no ícone localizado no canto inferior esquerdo da tela na
barra de funções, ao se clicar nos será apresentada a tela abaixo.
Nessa tela devemos informar o nome da função, o titulo ( esse é o nome que sera usado para exibi-la na
nossa barra de funções), o tipo de execução e os argumentos de entrada da nossa função.

Após feita as configurações acima basta se clicar em “Create Function” e a seguinte tela será
disponibilizada.
Na região do campo “imports” devemos adicionar as bibliotecas java que iremos utilizar caso seja
necessário, caso contrário, basta deixa-la em branco e no campo abaixo incluir o código java que se
deseja utilizar.

Vale lembrar que esse editor é bem simples, não tem critica a erros de sintaxe e ou nomes de variaveis,
não edenta código automaticamente e não oferece um menu de help, dessa maneira aconselho que seja
utilizada uma EDI Java como o Eclipse para ser criar e testar o código antes de se utilizar como UDF.

Operation Mapping
Nossas transformações e service interfaces são agrupadas em um único objeto, o “operation Mapping”
nele informamos o “service interface” que criamos, definindo assim se o tipo da nossa interface
( síncrona ou assíncrona) as estruturas que serão utilizadas ( message types ) e as transformações que
serão utilizadas.

Ou seja trata-se de um agrupador de todos os dados referentes aos nossos objetos de integração.

Para criarmo um operation mapping basta clicarmos com o botão direito sobre o namespace onde
desejamos que ele seja armazenado e a seguinte tela será apresentada.
Basta informamos o nome que desejamos para o Operation Mapping e clicar em “Create”e aparecera na
nossa IDE a tela para configurarmos esse objeto.
Na tela de configuração devemos proceder da seguinte maneira:

1) Na área em vermelho ao lado esquerdo da tela, devemos colocar o “Message Interface” do tipo
output criado anteriormente e que será a interface de origem dos dados que estão sendo
enviados para a transformação do nosso cenário de integração, para isso podemos proceder de
duas maneiras, ou selecionando o “message interface” desejado no menu ao lado esquerdo ou
simplesmente clicando no campo Name na linha que aparece dentro dessa area e selecionando
o botão que será apresentado e se navegando até o message interface que se deseja utilizar.

2) Na área em amarelo ao lado direito da tela, devemos colocar o “Message Interface” do tipo
input criado anteriormente e que será a interface de destino dos dados que já sofreram
transformação no nosso cenário de integração, para isso podemos proceder de duas maneiras,
ou selecionando o “message interface” desejado no menu ao lado esquerdo ou simplesmente
clicando no campo Name na linha que aparece dentro dessa area e selecionando o botão
que será apresentado e se navegando até o message interface que se deseja utilizar.

3) Após os passos 1 e 2 deve-se clicar no botão “read interface” ( em azul na figura ) para que as
configuração sejam lidas e os campos de “Source Message” e “Target Message” sejam
preenchidos automaticamente.

4) Feito o passo 3, deve-se selecionar o Message Mapping disponivel para essa interface especifica
clicando-se no campo “name” que estará disponivel e selecionando o message mapping através
do botão .

OBs.: caso seja uma interface síncrona, abaixo do botão “Read Interface” será apresentado dois folders
com o nome “request” e o outro com o nome response e sendo dessa maneira necessário que se repita
o passo 4 duas vezes, uma vez para cada folder.
Process Integration Scenarios
Basicamente o Process Integration Scenário é um facilitador de configuração utilizado para após as s
interfaces estarem prontas no ESR criarmos pacotes para automatizar o processo de criação dos
cenários no ESD.

O PIS é um fluxo da mensagem dentro no nosso cenário com uma “ação” de início e outra “ação” de
final de processo, entre essas duas ações podem haver outras interligadas mas que seguem
obrigatoriamente da de ínicio, sendo chamada cada uma das ações específicas até a de final de
processo.

Configurando um Process Integration Scenário

Para criarmos um process integration scenario basta clicarmos com o botão direito sobre o namespace
que queremos armazena-lo e a tela abaixo será exibida.

Selecione a opção Process Integration Scenario Objects/Process Integration Scenario, em seguida

nomeio com o nome desejado, normalmente adcionamos o prefixo “PIS_” antes do nome, e clique em
“Create”. Uma tela de configuração desse objeto será exibida dentro da nossa IDE.
Nessa tela visualizamos várias colunas, nessas colunas nós iremos adicionar os “Application
Components” que utilizaremos para definir o fluxo de ações, cada Apliccation Component é uma
referência ao produto cadastrado no SLD que será responsável por conter a estrutura da mensagem que
utilizaremos para a integração. Para adicionar um aplication component, basta clicar em uma coluna que
não tenha sido utilizada até o momento e em seguida com o botão direto do mouse selecionar a opção
“Insert Application Component” .
Será apresentada uma tela onde iremos selecionar o produto e as demais opções para criarmos uma
coluna de Application Component.

Na opção “Product Version” ( que já vem selecionada por default ), iremos selecionar o nome de um dos
produtos que utilizamos em nossas interfaces, lembrando que, nesse momento selecionamos o produto
que contem a interface para a mensagem que iremos utilizar naquele momento para cada uma das
ações.

Podem ocorrer situações em que um único produto contenha todas as interfaces, nesse caso, ele será
inserido uma vez para cada ação que será disparada em colunas diferentes.
Logo após selecionada a versão do produto que iremos trabalhar devemos selecionar o Software
Component que estaremos vinculados em uma eventual ação a ser criada. E, por último, damos um
nome e uma descrição para o Application Component que estaremos criando. Caso seja um integration
Process, devemos selecionar o IP correspondente na pasta “Integration Process” . No final basta clicar
em Apply que a coluna para qual criamos o Application Component estará vinculada ao componente.

Repita os passos descritos até que todos os applications compnents que serão necessários estejam
devidamente criados para começarmos com a criação das ações para definirmos o nosso integration
scenário como o exemplo abaixo demonstra ( nesse caso teremos apenas duas colunas de ações, caso
estivessemos usando um integration process provavelmente haveriam mais colunas ).

Actions
Após criado os application components em nósso integration scenário devemos comecar a criar as ações
( actions ) que serão utilizados para definir os momentos de configuração de um cenário de integração.

Para criarmos ações basta clicar com o botão direito em um application component e logo em seguida
na opção “Create Action”.
Logo em seguida será disponibilizada uma tela onde devemos informar qual o tipo de ação, se é uma
ação interna do nosso SFWCV ou se é uma ação que chama uma interface de um outro SFWCV
existente, no caso desse exemplo tomemos como referência uma interface interna do nosso SFWCV.
Clique em “ Continue” para prosseguir para a tela de configuração do Action.

Na tela seguinte será pedido que seja criado um nome para o Action em questão, normalmente
seguimos o padrão com o prefixo “AC_” antes do nome. Clique em Finish e prossiga com a criação do
Action.
Será apresentada a seguir a tela de configuração do Process Integration Scenario com uma caixa com o
action que criamos, clique duas vezes sobre o action e a tela de configuração do mesmo será
apresentada.

Na tela de configuração do action, clique no botão “Editar” , e insira a interface que irá ser utilizada
ou dentro do grupo de “outbound interface” ou de “inbound interface”, para isso, basta clicar no botão
respectivo de cada um dos grupos, dessa maneira uma linha será disponibilizada e para inserir a
interface basta selecionar ela no menu “Interface Objects” ao lado esquerdo da tela e arrastar para cima
da nova linha de maneira que ela fique completamente seleciona e soltar o objeto, automaticamente os
campos de configuração dessa interface estarão preenchidos. Clique em salvar e retorne para a tela do
integration scenario e repita esse procedimento para cada uma das ações que forem necessárias serem
criadas lembrando que, caso as ações sejam sincronas sempre estarão no mesmo nivel no integration
scenario, caso sejam assincronas estarão em níveis diferentes.

Após criados todos os actions, no nosso exemplo estamos utilizando ações sincronas, devemos
configurar qual delas é a ação de ínicio de processo e a de final, para isso basta clicar com o botão
direito em cima de cada uma dela e selecionar se ela for de incio de processo ou de final de processo
como demonstrado abaixo:
Para a ação que será configurada como inicio do processo aparecerá um ponto negro acima do action e
para a que está configurada como final de processo, aparecerá um ponto identico mas abaixo da ação.

Após definida a ação de inicio e de fim de processo devemos conectar as ações para isso, basta
selecionar primeiramente a ação à direita e após isso a ação à esquerda pressionando o botão shift do
teclado e clicando-se com o mouse sobre cada uma delas, logo após basta cliclar novamente sobre as
ações selecionados e selecionar a opção “Create Connection...”.

As ações estamdo devidamente no nivel correto para seu tipo de sincronia ou assincronia, ao tentar
realizar a conexão entre elas, apresentará a tela abaixo para se configurar a conexão entre elas:
Estando as interfaces de output e input corretamente selecionada entre as opções existentes ( podem
haver mais de uma opção para cada tipo de interface dependendo da configuração do action ) devemos
selecionar a aba Assign Mapping e selecionar o Operation Mapping Correspondente que foi criado
anteriormente.
Caso tenhamos criado um Communication Channel Template ( vide próximo tópico como criar um CC
template ), clique sobre a opção “ Assign Communication Channel Template” e selecione os respectivos
CCs que serão utilizados, caso contrário poderá pular essa etapa, caso for necessidade de se criar
alguma documentação para acompanhar esse processo basta clicar na aba “ Documentation” e inserir
qualquer texto que desejar. Ao final clique em Apply e finalise o seu integration scenário.
Communication Channel Template
Quando desejamos pré-configurar um communication channel a ser criado no ambiente do Directory
para ser utilizado pelo nosso futuro cenário de integração podemos utilizar um template criado no
ambiente do repository.

Esse communication channel template deve estar associado ao nosso Integration Scenário e dessa
maneira, no momento de configuração do Scenário poderemos gerar os devidos CCs que estiverem
vinculados a ele.

Para criarmos um Communication Channel Template, basta clicarmos com o botão direito sobre o
namespace onde desejamos armazena-lo e a tela abaixo será exibida.
Selecione a opção “Adapter Objects/Communication Channel Template” e em seguida insira o nome
desejado para esse objeto, normalmente acrescentamos o prefixo “CCT_” antes do nome.
Após clicado para criar o objeto, uma tela de configuração do CCT aparecerá para que realizemos os
parâmetros de configuração muito similar à tela de configuração do CC existente no Directory.

Basta selecionarmos o tipo de Adaptador ( SOAP, RFC, IDOC, HTTP, XI, FILE, etc), a direção da
mensagem( sender ou receiver), o tipo de protocolo e o protocolo de mensagem, caso deseje
configurações mais especificas para o seu CC, basta clicar no botão de “ Attributes” e selecionar os
parâmetros que deseja pré-configurar e após isso clique em salvar e ao final ativar.

Não esqueça que ele só será disponibilizado via um Process Integration Scenário por isso, edite as
configurações de conexão entre os Actions correspondentes ao seus CCs templates e depois salve e
ative o Process Integration Scenário.