Destaques da Integração Siebel CRM com Kafka

A ideia aqui é explorar um tema técnico de grande relevância: a integração entre Siebel CRM e Kafka Broker utilizando um AI Sidecar como intermediário.

O objetivo deste artigo não é fornecer um tutorial completo, mas sim destacar os pontos mais importantes – o “mapa do tesouro” – para uma configuração adequada. Usando como base o que está documentado e o que não está documentado, trago os highlights que acredito que você precisa conhecer para evitar surpresas no caminho. 

Por que Integrar Siebel CRM com Kafka?

Antes de entrarmos nos detalhes técnicos, é importante entender o valor dessa integração.

O Siebel CRM é uma plataforma robusta para gestão de relacionamento com clientes, amplamente utilizada em grandes empresas. Já o Kafka Broker é uma solução de mensageria distribuída, ideal para arquiteturas orientadas a eventos e integração em tempo real.

Combinar os dois permite trocas eficientes de dados e eventos, modernizando a infraestrutura e habilitando cenários de alta escalabilidade.

Lembra daqueles ETLs legados que ninguém lembra mais quem fez, porque fez, de onde vêm os dados e sempre que dá problema exige praticamente um assessment completo? Então, talvez existam cenários que nem um ETL tradicional nem uma integração http síncrona sejam os ideais, ainda mais quando dispomos de recursos mais adequados e 100% suportados pelo produto.

Pontos Críticos para o Sucesso

A integração entre Siebel e Kafka envolve via AI Sidecar diversas camadas de configuração, desde variáveis de ambiente até ajustes de segurança e performance. A seguir, destaco os aspectos que eu julgo serem dos mais relevantes, com alguns exemplos práticos para ilustrar sua importância.

1. Variáveis de Ambiente: A Base da Integração

Configurar corretamente as variáveis de ambiente é o primeiro passo para habilitar a integração Pub/Sub entre Siebel e Kafka. Esses parâmetros definem comportamentos fundamentais do sistema. Alguns exemplos incluem:

• SIEBEL_EVENT_PUBSUB=1
  • Ativa a funcionalidade de publicação e subscrição de eventos.
• SIEBEL_EVENT_PUBSUB_PAYLOAD_STRUCT=2
  • Define a estrutura de payloads a ser utilizada, garantindo compatibilidade com os formatos esperados.
• SIEBEL_EVENT_PUBSUB_TLS=1
  • Habilita a comunicação segura via SSL/TLS, essencial em ambientes corporativos que exigem proteção de dados.

Sem a configuração adequada dessas variáveis, a integração simplesmente não funciona, independentemente de outros ajustes.

2. Senhas Criptografadas: Segurança na Configuração

A autenticação entre componentes como Siebel Object Manager e AI Sidecar exige senhas criptografadas. Para isso, utiliza-se o utilitário EncryptString.jar, encontrado no diretório do Siebel Server (por exemplo, <SIEBEL_SERVER>\jre\bin\java -jar EncryptString.jar senhasegura). O resultado criptografado deve ser utilizado nos arquivos de configuração, como applicationinterface.properties ou aieventconfig.txt. Por exemplo:

• No arquivo aieventconfig.txt, a senha criptografada pode ser configurada como: "Password": "<valor_criptografado>". Um erro na geração ou no uso dessa senha pode levar a falhas de conexão, dificultando o diagnóstico sem logs detalhados.

3. Configuração do AI Sidecar,  o Núcleo da Integração

O AI Sidecar – que pode ser qualquer applicationcontainer_external – atua como a ponte entre Siebel CRM e Kafka, e sua configuração é um dos pontos mais complexos e importantes da arquitetura.

No arquivo aieventconfig.txt, diversos parâmetros impactam performance e escalabilidade. Veja alguns exemplos:

• SessionPoolSize: Define o número de threads disponíveis para conexão com o Siebel Object Manager. Um valor como "SessionPoolSize": "5" pode ser suficiente para ambientes pequenos, mas cenários de alto volume podem exigir ajustes maiores.
• NumberOfConsumers e Partitions: Para um tópico Kafka chamado "siebel-poc", configurar "Partitions": "0,1,4" e "NumberOfConsumers": "5" ajuda a garantir balanceamento de carga e alta disponibilidade. O ideal é alinhar o número de consumidores (AI Sidecars dentro da sua arquitetura) com as partições disponíveis no tópico.
• KafkaConsumerPollInterval: Um intervalo de leitura como "KafkaConsumerPollInterval": "60" (em segundos) define a frequência de consumo de mensagens. Tópicos com alta criticidade podem precisar de valores menores para reduzir latência.

Além disso, o arquivo aieventconfig.txt deve ser um JSON válido, sem comentários ou formatações incorretas, pois qualquer erro de sintaxe interrompe a integração.

4. Segurança com SSL/TLS

A comunicação segura entre Siebel, AI Sidecar e Kafka muitas vezes depende de SSL/TLS, configurado no arquivo applicationinterface.properties. Alguns parâmetros importantes incluem:

• "TLSEnabledCipherSuites": Uma lista como "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_256_GCM_SHA384" deve ser compatível com o Kafka Broker para evitar falhas de handshake.
• "AIEgressServerKeyStoreName" e "KafkaKeyStoreName": Caminhos para os arquivos JKS (KeyStore/TrustStore), que geralmente precisam ser fornecidos pela equipe de integração, infraestrutura ou segurança da informação, junto com as respectivas senhas criptografadas.
  • Em raras ocasições o Kafka Broker pode estar no mesmo domínio da sua aplicação Siebel. Se esse for o caso (um ambiente de testes talvez) as wallets JKS do Siebel – aquelas com certificados “auto-assinados” ou com o certificado do seu domínio Extranet – podem ser utilizadas também como JKS de certificados para comunicação segura com o Kafka Broker. 

Configurações incorretas nesses parâmetros vão resultar em erros de conexão que não são imediatamente óbvios, exigindo testes prévios para validação.

5. Publicação de Dados: RTE x eScript

Nas versões do Siebel acima da 23.12, salvo engano, existem duas abordagens principais para publicar eventos do Siebel para o Kafka: Run Time Events (RTE) e eScript. Cada uma tem suas particularidades. Versões mais antigas não contam com a flexibilidade dos RTE.

• RTE com eventpayloadconfig.txt: Ideal para cenários simples, permite configurar payloads automáticos. Por exemplo, no arquivo eventpayloadconfig.txt, você pode definir um evento para o Business Component “Account” com campos específicos: Fields: Name,Location. O resultado será um JSON como {"Account": {"Name": "Teste Kafka", "Location": "123456789"}}. Porém, essa abordagem não permite customizar nomes ou formatos de campos (ainda, isso pode mudar em versões futuras).
• eScript para Flexibilidade: Quando há necessidade de controle maior, o eScript é a melhor opção. Um exemplo seria montar um PropertySet com dados de “Contact” e “Account” e publicá-lo via Business Service Event Handler:
  
  Copiar

  inpPS.SetProperty("topic", "external-siebel-poc");
contactPS.SetProperty("First Name", "John");
contactPS.SetProperty("Last Name", "Doe");
oBS.InvokeMethod("SendEvent", inpPS, outPS);


  Em ambos os casos é importante evitar payloads muito grandes ou consultas desnecessárias para não impactar a performance. Por que digo isso? Bem, lendo a documentação você vai ver que é possível usar um “Fields: All” na configuração de integração com RTE. Imagino cenários rarírssimos ou extremamente controlados (BCs customizados com poucos campos ativos, nenhum MVF e relacionamentos simples) para usar algo assim. Cuidado com as armadilhas da extrema simplificação, principalmente com BCs vanilla.

6. Escalando a Integração com Múltiplos Sidecars

Para cenários de alta disponibilidade, configurar múltiplos AI Sidecars é uma estratégia poderosa. O arquivo aiconnection.txt permite listar diferentes configurações:

• Mesmo Servidor, Portas Diferentes: EAIObjMgr_ptb=servidor1.local.com:9098;servidor1.local.com:9099.
• Servidores Distintos: EAIObjMgr_ptb=servidor1.local.com:9098;servidor2.local.com:9098.

Essas configurações ajudam a distribuir a carga, mas exigem planejamento para garantir que cada AI Sidecar tenha os recursos necessários e que os tópicos Kafka estejam bem balanceados.

7. Testes e Validação

Antes de colocar a integração em produção, é fundamental realizar testes em ambiente controlado. Isso inclui:

• Testar a comunicação SSL/TLS entre Siebel, AI Sidecar e Kafka, verificando logs para identificar falhas de conexão.
• Validar os payloads gerados, seja via RTE ou eScript, para garantir que atendam às expectativas do consumidor no Kafka.
• Documentar todas as configurações, como tópicos, partições e número de consumidores, para facilitar troubleshooting futuro.

Um exemplo prático seria simular a publicação de um evento via RTE e verificar se o JSON gerado no Kafka contém todos os campos esperados, ajustando o eventpayloadconfig.txt se necessário.

O Mapa Está nas Suas Mãos

Integrar Siebel CRM com Kafka é uma tarefa poderosa, mas cheia de detalhes que demandam atenção.

Neste artigo, busquei destacar alguns pontos que julgo mais críticos: variáveis de ambiente, senhas criptografadas, configurações do AI Sidecar, segurança, publicação de dados e arquiteturas escaláveis. Entretanto, tenha em mente que cada caso é um caso e Siebel integrado com Kafka Broker não substitui outras alternativas de integração, apenas as complementa para casos de uso específicos.

Este é o mapa do tesouro, mas a jornada é sua. Com sua equipe, um bom planejamento e testes rigorosos, você poderá garantir uma integração robusta e eficiente.

Se tiver dúvidas ou experiências para compartilhar, deixe um comentário ou entre em contato.