Esempi di calcoli in finestra
Questa sezione contiene alcuni ulteriori esempi dei calcoli in finestra con spiegazioni sul loro funzionamento. Inizialmente viene riportata una versione estesa dell'enunciato sui requisiti e un calcolo modello corrispondente con segnaposti. È possibile utilizzare quanto segue per semplificare la scrittura di calcoli base.
Quando TRIGGER_FIELD su TRIGGER_OBJECT passa a VALUE, modificare la PROPERTY di TARGET a vero/falso.
Il calcolo corrispondente a questo enunciato sui requisiti è:
import System
static def GetAttributeValue(Incident):
PropertyState = false
if TRIGGER_OBJECT.TRIGGER_FIELD != null and TRIGGER_OBJECT.TRIGGER_FIELD._Title == 'VALUE':
PropertyState = true
return String.Format(":SetPROPERTY(TARGET, {0});", PropertyState)La sostituzione dei segnaposti dall'enunciato sui requisiti nel calcolo e l'aggiunta di TRIGGER_FIELD al pannello Dipendenze nell'editor Calcoli fornisce all'utente il calcolo richiesto. Raccomandiamo inoltre di sostituire tutti i riferimenti a "PropertyState" con un nome più descrittivo per la variabile.
Il resto di questa sezione fornisce esempi basati su questo calcolo e ne spiega la logica. Gli esempi successivi ampliano ulteriormente il calcolo.
In questi calcoli i rientri sono molto importanti in quanto stabiliscono l'ambito di applicazione delle funzioni. Pertanto, se si copiano esempi da questo documento, assicurarsi che vengano mantenuti i rientri corretti quando vengono incollati nell'editor di calcolo.
Utilizzo delle istruzioni If per ripristinare i valori
L'esempio seguente amplia l'esempio fornito in Configurazione dei calcoli in finestra in modo che il campo Impatto venga impostato su non obbligatorio e diventi obbligatorio solo se il campo Urgenza viene impostato su Urgente. Se il campo viene cancellato (impostato su null), oppure impostato su un altro valore, allora il campo Impatto viene nuovamente impostato come non obbligatorio.
Il nostro enunciato sui requisiti per questa situazione è:
Quando Urgenza viene impostato su Urgente, SetMandatory di Impatto passa a vero.
Ciò informa che il campo di attivazione è Urgenza, che l'attributo di destinazione è Impatto e che la funzione in finestra è :SetMandatory(,).
Una buona struttura per un calcolo in finestra è la seguente:
- definire una variabile iniziale che specifichi il valore tipico vero o falso per la funzione in finestra
- creare quindi un'istruzione che modifichi la variabile in caso di selezione dei valori appropriati
- restituire infine la funzione in finestra utilizzando la variabile per impostare il relativo parametro vero/falso
Ad esempio:
import System
static def GetAttributeValue(Incident):
MandatoryUrgency = false
if Incident._IncidentUrgency != null and Incident._IncidentUrgency._Title == 'Urgente':
MandatoryUrgency = true
return String.Format(":SetMandatory(_Impact, {0});", MandatoryUrgency)La terza linea, la quarta linea e la linea finale presentano un rientro singolo; la quinta linea presenta un rientro doppio.
La terza linea crea una variabile denominata MandatoryUrgency e imposta il proprio valore su falso. Si tratta del valore predefinito più comune per il calcolo.
La quarta linea effettua un test per verificare se l'Urgenza è stata impostata su Urgente (Incident._IncidentUrgency._Title == 'Urgente'). Notare che prima che il calcolo possa testare il valore dell'attributo Incident._IncidentUrgency._Title, il linguaggio del calcolo richiede di verificare che l'oggetto dell'attributo non sia null (Incident._IncidentUrgency != null).
Se la quarta linea è vera e l'Urgenza non è null, ed è impostata su Urgente, allora viene eseguita la quinta linea, che imposta il valore della variabile MandatoryUrgency su vero.
Infine, viene eseguita la sesta linea, che imposta il valore dell'attributo di calcolo. Dato che stiamo facendo riferimento a una variabile, il linguaggio del calcolo ci richiede di generare la stringa di ritorno utilizzando una funzione String.Format. Essa ha la forma String.Format("function(attribute, {0});", variable) – il valore {0} viene restituito dalla variabile quando viene generata la stringa, per fornirci :SetMandatory(_Impact,MandatoryUrgency);. Per impostazione predefinita, MandatoryUrgency è falso, pertanto il campo Impatto non è obbligatorio. Tuttavia, se l'Urgenza viene impostata su Urgente, allora le condizioni specificate nella quarta linea vengono rispettate e la quinta linea viene eseguita. Ciò imposta quindi la variabile MandatoryUrgency su vero, in modo che il campo Impatto diventi obbligatorio.
Notare che la terza e quinta linea utilizzano un unico segno uguale = mentre la quarta linea utilizza due segni uguale ==.
= significa "rendi questo uguale a", mentre == significa "è uguale?"
Aggiornamento di due campi con un unico calcolo
L'esempio successivo mostra come è possibile aggiornare due campi usando un unico calcolo, mediante un calcolo simile a quello riportato nell'esempio precedente. In questo esempio, i campi Elemento della configurazione e Tipo Elemento della configurazione appaiono solo se la Categoria viene impostata su Hardware.
Il nostro enunciato sui requisiti per questa situazione è:
Quando la Categoria viene impostata su Hardware, SetHidden di Elemento della configurazione E Tipo Elemento della configurazione passeranno a falso.
Ciò informa che il campo di attivazione è Categoria, che gli attributi di destinazione sono Elemento della configurazione E Tipo Elemento della configurazione e che la funzione in finestra è :SetHidden(,).
import System
static def GetAttributeValue(Incident):
HideCI = true
if Incident.Category != null and Incident.Category.FullName == 'Hardware':
HideCI = false
return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});", HideCI, HideCI)La terza, la quarta e la sesta linea presentano un rientro singolo; la quinta linea presenta un rientro doppio. La sesta linea lunga appare come una linea singola nell'editor di calcolo.
La terza linea imposta la variabile HideCI su vero.
La quarta linea verifica che Categoria non sia null e sia impostata su Hardware.
Se la quarta linea è vera, la quinta linea viene eseguita e imposta HideCI su falso.
Infine, viene eseguita la sesta linea, che imposta il valore dell'attributo calcolo su String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});", HideCI, HideCI). Per impostazione predefinita, HideCI è vero, pertanto i campi ConfigurationItemType e ConfigurationItem sono nascosti. Tuttavia, se la Categoria viene impostata su Hardware, allora le condizioni specificate nella quarta linea vengono rispettate e la quinta linea viene eseguita. Ciò a sua volta imposta la variabile HideCI su falso, pertanto i campi ConfigurationItemType e ConfigurationItem diventano visibili.
Quando si utilizza String.Format per restituire più di una funzione che utilizza le variabili, si fa riferimento alle variabili nella funzione come numeri in parentesi graffe, per poi aggiungere successivamente le variabili in ordine. Ad esempio:
String.Format("function(attribute, {0});function(attribute, {1});function(attribute, {2});", variable 0, variable1, variable 2)
:SetHidden mostra e nasconde inoltre l'etichetta associata all'attributo di destinazione. Tuttavia, non è possibile utilizzare :SetHidden per etichette statiche aggiunte dall'albero Controlli in Gestione finestre.
Utilizzo di varie funzioni con un'unica attivazione
Gli esempi precedenti hanno sempre restituito una sola funzione in finestra: modificando lo stato obbligatorio di uno o più campi o modificando lo stato nascosto. Questo esempio mostra come è possibile aggiornare due funzioni diverse usando un unico calcolo. Questo esempio amplia il precedente, con i campi Elemento della configurazione e Tipo Elemento della configurazione visualizzati se la Categoria viene impostata su Hardware, ma anche con il Tipo Elemento della configurazione reso obbligatorio.
Il nostro enunciato sui requisiti per questa situazione è:
Quando la Categoria viene impostata su Hardware, SetHidden di Elemento della configurazione E Tipo Elemento della configurazione passano a falso E SetMandatory di Tipo Elemento della configurazione passa a vero.
Ciò informa che il campo di attivazione è Categoria, che gli attributi di destinazione sono Elemento della configurazione e Tipo Elemento della configurazione e che le funzioni in finestra sono :SetHidden(,) e SetMandatory(,).
import System
static def GetAttributeValue(Incident):
HideCI = true
MandatoryCI = false
if Incident.Category != null and Incident.Category.FullName == 'Hardware':
HideCI = false
MandatoryCI = true
return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});:SetMandatory(ConfigurationItemType,{2});", HideCI, HideCI, MandatoryCI)La terza, la quarta, la quinta e l'ottava linea presentano un rientro singolo; la sesta e la settima linea presentano un rientro doppio. L'ottava linea lunga appare come una linea singola nell'editor di calcolo.
La terza linea imposta la variabile HideCI su vero – per impostazione predefinita desideriamo mantenere nascosti i campi CI e Tipo CI.
La quarta linea imposta la variabile MandatoryCI su falso – per impostazione predefinita desideriamo mantenere il campo Tipo CI come non obbligatorio.
Se la quinta linea è vera, sia la sesta che la settima linea vengono eseguite e impostano HideCI su falso e MandatoryCI su vero. Entrambe queste linee sono in esecuzione, dato che presentano lo stesso rientro nel calcolo.
Infine, viene eseguita l'ottava linea lunga, trasferendo il valore di HideCI alle prime due funzioni, mentre il valore di MandatoryCI passa alla terza funzione.
Dato che si sta inviando la stessa variabile alle prime due funzioni, si potrebbe riscrivere l'ottava linea nel modo seguente
return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{0});:SetMandatory(ConfigurationItemType,{1});", HideCI, MandatoryCI)
Utilizzo di funzioni diverse in base ai valori di un'attivazione
Questo esempio mostra come è possibile utilizzare una funzione diversa in base al valore selezionato nell'attributo di attivazione. Se la Priorità viene impostata su Alta, allora il campo Motivo diventa obbligatorio e modificabile; se la Priorità viene impostata su Bassa, allora il campo Motivo diventa non obbligatorio e di sola lettura; altrimenti, il campo Motivo rimane nel proprio stato predefinito.
Questo calcolo richiede un attributo con il Nome impostato su _reason da aggiungere all'oggetto Incident.
Il nostro enunciato sui requisiti per questa situazione è:
Quando la Priorità viene impostata su Alta, SetMandatory di Motivo passa a vero E SetReadOnly di Motivo passa a falso; quando la Priorità viene impostata su Bassa, SetReadOnly di Motivo passa a vero E SetMandatory di Motivo passa a falso.
Ciò informa che il campo di attivazione è Priorità, che l'attributo di destinazione è Motivo e che le funzioni in finestra sono :SetMandatory(,) e SetReadOnly(,). Potremmo inoltre scrivere:
In tutti gli altri momenti, sia SetMandatory sia SetReadOnly di Motivo hanno il valore falso.
Ciò informa che il valore predefinito per SetMandatory e SetReadOnly di Motivo è falso.
import System
static def GetAttributeValue(Incident):
MandatoryReason = false
ReadOnlyReason = false
if Incident.Priority != null and Incident.Priority.Title == 'Alta':
MandatoryReason = true
elif Incident.Priority != null and Incident.Priority.Title == 'Bassa':
ReadOnlyReason = true
return String.Format(":SetMandatory(_reason, {0});:SetReadOnly(_reason, {1});", MandatoryReason, ReadOnlyReason)La terza, la quarta, la quinta, la settima e la nona linea presentano un rientro singolo; la sesta e l'ottava linea presentano un rientro doppio. La nona linea lunga appare come una linea singola nell'editor di calcolo.
La terza linea imposta la variabile MandatoryReason su falso – per impostazione predefinita desideriamo mantenere il campo Motivo come non obbligatorio.
La quarta linea imposta la variabile ReadOnlyReason su falso – per impostazione predefinita desideriamo mantenere il campo Motivo come di sola lettura.
Se la quinta linea è vera e il campo Priorità è impostato su Alta, allora la sesta linea viene eseguita e imposta MandatoryReason su vero.
Se la quinta linea NON è vera, allora viene eseguita la settima linea. Le linee elif ("else if") vengono eseguite solo se la linea precedente risulta vera. Se questa linea è vera e il campo Priorità è impostato su Bassa, allora l'ottava linea viene eseguita e imposta ReadOnlyReason su vero.
Infine, la nona linea viene eseguita usando i valori impostati di MandatoryReason e ReadOnlyReason.
Ciò significa che, per impostazione predefinita, MandatoryReason e ReadOnlyReason presentano il valore falso, pertanto il campo Motivo non è né obbligatorio né di sola lettura. Tuttavia, se la Priorità viene impostata su Alta, allora MandatoryReason è vero (quinta e sesta linea), mentre ReadOnlyReason è ancora falso, pertanto Motivo è obbligatorio ma non di sola lettura. Se la Priorità viene impostata su Bassa, allora ReadOnlyReason è vero (settima e ottava linea), mentre MandatoryReason è falso, pertanto Motivo è obbligatorio ma non di sola lettura.
Utilizzo delle date nei calcoli
Questo esempio rende il campo Motivo obbligatorio se la data selezionata nel campo Data richiesta è impostata entro sette giorni dalla data corrente.
Questo calcolo richiede attributi con il relativo Nome impostato su _reason e _daterequired da aggiungere all'oggetto Incident. Ricordarsi di non aggiornare lo stesso campo con calcoli diversi.
Il nostro enunciato sui requisiti per questa situazione è:
Quando la Data richiesta è impostata entro 7 giorni da oggi, SetMandatory di Motivo passa a vero.
Ciò informa che il campo di attivazione è Data richiesta, che l'attributo di destinazione è Motivo e che la funzione in finestra è :SetMandatory(,).
import System
static def GetAttributeValue(Incident):
MandatoryReason = false
if Incident._daterequired != null and Incident._daterequired < DateTime.Today.AddDays(7):
MandatoryReason = true
return String.Format(":SetMandatory(_reason,{0});", MandatoryReason)La terza linea, la quarta linea e la linea finale presentano un rientro singolo; la quinta linea presenta un rientro doppio.
La terza linea crea una variabile definita MandatoryReason e la imposta su falso – per impostazione predefinita desideriamo mantenere il campo Motivo come non obbligatorio.
La quarta linea utilizza un metodo .Net denominato .AddDays per determinare se la Data richiesta è inferiore alla data odierna più 7 giorni. Se lo è, allora la quinta linea viene eseguita e imposta MandatoryReason su vero.
La sesta linea genera quindi la funzione SetMandatory appropriata.
Per ulteriori informazioni sull'utilizzo dei metodi .Net nei propri calcoli, consultare il sito Web della comunità Ivanti.