Melhores práticas de script

O scripting permite que você estenda a lógica de negócios IBM® Maximo® Manage usando Python, JavaScript, ou qualquer outra linguagem de script JSR223-compliant. Todo o código de script é compilado no bytecode Java™ e armazenado em cache como parte dos caches de tempo de execução do Maximo Manage . Quando o script é iniciado, é o bytecode em cache que é executado pela Java virtual machine usando a ponte JSR223 . Como o código de script é executado no mesmo encadeamento que outra lógica de negócios do Maximo Manage gravada em Java, o código de script mal gravado pode afetar negativamente o desempenho do sistema. Siga as diretrizes de desempenho do Maximo Manage porque o script é equivalente ao código customizado Maximo Manage .

Escolha do ponto de partida e do evento corretos

Os pontos de ativação são pontos acionadores de script Muitas vezes, a escolha do ponto de inicialização correto pode ajudar a evitar determinados problemas de desempenho na criação de scripts. Por exemplo, em liberações anteriores, nenhum suporte estava disponível para inicialização do valor de atributos. Isso levou muitos desenvolvedores de script a usarem o evento de inicialização do ponto de ativação do objeto (OLP) para inicializar os valores de atributo do objeto de negócios do Maximo (MBO) Embora a funcionalidade não tenha sido afetada, ela pode levar a problemas de desempenho quando você seleciona muitos MBOs. O script do evento de inicialização OLP é executado para cada MBO selecionado no MboSet, mesmo que o atributo cujo valor está sendo inicializado pelo script não seja usado ou mostrado. É possível evitar esse problema alterando o ponto de ativação do objeto para um ponto de ativação do atributo para o evento inicializar valor. O seguinte código de script de amostra mostra que thisvalue é o valor de inicialização do atributo atual:

if priority is not None:
   thisvalue=2*priority

A estrutura MBO inicia esse script somente quando esse atributo é referido pelo código ou pela interface com o usuário

Outro exemplo de opção de ponto de ativação é eventos de salto de integração. Geralmente, os desenvolvedores usam o script de saída de usuário para determinar se precisam ignorar uma mensagem de integração de saída. No entanto, neste ponto o sistema já incorreu no custo de serializar os MBOs. Em vez disso, você deve usar o script do filtro de eventos do canal de publicação que é chamado quando o evento é acionado e antes que qualquer serialização de MBOs aconteça. A amostra a seguir mostra o script do filtro de eventos que funciona com os MBOs.

if service.getMbo().getString("status")=="APPR":
  evalresult=False
evalresult=True

Evite eventos de inicialização de objeto dispendiosos se chamado a partir da guia Lista

Você pode desejar usar scripts de inicialização de objeto dispendiosos somente quando o objeto for inicializado a partir da guia Principal e não da guia Lista . Na guia Principal , há apenas um objeto Na guia Lista , há muitos objetos Nesses casos, o seguinte código de amostra é útil:

from psdi.common.context import UIContext
if UIContext.getCurrentContext() is not None and UIContext.isFromListTab()==False:
    ..costly initialization..

Cuidado com scripts de eventos do ponto de ativação conflitantes

A estrutura de script permite anexar vários scripts ao mesmo evento de ponto de ativação.. Isso representa um problema se o código de script espera executá-lo em uma determinada ordem antes ou depois de determinados outros scripts no mesmo evento do ponto de ativação Como o tópico de evento do Maximo é um mapa não ordenado, os eventos são acionados sem uma ordem fixa Isso pode potencialmente causar problemas se a dependência de pedido não for gerenciada corretamente Você deve avaliar a razão para anexar vários scripts para o mesmo evento de ponto de ativação e avaliar se faz mais sentido combiná-los em um script A outra opção é assegurar que não haja dependência entre os scripts.

Evite chamar salvar no meio de uma transação

Esse padrão de codificação pode causar problemas para transações e disparos de eventos do Maximo Manage Idealmente, quando uma transação está em andamento, o script deve tentar fazer parte dessa transação abrangente. Os MBOs criados ou atualizados por um script são automaticamente parte da transação abrangente, contanto que tenham sido criados a partir do MBO do ponto de ativação do script ou de qualquer MBO relacionado. Se você criar um MBO usando a API MXServer.getMXServer().getMboSet(“…”, ele estará fora da transação abrangente, a menos que você o adicione explicitamente à transação abrangente seguinte:

mbo.getMXTransaction().add(<newly created a mboset>)

Chamando MboSet.count () muitas vezes

Um erro comum ao gravar scripts é verificar a contagem de um MboSet várias vezes A chamada count () acaba disparando um SQL toda vez que é chamado. Uma abordagem melhor é chamá-lo uma vez, armazenar o valor em um var e reutilizar esse var para o fluxo de códigos subsequente. O exemplo a seguir demonstra essa abordagem

cnt = mboset.count()
if cnt<=1:
  service.log(“skipping this as count is “+cnt)

Não codifique conforme mostrado no exemplo a seguir.

if mboset.count()<=1:
  service.log(“skipping this as count is “+mboset.count())

Fechando o MboSet .

A estrutura MBO sempre libera os MboSets criados após uma transação ser concluída. Isso será verdadeiro se todos os MboSets tiverem sido criados como um conjunto relacionado para o MBO do ponto de ativação ou qualquer um de seus MBOs relacionados No entanto, se o MboSet for criado usando a API MXServer.getMXServer().getMboSet(...), o código do script será responsável por fechar e limpar esse MboSet. O exemplo a seguir mostra como limpar MboSet.

try:
  ..some code..
finally:
  mboset.cleanup()

Se você não limpar os MboSets, poderão ocorrer erros de falta de memória.

Evite o script de compatibilidade Mozilla para Nashorn

A mudança de Rhino e Java 7 para Nashorn e Java 8 é recomendada por motivos de desempenho Nashorn tem melhor desempenho em Java 8 do que Rhino. Usar o script de compatibilidade Mozilla com o Nashorn pode resultar em desempenho ruim no Java 8.

Verifique se a criação de log está ativada antes da criação de log

A criação de log geralmente é feita no script sem verificar o nível de log. A amostra a seguir mostra como isso pode impactar o desempenho:

service.log("count of mbos "+mboset.count())

Este código infelizmente resulta em mboset.count() sendo chamado, mesmo que a criação de log de script esteja desativada.

Uma melhor abordagem é verificar se a depuração está ativada antes de chamar mboset.count().

from psdi.util.logging import MXLoggerFactory
logger = MXLoggerFactory.getLogger("maximo.script");
debugEnabled = logger.isDebugEnabled()

if debugEnabled:
  service.log("count of mbos "+mboset.count())

A função a seguir na variável service permite verificar se a criação de log está ativada:

if service.isLoggingEnabled():
  service.log(“count of mbos “+mboset.count())

Evite acessar o cache de scripts

O acesso ao cache de scripts a partir do código do script de automação resulta em dependência circular e causa instabilidade quando o cache de scripts está sendo carregado, ou seja, carga parcial. Ao escrever um script, use scripts de biblioteca para o desenvolvimento de scripts modulares e, assim, evite acessar o script a partir do cache.