Di seguito è riportato un elenco di eventi nel sistema che forzano il ricalcolo nel motore:
È possibile aggiungere i dati non elaborati e i dati intermedi dopo l'ora effettiva in cui si sono verificati. Un esempio è il caso in cui alcune origini evento non erano attive e non hanno ricevuto i dati. Una volta aggiunti i nuovi dati, il motore esegue il ricalcolo a partire dal valore di data/ora dell'evento aggiunto. Ad esempio, il valore del dollaro è stato immesso alla fine del mese. I calcoli dell'intero mese erano basati sul valore del dollaro in quel periodo. Quando il motore torna all'inizio del mese, esegue il ricalcolo utilizzando il nuovo valore.
I dati possono essere corretti anche dopo che sono stati calcolati. Le correzioni sostituiscono i dati non elaborati.
Nota: questa situazione non è applicabile ai dati intermedi, in cui non è possibile aggiungere correzioni.
Quando viene aggiunta una correzione, il motore deve trovare uno stato prima dell'avvenuta modifica. Il motore quindi avvia il ricalcolo delle metriche con i nuovi dati corretti inclusi nel calcolo da quel periodo.
Ad esempio, se un utente ha immesso per errore il numero 5 come ultima settimana dei dati non elaborati. L'utente sostituisce 5 con 3. Il motore deve eseguire il ricalcolo dalla data in cui è stato inserito 5. Il numero 3 viene utilizzato al posto di 5.
NOTA: una correzione può consistere nell'eliminazione dei dati non corretti, senza sostituzione con nuovi dati.
Gli eventi vengono ricevuti in base alla registrazione a:
Quando una risorsa viene modificata, il motore esegue il ricalcolo a partire dal punto in cui è avvenuta la modifica della risorsa. Ad esempio, questo ricalcolo si verifica quando viene assegnata o rimossa una risorsa da un gruppo di risorse o si modifica il valore di un attributo personalizzato di risorsa.
Nel caso in cui un elenco di server presenta un'indicazione continua sul proprio stato, il server 3 è stato messo fuori servizio per manutenzione. Il server 3 è stato rimosso senza una notifica di sistema. L'utente informa il sistema che il server 3 è inesistente durante il periodo di manutenzione. Il motore torna indietro ed esegue il ricalcolo dalla data in cui il server 3 è stato rimosso.
Quando viene eseguita una modifica nell'attributo personalizzato di una risorsa, il motore esegue il ricalcolo di tutte le metriche associate alla risorsa. Le metriche vengono ricalcolate a partire dalla data in cui è stato modificato l'attributo personalizzato.
Ad esempio, considerare uno scenario in cui i server si trovano a Napoli, Roma e Milano. L'utente decide di includere i server di Roma nel gruppo di Napoli. Il responsabile decide quindi che i server di Roma sono di fatto parte del gruppo di Napoli e cambia lo stato dei server di Roma. Il motore deve ora eseguire il ricalcolo.
È possibile creare eccezioni per periodi di tempo definiti. Ad esempio, è presente un periodo di tempo definito come interno all'orario lavorativo normale, ma si verifica un'eccezione a causa di un blackout. Questa eccezione rimuove l'intervallo di tempo specificato dal normale orario lavorativo. Gli eventi sono ancora gestiti, anche se adesso sono considerati al di fuori del periodo di applicazione. Una volta che tale orario viene differenziato dalla normale routine, è possibile definire il comportamento al di fuori del periodo di applicazione nello script di business logic. Tuttavia, l'utente non può ancora definire il comportamento del motore durante il periodo dell'eccezione. Il comportamento non può essere modificato rispetto al comportamento standard esterno al periodo di applicazione. È possibile definire le eccezioni che precedono o seguono l'effettivo periodo di tempo. Quando viene aggiunta un'eccezione a un periodo di tempo che è stato calcolato dal motore, il ricalcolo viene eseguito in modo tale da prendere in considerazione l'eccezione.
Ad esempio, è presente un caso in cui è stata notificata un'interruzione di alimentazione una settimana fa. Il sistema esegue i calcoli fino all'ora presente, senza prendere in considerazione l'interruzione di alimentazione. In questo caso è necessario eseguire il ricalcolo.
È possibile creare la business logic definita dall'utente in ciascuna metrica separata. Inoltre, se la logica è centrale e deve essere riutilizzata, è possibile inserirla all'interno di un modulo di business logic. Questo consente all'utente di creare la logica una sola volta e di utilizzarla in più metriche. Tuttavia, quando il modulo viene modificato per correggere un errore nella logica, tutte le metriche associate al modulo modificato vengono interessate. Le metriche devono eseguire un nuovo calcolo per prendere in considerazione la correzione.
Ad esempio, un utente dispone di più client e tutti richiedono una metrica di assistenza tecnica. È possibile inserire la logica relativa all'assistenza tecnica in un modulo di business logic.
La riutilizzabilità degli eventi è una funzionalità che consente di creare metriche che utilizzano come input i risultati del calcolo di altre metriche. I dati di questo tipo sono noti come dati intermedi. Questi dati vengono creati impostando una metrica per l'invio di eventi in una struttura simile a quella dei dati non elaborati. La metrica di destinazione, quindi, esegue la registrazione alla metrica di origine e riceve gli eventi inviati nello stesso modo in cui una metrica riceve gli eventi di dati non elaborati. Se la metrica di invio esegue il ricalcolo, deve eliminare gli eventi precedentemente inviati ed eseguire il ricalcolo del periodo di tempo per il quale tale ricalcolo è richiesto. Ciò significa che i dati intermedi inviati precedentemente non sono più aggiornati. È necessario che le metriche registrate per la ricezione di questi dati eseguano il ricalcolo per prendere in considerazione i nuovi dati.
Durante la creazione di una versione del contratto, alcune o tutte le metriche contenute vengono ricalcolate dall'inizio della versione del contratto. Il ricalcolo viene eseguito solo per le metriche che presentano modifiche rispetto alla versione precedente. Non si riceve alcun ricalcolo se viene creata una versione del contratto e quindi confermata direttamente. Nessun ricalcolo si verifica perché le metriche contengono modifiche.
Di seguito sono elencati i casi in cui non viene eseguito il ricalcolo:
Una nuova versione del contratto viene considerata un calcolo, non un ricalcolo, pertanto non viene visualizzata nella cronologia di ricalcolo.
Ad esempio, supponiamo che esista un contratto triennale con la società ABC. È possibile estendere il contratto per un ulteriore anno. Con questa modifica viene creata una nuova versione del contratto. ACE1 eseguirà il ricalcolo delle metriche a partire dal 1° gennaio 2005.
Nessuna modifica viene apportata se si dispone di un contratto con 100 metriche e viene creata una versione con la modifica del parametro di UNA delle metriche. Per le altre metriche il ricalcolo non viene eseguito.
Nota: se vengono apportate modifiche nel periodo remoto, viene eseguito un ricalcolo lungo. Il ricalcolo richiede molto tempo, in quanto le metriche interessate devono eseguire il ricalcolo dall'ora della modifica.
|
Copyright © 2013 CA.
Tutti i diritti riservati.
|
|