Introdução

Um dos desafios comuns ao integrar Siebel com outras aplicações é saber quando enviar a informação do Siebel para as mesmas. Existem uma grande variedade de soluções e arquiteturas. Partilhamos aqui uma solução assíncrona de alta fiabilidade com Queues.

Arquitetura

Na arquitetura proposta começamos por disponibilizar uma tabela, interna ou externa ao esquema Siebel, dependendo do tipo de projeto, que irá armazenar o Id  do registo alterado, o tipo de registo, o estado de processamento (por processar, processado, ou outros estados se necessário), bem como que tipo de mudança foi feita (atualização, eliminação, inserção, outros). Outras informações também podem ser armazenadas se necessário. 

Inserções e atualizações, na maioria dos casos, são simples. Uma Workflow Policy pode ser usada para verificar as tabelas relevantes usando um Workflow Policy Component customizado. Isto permitirá que os campos relevantes para as aplicações externas sejam monitorizados. Um Workflow pode então ser usado para obter o ID da linha ou quaisquer outros campos relevantes dos Business Components (BCs) e escrevê-los na Queue. 

Apesar disso, há alguns casos especiais. O trigger  da Workflow Policy encontra-se sobre o ID do registo que está a ser adicionado/atualizado. No entanto, em alguns casos, poderá ser necessário obter informações de BCs que estão sobre as tabelas de extensão ou de BCs que não são o Business Component principal de um Business Object. No primeiro cenário, se o ID é o mesmo que o da tabela principal, não há problemas. No entanto, se o ID é diferente, então o Policy Component tem de ser configurado para passar o ID correto para cada tabela. Nos restantes casos, depende da situação, mas normalmente a melhor solução é criar um novo Business Object, onde o Business Component de interesse será o BC primário. 

Para identificar registos apagados, o processo é um pouco diferente, visto que não será possível obter os IDs apagados com um trigger. 

Existem, contudo, duas opções: um Runtime Event ou codificação direta sobre um BC. A primeira abordagem funciona corretamente para casos onde a eliminação não é feita numa tabela de extensão. No entanto, uma vez que a eliminação numa applet MVG será enviada através deste processo, um erro será lançado se um Runtime Event estiver presente e o erro não for desativado. Este processo poderá também causar problemas no rollback da criação de um novo registo, visto que isto será passado ao BC como uma remoção apesar de o ID nunca ter sido criado. Este problema ocorre independentemente do registo ser criado na UI ou em background.

Em oposição a codificação direta permite-nos contornar ambos os problemas programando especificamente para cada processo. O Workflow a usar para o delete poderá até ser independente do Business Object e dependendo do nível de customização, um único Workflow poderá ser usado para todos os eventos de eliminação de dados. 

Conclusão

Como exposto acima, o Siebel apresentará informações sobre atualizações relevantes para aplicações/processos externos. Utilizando colunas adaptadas para cada projeto, isto permitirá que estas aplicações obtenham apenas os dados atualizados necessários.  

#Siebel #Queue #Workflow #TempoExecução