Aqui temos um approach simples para criar uma espécie de Time To Live (TTL) em sessões de Application Object Manager (AOM) do Siebel CRM.
O problema que TTL em Sessões AOM Siebel resolve
Num cliente onde um trabalho de robustez do ambiente de Siebel CRM estava sendo feito, destacamos alguns problemas encontrados e que são relevantes para a análise desse caso de uso:
- O Memory Based Recycle estava ligado e os processos do eCommunicationsObjMgr_ptb estavam causando memory leak
- Tarefas (sessões) do eCommunicationsObjMgr_ptb ficando logadas ad eternum
Se você leu o artigo Memory Leak e Memory Recycle em ambientes Siebel CRM sabe que o recurso de MBR tem certas particularidades que podem, ao invés de ajudar a manter o ambiente operacional, acelerar o processo de degradação e indisponibilidade.
Nesse caso específico, os processos do eCommunications atingiam o limite de memória definido nos parâmetros do MBR, mas não liberavam recursos. O motivo eram os usuários que seguiam conectados por tempo indeterminado impedindo os processos de reciclar.
Boa parte desses usuários já haviam fechado o browser, mas a engine do Alarm Manager impedia que as sessões finalizassem por idle time devido a falta de alinhamento entre o Session Idle Time (idletime do AI/SWSE) e a preferência de sistema Alarm Manager Load Frequency.
Ajustando esses parâmetros, conseguimos garantir que as sessões abandonadas finalizassem por idle time. Existe vasto material no MOS mencionando esses parâmetros e, portanto, não vamos entrar em detalhes.
Contudo, nos casos onde o usuário não fazia logoff e nem fechava o browser precisávamos de algum recurso para, em algum momento, finalizar suas sessões.
Nesses casos específicos, a engine do Alarme Manager não deixa a sessão fechar por idle time porque, na prática, essas sessões não ficam idle.
Eis a solução para Time To Live (TTL)
Bem, poderíamos pensar numa forma de criar um contador de tempo dentro das sessões do Siebel, mas, sinceramente, acredito ser um esforço desnecessário com extremo desperdício de braços de desenvolvimento além de uso inútil de recursos de infraestrutura.
Do mais, por que precisamos criar um contador de tempo se já temos um prontinho? Explico:
A preferência de sistema Alarm Manager Load Frequency controla o tempo de leitura dos Actions com alarme flagado e o push desses alarmes no browser. Ou seja, eu sei exatamente a frequência de execução dessa engine e, se eu sei a frequência, eu sei tenho um contador.
Obs.: É importante impedir que o próprio usuário altere suas preferências pessoais de frequência de alarme. Isso pode ser feito validando ou impedindo a alteração dos campos “Calendar/EnableAlarmManager” e “Calendar/DefaultTimeSlotInterval” do Business Component “User Preferences”.
Para esse caso de uso vamos considerar que o Alarm Manager Load Frequency foi configurado com o valor de 15 minutos. Nesse caso, o Business Service vanilla “Alarm Manager” tem seu método “GetAlarms” invocado a cada 15 minutos.
No PreInvokeMethod do BS “Alarm Manager”, inserimos o seguinte trecho de código:
Considerações sobre Sessões AOM
- O recurso acima foi testado num Siebel IP 15 (Atualização de 11/02/2021: Recurso testado no IP 21.1 com sucesso. Contudo, as configurações de Session Idle Time são feitas via SMC e não através de eapps.cfg).
- O BS “LS Medical Product Issue Service” possui pouca documentação, mas parece funcionar sem bugs para esse tipo de implementação e nessa versão do Siebel
- O código pode ser melhorado com
- Alertas algumas horas antes de fechar a sessão
- Validações extras e exceções
- Limpeza da profile de controle de execuções do Alarm Manager para acelerar ou retardar o logoff do usuário
Abaixo um vídeo reproduzindo a configuração com parâmetros mais agressivos e com frames acelerados para exemplificar como ficará o ambiente:
Não deixem de comentar os artigos.
Abraço.
Do you need help with Assessment and Troubleshootings in your Oracle Siebel CRM environment or in the Database? Contact us.