Ir para o conteúdo

Melhores práticas para SAP

Introdução

Há uma série de questões e considerações exclusivas para projetos de integração SAP, particularmente para integrações bidirecionais. Esta página apresenta informações relevantes para todas as integrações SAP, padrões de integração comuns para SAP e suas considerações de design, e how-tutoriais específicos da SAP.

Informações básicas

Esta seção aborda a terminologia SAP e Jitterbit, atualização de dados SAP, estrutura IDoc e formatos de data.

Terminologia

Esta seção define a terminologia específica do SAP relacionada ao Jitterbit Design Studio e seu SAP Connector.

Terminologia SAP

  • SAP: Quando nos referimos ao SAP, queremos dizer uma versão do SAP que é compatível com o conector SAP do Jitterbit Design Studio. O componente essencial que o Design Studio SAP Connector requer é uma versão do SAP que usa o SAP Java Connector (SAP JCo). Isso inclui o ECC versão 6 ou posterior e o SAP S/4HANA single-tenant.
  • IDoc: Um Documento Intermediário (IDoc) é um arquivo de texto com um formato predefinido semelhante a um documento de Intercâmbio Eletrônico de Dados (EDI). Existem IDocs para objetos de dados mestres, como clientes e fornecedores, bem como para objetos transacionais, como ordens de venda. Originalmente usados para trocar dados entre sistemas SAP, os IDocs também podem ser usados para integração de externo. Esteja ciente de que um IDoc usa abreviações em alemão dentro do documento.
  • BAPI: Uma Business Application Programming Interface (BAPI) é uma API — similar a uma API SOAP ou REST — e usa uma construção de solicitação e resposta para se comunicar com o SAP. Uma diferença principal do SOAP ou REST é que um BAPI tem um único método e é específico para um objeto. Por exemplo, há 60 BAPIs relacionadas somente ao objeto do cliente da SAP. Os BAPIs são entregues e mantidos pelo SAP.
  • RFC: Um RFC (Remote Function Call) é o mesmo que um BAPI, exceto que um RFC pode ou não ser mantido em atualizações SAP. Alguns RFCs são padrão e fornecidos pela SAP. RFCs personalizados também podem ser criados para dar suporte a integrações e devem ser mantidos pelo cliente SAP.

Terminologia Jitterbit

  • Conector SAP: O conector SAP do Jitterbit Design Studio usa SAP Java Connector (SAP JCo) para trabalhar com objetos SAP e é compatível com ECC versão 6 ou posterior, e SAP S/4HANA on-premises. O SAP Connector pode ser usado pronto para uso para comunicações de entrada SAP do Harmony para o SAP usando RFCs, BAPIs ou IDocs.
  • Ouvinte de eventos SAP: O Jitterbit SAP Event Listener é um aplicativo que instala e executa como um serviço em um servidor Windows ou Linux. Ele estende a funcionalidade do SAP Connector ouvindo e recebendo IDocs de saída do SAP. Usando o protocolo RFC transacional (tRFC), os IDocs são enviados em um lote sem uma ordem definida. Usando o protocolo RFC em fila (qRFC), o SAP Event Listener responde ao SAP após receber cada IDoc, sinalizando ao SAP para enviar o próximo IDoc na transação.

Atualizando dados SAP

Como prática recomendada, ao atualizar dados no SAP, usar um BAPI ou RFC é geralmente preferível a usar um IDoc. O principal motivo para isso é que BAPIs e RFCs retornam uma resposta que pode ser usada no projeto de integração:

  • Uma atualização bem-sucedida geralmente tem IDs de registro na resposta, que podem ser usadas para atualizar o aplicativo de origem.
  • Se um erro for retornado, ele pode ser incorporado aos processos de tratamento de erros.

Em comparação, quando um IDoc é enviado, o único reconhecimento enviado de volta é um código indicando que ele foi recebido; não há indicação de sucesso ou falha. IDocs são processados no SAP de forma assíncrona. Se um IDoc falhar, a ação do usuário é necessária para reprocessar o IDoc.

Existem certos cenários em que um IDoc é preferível:

  • Um IDoc pode conter vários registros, enquanto BAPIs e RFCs geralmente podem manipular apenas uma única atualização de registro. Um cenário de atualização em massa pode exigir o uso de um IDoc.
  • Um IDoc pode ser usado para capturar dados alterados, enquanto BAPIs e RFCs não podem manipular consultas baseadas em registro de data e hora.
  • Pode haver funcionalidade que um IDoc pode invocar que não está disponível usando um BAPI ou RFC.

Estrutura do IDoc

A estrutura de um IDoc é plana. Embora o XML pareça hierárquico, os nós repetidos não são realmente aninhados dentro dos nós pais.

Na estrutura de exemplo abaixo, todos os segmentos do pai IDOC estão no mesmo subnível. As informações do cabeçalho estão no mesmo nível que as informações do item:

anexo

Formatos de data

Embora o SAP possa exibir datas em sua GUI em diferentes formatos (seguindo as convenções do país), o formato de dados para as APIs SAP é yyyy-mm-dd.

Padrões de integração

Esta seção apresenta padrões de integração comuns que podem ser usados para interagir com dados SAP.

Integração de dados mestres de clientes

No SAP, um cliente pode ser uma das — ou uma combinação de — funções de parceiro, como SoldTo, ShipTo e BillTo. Por exemplo:

  • Um cliente pode ser seu próprio SoldTo, ShipTo e BillTo.
  • Um cliente pode ser um SoldTo e um BillTo, com um cliente diferente como ShipTo.
  • Um cliente pode ser um SoldTo com muitos outros clientes sendo os ShipTos (um caso comum em que um cliente de franquia tem muitos locais)

Ao usar o objeto de cliente SAP em projetos de integração, é essencial ter um entendimento completo dos requisitos de integração para clientes e funções de parceiros.

Com um carregamento inicial de dados, em geral os clientes SoldTo precisam ser carregados primeiro, já que os outros clientes dependem do SoldTo para existir no endpoint de destino para construir o relacionamento. Como o BillTo contém o endereço de cobrança, frequentemente a definição do cliente do endpoint precisa dos endereços principal e de entrega, e a integração precisa atualizar o cliente SoldTo com o endereço BillTo no endpoint.

No exemplo abaixo, um único IDoc do SAP resulta em um upsert para uma conta e uma conta filha de objeto personalizado no Salesforce:

anexo

Integrações bidirecionais

Projetos de integração bidirecional são aqueles em que os dados fluem tanto para quanto de cada endpoint. Por exemplo, você pode precisar que os dados do cliente SAP sejam criados em um endpoint de destino e que quaisquer alterações nos dados do cliente nesse endpoint de destino sejam refletidas nas funções de clientes e parceiros no SAP.

Como as regras de validação de dados de criação de objetos do SAP são mais rigorosas do que outros endpoints, isso requer trabalho personalizado tanto no endpoint quanto no próprio SAP para lidar com as funções do parceiro. Este exemplo mostra a movimentação de contas do Salesforce para o SAP e lida com o gerenciamento da função do parceiro:

anexo

Capturando dados alterados para objetos de dados mestre

Em geral, IDocs são usados para capturar dados alterados no SAP, pois BAPIs e RFCs não podem manipular consultas baseadas em registro de data e hora.

IDocs podem ser configurados para serem gerados usando ponteiros de alteração associados a um objeto e podem ser gerados para conter todos os dados ou apenas alterações. Obter todos os dados geralmente é uma escolha melhor, pois pode haver relacionamentos nos dados que são necessários para um upsert. No entanto, atualizações em massa de dados podem disparar milhares de IDocs por vez, cujo processamento pode então exceder o login ou outros limites no endpoint de destino.

Processamento direto

O processamento direto segue este fluxo de dados:

  1. O SAP Event Listener recebe um IDoc.
  2. O SAP Event Listener move a payload para a fila de operação do Jitterbit.
  3. A operação recebe o IDoc.
  4. Os dados do IDoc são carregados no endpoint de destino.

Embora o processamento seja direto, considere estes efeitos do processamento direto:

  • Se milhares de IDocs forem enviados de uma vez, o SAP Event Listener instanciará vários threads e criará várias chamadas simultâneas. Se a chamada for para atualizar um endpoint com limites de login, como Salesforce, o volume de chamadas poderá exceder os limites de login.
  • Se o endpoint de destino estiver inacessível, a payload do IDoc não será entregue ao destino final e será perdida.

Processamento de armazenamento e encaminhamento

A alternativa ao processamento direto é o processamento de armazenamento e encaminhamento, em que a payload do IDoc é gravada em um arquivo temporário.

Na cadeia de operação de exemplo abaixo:

  1. A primeira operação recebe um IDoc do SAP Event Listener e o armazena localmente.

  2. A segunda operação é em um cronograma rápido (como a cada minuto) e escaneia o diretório de arquivos em busca de arquivos para processar. Quando os arquivos são encontrados, eles são passados em loop e cada arquivo é passado para a próxima operação.

  3. Quando a última operação na cadeia é executada, ela exclui o arquivo, e o loop é repetido até esgotar. Se houver uma falha técnica durante o processo, o arquivo não é excluído e é reprocessado uma segunda vez.

    Nota

    Por padrão, os arquivos temporários são armazenados por 24 horas antes de serem excluídos. Isso é configurável para um período maior, se necessário.

anexo

anexo

Ao executar operações em um ambiente multiagente, um IDoc pode ser recebido pelo Agent 1 e armazenado localmente, mas o agendamento pode selecionar o Agent 2, que não encontrará arquivos para processar. Não será até que o Agent 1 seja chamado pelo agendador que seus arquivos serão processados.

Tenha em mente que todos os arquivos nos diretórios temporários serão processados até esgotarem. Se houver um requisito de que os IDocs devem ser garantidos para serem processados em ordem, então use um recurso compartilhado, como um site FTP, um sistema de arquivos local ou um banco de dados. No entanto, adicionar armazenamentos de dados externos pode criar um ponto de falha adicional. Clusters de Agente são usados para failover e balanceamento de cargas, portanto, usar armazenamentos de dados externos que não são configurados de forma semelhante pode prejudicar a robustez geral do sistema.

Extraindo um ID para buscar dados adicionais

Se o IDoc tiver um ID, um BAPI pode ser chamado para buscar dados adicionais:

anexo

anexo

No exemplo acima, olhando para a terceira operação (3. Mat-Get Details), o IDoc é lido para recuperar o ID do material, que é então usado para chamar um RFC personalizado. Esta captura de tela mostra a transformação extraindo o ID do material:

anexo

Como tutoriais específico do SAP

Esta seção fornece tutoriais específicas do SAP para estes tópicos:

Manipulando datas finais vazias

Se uma data final não for preenchida no SAP (como pode ser o caso em um contrato "perene"), o SAP enviará 00000000 em um IDoc, que pode ser capturado e manipulado:

result = FindValue("108", OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.IDDAT$, OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.DATUM$);
If(result == "00000000",
  RunScript("<TAG>Scripts/WTOL</TAG>", "No End Date, using 12/31/4000");
  result="40001231"
);
GetUTCFormattedDateTime(result, "UTC", false);
// The year 4000 is the maximum date used by Salesforce

Para mais detalhes, veja as funções Jitterbit FindValue(), RunScript(), e GetUTCFormattedDateTime().

Encontrar funções de clientes e parceiros

Ao procurar a função de cliente ou parceiro apropriada no SAP, preste atenção especial às abreviações em alemão.

Por exemplo, ao criar uma ordem de venda, na GUI do SAP você pode ver um nome como Sold-To Party ou a função de parceiro equivalente específica do idioma SP, mas a API do SAP usa a abreviação alemã AG, conforme mostrado na primeira coluna:

Função do parceiro Idioma Nome Função do parceiro específica do idioma
AG EN Parte vendida SP
RE EN Parte do projeto de lei BP
RG PT Pagador PA
NÓS EN Parte de embarque SH

Usando o construtor de funções SAP para modelar uma chamada de API

Ao mapear dados em uma transformação usando um destino BAPI ou RFC, é útil testar os valores exatos que o SAP está procurando, pois o que é visto na GUI do SAP geralmente não é o que é usado na API do SAP.

Você pode usar o código de transação SAP SE37 para acessar o Function Builder da SAP para modelar uma chamada BAPI ou RFC. Para um exemplo completo, consulte Parte 2: Modelando a consultar na instância SAP em Guia para usar RFC_READ_TABLE para consultar tabelas SAP.

Manipulando convenções BAPI

Certos BAPIs — como BAPI_SALESORDER_CREATEFROMDAT2 — têm conjuntos de campos que exigem tratamento especial.

Conforme mostrado abaixo, os campos que são mapeados no cabeçalho (ORDER_HEADER_IN) são repetidas no *_INX pasta. Para informar ao SAP que você pretende preencher os campos de cabeçalho, insira um "X" como o valor do campo em cada um dos campos que são uma repetição de um campo de cabeçalho:

anexo

No entanto, no ORDER_ITEMS_INX seção, a ITM_NUMBER campo sob ORDER_ITEMS_INX não tem um "X" inserido; em vez disso, ele recebe o mesmo número de item usado no campo ORDER_ITEMS_IN:

anexo

Manipulando funções de parceiros com pastas adicionais

Nesta seção, precisamos passar SoldTo, ShipTo e BillTo. Adicionamos pastas adicionais para mapeá-los e definimos como padrão as funções de parceiro (AG, WE, RE):

anexo

Lidar com funções de parceiro com oSetInstances função

Uma alternativa para adicionar novas pastas é usar o SetInstances() função sem pastas adicionais:

anexo

Na condição raiz, criaríamos uma série de matrizes dentro de um PartnersArray e configure-o para o ORDER_PARTNERS usando:

SoldToParentArray = Array();
Set(SoldToParentArray, "AG", -1);
Set(SoldToParentArray, Order$Header$Sold_To_Customer_Number$, -1);

ShipToParentArray = Array();
Set(ShipToParentArray, "WE", -1);
Set(ShipToParentArray, Order$Lines$Line#1.Customer_Number$, -1); // new change

BillToParentArray = Array();
Set(BillToParentArray, "RE", -1);
Set(BillToParentArray, Order$Header$Bill_To_Customer_Number$, -1);

PartnersArray = Array();
Set(PartnersArray, SoldToParentArray, -1);
Set(PartnersArray, ShipToParentArray, -1);
Set(PartnersArray, BillToParentArray, -1);

SetInstances("ORDER_PARTNERS", PartnersArray);
True

Na condição da pasta em ORDER_PARTNERS, para definir as instâncias usaríamos:

$instanceReference = GetInstance();
True

Para mais detalhes, veja as funções Jitterbit Set(), GetInstance(), e SetInstances().

Manipulando números de linha incrementais

Na seção ORDER_SCHEDULES_IN, inseriríamos novamente um "X" nos campos de dados.

anexo

Para o campo SCHED_LINE, o SAP os incrementa em 10 (linha 10, linha 20, linha 30 e assim por diante). Podemos usar uma variável global counter na condição sob ORDER_SCHEDULES_IN para calcular o valor:

If(Length($ItemLineCounterS) == 0, $ItemLineCounterS = 0);
$ItemLineCounterS = $ItemLineCounterS + 10;
True

Para mais detalhes, veja a função Jitterbit Length().

Recuperando valores de um IDoc

Aqui queremos obter datas de início e término de um IDoc para criar um contrato. Os dados estão localizados aqui:

anexo

Em E1EDP03, queremos o DATUM valor onde IDDAT == 107 (ou 108) para as datas de início e término, respectivamente. Uma função útil para isso é o Jitterbit FindValue() função. Esta função percorrerá o IDDAT valores, encontre aquele com "107" e recuperar o DATUM campo:

result=FindValue("107", OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.IDDAT$, OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.DATUM$);

Solução de problemas de confirmações BAPI

Em alguns cenários, você pode descobrir que, embora a execução de um BAPI pareça bem-sucedida, a transação esperada não é confirmada no SAP.

Isso pode ocorrer se um BAPI retornar um tipo de resposta diferente de S (Sucesso). O SAP Connector do Jitterbit, por padrão, emite um commit de transação BAPI (no mesmo thread) somente quando uma resposta BAPI é Sucesso. No entanto, ele não emite um commit de transação se a resposta BAPI for qualquer coisa diferente de Sucesso.

Por exemplo, o tipo de resposta pode ser I (Informação), E(Erro), ou W(Warning). O tipo de resposta é retornado no RETURN campo TYPE do nó:

anexo

Se você estiver usando um BAPI personalizado, recomendamos alterar o BAPI para retornar um Sucesso.