Chamada de Função Remota (RFC) em SAP Tutorial ABAP

⚡ Resumo Inteligente

A Chamada de Função Remota (RFC) é a SAP Mecanismo de comunicação que permite a um programa ABAP invocar um módulo de função em execução em outro sistema. SAP ou sistema externo. Absolutamente.tracÉ a infraestrutura de rede, converte formatos de dados e comunica as falhas ao solicitante de forma clara.

  • 📡 Mecanismo Central: CALL FUNCTION…DESTINATION invoca um módulo de função em um destino lógico definido em SM59.
  • 🔁 Quatro variantes: SyncRFCs cronológicos, assíncronos, transacionais e enfileirados garantem, cada um, uma configuração de entrega diferente.tract.
  • 🌐 Tipos de conexão: O SM59 suporta os tipos 3 (ABAP para ABAP), 1 (pares no mesmo banco de dados) e 2 (programas externos).
  • 🛠️ Caminho de construção: Configure o módulo de função para "Habilitado para acesso remoto" na transação SE37, codifique-o e defina o destino no servidor SM59 para o chamador.
  • 🤖 Ângulo da IA: Assistentes de IA geram stubs RFC ABAP a partir de especificações em linguagem natural e analisam erros SM58, transformando-os em correções práticas.

Funções da interface RFC

O que é RFC em SAP?

RFC é um anagrama para Chamada de função remotaÉ o mecanismo que permite que aplicações empresariais se comuniquem e troquem informações — em formatos predefinidos — com outros sistemas. A RFC é a forma mais comum de comunicação. SAP Um sistema comunica-se com outro e também serve de ponte entre eles. SAP sistemas para não-SAP aplicações.

A RFC oferece duas interfaces:

  1. Uma interface de chamada para Programas ABAP.
  2. Uma interface de chamada para não-SAP programas.

Qualquer programa ABAP pode invocar uma função remota usando o FUNÇÃO DE CHAMADA...DESTINO demonstração. O DESTINATION parâmetro diz ao SAP sistema em que a função chamada é executada em um sistema diferente daquele que a chamou.

Sintaxe

CALL FUNCTION 'remotefunction'
  DESTINATION dest
  EXPORTING  f1 = ...
  IMPORTING  f2 = ...
  TABLES     t1 = ...
  EXCEPTIONS ...

Os destinos lógicos são definidos por meio de transação. SM59 e armazenado em tabela RFCDES.

Funções da interface RFC

Funções da interface RFC

O ambiente de execução RFC é responsável por três coisas em cada chamada:

  • Converter todos os dados dos parâmetros para a representação esperada pelo sistema remoto.
  • Chamar as rotinas de comunicação necessárias para conversar com o sistema remoto.
  • Lidar com erros de comunicação e apresentá-los ao interlocutor através do EXCEPTIONS parâmetro de CALL FUNCTION.

comunicação RFC entre SAP sistemas

RFC é o SAP Protocolo que gerencia a comunicação entre sistemas e simplifica a programação relacionada. É o processo de chamar um módulo de função que reside em uma máquina diferente daquela do programa que o chama. Tecnicamente, as RFCs podem ser usadas para chamar um módulo de função no mesmo sistema. mesmo máquina, mas são mais frequentemente usadas quando os programas que chamam e os programas chamados são executados em máquinas separadas. O sistema de interface RFC é usado para estabelecer conexões RFC entre diferentes SAP sistemas, bem como entre SAP e externo (não-SAP) sistemas.

Informações essenciais sobre RFC

  • SAP utiliza o CPIC Protocolo (Interface de Programação Comum para Comunicação) para transferência de dados entre sistemas. CPIC é SAP-específico. RFC é uma interface de comunicação construída sobre CPI-C, mas com mais funções e uma interface mais amigável para programadores de aplicativos.
  • As funções da biblioteca RFC suportam o Linguagem de programação C e Visual Basic em Windows .
  • As conexões RFC funcionam em todo o sistema. Uma conexão RFC definida no cliente 000 também pode ser usada a partir do cliente 100 sem qualquer diferença.
  • RFC é o protocolo para chamar sub-rotinas especializadas (módulos de função) pela rede. Módulos de função são comparáveis ​​a funções em C ou procedimentos em Pascal: eles expõem uma interface definida através da qual dados, tabelas e códigos de retorno são trocados. Os módulos de função são gerenciados internamente. SAP sistema em uma biblioteca dedicada, o Construtor de funções.
  • O Construtor de Funções (transação) SE37) oferece aos programadores de aplicativos um ambiente para escrever, documentar e ensaio Módulos de função que podem ser chamados localmente e remotamente. O sistema gera automaticamente o código adicional (o esboço de RFC) necessário para chamadas remotas.
  • As conexões RFC são mantidas usando transações. SM59. SAP também envia um SDK RFC (Kit de Desenvolvimento de Software) que utiliza extensas bibliotecas C para que programas externos possam se conectar ao SAP sistema.
  • A única diferença entre uma chamada remota para outro servidor e uma chamada local é a DESTINATION parâmetro que especifica o servidor de destino no qual o programa deve ser executado.

Vantagens do RFC

A RFC reduz o esforço de programação ao eliminar a necessidade de reimplementar módulos e métodos na extremidade remota. A camada RFC cuida de:

  • Converter os dados para um formato que o sistema remoto (destino) possa entender.
  • Executar as rotinas necessárias para estabelecer a comunicação com o sistema remoto.
  • Lidar com erros que surgem durante a comunicação.
  • Garantir uma semântica transacional confiável quando variantes transacionais ou enfileiradas são utilizadas.

Tipos de RFC

Tipos de RFC

SAP Suporta quatro variantes de RFC. Cada uma oferece um equilíbrio diferente entre latência, confiabilidade e garantias de ordenação.

1. SyncRFC cronal (sRFC)

SyncA RFC cronous exige que tanto o cliente quanto o servidor estejam disponíveis no momento da chamada. É o tipo mais comum e é usado sempre que o chamador precisa do resultado imediatamente após a execução.

sRFC é um meio de comunicação entre sistemas onde se esperam confirmações (ACKs). Os recursos do sistema de origem aguardam no sistema de destino e garantem que a mensagem chegue com um ACK. Os dados trocados são consistentes e confiáveis.

A desvantagem é que, se o sistema de destino estiver indisponível, os recursos do sistema de origem aguardam até que ele volte a funcionar, o que pode levar os processos do sistema de origem a entrarem em modo de suspensão/RFC/CPIC no sistema de destino e bloquear recursos.

Usado para:

  • Comunicação em tempo real entre sistemas.
  • Comunicação entre o SAP Servidor de Aplicativos Web e o SAP GUI.

2. RFC Assíncrono (aRFC)

A comunicação RFC assíncrona ocorre entre sistemas sem a necessidade de confirmação — comparável ao drop (desconexão).ping um cartão postal. Ambos os sistemas não precisam estar disponíveis no momento da execução, e o resultado não é retornado imediatamente ao sistema que fez a chamada.

O recurso do sistema de origem não espera pelo sistema de destino; ele entrega os dados e prossegue. Isso torna o aRFC rápido, mas não confiável por si só — os dados podem ser perdidos se o sistema de destino estiver indisponível.

Usado para:

  • Comunicação "disparar e esquecer" entre sistemas.
  • Processamento paralelo entre sistemas.

3. RFC transacional (tRFC)

A RFC transacional é uma forma especial de RFC assíncrona. Ela garante o processamento de etapas que, de outra forma, seriam autônomas, seguindo um padrão semelhante ao de transações.

O tRFC executa o módulo de função chamado no servidor RFC exatamente uma vez, mesmo que os dados sejam enviados várias vezes devido a problemas de rede. O sistema remoto não precisa estar disponível no momento em que o cliente RFC executa a chamada. O componente tRFC armazena a função chamada e seus dados no servidor. SAP banco de dados sob um único ID da transação (TID)Se o sistema de destino estiver indisponível, os dados são gravados em tabelas RFC (visíveis na transação). SM58) e posteriormente captado pelo relatório do agendador RSARFCSE, que é executado a cada 60 segundos.

Usado para:

  • Extensão da RFC assíncrona com entrega no máximo uma vez.
  • Comunicação confiável entre sistemas onde a execução exatamente uma vez é essencial.

4. RFC em fila (qRFC)

O RFC enfileirado estende o tRFC garantindo que as etapas individuais sejam processadas na sequência especificada pela aplicação que faz a chamada. Para assegurar que múltiplas LUWs (Unidades Lógicas de Trabalho/transações) sejam processadas na ordem pretendida, o tRFC pode ser serializado utilizando filas de entrada e saída — daí o nome “RFC enfileirado”.

Usado para:

  • Extensão da RFC transacional com ordenação estrita.
  • Cenários em que uma sequência de processamento definida é obrigatória.
  • Casos em que várias transações devem ser processadas em uma ordem predefinida.

Comparação de tipos RFC

Formato Chamada em espera? Confiável? Pedido feito? Melhor Para
sRFC Sim Sim N/A (chamada única) Consultas em tempo real
umRFC Não Não Não Dispare e esqueça, trabalho paralelo
tRFC Não Sim (exatamente uma vez) Não Atualizações assíncronas confiáveis
qRFC Não Sim (exatamente uma vez) Sim Atualizações rigorosamente ordenadas

Tipos de conexões RFC

Tipos de conexões RFC

O SM59 suporta vários tipos de conexão. Os três que você encontrará com mais frequência estão resumidos abaixo.

Tipo 3 — ABAP para ABAP

As entradas do tipo 3 especificam a conexão entre Sistemas ABAPO nome do host ou endereço IP é obrigatório; as informações de login podem ser fornecidas opcionalmente. O Tipo 3 é aplicável tanto para RFCs entre sistemas ABAP quanto para chamadas externas para sistemas ABAP.

Tipo I — Par de mesmo banco de dados

As entradas do tipo I especificam sistemas ABAP que compartilham o mesmo banco de dados que o sistema atual. Essas entradas são predefinidas e não podem ser modificadas. Um nome de entrada típico se parece com: ws0015_K18_24:

  • ws0015 — nome do host
  • K18 — nome do sistema (banco de dados)
  • 24 — Nome do serviço TCP

Tipo T — Programa Externo

Os destinos do tipo T conectam-se a programas externos que usam a API RFC para receber RFCs. O tipo de ativação pode ser... Começar or RegistroSe for "Iniciar", o nome do host e o caminho do programa a ser iniciado devem ser fornecidos.

Como Code uma RFC

A construção completa de uma RFC tem cinco etapas. As três primeiras envolvem cliques mecânicos nos conectores SE37 e SM59; as duas últimas consistem em obter o conector.traccerto.

Passo 1: Na guia de atributos do módulo de função da transação SE37, defina o tipo de processamento para Módulo habilitado para controle remoto Para marcar o módulo de função como compatível com RFC.

Módulo SE37 com controle remoto

Passo 2: Escreva o código do módulo de função no editor de código-fonte.

código-fonte do módulo de função

Passo 3: Defina o destino do servidor RFC no sistema cliente RFC que chama a função remota — feito na transação. SM59.

Configuração de destino SM59

Etapa 4 — Declaração de parâmetros: Todos os campos de parâmetros para um módulo de função remoto devem ser definidos como campos de referência — ou seja, tipados com base em campos do Dicionário ABAP. Parâmetros de valor não são permitidos para módulos de função com suporte remoto.

Etapa 5 — Exceções: O sistema levanta FALHA DE COMUNICAÇÃO e FALHA_DO_SISTEMA internamente, em erros de nível de transporte. Exceções de nível de aplicação podem ser lançadas dentro de uma função remota exatamente como em uma função local.

Depurando chamadas de função remota

  • É não é possível depurar Uma chamada de função remota para um sistema não-ABAP da maneira clássica — o ambiente de execução externo é opaco.
  • No entanto, para chamadas RFC ABAP-para-ABAP, o depurador ABAP pode ser usado para monitorar a execução da função RFC dentro do sistema remoto.
  • Com chamadas remotas, o depurador ABAP (incluindo sua interface de usuário) é executado no sistema local. Os valores de dados e outras informações de tempo de execução da função remota são transmitidos de volta do sistema remoto.

Chave SAP Transações RFC

O conjunto de ferramentas RFC para o dia a dia se resume a um punhado de códigos de transação (T-codes) que todo desenvolvedor ABAP e administrador Basis deve conhecer instintivamente.

código T Propósito
SM59 Manter os destinos RFC — host, logon, tipo, segurança.
SE37 Construtor de Funções — crie ou edite módulos de função habilitados para acesso remoto.
SM58 Monitore as RFCs transacionais com falha e reprocesse-as.
SMQ1 / SMQ2 Monitorar filas qRFC de saída (SMQ1) e de entrada (SMQ2).
CONFIANÇA Manter os certificados SSL usados ​​pelos destinos RFC protegidos por HTTPS.
ST22 Inspecionar despejos de memória curtos causados ​​por falhas em chamadas remotas.

Melhores Práticas para SAP RFC

Uma camada RFC bem projetada mantém as integrações rápidas, observáveis ​​e fáceis de evoluir. Os seguintes hábitos valem a pena serem incorporados a todos os projetos.

  • Escolha a variante correta para o contract. Use sRFC para pesquisas síncronas, tRFC para atualizações assíncronas (no máximo uma vez) e qRFC quando a ordem for importante.
  • Reutilize um destino por sistema de destino. Em vez de distribuir nomes de host por vários destinos, isso permite a rotação de credenciais. tractabela.
  • Nunca insira credenciais diretamente no código. Em ABAP, utilize conexões de sistema confiáveis ​​ou tickets de logon seguros sempre que possível.
  • Monitore os indicadores SM58 e SMQ2 rotineiramente. Entradas tRFC travadas atrasam silenciosamente os processos de negócios até que sejam reprocessadas.
  • Passe apenas parâmetros do tipo referência. Os parâmetros de valor interrompem os módulos de função habilitados para acesso remoto.
  • Use o STRUST para gerenciar certificados TLS. Para destinos HTTPS — certificados expirados são uma das principais causas de erros misteriosos de COMMUNICATION_FAILURE.

Perguntas Frequentes

RFC é o protocolo de baixo nível que chama qualquer módulo de função habilitado para acesso remoto. Um BAPI é um protocolo específico, SAP-Módulo de função certificado que expõe um método de objeto de negócios estável — toda BAPI é exposta por meio de RFC, mas nem toda chamada de RFC atinge uma BAPI.

Uma RFC confiável é um destino SM59 onde o sistema de destino confia na autenticação do chamador, portanto, nenhuma senha é trocada em cada chamada. O contexto do usuário do chamador é propagado. Isso elimina credenciais codificadas, ao custo de uma configuração mais rigorosa.

A transação SM58 exibe entradas RFC transacionais com falha ou pendentes, aguardando reprocessamento. Cada linha contém o ID da transação, o módulo de função chamado, o destino, o texto do erro e a hora da última tentativa.

Não. Por padrão, o tráfego RFC não é criptografado. Destinos SNC (Secure Network Communications) ou TLS/HTTPS devem ser configurados para criptografar o tráfego. O SNC é o mecanismo padrão para ambientes de produção.

O tRFC garante que uma chamada seja executada exatamente uma vez, mas não preserva a ordem entre as chamadas. O qRFC se baseia no tRFC e, adicionalmente, serializa as chamadas por meio de filas de entrada ou saída, de modo que as chamadas sejam executadas na sequência exata definida pela aplicação.

Sim. Programas externos podem se registrar em um SAP gateway usando o SDK RFC (JCo para Java, NCo para .NET ou o SDK C). SAP Em seguida, as chama através de um destino do tipo T, tal como qualquer módulo de função ABAP.

Os assistentes de IA geram stubs RFC ABAP a partir de especificações em linguagem natural, sugerem o tipo de destino correto para um cenário e traduzem o texto de erro SM58 em uma lista concreta de correções — acelerando o trabalho de integração diário para as equipes de Basis e ABAP.

Sim. Forneça a um assistente de IA o dump ST22 ou o erro SM58 e ele correlacionará os padrões COMMUNICATION_FAILURE / SYSTEM_FAILURE com as causas raiz mais prováveis ​​— certificado expirado, gateway inativo, autorização ausente — e sugerirá o código de transação (T-code) relevante para inspeção.

Resuma esta postagem com: