B2B - Cliente e Transportadora

[Former Member]

Fizemos uma alteração na solução standard do B2B.

Na função que chama o Proxy, eu criei um enhancement-point para manipular o campo CNPJ para identificar qual o tipo de mensagem será enviada, no meu caso EMAIL Ou WebService, até ai OK.

O problema é que assim que manda o XML para o cliente eu estou também mandando para a Transportadora o XML, usando o mesmo Proxy e interface PI, repliquei a lógica standard para o envio para a transportadora. Quando ocorre algum erro no envio por email para o Cliente ou para a Transportadora, ex: email não cadastrado, e para o outro envio vai com sucesso o status no monitor do GRC fica com sucesso e eu não consigo reprocessar a mensagem que deu erro. Se os dois cadastros estão OK, ele manda com sucesso para os dois sem problemas.

Existe a possibilidade de caso der erro em algum, deixar com mensagem de erro no monitor do GRC para ser reprocessado posteriormente? Mesmo que uma das duas mensagens tenha ido com sucesso, melhor mandar duas vezes do que não mandar.

Como o cadastro do cliente é mais dinâmico do que o da transportadora, clientes temos mais de 2.000 e transportadoras 3, pensei em assim que executasse a Proxy da interface para o Cliente, tentar identificar se deu erro no Ack, se deu erro eu nem continuo o processo para a transportadora, porém não consegui identificar no código quando deu erro ou não.

Alguém tem alguma idéia?

Desde já, muito obrigado.

[Former Member]

Ainda não foi implementada, mas por enquanto vou deixar desse jeito, pois está funcionando de certa forma, atualizando o status com erro depois do Ack. E com isso reprocessando funciona.

Abraço Henrique.

[Former Member]

Obrigado Henrique.

Dando uma olhada nesse programa, verifiquei que tem a chamada do método cl_proxy_access=>get_acknowledgment.

Esse programa é executado por job? Ou então como ele é disparado?

Eu poderia adicionar esse método depois de enviar a interface para tentar identificar qual o status do Ack?

Fiz uns testes agora, e ele mantém o status da ultima mensagem. Fiz um teste tirando o email do Cliente pra dar erro, executei, ficou com status de sucesso no monitor, pois a ultima mensagem, a do transportador, foi processando com sucesso,Depois de um tempo, fui verificar e estava com status de erro no monitor, olhando nas mensagens da sxmb_moni, o Ack da mensagem com erro tentou enviar depois de 4 minutos e como deu erro novamente, atualizou o status no monitor do GRC com erro.

Obrigado novamente.

Maicon.

[henrique_pinto]

Olá Maicon,

sim, esse report é executado via job (schedulando o /xnfe/process_reports, que chama ele via submit).

Nao vai adiantar vc fazer o =>get_acknowledgement() logo depois de manda pois demora um pouco pra mensagem ser executada pelo Integration Engine, Mapping Runtime, Adapter Engine etc.; até dar o erro, vai ter um deltaT considerável. E fazer um while ack() vazio, wait 5seconds, é sacanagem, eheehehehe.

Por isso sugeri, se quiser modificar, que pense em modificar o proprio form get_acknow, pois ele é executado via job, e uma hora vc pega o ack.

Mas note que não necessariamente vc quer que o usuário restarte o B2B manualmente. Como vc mesmo observou, por ser uma interface assíncrona, o próprio Adapter Engine faz retries automáticos de envio depois de 5 minutos do ultimo erro. Somente em caso de erro permanente é q faz sentido fazer o restart; esse "erro permante" vc pode observar vendo o status da mensagem no Mesage Monitoring do RWB (componente Adapter Engine). Infelizmente nao sei dizer se esse nível de detalhamento do erro volta no ack que vai pro Integration Engine, se voltasse seria o mundo perfeito, e daí vc poderia fazer um IF status = vai tentar de novo, nao joga erro no monitor (talvez faça sentido um status novo, algo do tipo "erro mas vai retentar enviar sozinho"), else status = erro permanente, daí vc joga erro no monitor pro usuário poder restartar.

Se nao vier no ack, daí vc ainda pode tentar pensar numa maneira de ler isso das tabelas do Adapter Engine, que eu pessoalmente nao manjo mas que deve ter alguma coisa no forum de PI.

Abs,

Henrique.

PS: pensei que seu 1o nome fosse Rosa, rs... Desculpe.

[henrique_pinto]

Maicon,

outra coisa, vc tem a nota 1559582 implementada?

Ela é do SP18.

Abs,

Henrique.

[henrique_pinto]

Maicon,

o erro do ack nao vem imediatamente na hora da chamada, entao nao tem como fazer assim.

O que acredito que esteja acontecendo é: pro GRC, nao importa qtas chamadas sejam feitas pro PI, o B2B é visto como apenas um único step lógico. Ou seja, ele espera apenas um unico retorno. O primeiro que chega deve ser salvo na tabela de status e acabou.

Veja o programa /xnfe/get_acknowledgment, form get_acknow.

Aqui ele determina se ele joga ok ou erro.

*   set error field
    CASE l_ack_status_simple-ack_status.
      WHEN '72' OR '77'.                          "Acknowledgment ok
        IF ls_acknowledg-message = gc_messtype_pi-ntb2b OR
           ls_acknowledg-message = gc_messtype_pi-ctb2b.
          lv_ok_flag = gc_true.
        ENDIF.
      WHEN '73' OR '83'.                          "Application error
        lv_error = 'AP'.
      WHEN '75' OR '85' OR '90'.                  "System error
        lv_error = 'SY'.
      WHEN '88'.                                  "Error not supported
        lv_error = 'SY'.
    ENDCASE.

Vc vai precisar modificar "de alguma maneira" a logica aqui pra considerar os 2, nao apenas o 1o que chega.

Abs,

Henrique.