Comunicação via RFC do DRC NF-e com o BTP

Comunicação via RFC do DRC NF-e com o BTP

A NF-e outbound usando o DRC é razoavelmente fácil de implementar, apesar de resumidamente precisar apenas ativar algumas BF’s, criar conta no BTP e comunicar o ERP com BTP, vários projetos que peguei tiveram problemas na fase inicial justamente para criar a comunicação do S/4HANA com o DRC NFe. No meu caso esses problemas foram por pequenos erros de configuração de BASIS/Infraestrutura.

Configurações com Proxy/Portas

O problema com proxy foi uma das mais comuns e por isso mesmo sendo funcional acabei aprendendo um pouco sobre essa parte. Pelo que tenho visto nos projetos de RISE usando private cloud a maioria dos clientes tem uma infraestrutura de rede que usa um proxy de internet na rede e uma porta específica para comunicação HTTP com o ambiente externo.

Nesses casos a porta em todos que vi é 3128. Essa porta precisa ser configurada tanto para a RFC como para o Client Profile para autenticação no serviço do BTP:

1- RFC com proxy/porta 3128

Esse aqui embaixo é um exemplo usando um host chamado proxy:

Mas como falei não é só a RFC que precisa disso. O Client Profile do OAuth 2.0 também precisa disso, se não utilizar ele vai dar erro na autenticação.

2- Client Profile com proxy/porta

A configuração da porta e do proxy é necessária aqui também. Os dados abaixo são só exemplo da config na oa2c_config, os dados do seu ambiente você confirma com BASIS/Infra.

Mas não acaba por aqui, caso você tenha incoming automation tem mais configuração pra fazer com RFC/Client Profile.

3 – RFC’s do Incoming com Proxy

Aqui tem uma coisa que não é boa na solução do Incoming usando DRC. Se existe necessidade de proxy, então precisa (por enquanto pelo menos) criar uma RFC para cada uma das ações/serviços do Incoming.

Nesse caso da proxy então a configuração da NFECLOUDCONFTMP precisa indicar uma RFC no campo (Connection to External Server) para cada serviço:

Nenhum BASIS vai ficar super feliz de criar mais de 10 RFC’s para o mesmo cenário e ter que fazer isso em QAS e PRD. O trabalho não é imenso, mas essa quantidade de RFC’s normalmente não faria sentido para teoricamente 1 serviço no BTP.

E de novo em cada RFC e no client Profile (o mesmo OAuth 2.0 é usado em todas as RFC’s do Incoming) tbm vai precisar indicar proxy e porta.

Conclusão

Passado o ponto de ter a comunicação funcionando pela primeira vez daí é só usar a parte funcional da solução, então no geral o setup do DRC é muito menor do que era o do GRC NF-e. Só para ter idéia, no GRC NF-e clássico precisava instalar um Netweaver, instalar um PI, fazer deploy do Add-on ABAP e do conteúdo do PI, configurar os cenários de integração, só aí já é um esforço imensamente maior do que confirmar um OAuth2.0 e umas RFC’s entre o ERP e o BTP.

Valeu Gurizada,

Renan Correa

Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube

Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil

Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.

Outros posts sobre TDF você pode conferir filtrando pela categoria TDF/DRC.