2011 WA Consultoria Carlos Rodrigo
[ SAP SAP PI NETWEAVER 7.0 ] Curso SAP PI Netweaver 7.0 de 2011
Indice Curso SAP PI 7.0 ............................................................................................................................................ 2 Fundamentos ............................................................................................................................................ 2 O que é o SAP PI ? ................................................................................................................................. 2 Metodologias ............................................................................................................................................ 2 ETL ( Extract / Transformation / Load ) ................................................................................................. 2 RPC ( Remote Process Call ) .................................................................................................................. 3 MOM ( Message Oriented Middleware ) .............................................................................................. 4 Integration Brokers ............................................................................................................................... 5 SOA ........................................................................................................................................................ 5 SAP PI Ambiente e Desenvolvimento de Interfaces .................. ........................... .................. .................. .................. .................. ................... .................. ........ 6 Arquitetura ............................................................................................................................................ 6 SLD......................................................................................................................................................... 8 ESR – Enterprise Services Repository .................................................................................................. 19
1
Indice Curso SAP PI 7.0 ............................................................................................................................................ 2 Fundamentos ............................................................................................................................................ 2 O que é o SAP PI ? ................................................................................................................................. 2 Metodologias ............................................................................................................................................ 2 ETL ( Extract / Transformation / Load ) ................................................................................................. 2 RPC ( Remote Process Call ) .................................................................................................................. 3 MOM ( Message Oriented Middleware ) .............................................................................................. 4 Integration Brokers ............................................................................................................................... 5 SOA ........................................................................................................................................................ 5 SAP PI Ambiente e Desenvolvimento de Interfaces .................. ........................... .................. .................. .................. .................. ................... .................. ........ 6 Arquitetura ............................................................................................................................................ 6 SLD......................................................................................................................................................... 8 ESR – Enterprise Services Repository .................................................................................................. 19
1
Curso SAP PI 7.0 Fundamentos O que é o SAP PI ? O SAP PI Netweaver é um sistema do tipo middleware, que disponibiliza ferramentas para o desenvolvimento de interfaces para integração de sistema utilizando o conceito da arquitetura SOA ( Service Oriented Architeture – Arquitetura Orientada de Servicos ) cuja as definições encontram-se na w3c.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 performance 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 ( Adapator Xi ), etc ... Em 2005, praticamente 1 ano após o lançamento do SAP XI 3.0, devido à quantidade versões lancadas 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 a 7.1 .
Metodologias Não podemos começar a falar de integração de sistemas utilizando o S AP 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 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 de ser utilizado porém ele possui diversos problemas técnicos entre eles podemos destacar: 2
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 se é criada 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, 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
3
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 das 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.
4
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, após realizada a conexão com sucesso, ele pode enviar a mensagem para qualquer outro sistema conectado ao IB como também receber as m ensagens de qualquer outro sistema. Esse sistema foi criado a partir de observação dos arquitetos de sistemas do sistemas de logísticas das empresas aéreas norte americanas 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 encontrava-se a localidade que ele desejava desembarcar.
SOA Com a popularização dos IBs, muitas empresas desenvolveram uma gama enorme de protocolos próprios bem como de adaptadores, tornando a tarefa de integração entre IBs distintos ou com mais de IBs praticamente impossível de ser administrada e ou construída para novas aplicações. Os problemas gerados 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. 5
Intuitividade: o serviço deve ter um proposito claro, intuitivo, provendo a solução para tarefas
previamente definidas com interfaces mais simples e limpa 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
SAP PI Ambiente e Desenvolvimento de Interfaces Arquitetura Observe a figura abaixo:
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.
6
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 re alizar 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; reprocessar mensagens direto pelo Engine; o visualizar payload de mensa gens etc. o
7
Integration Server (IS): É o mecanismo central de mensagens do PI. Todas as mensagens seja SAP, não
SAP, A2A ou B2B independentemente da tecnologia de backend, são processadas de forma consistente.
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 8
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 e 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.
9
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 Product Version”
abrindo em seguida a tela abaixo.
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 Software Unit 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.
10
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 c ampo
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 Create e o Software Component já será criado. Com o Sotftware Component criado basta importar ele no SLD ( será demosntrado mais à frente como deve ser feito ) para começarmos a construção dos objetos relacionados às interfaces que iremos construir no Intergration Repository Builder.
11
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 entrar na tela de cadastro do TS, basta clicar no botão New.
12
Após isso, irá abrir uma tela pedindo para que informemos o tipo de TS que iremos criar, conforme dito anteriormente entre todas as opções selecionaremos a “Third Party” ( sistema de terceiro ).
A tela irá mudar automaticamente mostrando no fluxo na parte de cima as etapas para esse tipo de TS. Clique em prosseguir NEXT.
13
Aparecerá na tela para que seja informado o nome do sistema e o host do sistema, no primeiro caso tenho sempre como sugestão que o nome do TS seja sempre iniciado com o prefixo TS_ e o resto um string que exemplifique claramente o sistema que se esta utilizando como serviço o host pode ser um endereço fictício do sistema, host do sistema ou simplesmente o endereço do fornecedor do sistema, pois como havia dito, para o TS Third Party esses dados são meramente informativos. A próxima tela apresentada pede que seja selecionado um produto para ser “instalado” no seu TS, na realidade,
nesse momento estaremos estabelecendo uma relação de vinculo dos objetos do Produto/Software Component com o TS e futuramente com o BS, dessa maneira, na hora da construção dos cenários de integração, ao se utilizar um Business System vinculado à esse TS que criamos aparecerão de maneira automática apenas os objetos de interfaces que estão instaladas/vinculadas a ele.
14
Selecione o produto e logo em seguida o Software Component que foi criado para essa interface de sistema e clique em FINISH. Concluimos assim a criação do nosso TS.
15
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 d o 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”.
Para incluir um novo BS basta clicar no botão “New Business System” que a seguinte tela será apresentada:
16
Escolha a opção que seja a necess ária para o momento, no nosso caso, third party, e em seguida clique em “Next”.
Selecione o TS que se deseja que esse BS seja vinculado e logo em seguida coloque um nome para o sistema que seja único.
17
Informe o nome do BS ( sugestão sempre utilize o pre fixo BS_ ) e clique em “Next”.
Selecione o produto e selecione a linha do Software Component que se deseja “amarrar” à esse BS que estamos
criando.
18
Selecione com qual “Integration Server” esse BS vai trabalhar, normalmente, em um ambiente normal, sempr e
haverá apenas um integration server. Clique em Finish e nosso BS estará finalizado e pronto para ser usado em nossas configurações de cenários de integração.
ESR – Enterprise Services 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.
Estrutura do ESR 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. 19
Para se importar um SCV basta acessar o ambiente do ESR e após logar no sistema e abrir o Enterprise Service Builder ( EDI ) do ambiente acessar o meno Tools-> Transfer from System LandscapeDirectory->Import Software Component Versions.
Logo em seguida será apresentada uma tela onde todos os Software Components criados no SLD estarão disponíveis. Selecione o que será utilizado para sua interface e clique em Import.
20
Importado o SFWC você verá uma tela como a apresentada abaixo:
21
Nela você vera primeiramente o nome do SFWC que você criou e logo em seguida uma referencia repetida do nome mas com a versão que ele representa nos cadastros do SLD, esse é o SFWCV ( Software Component Version ).
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.
22
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ín io que qualifica o tipo de interface “/sub_dominio/nome_da_interface”. Isso não é regra, m as a maioria dos desenvolvedores utiliza e ssa
conotação e é o que usaremos durante o nosso curso. Para criarmos um namespace basta clicarmos duas vezes no SFWCV e uma janela de propriedades será aberta no ESR Builder como demonstrado abaixo:
Para criarmos o namespace basta clicarmos no botão de editar e na tabela de namespaces inserir o namespace que se deseja criar com o prefixo http:// e ou urn:// .
23
Logo em seguida basta clicar em “salvar”. O namespace aparecera automaticamente abaixo do SFWCV pronto
para desenvolvermos nossas interfaces porém não vai estar ativo, entende-se por ativo, os objetos salvos porém não inicializados no ESR, ou seja, eles existem, mas ainda não podem ser utilizados como um serviço de integração.
24
Para ativarmos o namespace, basta clicarmos na aba “Change Lists”.
25
Clique com o botão direito no elemento “Standard Change List” e o menu com a opção “activate” será
disponibilizado, selecione essa opção.
26
Logo em seguida é demonstrada uma lista com os objetos que serão ativados, no nosso caso, nesse momento são todos os demonstrados na lista, basta clicar no botão Activate e seguir com o desenvolvimento de nossas interfaces.
27
Interface Objects Após ativado um namespace, vários subitens são disponibilizados o que nos importa nesse momento é o “Interface Object”, é onde primeiramente criamos os nossos objetos de integração ( data types, message types, message
mappings, external definitions, etc...). Para iniciarmos uma interface iremos pela definição da estrutura de integração, lê-se data type.
Data Type Um data type é a definição propriamente da estrutura que iremos utilizar em um lado, ou em alguns casos, em ambos os lados de uma integração de sistemas. O data type é um tipo primitivo de dado, ou seja, ele é a penas uma definição e não a interface utilizável, fazendo uma comparação com o java por exemplo, ele é a criação da classe e seus atributos/elementos e não a instanciação da mesma. O data type é formado pelo seu nome, que geralmente por definição de mercado utilizamos um prefixo “dt_” antes do seu nome. Para criarmos um data type basta clicar com o botão direito do mouse no subitem “Data Type” do “interface Objects” e em seg uida escolher a opção new.
28
Será apresentado logo em seguida uma janela solicitando o nome do seu data type, uma descrição breve e os campos de SFWCV e namespace já virão preenchidos automaticamente.
29
Preencha com o nome e a descrição que pretende usar n a sua estrutura e clique em “Create”. Logo em seguida aparecerá a tela onde o data type será configurado/criado.
O primeiro elementoque 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 30
incluirmos elementos e ou atributos basta clicar com o botão direito do mouse sobre esse elemento e adiciona-los conforme a necessidade.
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. Selecionada a criação de um elemento a seguinte linha será disponibilizada:
31
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 po r um prefixos “xsd:”:
32
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ênc ia “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.
33
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 é o carregamento do data type em uma classe propriamente dita de acesso, ou seja, nesse momento a estrutura passa a não ser um tipo primitivo dos dados e sim um objeto de dados. Para se criar um Message Type basta clicar com o botão direito no subitem do seu SFWCV referente aos message types e selecionar “New”.
Logo em seguida é exibida uma tela onde você deve informar o nome do seu Message Type e uma descrição breve, o SFWCV e o namespace já irão ser preenchidos automaticamente, aconselhamos utilizar um prefixo para o nome do seu Message Type, “mt_
”, dessa maneira, durante a construção das inte rfaces ficará bem visível o que são cada um dos objetos.
34
Clicando em “Create” a tela de configuração/criação do seu Message Type, para esse tipo de objeto não muito o
que fazer, basta associa-lo à um data type, para isso existem duas formas de ser feita, a mais pratica é selecionar o data type direto da janela de navegação e arrasta-lo até o ícone de uma mão ( simplesmente, nessa mesma região, clicar no ícone
) na região “Data Type Used” ou
e navegar até o seu data type.
Após selecionado o data type que pretende usar nesse message type notamos que, na parte da janela que mostra a estrutura de dados, que o nome da estrutura não é mais a que estava no data type que foi criado e sim o do message type, o data type passou a ser um tipo de dado como por exemplo o xsd:string, apartir desse momento, todas as referencias à essa interface serão feitas à estrutura mt_ inclusive referente a mapeamento de futuras transformações de dados.
35
Para concluirmos a criação de um message type, basta salva-lo e ativa-lo como feito anteriormente.
Message 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 ( BPM ) 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 devolva uma outra mensagem de conclusão do processo e ou confirmação do recebimento e 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 trabalhados 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 message interface. Isso ocorre pois os próprios formatos IDOC e RFC já possuem sua definição como processo síncrono pela própria SAP. Para criarmos um message interface basta selecionarnos dentro de nosso SFWCV o Interface Objects, expandir o menu, clicar com o botão direito na opção “Message Interface” e em seguida em “New”.
36
Será exibida em seguida uma tela onde é solicitado que coloquemos o nome que desejamos para o nosso message interface, uma breve descrição ( opcional ) o namespace e o nome do SFWCV, os dois últimos sempre serão preenchidos automaticamente, coloque o nome como definido no inicio do curso com o prefixo “mi___” .
37
Logo após se clicar no botão “Create” no s será apresentada a tela de configuração do nosso message interface
como demonstrado abaixo.
Nas opções de atributos ( “Attributes” ) temos as seguintes opções:
Categorias: 38
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.
Mode: o
o
Synchronous : Mensagem síncrona, onde, uma mensagem que é enviada possui um tipo de dados de retorno obrigatoriamente. Assynchronous: Mensagem sem necessidade de aguardar uma outra estrutura de retorno.
Após escolhido o tipo da interface que se deseja trabalhar deve-se vincular um message type à interface que estamos criando para isso basta seguir com o mesmo procedimento que utilizamos para vincular um data type à um message type, selecionando o message type no menu do lado esquerdo da tela e arrastando o mesmo até o ícone
ou simplesmente se clicando no ícone
.
Caso você tenha optado por criar uma interface síncrona é necessário que vc vincule um segundo message Type, 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 “Interface Mapping ). Os objetos de transformação ( message mapping, javammapping e interface mapping ) serão discutidos separadamente à partir desse momento. 39
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 se criar um massage mapping basta acessar o menu do seu SFWCV, expandir a opção Mapping Objects, selecionar a opção “message Mapping”, clicar com o botão direito e selecionar a opção “New”.
A primeira tela que é disponibilizada segue o padr ão das que utilizamos para criar os “interfaces Objects”, você deve informar o nome do seu Mess age Mapping, sugerimos nesse moemento utilizar o prefixo “MM_” antes do nome do seu mapeamento mas isso é facultativo, e uma descricao breve, os demais dados já virão preenchidos automaticamente. Clique em “create”.
40
A seguinte tela sera aprenstada, nela que faremos as configuracoes e os desenvolvimentos necessarios para a nossa transformação.
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. 41
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. 42
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 S tring 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 43
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.
44
Nessa tela devemos informar o nome da função no campo label, uma descrição breve ( opcional ) e os argumentos com os respectivos nomes, por default é fornecido na tela um primeiro argumento com o nome “a” do tipo String,
basta alterarmos o nome ( oopcional ) e ou adicionarmos mais clicando-se no ícone
.
Após feita as configurações acima basta se clicar em “Create Function” e a seguinte tela será disponibilizada.
45
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.
Interface Mapping Nossas transformações e message interfaces são agrupadas em um único objeto, o “Interface Mapping” nele
infor mamos o “message 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. Para criar uma Interface Mapping basta acessarmos o menu do nosso SFWCV expandir o nosso namespace, dentro dele acessar a opção Mapping Objects e dentro dela clicar com o botão direito do mouse no item “Interface Mappings” e escolher a opção “New”.
46
Será apresentada uma tela onde devemos informar o nome do Interface Mapping que desejamos criar, aconselhase a usar o prefixo “IM_” antes do nome que vamos utilizar, opcionalmente podemos colocar uma breve descrição sobre esse objeto e os campos namespace e SFWCV já estarão preenchidos automaticamente, cliq ue em “Create” e será disponibilizada a tela para configuração do Interface Mapping.
47
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 si mplesmente clicando no campo Name na linha que aparece dentro dessa area e selecionando o botão se navegando até o message interface que se deseja utilizar.
que será apresentado e
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 message interface que se deseja utilizar.
que será apresentado e se navegando até o
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 clicandose no campo “name” que estará disponivel e selecionando o message mapping através do botão
.
48
Após realizados os passos descritos, basta salvar e ativar o Interface Interface Mapping que foi criado. 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.
Integration Scenarios & Integration Process Integration Scenario Basicamente o Integration Scenário é um facilitados de configuração utilizado para após as nossas interf aces estarem prontas no IR criarmos pacotes p acotes para automatizar o processo de criação dos cenários no Integration Directory. O IS é um fluxo da mensagem dentro no n osso cenário com uma “ação” de início início e outra “ação” de final de processo, entre essas duas ações podem haver outras outras interligadas mas que seguem obrigatoriamente obrigatoriamente da de ínicio, sendo chamada cada uma das ações específicas até a de final de processo.
Criando um Integration Scenario Parar criarmos um novo Integration Scenario basta dentro do nosso SFWCV acessarmos o grupo Integration Scenario & Integration Process, expandir as opções e em seguida, na opção Integration Scenario clicar com o botão direito e sel ecionar ecionar a opção “ New”.
49
Será apresentada a tela incial de criação/configuração desse objeto exigindo que se informe o nome, que geralmente por convenção utilizamos o prefixo “IS_”, e também existe a possibilidade de informarmos
uma descrição breve sobre esse objeto ( não obrigatoriamente ).
Informando-se o nome e clicando no botão create será disponibilizada a tela principal de criação/configuração do Integration Scenário.
50
Nessa tela visualizamos várias colunas, nessas colunas nós iremos adicion ar 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.
51
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 52
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 ).
53
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 54
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 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.
55
Na tela de configuração do action, clique no botão “Editar”
, e insira a interface que irá ser utilizada ou dentro
respectivo de cada um dos grupos, dessa maneira uma linha será disponibilizada e para inserir a interface basta selecionar ela no do grupo de “outbound interface” ou de “inbound interface”, para isso, basta clicar no botão
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.
56
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 57
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:
58
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 Interface Mapping Correspondente que foi criado anteriormente.
59
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 b asta clicar na aba “ Documentation” e inserir qualquer texto que desejar. Ao final clique em Apply e finalise o seu integration scenário.
60
Salve e ative todos os objetos criados.
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. 61
Para se criar um Communication Channel Template basta acessar o menu “Adapter Objects” no seu Software
Component Version e clicar c om o botão direito na opção “ Communication Channel Template” selecionando a opção “ New”.
Após selecionado o botão para criar um novo CC Template, uma tela será disponibilizada para darmos um nome para esse objeto, normalmente usamos o prefixo “CC___” antes do nome do nosso CC Template. Após incluir o nome clique no botão “Create”.
62
Após clicado para criar o objeto, uma tela de configuração do CC 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. 63
