Detalhes importantes na configuração para sistemas parceiros no EBS

Networking

Nesse post falarei sobre uma experiência que tive em um projeto de R12 no ano passado (2013).

Em um certo momento do projeto a equipe responsável por um dos sistemas parceiros começou a realizar testes de interface, onde seria feita a comunicação desse sistema com os módulos do EBS. Mas um problema estava acontecendo, nada do EBS chegava nesse sistema.

Os consultores funcionais do EBS foram chamados para ajudar a entender o que estava acontecendo. Verifica profile aqui, value set lá… E até então estava tudo certo. Geralmente nesse ponto começa aquele empurra-empurra de responsabilidades como acontece na maioria dos projetos.

Os funcionais me pediram ajuda e eu comecei a analisar o problema. Comecei a depurar o código para tentar descobrir em que momento acontecia o problema. Depois de um tempo fuçando verifiquei que os erros estavam ocorrendo em algumas triggers. Essas triggers estavam em algumas tabelas importantes dos principais módulos que trocam dados com os sistemas parceiros. O que ocorria era que quando uma determinada profile estava setada como “Yes”, a trigger executava um bloco de código que gerava a exceção. A exceção em questão era que aquele código estava tentando efetuar um “ROLLBACK”, recurso que não é permitido dentro de triggers. Como a trigger era core, eu não poderia simplesmente alterar e colocar pra funcionar. Então expliquei o problema e foi aberto um chamado.

A Oracle mandou um patch, o ATG aplicou e começaram a testar novamente. Resolveu? Não! Agora o que acontecia era que nenhum erro aparecia mas também a interface não funcionava.

Resolvi dar uma olhada novamente nas triggers e analisei o que o patch tinha feito, infelizmente não resolvia o problema ainda.

O negócio começou a ficar feio, o tempo passando e nada de interface funcionando. Nessa altura toda a equipe já estava sabendo e tentando ajudar.

Então eu e mais dois funcionais fomos para uma sala reservada para tentar descobrir o problema. Trocamos informações e então eu comecei a pesquisar na Internet, ler a documentação, manuais, MOS, etc. Primeiramente descobri que a profile que era verificada na trigger era a que controlava se os dados entre o EBS e os sistemas parceiros deveriam ser trocados ou não:

OKL: Ativar Eventos de Negócios para ISV (Em português)
CLL_F255: Enable Business Events for ISV (Em inglês)

Quando essa profile estava como “No” não dava erro porque na trigger o código problemático só era executado se ela estivesse como “Yes”. Então uma coisa era certa, ela tinha que estar “Yes” de qualquer jeito para a interface funcionar. Então comecei a fuçar mais para tentar descobrir o que estava gerando a exceção, até que cheguei na lookup CLL_F255_ISV_EVENTS:

Lookup: CLL_F255_ISV_EVENTS
Lookup: CLL_F255_ISV_EVENTS

Eram dois problemas:

  1. O conteúdo no campo Etiqueta para “GESPLAN” deveria estar nulo (Na imagem acima já estava corrigido). Pelo que entendi, devem existir mais de um tipo de mecanismo de integração (BPEL, DBLINK, etc). Como no cliente em questão não era utilizado BPEL, isso gerava uma exceção e interrompia todo o processo.
  2. O outro problema era no conteúdo do campo Significado para o registro do Synchro, que também gerava exceção. (Para o parceiro Synchro no cliente em questão, era correto utilizar “BPEL” no campo Etiqueta). Mas olhando o conteúdo do campo Significado, parecia estar tudo OK, batia com o que estava no manual. O que poderia estar errado? Aí que me veio uma “luz” e resolvi olhar como estava o conteúdo em outros idiomas:
    Na imagem acima está correto, os dois textos estão iguais. Mas quando abri essa tela com as traduções, eles estavam diferentes.Como é o conteúdo do campo Significado que é utilizado no código, ele precisa estar igual em todos os idiomas utilizados pelo cliente.

Acertados esses pontos, tudo passou a funcionar.

Toda essa configuração faz parte do novo mecanismo utilizado na R12 para integração com os parceiros: ISV Integration Solution

Uma tabela que pode ser útil para analisar os processos é: CLL_F255_NOTIFICATIONS

Mais detalhes no note abaixo:

LAD Add-on Localizations – R12.1 ISV Integration Solution (Doc ID 960846.1)

O post ficou grande, tentei detalhar o máximo possível com o mínimo de texto. O intuito aqui não é apontar o dedo pra ninguém e sim deixar registrado tudo o que passamos para que no futuro outras pessoas possam evitar essa dor de cabeça. São detalhes mínimos que qualquer um pode cometer.

Quanto mais trabalharmos em equipe, mais sucesso teremos.

12 Comentários


  1. Show Eduardo! Obrigado por compartilhar. Só uma pergunta: quem cria os valores na CLL_F255_ISV_EVENTS quando tiver uma nova integração com outro parceiro?

    Responder

    1. Danilo, quando eu dei uma olhada no manual dos parceiros tinha um tópico dizendo pra criar esse registro. Então, teoricamente o parceiro que deve fazer essa configuração, assim como ativar a profile. Mas é bom a gente ficar sabendo pra entender o processo e evitar esses problemas. Lembro que no começo ninguém do EBS sabia a utilidade dessa profile e em alguns momentos até desativavam ela pra parar de dar erro.

      Responder

  2. Artigo muito bem feito e com uma linguagem bem simples para entendimento!
    Vale lembrar que quando cadastrada um novo registro que possui suporte a mult-idiomas, a tradução inicial do idioma base (idioma da sessão que o usuário esta logado) é replicada para todos os outros idiomas. E essa replicação é mantida até que ocorra uma alteração através de outro idioma não base (logando em outro idioma ou clicando no globinho).
    Abraço a todos

    Responder

    1. Muito obrigado Leonardo. E é isso aí mesmo, obrigado pelo complemento!

      Responder



  3. Eduardo excelente artigo..Outra dica importante é somente cadastrar na lookup os parceiros que irão utilizar a interface notificação e sempre criar a tabela xxisv_partnername_events no user recomendado “XXISV” ou no DB user definido no projeto, para dessa forma gerar as notificações na tabela cll_f255_notifications . Se a tag for “BPEL” a interface tbem dispara o business event relacionado ao ponto de integração gerando uma instance no Weblogic. Na lista de pacthes relacionada no MOS Note 960846.1 consta um patch que corrige a tradução da profile “OKL: Ativar Eventos de Negócios para ISV”

    Responder

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *