¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Quando usar qRFC ou tRFC no estudo do RFC? Dicas de especialistas.

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 10 Vistas
0
Cargando...

Estou estudando RFC agora, não entendo quando devo usar qRFC ou tRFC. Pode algum especialista me dizer?

Obrigado

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

3 Respuestas

0
Cargando...

Olá Kim,

Por favor, verifique este link:

http://help.sap.com/saphelp_nw2004s/helpdata/en/62/73241e03337442b1bc1932c2ff8196/content.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm

tRFC e qRFC

O RFC transacional e o qRFC utilizam a verificação de recursos. Os elementos da linguagem ABAP associados a ambos os tipos de RFC são:

CHAMAR FUNÇÃO Função remota EM TAREFA EM SEGUNDO PLANO DESTINO destino

Com uma chamada adicional prévia (TRFC_SET_QIN_PROPERTIES ou TRFC_SET_QUEUE_NAME) é possível definir tRFC como qRFC.

Este comando ABAP marca o módulo de função da função remota para processamento assíncrono. O módulo não é executado imediatamente. Os dados transferidos com EXPORTING ou TABLES são colocados em uma tabela de banco de dados. Um COMMIT WORK então ativa o módulo de função. Existem vários casos:

? Os dados são atualizados. Se o tRFC/qRFC foi ativado dentro da atualização, eles são executados em paralelo após a atualização V1 (dentro da atualização). Se a chamada tRFC/qRFC estiver registrada no planejador, o planejador é ativado simplesmente dentro da atualização. A execução do tRFC/qRFC é feita fora da atualização através do planejador.

? Os dados não são atualizados. Os módulos de função tRFC/qRFC iniciados dentro da LUW da aplicação são executados em paralelo na medida do possível. Se os recursos do sistema local estiverem esgotados, o tRFC/qRFC é serializado para não aumentar ainda mais a utilização de recursos. No entanto, isso não ocorre se os módulos de função tRFC/qRFC forem processados em lote. Se o tRFC/qRFC for iniciado em lote, eles são sempre processados em paralelo como no processo de atualização, independentemente da utilização de recursos do sistema.

Não são feitas verificações de recursos com chamadas RFC a partir do processo de atualização ou lote, pois devem sempre ser processadas em paralelo para evitar bloqueios.

Atenciosamente,

raam

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá kim,

Bem-vindo ao sdn.

O Modelo de Comunicação qRFC

Propriedades do qRFC e Possíveis Usos

Todos os tipos de aplicativos são instruídos a se comunicar com outros aplicativos. Esta comunicação pode ocorrer dentro de um sistema SAP, com outro sistema SAP ou com um aplicativo de um sistema remoto externo. Uma interface que pode ser usada para lidar com essa tarefa é a Chamada de Função Remota (RFC). As RFCs podem ser usadas para iniciar aplicativos em sistemas remotos e executar funções específicas.

Enquanto a primeira versão da RFC, a RFC síncrona (sRFC), exigia que ambos sistemas envolvidos estivessem ativos para realizar uma comunicação síncrona, as gerações posteriores de RFC tinham uma variedade maior de recursos à disposição (como serialização, garantia de execução única e o sistema receptor não precisa estar disponível). Esses recursos foram ainda mais aprimorados através da RFC em fila com entrada/saída.

A comunicação entre aplicativos dentro de um sistema SAP e também com um sistema remoto pode ser basicamente alcançada usando a Chamada de Função Remota (RFC). Aqui, os seguintes cenários são possíveis:

∑ Comunicação entre dois sistemas SAP independentes

∑ Comunicação entre um sistema SAP chamador e um sistema receptor externo

∑ Comunicação entre um sistema externo chamador e um sistema SAP receptor

O modelo de comunicação a seguir mostra como esses cenários de comunicação podem ser vistos na realidade. O processo de envio real ainda é realizado através da RFC transacional (tRFC). Filas de entrada e saída são adicionadas ao tRFC, o que nos deixa com um qRFC (Chamada de Função Remota em Fila). O sistema emissor também é chamado de sistema cliente, enquanto o sistema alvo corresponde ao sistema servidor.

Cenário 1: tRFC

Este cenário é apropriado se os dados enviados forem independentes entre si. Um aplicativo chamador (ou cliente) no sistema 1 usa uma conexão tRFC para um aplicativo chamado (ou servidor) no sistema 2. Neste cenário, os dados são transferidos por meio do tRFC, o que significa que cada módulo de função enviado para o sistema alvo tem garantia de ser executado apenas uma vez. Não é possível definir a sequência em que os módulos de função são executados, nem o momento da execução. Se ocorrer um erro durante a transferência, é programado um trabalho em segundo plano que reenvia o módulo de função após 15 minutos.

Cenário 2: qRFC com fila de saída

Neste cenário, o sistema emissor usa uma fila de saída para serializar os dados que estão sendo enviados. Isso significa que os módulos de função mutuamente dependentes são colocados na fila de saída do sistema emissor e têm garantia de serem enviados ao sistema receptor na sequência correta e apenas uma vez. O sistema chamado (servidor) não tem conhecimento da fila de saída no sistema emissor (cliente), o que significa que neste cenário, cada sistema SAP também pode se comunicar com um sistema não SAP (Nota: o código de programação do sistema servidor não deve ser alterado. No entanto, deve ser compatível com tRFC).

Cenário 3: qRFC com fila de entrada (e fila de saída)

Neste cenário, além de uma fila de saída no sistema emissor (cliente), também há uma fila de entrada no sistema alvo (servidor). Se houver um qRFC com fila de entrada, isso sempre significa que há uma fila de saída no sistema emissor. Isso garante que a sequência e controle eficientemente os recursos no sistema cliente e no sistema servidor. A fila de entrada processa apenas tantos módulos de função quanto os recursos do sistema alvo (servidor) permitirem naquele momento. Isso evita que um servidor seja bloqueado por um cliente. Um cenário com fila de entrada no sistema servidor não é possível, pois a fila de saída é necessária no sistema cliente para garantir a sequência e evitar que aplicativos individuais bloqueiem todos os processos de trabalho no sistema cliente.

Propriedades dos Três Tipos de Comunicação

Para ajudar na decisão sobre qual tipo de comunicação usar em sua paisagem de sistemas para seus requisitos, as vantagens dos três tipos de comunicação estão listadas a seguir:

...

1. tRFC: apenas para módulos de função independentes

2. qRFC com fila de saída: garante que os módulos de função independentes sejam enviados um após o outro e apenas uma vez (serialização). Adequado também para comunicação com servidores não SAP.

3. qRFC com fila de entrada: além da fila de saída no sistema cliente, uma fila de entrada garante que apenas tantos módulos de função sejam processados no sistema alvo (servidor) quanto os recursos atuais permitirem. O sistema cliente e o sistema servidor devem ser sistemas SAP. Um processo de trabalho é usado para cada fila de entrada.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?