Você está na página 1de 33

Scripting Com Maximo

Anamitra Bhattacharyya [desenvolvedor-chefe] Sampath


Sriramadhesikan [Designer de chumbo]
Scripting é um novo recurso que foi introduzido no Maximo versão 7.5 com base no feedback da
comunidade de usuários que ansiava ter uma maneira mais simples, mas eficaz de personalizar o
produto sem ter que passar pela dor de inatividade do sistema e curva de aprendizagem.

Enquanto Maximo fornece grande número de pontos de personalização, a maioria deles precisa JAVA habilidades de
codificação para fazer qualquer significativa [com base lógica] personalização. Seria também muitas vezes precisam de
conhecimento profundo de Maximo apis, bem como os internos Maximo. Que muitas vezes pode ser uma tarefa difícil mesmo
para um programador experiente.

Em vem Maximo scripting para ajudar a aliviar algumas dessas preocupações. Maximo scripting é baseada
principalmente na especificação JSR 223 que faz parte do JAVA 6. Esta JSR permite uma aplicação JAVA [neste caso
Maximo] para receber motores de script que são compatíveis com essa especificação. Os motores que são
suportadas em uma OOTB Maximo 75 são

1. Mozilla Rhino (JavaScript) que é fornecido com o IBM / Oracle (Sun) JDK
2. Jython que está incluída como parte de Máximo

Isto implica, basicamente, que os usuários podem usar qualquer uma destas 2 linguagens de script para
personalizar Maximo usando a estrutura scripting Maximo. Entendemos que existem outros populares JSR
223 mecanismos de script compatível como JRuby / Groovy e deve ser bastante simples para adicionar
suporte para estes adicionando esses motores [frascos] no Maximo classpath do aplicativo. A forma como o
quadro de script está escrito - ele deve ser capaz de detectar os frascos do classpath e mostrar-lhes línguas
disponíveis na aplicação scripting. No entanto, gostaria de mencionar que neste ponto Maximo só foi testado
com os motores de Rhino-JavaScript e Jython e JSR 223, sendo razoavelmente nova, muitos dos motores
“compatíveis” podem ter potenciais problemas com a sua implementação que pode impedir a integração
perfeita com Maximo.

Agora vamos se familiarizar com os diferentes artefatos do quadro scripting. Abaixo está uma figura que pode lhe
dar uma sensação visual para o design e tempo de execução artefatos.

design Hora

Identificar Maximo ponto de Crio Launchpoint


Existe um já existente
componente para para esse componente sim Escolha um roteiro
roteiro?
customizar ponto

Modificar ligações
Não
variáveis [se necessário]
Autor / Editar
Ligar variáveis Commit projeto
Roteiro

Commit projeto

sim

Não Cache Anexar Launcpoint proxy


compilar Erro de compilação?
Compilar d para segmentar Máximo
Script Script Componente
Base de dados
Com base neste fluxograma projeto, podemos ver que existem 3 artefatos distintas - Launchpoint,
Escrita e Variáveis que compõem o quadro.

Roteiro

Primeiro, claro, é o roteiro que é um arquivo de texto que você pode editar dentro Maximo ou fora de Maximo [em sua escolha de editores

e importar de volta para Maximo]. Cada script tem um atributo associado - scriptLanguage que ajuda a figura de tempo de execução o

mecanismo de script apropriado para invocar para o processamento do script. A lista de valores para linguagens de script disponíveis vêm
dos motores de script fornecendo no classpath. É comum para os motores de script para fornecer múltiplos alias ou nomes curtos para o

suporte ao idioma fornecido por esse motor. Por exemplo, o motor Jython fornece 2 nomes - Jython e python - ambas referentes ao mesmo

idioma Motor / script. A seleção de qualquer um é bem e produz um comportamento idêntico. A maioria dos motores apoiar a compilação

de script que eventualmente converte o script para um bytecode executável [para a JVM]. Os que apoiamos OOTB - JavaScript e Jython

tanto apoio cumprido scripts. Quando o implementador está comprometendo o processo de design - no fundo do quadro seria compilar e

cache do script. Este processo é muitas vezes referida como a geração de scripts “quentes” que estão prontos para executar. Observe se há
uma falha de compilação o processo não vai cometer e o implementador tem que corrigir o script para prosseguir. Antes de saltar ainda

mais para estes artefatos, vamos olhar para o suporte a aplicativos para o quadro scripting. Observe se há uma falha de compilação o

processo não vai cometer e o implementador tem que corrigir o script para prosseguir. Antes de saltar ainda mais para estes artefatos,
vamos olhar para o suporte a aplicativos para o quadro scripting. Observe se há uma falha de compilação o processo não vai cometer e o

implementador tem que corrigir o script para prosseguir. Antes de saltar ainda mais para estes artefatos, vamos olhar para o suporte a

aplicativos para o quadro scripting.

Criação Ponto / Lançamento Script

Isto é feito através de assistentes lançados a partir da guia lista na aplicação Autoscript. A aplicação Autoscript
pode ser iniciado a partir do menu GoTo → Configuração do Sistema → Autoscript. Na guia Lista suspensa ações
listar há uma enorme quantidade de assistentes que lhe permite

1. Crie um script de baunilha sem qualquer ponto de lançamento.


2. Criar scripts com o ponto de lançamento de objeto.
3. Criar scripts com o ponto de lançamento Atributo.
4. Criar scripts com o ponto de lançamento Ação.
5. Criar scripts com ponto condição costume lançamento.

Esses assistentes irá conduzir você através do processo de criação de um script e associando pontos de lançamento com ele.
Vamos discutir pontos de lançamento em detalhes em uma seção posterior.

manutenção de ponto / Lançamento Script

Após o ponto de roteiro e lançamento foram criados - os usuários podem vir para o
aplicação Autoscript para manutenção. Isso pode ser feito usando as principais variáveis / / abas ponto de lançamento
em que a aplicação. Pode-se modificar o script, adicionar ou atualizar as variáveis e suas ligações, bem como as ligações
no nível de ponto de lançamento [se eles são substituível]. Eliminação de variáveis não são permitidos a menos que
nenhum dos pontos de lançamento referem-se a essa variável.

Variáveis e vinculações

Em seguida na linha são o variáveis e sua Ligações. As variáveis são o que os scripts usam para interagir com Maximo. As variáveis podem ser IN,
INOUT ou OUT. Estas seguem o defintion clássica de passe IN- por valor, INOUT / OUT - passado por referência. O script pode modificar apenas
o tipo INOUT e OUT de variáveis. Modificação de variáveis no script não tem impacto fora do script. As variáveis podem ser ligados a um
artefato Maximo como um atributo mbo, um maxvar, uma propriedade do sistema maximo ou pode ser ligado a um valor literal que não
amarrar volta para qualquer artefato Maximo. variáveis nota ligados a um maxvar ou uma propriedade do sistema são do tipo em apenas como
eles não podem ser modificados pelo script. As variáveis podem ser do tipo escalar ou matriz. variáveis tipo de matriz são suportados apenas
para ligações de atributos MBO e são sempre do tipo IN. Mais informações sobre as variáveis do tipo de matriz mais tarde como este precisaria
de uma seção dedicada a discutir. Tipo de dados variável de atributos MBO

é impulsionado pelo tipo de dados atributo MBO. Assim, por exemplo uma variável vinculado a ordem de compra MBO TOTALCOST atributo
herdarão o seu tipo ou seja, um duplo. Variáveis ligadas para maxvar e propriedades do sistema são sempre de tipo cadeia. Variáveis
vinculados a valores literais pode definir o seu tipo de dados explicitamente, definindo atributo “literaldatatype” na tabela de autoscriptvars.
Os tipos de dados suportados são literal - ALN, INTEGER, SMALLINT, decimais, YORN, DATETIME e flutuar. ligações variável pode ser definida
tanto a nível script eo Variáveis vinculados a valores literais pode definir o seu tipo de dados explicitamente, definindo atributo
“literaldatatype” na tabela de autoscriptvars. Os tipos de dados suportados são literal - ALN, INTEGER, SMALLINT, decimais, YORN, DATETIME
e flutuar. ligações variável pode ser definida tanto a nível script eo Variáveis vinculados a valores literais pode definir o seu tipo de dados
explicitamente, definindo atributo “literaldatatype” na tabela de autoscriptvars. Os tipos de dados suportados são literal - ALN, INTEGER,
SMALLINT, decimais, YORN, DATETIME e flutuar. ligações variável pode ser definida tanto a
nível script eo launchpoint nível - desde a definição no nível script permite substituição desse valor. Mais sobre isso no Launchpoints seção.

Um outro aspecto importante do OUT e variáveis INOUT é a forma como os seus valores podem ser definidos de
volta para os MBO. atributos MBO pode ser definido com a bandeira noaction que determina se modificar o valor
do atributo mbo fará com que o campo de rotina ação validações de ser chamado ou não. atributos MBO pode ser
definido com a bandeira novalidation que determina se modificar o valor do atributo mbo fará com que as
validações de campo validar rotina a ser chamado ou não. Atributos MBO pode ser definido usando bandeiras
NOACCESSCHECK que determinam se a rotina Ação / validação dos atributos MBO será chamado ou não. Um
atributo mbo pode ser definido com qualquer combinação destas bandeiras. Tudo isso pode ser feito a partir dos
assistentes de criação ponto de script / lançamento e aplicação de manutenção Ao selecionar as opções [checkbox].

Variáveis implícitas e explícitas

Outra característica importante é o conceito de Implícito e Explícito variáveis.


variáveis explícitas são o que acabamos de ler sobre - os que você define e de Ligação na página variáveis
explicitamente. variáveis implícitas são as únicas que você não definem nessa página e são fornecidos a você nos
bastidores pela estrutura. Implícitos seguir a convenção sobre o teste padrão de configuração onde o quadro
inteligentemente injetar variáveis em tempo de execução que poderiam teria necessidade de codificação Java para
buscar / set. Alguns dos implícitos são injetados com base nas variáveis explícitas definidas e alguns são injetados
independentemente deles. Permite cobrir os que são injetados independentemente das variáveis explícitas em
primeiro lugar. A lista deles é como abaixo com uma pequena sinopse descreve o que eles são.

Nome Tipo Descrição aplicabilidade

aplicativo Corda Nome do aplicativo Maximo que Todos os pontos de lançamento


iniciou a execução do script.

do utilizador Corda Nome do usuário cuja ação Todos os pontos de lançamento


iniciada a execução do script.

mbo psdi.mbo.Mbo O mbo atual no Todos os pontos de lançamento


contexto da execução do script. Por
exemplo, no caso do Lançamento
objeto de ponto este será o Mbo que
está gerando os eventos em que o
quadro roteiro está escutando. Para o
ponto de lançamento atributo este é o
atributos proprietário mbo. De Acção
ponto de lançamento é dizer a escalada
ou fluxos de trabalho mbo.

mboname Corda O nome do mbo atual no Todos os pontos de lançamento


contexto da exection script.

errorkey Corda Este é para jogar MXExceptions do Todos os pontos de lançamento


script sem ter que importar ou se
referir a essa API explicitamente.
Isto refere-se a chave erro no
MXException. Isso funciona em
conjunto com o errorgroup eo
params variáveis implícitas. Para
aqueles não familiarizados com o
Nome Tipo Descrição aplicabilidade
MXException api - sua a forma
padrão para lançar exceções de
componentes baseados Maximo. A
mensagem de exceção é traduzido
que é a principal vantagem de usar
essa api em oposição a apenas
levantar uma exceção Java padrão
que não vai ser traduzido.

errorgroup Corda Seu uso é o mesmo que o anterior ou Todos os pontos de lançamento
seja, o errorkey. Este aponta para o
grupo de erro do MXException.
Juntamente com o errorkey ele ajuda a
apontar exclusivamente a uma
mensagem de erro no Maximo
repositório de mensagens.

params Corda[] Este é o params para a mensagem de Todos os pontos de lançamento


erro MXException. Portanto, se o
MXException sendo jogados
utilizando este mecanismo é
parametrizado então este params
variável implícita deve ser usado para
definir os parâmetros.

interativo boleano É uma variável booleana que indica se Todos os pontos de lançamento
o script é executado em uma sessão
interativa / UI [valor verdadeiro] ou uma
sessão de fundo [como dizem
Integração].

evalresult boleano Esta é uma variável booleana do tipo ponto de Lançamento


OUT para indicar o resultado da única condição
avaliação condição.

onAdd boleano Esta variável boolean indica onde o Todos os pontos de


Mbo no script está sendo adicionado lançamento. Idealmente
[isto é novo Mbo - valor verdadeiro] ou seria valioso para pontos de
não. O desenvolvedor script pode usar lançamento de objeto onde
isso para fazer o
Nome Tipo Descrição aplicabilidade
ações condicionais ou script é aplicável para
validações com base no estado vários tipos de eventos
do Mbo. [Adicionar, atualizar,
excluir etc]

OnUpdate boleano Esta variável boolean indica onde o Mesmo que onAdd
Mbo no script está sendo atualizado - Todos os pontos de
lançamento.
[ie sair Mbo - valor verdadeiro] ou
não. O desenvolvedor script pode
usar isso para fazer ações
condicionais ou validações com base
no estado do Mbo.

onDelete boleano variável booleana indicando se o Mesmo que onAdd


mbo no contexto script está ficando - Todos os pontos de
lançamento.
excluído [valor verdadeiro] ou não.

açao Corda O nome da ação que foi gerado a Ponto de Ação


partir do assistente Ação Lançamento
Lançamento Point.

scriptName Corda O nome do Script aquele é ficando Todos os pontos de lançamento


executado.

launchPoint Corda O nome do ponto de lançamento para Todos os pontos de lançamento


o qual o script está sendo executado.

scriptHome psdi.mbo.Mbo Este é o mesmo que o Ponto de Ação


implict “MBO” variável descrito Lançamento
anteriormente. Esta duplicação é para
compatibilidade com versões anteriores.

wfinstance psdi.workflow. O mbo exemplo do fluxo de trabalho. Lançamento ação


WFInstance Point - apenas quando a
ação é lançado a partir de
um fluxo de trabalho.

Agora vamos falar sobre essas variáveis implícitas que são injetados no script com base nas variáveis
explicitamente definidas.

Uma coisa a ter em mente - todas estas variáveis implícitas que descrevemos abaixo
baseiam-se nas variáveis explicitamente definidas cujo tipo de ligação é um atributo Mbo. Não há variáveis
implícitas para as variáveis explicitamente definidas de outros tipos de ligação como - literais, Maxvars e
propriedades do sistema. Abaixo está a lista das variáveis implícitas. Suponha “var” é a variável explicitamente
definido que se liga a um atributo de MBO.

Nome Tipo Descrição aplicabilidade


var_required boleano bandeira exigido dos Todos os pontos de
mbo atribuo isso var lançamento. O script pode
se liga a. modificá-lo, desde que var
é do tipo OUT ou INOUT.

var_readonly boleano bandeira somente de leitura Todos os pontos de


dos mbo atributo que se lançamento. O script pode
liga ao var. modificá-lo, desde que var
é do tipo OUT ou INOUT.

var_hidden boleano bandeira escondido dos Todos os pontos de


mbo atributo que se liga lançamento. O script pode
ao var. modificá-lo, desde que var
é do tipo OUT ou INOUT.

Mesmo tipo que o


var_internal atributo Por tipo de domínio Todos os pontos de
MBO para o qual se liga sinônimo de atributos lançamento. Aplicável
ao var. MBO [como status] isso apenas se var está ligado a
representa o valor interno um atributo mbo que se liga
[maxvalue] para o a um domínio sinónimos. O
atributo mbo. script não pode modificá-lo.

Mesmo tipo que o


var_previous atributo O valor anterior do mbo Atributo pontos de
MBO para o qual se liga atribuir ou seja, o valor lançamento - aplicável
ao var. imediatamente antes do apenas para o atributo
valor do atributo tem que gerou o evento. O
mudado. script não pode
modificá-lo.

Mesmo tipo que o


var_initial atributo O valor inicial do Todos os pontos de
MBO para o qual se liga atributo mbo ou seja, o lançamento. O script não
ao var. valor atribuído a esse pode modificá-lo.
atributo quando o mbo
foi inicializado.
Nome Tipo Descrição aplicabilidade
var_modified boleano Indica se o atributo Todos os pontos de
MBO para o qual a lançamento. O script não
variável se liga ao var pode modificá-lo.
foi modificado ou não.

Nós vamos cobrir mais sobre eles usando exemplos como parte da seção de pontos de lançamento.

Variáveis de matriz

Vamos falar um pouco sobre as variáveis de matriz como que iria apresentá-lo ao conceito de Mbo Caminho do
relacionamento [MRP].

O formato MRP é uma extensão da notação de caminho atributo atual. A notação de caminho atributo mbo
atual suporta o ponto “” para permitir atravessar MBO relacionados e buscar valor do atributo a partir deles.
Um exemplo do formato de corrente é mostrada abaixo [os exemplos são baseados da PO mbo]:

poline.pocost.costlinenum - o que nos dá o primeiro de poline [o nome da relação é poline] 1 st de


POCOST [o nome da relação é POCOST] colstlinenum atributo. OU

poline [i] .pocost [j] .costlinenum - o que nos dá o i th poline de [o nome da relação é poline] j th
POCOST de [o nome da relação é POCOST] atributo colstlinenum.

A notação MRP acumula-se sobre esta notação caminho atributo. A única diferença fundamental é que MRP leva a
uma lista / matriz de Mbo atributos. Por exemplo, se tomarmos os exemplos acima de um MRP pode ser parecido
com:

poline.pocost.costlinenum * - que nos dão uma lista combinada ou matriz de MBO POCOST para todos os
tensores.

poline [linecost> 100] .pocost [percentual <100] .costlinenum * - o que nos dá tudo costlinenum de onde as
OBs POCOST tem percentual <100 para todos os tensores com linecost> 100. Isto é efectivamente filtrar a
cláusula relação [poline e pocost] para peneirar apenas os MBO que satisfazem a condição específica. Isso
pode genericamente ser representado por:

poline [condition1] .pocost [condition2] .costlinenum *


onde condition1 e condirion2 pode ser uma condição Maximo ou SQL matéria-onde. Como
você já deve ter notado - o * no final de esta notação indica matrizes ao invés de apenas um
valor escalar. Considerar outra variação deste, como mostrado abaixo: poline [condição1]
.pocost [i] .costlinenum

o que implica costlinenum de todo i th POCOST de cada poline que satisfaz condtion1.

Vemos que o conteúdo com a chave '[' e ']' podem ser sobrecarregados em 3 maneiras diferentes.

1. Pode ser um número significando um índice de matriz.


2. Ela pode ser uma condição que pode ser Máximo prefixado com o cond:
3. Pode ser um SQL cru onde

Agora vamos levar em consideração a diferentes cenários / contexto desta avaliação MRP. Nota destes casos
descritos a seguir podem ser misturados em um MRP como parte dos diferentes sinais de relação.

MRP sem filtro


Esta é uma MRP, onde nenhum dos símbolos tem qualquer relação filtro associado. Este é o caso mais
simples onde o MRP parece R1.R2 ... onde R1 e R2 são nomes de relação e não há nenhuma cláusula
de filtro associado a essas relações. Neste caso, a avaliação envolveria apenas a iteração sobre o
conteúdo de R1 e R2 MboSets e preparar uma lista de MBO R2.

MRP com o Índice de filtro:


Esta é uma MRP, onde uma ou mais das fichas relação possui um Índice de filtro associado. Este é o caso em que
o MRP parece R1 [index1] .R [...] .... onde uma relação token [uma ou mais] tem o Índice de filtro =>
para que Mboset identificado pela relação R1 usar o Mbo no índice “index1” para a avaliação de MRP. Esta é
uma filtragem de memória dentro e não tem impacto sobre o estado da MboSet no qual o filtro do índice
está sendo aplicado.

MRP com filtro condição:


Esta é uma MRP, onde uma ou mais das fichas relação possui um filtro associado com uma condição
Máximo. Este é outro exemplo de filtragem na memória onde o MRP parece R1 [cond: c1] .R2 [...] onde c1 é
um nome de uma condição Maximo e cond é o prefixo indicando que é uma condição Maximo. A
avaliação baseia-se na memória de filtragem dos MBO em MboSet R1 com base na condição c1 e não tem
impacto sobre o estado do MboSet em que o filtro está sendo aplicado.

MRP com um filtro, onde:


Esta é uma MRP, onde uma ou mais das fichas relação possui um filtro associado
com uma cláusula onde. Isso equivale a acrescentar um adicional onde cláusula a cláusula relação existente.
Isso definitivamente iria causar o reset MboSet relacionado para ser chamado e enquanto ela pode funcionar
para certos casos, definitivamente resultariam é emitido imprevisível para sessões de usuário interativas
[usuário vendo um aplicativo]. A implementação deve usar relações temporárias criadas dinamicamente para
substituir cada uma das relações associadas a um tal filtro para avaliar esta MRP. Assim, por exemplo, se o
MRP foi R1 [onde] .R2.R3 [onde] a aplicação deve substituir [transparente] R1 e R3 com os nomes de relações
temporárias com a mesma relação cláusula como os seus homólogos originais. Isso só funcionará se todos
os MBO referidos pelas fichas relação MRP não foram toBeSaved () => o em memória de estado representa
seu estado no armazenamento persistente.

Uma coisa a notar aqui é - a sua sempre recomendável usar apenas as relações pré-definidas em
oposição a dinamicamente adicionar filtros para a relação apenas manter o desempenho em mente. A
razão é - no caso de precisarmos acessar essa variável mais de uma vezes - o avaliador irá sempre criar
uma relação temporária entre o src e os objetos alvo. Este, porém, impedirá o uso de um
relacionamento em cache conjunto das OBs de origem.

A abordagem cláusula onde irá acrescentar a condição cláusula WHERE. A abordagem a condição irá filtrar a
MboSet na memória sem disparar um sql onde cláusula para o filtro adicionado. Este, porém, levará mais
tempo para peneirar do que usar a cláusula SQL. A aplicação de condições podem ser usados para definir os
confitions filtro.

Launchpoint Launchpoints são o que chamamos os pontos de personalização do aplicativo. Launchpoints


definir qual aplicação artefato o usuário quiser personalizar, anexando o script a esse ponto. Com efeito, o
script é executado [ lançado] no contexto de um launchpoint. Por exemplo, se o usuário quiser personalizar a
inicialização MBO ativos rotina as palavras-chave mbo ativos & rotina de inicialização

define que launchpoint. Outro exemplo pode ser que o usuário quiser personalizar rotina de validação de campo
de atributo purchaseprice do Activo de MBO. Aqui as palavras-chave que definem a launchpoint são - mbo de
ativos, atributo purchaseprice e rotina de validação de campo. Então, na verdade um launchpoint é uma
configuração para identificar o ponto de aplicação que estamos tentando personalizar. Um script pode ser
associado com um ou mais launchpoint ao mesmo tempo. Por exemplo, um script de validação nível do site
genérico pode ser associado com todos os objetos de nível do site em Maximo - onde cada associação é definida
como uma launchpoint individual. Um script pode ser associado com launchpoints de um e apenas um tipo. Por
exemplo, um script associado com o ponto de lançamento de objeto não pode ser associado novamente com
outro ponto de lançamento atributo. Uma vez que a primeira associação é feita entre um script e um ponto de
lançamento - todos os pontos de lançamento subseqüentes tem que ser do mesmo tipo que o primeiro.

Agora vamos dar uma olhada nas launchpoints [aka pontos de personalização] retocadas
pelo quadro scripting. Abaixo está a lista dos pontos suportados atualmente.
1. inicialização Mbo e salvar lógica ponto [aka launchpoint Object].
2. Mbo atribuir modificação valor - validação e lógica de ação [também conhecido como objeto de atributo
launchpoint].
3. Ações - que são utilizados por uma grande variedade de outros componentes como Workflow,
Escalation, Menu UI, UI Botões [aka launchpoint Ação].
4. condições personalizados - usados por condições de fluxo de trabalho, condicional UI etc [aka costume
condição launchpoint].

Launchpoints são o que você pensa em primeiro lugar quando você quiser personalizar um aplicativo. Não admira que
todos os assistentes no aplicativo Script começa com a definição do launchpoint. Em seguida vamos explorar os tipos de
ponto individuais para entender o que eles trazem para a mesa para customizers e implantadores.

Ponto de Lançamento objeto

Em primeiro lugar na nossa lista é o objeto ponto de lançamento. Este launchpoint permite invocar scripts para os eventos
MBO - inicialização e salvar aqueles ponto [adicionar, atualizar e excluir]. Um ponto de partida pode ser configurado para
atender a um ou mais desses eventos ao mesmo tempo. O script terão acesso ao evento Mbo [via variável implícita “MBO”],
bem como todos os MBO relacionados. Os scripts baseados em eventos de inicialização pode ser usado para definir campos
calculados, definir campos como somente leitura / requerido / defaults condicionais escondidos ou definido como atributos
MBO. Os scripts baseados em eventos salvar o ponto pode ser usado para implementar salvar validações objeto de ponto,
bem como salvar ações pontuais. Abaixo está um exemplo que irá demonstrar um script ponto de inicialização ea próxima
seria demonstrar uma salvar roteiro ponto.

Então vamos dar o caso de uso em mente antes de saltar para o código e configuração. Suponha que queremos
personalizar a aplicação de Ativos para exibir a quantidade total de peças de reposição em um novo atributo de
objeto de ativos não-persistente chamado sparepartqty. Isto resume-se à exigência - sempre que um MBO ativos é
inicializado o sparepartqty irá exibir a soma de todas as quantidades de peças de reposição associados com esse
activo. Assim, com base no nosso conhecimento de pontos de lançamento temos que será um Ponto de Lançamento
objeto para o ativos objeto e precisamos anexar o script para o evento de inicialização do objecto de Activos. Para
fazer isso, precisamos lançar a “criar scripts com o objeto Lançamento Point” wizard como mostrado abaixo.
Quando o assistente é lançado a primeira coisa que fazemos é criar um ponto de lançamento, como mostrado abaixo. Observe que
o evento “inicializar” é o que nós queremos usar para o lançamento deste script.

Então agora vamos olhar para as variáveis que possam ter necessidade de fazer essa personalização.
Primeiro, claro, é uma variável chamada sptqt que se liga ao novo ativo mbo atributo sparepartqty. Agora
nós só pretende definir o valor desse atributo e, portanto, esta variável seria do tipo OUT. Em seguida,
precisamos obter todas as quantidades dos relacionados sparepart MBO do ativo. Para fazer isso, usamos a
notação variável array * para obter uma matriz de valores de quantidade do sparepart relacionado MboSet.
Vamos dizer que a variável de matriz é qtys e seu valor ligamento seria <trunfo para sparepart nome da
relação>. <Nome do atributo> * que é sparepart.quantity *. A * no fim de curso indica a natureza matriz
desta variável e também instrui a estrutura para formar a matriz por meio da relação especificada.
E, como mencionado variáveis de matriz anteriores são sempre do tipo IN e que é perfeito para isso, já que não está
modificando as quantidades - estamos simplesmente somando isso. Assim, com estas variáveis básicas definido que
na próxima iria tentar escrever o roteiro como abaixo

se qtys não é None:


sptqt = soma (qtys)

Basicamente um forro 2, que valida se há de facto sparepart Mbo do e se houver, em seguida, resumi-los e
configurá-lo para a variável sptqt. O quadro de script pega isso e define o valor de volta para a ligação do
sptqt ie sparepartqty. Assim, a quantidade de codificação Java feito aqui é um grande zero - o seu roteiro
jyhton puro. Agora vai pela natureza dos campos calculados - o sparepartqty sempre deve ser lido apenas. E
o melhor lugar para definir que somente leitura que não seja esse script - que incorpora o evento de
inicialização de ativos. Abaixo está o script final que adiciona o código para definir o atributo sparepartqty
apenas para ler. sptqt_readonly = True se qtys não é None:

sptqt = soma (qtys)


Uma vez que você pressionar o botão criar na última etapa do assistente para criar o script - uma criação bem-
sucedida do script e do ponto de lançamento irá gerar esta resposta como mostrado abaixo.

Em caso de um erro de compilação que você seria forçado a ficar para trás na última página até que você cancelar ou
corrigir esse script.

Aqui você vê a magia deste conceito variável implícita. Quando você limita sptqt para sparepartqty atribuem o
quadro de script injetado em tempo de execução não só a sptqt variável, mas também algumas variáveis implícitas
como sptqt_readonly, sptqt_required e sptqt_hidden cada um dos quais são do tipo boolean e atende a apenas o ler,
necessário e bandeiras escondidas do Mbo atributo. Definir um campo mbo para somente leitura de outra forma
teria exigido codificação Java. Um código java para fazer esta mesma funcionalidade seria semelhante abaixo

mbo.setFieldFlag ( “sparepartqty”, MboConstants.READONLY, true); MboSetRemote


sparepartSet = mbo.getMboSet ( “sparepart”); int i = 0;

MboRemote sparepartMbo = sparepartSet.getMbo (i); duplo


totalQty = 0; while (sparepartMbo! = null) {

totalQty + = sparepartMbo.getDouble ( “quantidade”);


sparepartMbo = sparepartSet.getMbo (++ i);
} Mbo.setValue ( “sparepartqty”, totalQty, MboConstants.NOACCESSCHECK); Então, por esta altura você deve ter
descoberto o que quantidade de dor quadro scripting te salvou !. Não basta pensar em termos de linhas de código
[que é quase um 1: 2] pensar também sobre o conhecimento api que você precisa para esta tarefa simples. E este
código nem sequer tratar a dor que você vai passar para anexar esse código à rotina de inicialização do Activo de
Mbo. Há suas escolhas são ainda mais peludo - ou você teria que estender o MBO de Ativos e substituir o método
init () de que mbo para colocar o seu código [caso em que no código acima apenas substituir a variável mbo com
ponteiro “este” ] ou você iria acabar anexando o seu código como um ouvinte para o evento do Mbo - que é uma
pilha api separado no seu próprio !. No framwork scripting todos estes são tomadas de cuidados para você o
momento de ter pressionado o botão “Criar” para acabar com o seu assistente [submetendo assim o seu roteiro].
Como um desenvolvedor de script que você acabou de codificar a lógica - o quadro cuida do por trás do trabalho
cenas de encanamento para gerenciar e
executar o seu script. Então, sim, você vai economizar tempo e dinheiro com isso com certeza.

Pela forma como o código java acima iria funcionar [desde que você faça o estilo sintaxe Jython sobre ele
- como remover o; e as chaves e ..] até mesmo dentro do script Jython - que é apenas no caso de você é
um programador java ávido !. Só não se esqueça de importar o seguinte antes de enviar o roteiro - de
MboRemote psdi.mbo importação de MboConstants psdi.mbo importação de psdi.mbo MboSetRemote
importação

que é a forma jython da importação de bibliotecas java externos. Isso mostra que, enquanto quadro scripting
dá enorme poder para desenvolvedores de scripts para obter a sua personalização Maximo feito sem saber apis
Maximo - ele não tirar o poder de codificação Java dos desenvolvedores que estão acostumados a isso. Então,
efetivamente você pode invocar todos os apis Maximo [por exemplo, fazer uma chamada de serviço Web para
buscar alguns dados externos usando o framework de integração] de dentro de um script, desde que você
tenha importado-los adequadamente.

Em seguida vamos passar para alguns salvar validações ponto que espero venha a ajudar a demonstrar mais características
deste quadro. Como antes permite lidar com o caso de uso em primeiro lugar. O caso de uso aqui é a necessidade de
personalizar o MBO de ativos para impor uma convenção de nomenclatura para os ativos [assetnum] com base em seus
tipos [assettype]. Isso efetivamente resume-se a exigência de que sempre que estamos criando Assets

temos que seguir uma convenção de nomenclatura para o assetnum. As palavras-chave são em blocos que nos
ajudam a identificar o tipo launchpoint eo ponto de evento em que tipo. Seu um launchpoint objeto para os MBO
ativos adicionar evento. Então, nós usamos o assistente de ponto de lançamento de objeto para criar e implantar
essa lógica personalizada. Para começar, precisamos descobrir as variáveis e suas ligações. Da obrigação seu claro
que precisamos dos 2 valores de entrada do assetnum e assettype. Portanto, há 2 IN variáveis chamadas anum e
ATYPE que são obrigados a esses atributos, respectivamente. Essas são as únicas 2 variáveis que precisamos fazer
esta tarefa. Abaixo está o código de script [em Jython]

def setError (prefixo):


errorkey global, errorgroup, params errorkey =
'invalidassetprefix' errorgroup = 'activo' params
= [prefixo, assettype]

se == atype_internal 'instalações' e não anum.startswith ( 'FT'):


setError ( 'FT')
elif atype_internal == 'FROTA' e não anum.startswith ( 'FL'):
setError ( 'FL')
elif atype_internal == 'TI' e não anum.startswith ( 'TI'):
setError ( 'TI')
elif atype_internal == 'produção' e não anum.startswith ( 'PR'):
setError ( 'PR')

Aqui nós definimos uma função jython chamado setError que é responsável por definir os sinalizadores de
erro. Nós vemos o uso do <nome da variável> variável implícita _INTERNAL que é aplicável somente para
os atributos que usa um synonymdomain. O <nome da variável> _INTERNAL fornece o valor interno para
esse atributo com base no seu valor externo atual. Portanto, este script usa o valor interno do atributo
assettype para estabelecer a convenção de nomenclatura. Por exemplo Activos com assettype
INSTALAÇÕES valor [internas] deve ter assetnum começando com “FT” etc. Este mesmo código em java
teria exigido saber a api Maximo para encontrar o valor interno do assettype usando a API do Translator
como abaixo.

Corda domainId = MXServer. getMXServer (). getMaximoDD (). getMboSetInfo ( "de ativos" ) .GetMboValue Info (
“assettype”) getDomainId (.); Corda atypeInternal = MXServer. getMXServer (). getMaximoDD (). getTranslator ().
toInternalString (domainId, mbo.getString ( “assettype”), MBO);

Isso é algo que até mesmo um desenvolvedor ávido Maximo acharia difícil de lembrar e usar e nós não
quero sequer entrar nos isso é trabalho de canalização necessários para executar este código.

Vemos também como os erros podem ser jogados neste quadro sem usar Maximo apis. Basta definir o errorgroup,
errorkey e params [opcional] ao grupo configurado mensagem de erro, a chave ea matriz params podem ser
derivadas das variáveis de script. Neste caso, têm predefinidos o ativo grupo de erro ea chave de erro
“invalidassetprefix” usando o aplicativo de configuração de banco de dados Maximo. Os parâmetros que você pode
fazer para fora são derivados em tempo de execução do script. Uma coisa a notar aqui é que esta forma de definir
sinalizador de erro para jogar erro não é em tempo real, ou seja, quando o código de script está executando a
exceção seria lançada somente depois que o código de script foi concluída a execução. No final da execução do script
do quadro iria detectar que uma bandeira de erro é definido e vai jogar a correspondente excpetion Maximo para
esse grupo de erro de combinação / chave. Então você deve considerar o fato de que, mesmo depois de definir os
sinalizadores de erro no script - a execução do script continuará e você deve ter um controlo adequado no seu
código de script para ignorar esse código se o sinalizador de erro é definido.

Esperemos que este não lhe dá a impressão errada de que você não pode jogar a MXException crua do código
de script - mostrado abaixo é como fazê-lo. de MXApplicationException importação psdi.util

....
....
Se <alguma condição>:
params = [prefixo, assettype]
levantar MXApplicationException ( 'trunfo', 'invalidassetprefix', params)
Como antes o quadro de script cuida de todas as canalizações nos bastidores. Assim que estiver pronto
submeter seu script usando o assistente, você pode vir para o aplicativo de Ativos e tentar salvar um ativo
de teste. Você deverá ver a sua rotina de validação é executada imediatamente. No reinício, sem orelha
reconstrução e não reafectação.

Atributo Lançamento Ponto

Em seguida, cobrir a Atributo Lançamento Ponto onde se pode personalizar a validação e ações usando o
framework scripting campo. Como antes o script terá acesso ao evento Mbo [via variável implícita “MBO”],
bem como todos os MBO relacionados. Além disso, o atributo modificado também estaria disponível
implicitamente como uma variável dentro do script. O nome da variável seria o valor minúsculas do nome do
atributo modificado. Um par de exemplos abaixo ajudaria a explicar isso melhor.

Como antes de continuar personalizando o Activo Mbo. O caso de uso desta vez é adicionar lógica de negócios
personalizada com base no Ativos preço de compra [ atribuir purchaseprice em Activo] valor. Por exemplo,
queremos definir o campo fornecedor necessário ou não necessário com base no valor do atributo purchaseprice e
também para calcular o custo de substituição com base no preço de compra. Nós também queremos garantir que
o preço de compra não exceda um valor máximo permitido. Com base no caso de uso sabemos que a lógica tem
que injetou na modificação do valor do atributo purchasprice - o que implica que deve ser modelado como um
atributo Lançamento Point. Abaixo está uma maneira de chegar ao assistente.

Assim que iniciar o assistente nossa etapa 1 é criar o ponto de lançamento, como mostrado ser
Agora vamos olhar para as variáveis que seria necessário para essa tarefa. Precisamos, definitivamente, a
variável purchaseprice. Mas nós não precisamos definir que explicitamente como que já está disponível
implicitamente dentro do script como o atributo em que o script está escutando. Em seguida temos o atributo
fornecedor para defini-lo necessário ou não com base no valor purchaseprice. Diga a variável que é vend e
seu tipo é OUT. O único remanescente é o replacementcost e dizer que se ligam que a variável chamada rc com
o tipo como OUT.

Nome variável tipo de variável Obrigatório

vend FORA fornecedor

rs FORA custo de reposição


Então agora vamos olhar para o script abaixo que entramos na próxima etapa do assistente. se purchaseprice>

200:
errorgroup = "algo" errorkey =
"else" else:

se purchaseprice> = 100:
vend_required = True outra

coisa: vend_required = False rc =

purchaseprice / 2

Como vemos as 3 variáveis purchaseprice, errorgroup e errorkey são variáveis implícitas que você não tem que definir.
Os únicos que você tinha que definir para este script são explicitamente vend e rc. E se purchaseprice é> 100 vamos
definir o fornecedor, conforme exigido pela configuração variável booleana implícita vend_required de verdadeiro e
falso caso contrário. Como discutimos anteriormente - quando uma variável é ligado a uma Mbo atribuem o quadro
sempre injeta implict variáveis que representam o estado meta dados do atributo - como [vend_] somente leitura,
[vend_] necessário e [vend_] escondido. Finalmente, calcular o custo substituir definindo
o rc variável para purchaseprice / 2 [basicamente rc é uma função do preço de compra]. Note cuidadosamente
que
Toda a lógica é feito dentro do “else:” bloco. Uma forma defeituosa para escrever o roteiro teria sido tão
abaixo.

se purchaseprice> 200:
errorgroup = "algo" errorkey =

"else" se purchaseprice> = 100:

mbo.setFieldFlag ( “Vendedor”, MboConstants.REQUIRED, verdadeiro) else:

mbo.setFieldFlag ( “vendor”, MboConstants.REQUIRED, false)


mbo.setValue ( “replacementcost”, purchaseprice / 2)

Isso é usar a suposição equivocada de que definir o errorgroup e errorflag fará com que o programa pare a
execução e jogue o erro [como uma exceção de lance em tempo real que retorna o controle de volta para o
chamador]. Como mencionado anteriormente isto não é como os sinalizadores de erro trabalhar. Ao contrário de
lançar uma exceção seu tempo não real. Ele vai lançar a exceção somente após a execução do script é concluída.
Portanto, neste caso código defeituoso bandeira exigido do vendedor será afetado eo valor substituir custo será
modificado e, em seguida, o script irá lançar uma exceção que não irá reverter essas mudanças. Isto é porque nós
usamos chamadas MBO explícitas para definir o valor ea bandeira. Se tivéssemos utilizado as variáveis esta ainda
teria trabalhado como as verificações quadro para o sinalizador de erro logo após o término da execução do script e
antes de definir uma saída e valores de variáveis INOUT de volta para a Mbo de. Assim, o código abaixo ainda teria
trabalhado, apesar de que não seria tão legível quanto o original.

se purchaseprice> 200:
errorgroup = "algo" errorkey =

"else" se purchaseprice> = 100:

vend_required = True outra

coisa: vend_required = Falso


rc = purchaseprice / 2

Agora vamos olhar para outro exemplo, antes de passar para o próximo tipo de ponto de lançamento. O
próximo caso de uso seria fazer o campo calculado que criamos para o Ativo sparepart cálculo quantidade
total mais em tempo real. Por exemplo, se alterar as quantidades de peças sobressalentes relacionadas
devemos ver o campo calculado [sparepartqty] alteração de valor em tempo real. Para isso, seria necessário
criar um script que será associado com o atributo quantidade sparepart. As ligações variáveis explícitas são
mostrados abaixo.
Nome variável tipo de variável Obrigatório

sptqt INOUT & Proprietário & .sparepartqty

Como evidente a partir da ligação a sptqt variável está ligado ao proprietário do atributo sparepartqty [mbo
Activo]. Nós temos que definir a variável sptqt com o Sem verificação de acesso como seu roteiro marcado
como somente leitura pelo nosso original [ponto de lançamento Object] na inicialização do mbo de ativos.
Como explicado anteriormente, a quantidade variável [o atributo no qual o script está ouvindo] seria injetado
implicitamente no script como esse é o atributo no qual o script está escutando. O script vai olhar como
abaixo.

sptqt = sptqt +-quantity_previous quantidade

Aqui vemos o uso da quantity_previous variável implícita. Isto representa o valor da quantidade de
atributo antes da modificação ou seja, o valor na inicialização do Mbo sparepart. E a quantidade
variável de curso tem o valor modificado atual do atributo quantidade.

Assim combinação deste roteiro, juntamente com o script ponto de lançamento de objeto pode dar-lhe uma
lógica campo calculado completa implementado usando a estrutura de script com 3 linhas de script e alguns
cliques no Assistente de script !.

ponto de Lançamento ação

Nós todos sabemos sobre a estrutura Ações Maximo. No caso de você não sabia - Maximo foi construído em um
biblioteca de ações que pode ser chamado a partir de fluxos de trabalho, escalações e UI menu e UI botões e uma
série de outros componentes. Mais frequentemente do que menos aqueles construídos na biblioteca de Ações não
são suficientes e implementadores sair e desenvolver suas próprias ações personalizadas e, claro, o idioma que você
é forçado a usar é JAVA. endereços de script esta preocupação em que uma ação pode ser programado com uma
linguagem de script de sua escolha [OOTB - Jython e JavaScript]. Vamos ver como podemos usar uma ação de
script para fazer alguns metros calculados para Ativos.

Como em diante vamos primeiro estudo a exigência que é a de ser capaz de calcular um valor de metro de ativos com
base em alguns outros medidores associados com esse activo. Por exemplo, vamos dizer que queremos calcular o valor
do medidor de pressão com base na IN-Pressur e medidor O-Pressur tal que a última leitura do medidor de pressão é o
somatório das IN e O-Pressur metros leituras. E vamos dizer que nós escolhemos fazê-lo de forma off-line, onde em
oposição a uma forma em tempo real [para o qual teria necessidade de usar pontos de lançamento de objeto para
eventos armadilha metros de modificação]. A maneira mais simples de fazer ações off-line de uma forma repetida em
Maximo é usar escalações que nada mais são que tarefas agendadas que executam uma ação predefinida no contexto de
um MBO. Agora, em vez de escrever o código java Ação vamos roteiro lo. Mostrado abaixo estão os passos para fazer
isso.
Primeiro vamos definir uma relação chamada assetmeterip [ activo pressão de entrada do medidor], utilizando a
aplicação DB-Config que refere uma mais valia para o medidor de Activos denominado EM-pressur. A cláusula onde é
como a seguir.

assetnum =: assetnum e siteid =: siteid e metername = 'EM-pressur' Da mesma forma que

definem os outros 2 relações nomeadamente assetmeterop e


assetmeterp como abaixo

assetnum =: assetnum e siteid =: siteid e metername = 'O-Pressur' assetnum =: assetnum e siteid =:

siteid e metername = 'pressão' Em seguida, usamos o assistente de Lançamento ponto de ação para

definir o Lançamento ponto de ação.

Embora este assistente criaria a ação por trás da cena - a sua a responsabilidade do implementador para
anexar referida acção para a escalada, o fluxo de trabalho ou o botão UI / menu. Por padrão, o nome do
ponto de lançamento é usado como o nome da ação, mas você pode modificar o valor de acordo com sua
convenção de nomenclatura. O nome do ponto de lançamento não precisa ser o mesmo que o nome da
ação. No primeiro passo do assistente você veria que o nome do objeto é opcional, que está em linha com o
quadro Maximo Ação quando um acto possa ou maynot ser associado a um objeto Maximo. Neste caso, no
entanto, não quer especificar o objeto como ativos como a ação é específica ao Activo Mbo. Desde estamos
definindo um novo script, vamos escolher a opção “New Script”.
A próxima página é a página de ligações para onde estamos indo para definir as variáveis que
pretendemos usar para o script e as suas ligações. Para fazer este trabalho tudo o que precisamos é o
último valor leitura da IN-Pressur e medidores O-Pressur e defina o valor calculado para o novo atributo
de leitura do medidor de pressão. Nós, entretanto, não quero definir o valor se o valor calculado é o
mesmo que o último valor de leitura do medidor de pressão como que geraria história leitura do medidor,
embora a leitura nunca foi modificado. Para verificar isso seria necessário o último valor de leitura do
medidor de pressão. Assim, nossos ligações variáveis será semelhante abaixo

Nome variável tipo de variável Obrigatório

iplr NO assetmeterip.lastreading

ROL NO assetmeterop.lastreading

plr NO assetmeterp.lastreading

pnr FORA assetmeterp.newreading


O iplr [IN-Pressur metros última leitura], ROL [O-Pressur metros última leitura] e PLR [PRESSÃO metros
última leitura] são todos do tipo IN como precisamos apenas esses valores para calcular o PNR [medidores
de pressão última leitura]. Observe o PNR é do tipo OUT como vamos defini-lo de volta para o mbo
medidor de pressão.

Página seguinte é o código de script e ele vai olhar como abaixo.

y = float (iplr) + float (ROL) se y


= float (plr)!
pnr = str (y)

Como você observar aqui y é uma variável local para o script.


Como você deve ter descoberto - o caso de verificação na 2 nd linha cuida de não atualizar o valor PNR se o valor
calculado é o mesmo que as PLR [PRESSÃO metros última leitura]. Note que este cálculo foi implementado como
uma mera adição apenas como um exemplo. Em implementações reais pode ser qualquer cálculo matemático
complicado quanto necessário para o seu caso de negócio e só limitado pelo suporte matemático fornecido pela
linguagem de script de sua escolha. Agora nós não estamos feito ainda como precisamos associar essa ação para
uma escalada. Nosso próximo passo é a criação de uma escalada que só se aplica a esses activos que têm todos os
3 metros. Nós usamos a condição escalada para implementar essa funcionalidade peneiração. A condição SQL para
o caso acima será semelhante abaixo.

existe (seleccionar assetnum de assetmeter onde metername = 'EM-pressur' e assetnum = asset.assetnum e siteid =
asset.siteid) e existe (seleccionar assetnum de assetmeter onde metername = 'O-pressur' e assetnum = asset.assetnum e
siteid = asset.siteid) e existe (seleccionar assetnum de assetmeter onde metername = 'pressão' e assetnum =
asset.assetnum e siteid = asset.siteid)

Em seguida, selecionar a ação para esta escalada - o nome da ação é o mesmo que o nome do ponto de
lançamento [a menos que você tinha modificado na etapa 1 do assistente]. Depois de ativar a escalada nosso
trabalho é feito - a escalada executa a ação de script para todos os Ativos com os 3 metros e as leituras do medidor
de ativos modificados são salvos e comprometido pelo quadro escalada. Uma coisa importante a notar aqui é se
você tinha escolhido para não prender a ação para um objeto de Maximo - a etapa 2 do assistente [variáveis e
ligações] não vai deixar você vincular uma variável para um atributo Mbo. No entanto, pode utilizar a, propriedade
literal sistema e maxvar tipos de ligação variáveis. Um caso de uso para que possam surgir quando você escrever
uma Ação genérico que dizer invoca um serviço [como um serviço Web] que
não é específico para um Mbo ou você pretende fazer o código de script com base no uso direto dos apis MBO
e, portanto, não vai precisar as ligações de atributos MBO.

Pontos condição de inicialização

Nós todos sabemos sobre as condições Maximo que são [com base no analisador javacc] usados em fluxos de trabalho,
condicional Uis etc. Um aspecto condições personalizadas permite que você escreva-se uma condição usando o código Java
no caso a condição é complicada o suficiente para ser codificado utilizando o javacc condição gramática base. Este ponto
de partida permite-lhe evitar que codificação Java e permite que você anexar uma condição script para estes componentes
Maximo [Workflows / Condicional UIs].

Vamos dar um exemplo para compreendê-lo melhor. O caso de uso é para adicionar uma condição para o fluxo de
trabalho que iria mudar o status de ativos de não está pronto para operar, se o activo tenha total de peças
sobressalentes quantidade como maior que 10 e o fornecedor de ativos não é nulo.

Como antes que iria lançar o assistente para o ponto condição de lançamento da aplicação Autoscript
[Lista Tab → suspensa ações → Criar → Criar Script com a Condição Personalizado Lançamento Ponto] e,
como outro este é também um processo de 3 etapas.

Passo 1 está é claro que define o ponto de lançamento. Como podemos ver este é um script totalmente novo.
Passo 2 será definir e ligam-se as variáveis. Este script irá envolver 2 variáveis conforme listado abaixo Nome
da variável
tipo de variável Obrigatório

vend NO fornecedor

qtys NO sparepart.quantity *
Passo 3 seria definir o script. O script seria parecido como abaixo se vend não é nenhum

e qtys não é nenhum e soma (qtys)> 10:


evalresult = true

Este evalresult como explicado anteriormente é uma variável implícita que transporta o resultado boolean da
avaliação condição. Sua pré-definido e está sempre lá para pontos condição de lançamento.

No final do processo de assistente quando nos submetemos o projeto - seria criar um script com a lógica
acima. Mas o trabalho ainda não está feito como temos agora para anexar o script com a condição real que,
infelizmente, ainda é um processo manual. Os passos estão listados abaixo:

1. criar um nó condição no designer de fluxo de trabalho.


2. Defina o título do nó condição para <scriptname>: <launchpointname> onde nome do script e o
nome do ponto de lançamento apontaria para o par ponto de lançamento roteiro + recém-criado.

3. fazer subir às propriedades do nó condição de diálogo [como mostrado abaixo no


screen shot] para definir o tipo de condição como de costume e definir o costume classe Java para
com.ibm.tivoli.maximo.script.ScriptCustomCondition que é o predefinido
proxy para as condições script.
4. Guardar e ativar o fluxo de trabalho.

Uma coisa a notar aqui é o valor do campo título. Este valor é mapeado para atributo do título a WFNODE Mbo que
tem um limite de 10 caracteres. E como você pode ver que o título está mantendo um ponteiro para o par ponto de
lançamento de script anexando o nome do script e o nome do ponto de lançamento com o “:” como separador.
Cada um nome do script e nome do ponto de lançamento pode ser de 20 caracteres [fora da definição da caixa].
Então nós temos um problema de comprimento aqui e neste momento não há muito que possamos fazer além de
manter os nomes do ponto de roteiro e lançamento limitado a 4 caracteres no máximo. Além disso, se o script tem
um e apenas ponto de partida podemos simplesmente omitir o nome do ponto de lançamento do título e apenas
fazer com o nome do script. Se todos estes fizeram você se perguntar por que foi feito desta forma ao invés de
manter uma entrada na tabela de WFNODE para o nome do script e o nome do ponto de lançamento, a resposta é
muito simples - nós apenas não queria modificar quaisquer artefatos Maximo existentes. A condição no exemplo foi
trivial e destina-se a demonstrar o aspecto “como fazer condições personalizadas usando scripts”. Como você deve
ter descoberto - podemos aproveitar todos os poderes de scripting neste ponto de lançamento e fazer todas as
avaliações complicados necessários para sair com o resultado boolean [evalresult] para a avaliação.

Activar e desactivar scripts de

Os scripts podem ser activados ou desactivados a partir do separador launchpoint da aplicação de scripting. Um script que
está desactivado não será invocado pelo Maximo. Por exemplo, se um ponto de Lançamento Atributo é desativado - o
roteiro para que launchpoint não será chamado quando dizem que o valor do que as mudanças de atributos MBO. Esta é
uma ferramenta muito útil para depuração quando você tiver algum problema com o comportamento do aplicativo e quer
tomar o script fora da equação temporariamente apenas para testar a aplicação de baunilha desprovido de toda a
personalização. Uma coisa a notar aqui é o valor do atributo de status Autoscript não tem significado a respeito de como o
quadro scripting vai [ou não] invocar o script. Então um script no projecto
Estado é tratado da mesma como um script no estado “Ativo”.

Scripts de depuração

Por padrão todos os logs relacionados roteiro é feito através do logger Autoscript. Cada script pode ser
configurado em diferentes níveis de log - DEBUG, INFO, o erro etc. A configuração padrão para qualquer script
está no erro que pode ser alterado de aplicação para a gestão ou no momento da criação [no 2 nd passo do
assistente]. Se fosse apenas para depurar o script abaixo

y = float (iplr) + float (ROL) se y


= float (plr)!
pnr = str (y)

Nós podemos colocar algumas instruções de depuração como print

“iplr =” + iplr print “ROL =” + ROL y = float (iplr) + float (ROL) print “y

=” + y, se y = float (plr)!

PNR = str (y) print “PNR


=” + PNR

Em seguida, precisamos ter certeza de que o nível de registro para o logger Autoscript está definido para o nível de log do
script. Por exemplo definir os dois para INFO. Isto irá resultar nas demonstrações de impressão para aparecer no seu log
SystemOut. Se necessário, as demonstrações de log produzidos por este logger pode ser redirecionado para um arquivo de
log dedicado segurando apenas as declarações de registo relacionadas com script. Note que a sintaxe da instrução de
impressão depende o idioma que o roteiro está sendo escrito com. Além disso, se o logger 'Autoscript' está definido para
nível erro registra apenas, em seguida, as instruções de impressão dentro do script de automação não será escrito no
arquivo de log. Os logs quadro scripting cobrir carregamento roteiro, inicialização, tempo de execução e assim por diante.
Para ver os valores que está sendo passada recebido por variáveis de script, defina o logger Autoscript para 'DEBUG', aplicar
as configurações de log e executar a configuração script. valores de variáveis devem ser a saída para o console arquivo de
log ou sistema. Como regra geral, podemos definir o logger Autoscript a INFO durante script de tempo de desenvolvimento
/ depuração e nível de INFO também que vai empurrar o script declarações de impressão específicas do arquivo de log log
definidos roteiros inidvidual. Abaixo está a lista de informações de log gerado automaticamente no nível de depuração do
quadro scripting.
nome do ponto 1. Inicie eo nome do script que está prestes a ser executado
2. Script tempo de execução (como o tempo decorrido entre o início e fim de roteiro
execução)
3. Nome da aplicação, registradas no nome de uso, nome MBO, MBO única ID
valores sempre injetado como dados implícitos para o script - autor script pode ou não pode usá-los

4. Valores variável passada para o script com base em ligações variáveis


(Variáveis que são provenientes de atributo MBO, MAXVAR, propriedade do sistema ou literal)

Para redirecionar seus registros de script para um arquivo de log separado siga os passos abaixo.

1. Ir para aplicativo Logging.


2. Clique em Gerenciar appenders a partir do menu Selecionar Ação.
3. Clique em Nova linha na caixa de diálogo Gerenciar appenders popup.
4. Preencha os detalhes como:

• Appender = ScriptingOnly [ou qualquer nome apropriado que você escolher]


• Appender classe de implementação = psdi.util.logging.MXFileAppender [você pode selecionar isso a partir da
lista de valores]
• File Name = autoscript.log [ou qualquer nome de arquivo apropriado que você escolher]
• Aceite todos os outros padrões.
5. Salve o novo appender clicando em OK.
6. Localize logger 'Autoscript' na seção Madeireiros raiz do aplicativo.
7. Clique no ícone Gerenciar appenders à direita do campo appenders na seção Detalhes para
logger 'Autoscript'.
8. Selecione apenas o appender criado anteriormente (ScriptingOnly), e de-selecionar qualquer outro
appender anteriormente associado a este logger.
9. Clique em OK para salvar a nova associação. A partir do menu Selecionar ação, clique em 'Aplicar' para que as
configurações de registro tenham efeito.