Guida all'implementazione › Implementazione › Implementazione di business logic (esperto di business logic) › All'interno della business logic › Flusso di eventi

Flusso di eventi

Come descritto in precedenza, gli input per la business logic sono gli eventi del motore e gli eventi di dati non elaborati.

Gli eventi di dati non elaborati ricevuti dalla business logic vengono determinati dalla funzione di registrazione in cui il codice richiede un insieme specifico di eventi di dati non elaborati definiti in base agli identificatori Tipo di evento e Risorsa.

Nella business logic, la registrazione associa inoltre una subroutine definita dall'utente che viene eseguita per gestire l'evento di dati non elaborati una volta ricevuto. (Per impostazione predefinita, è necessario rinominare OnXXXEvent con un nome più significativo.)

Gli eventi del motore vengono generati dal motore in base alle definizioni di contratto e metrica associate. Una volta generato e ricevuto l'evento del motore, il motore esegue il gestore eventi pertinente. Ciascun evento del motore ha un gestore eventi implicito. Questi gestori di evento corrispondono a funzioni e procedure definite nella parte superiore del VBScript. Sono obbligatori il gestore eventi che gestisce la registrazione e la funzione Result per l'implementazione nel codice. Tutti gli altri gestori eventi sono facoltativi. Tuttavia, la business logic non elabora gli eventi del motore per cui non sono implementati i gestori eventi. Pertanto, è consigliabile mantenerli, anche se non vengono utilizzati, per consentire miglioramenti futuri.

Nota: durante la scrittura dello script di business logic è importante implementare tutti gli eventi del motore per comprendere tutte le possibilità finali. Ad esempio, anche se durante la prima fase di implementazione la definizione di un periodo di applicazione non era valida, ma lo sarà in futuro, tutte le formule richiederanno la rettifica. Si consiglia pertanto all'esperto di business logic di definire in anticipo il comportamento nel periodo di applicazione e fuori il periodo di applicazione, anche se inizialmente non è applicabile, in modo che quando il comportamento è introdotto, le necessarie modifiche al sistema sono banali.

Di seguito sono riportati diversi eventi del motore e i relativi gestori eventi:

• OnLoad (Time): facoltativo, invocato una sola volta all'inizio dei calcoli quando il contratto è in fase di attivazione. Può essere utilizzato per inizializzare le variabili globali.
• OnRegistration (Dispatcher): obbligatorio, procedura per richiedere i relativi eventi di dati non elaborati e associarli alle procedure di gestione definite dall'utente. Gli eventi vengono invocati e associati alle procedure utilizzando i metodi dell'oggetto Dispatcher.
  OnRegistration viene invocato una volta dal motore di calcolo all'inizio del calcolo della metrica e ogni volta che una risorsa registrata per la metrica entra in vigore, cosicché il motore valuta il gruppo di modifiche apportate a tale risorsa che possono influenzare l'insieme di eventi trasmessi per la formula. Il motore presenta la definizione della richiesta dell'evento definita in base agli identificatori Tipo di evento e Risorse e nel caso in cui una risorsa (o gruppo di modifiche che contiene più risorse) cambia qualcosa legato a questo insieme. Una volta diventata effettiva, viene attivato un gestore eventi OnRegistration.
• OnPeriodStart (Time): facoltativo, invocato all'inizio del periodo di tempo dell'agente (impostato in base all'unità di tempo). Il primo OnPeriodStart viene attivato una volta che il contratto è diventato effettivo, quando il saldo dei periodi inizia con unità di tempo di un'ora intera. Questo gestore eventi viene in genere utilizzato per inizializzare periodicamente le variabili, ad esempio un contatore che contiene il numero di incidenti aperti entro il periodo di calcolo che deve essere quindi inizializzato a zero all'inizio di ogni periodo.
• OnPeriodEnd (Time,IsCompleteRecord): facoltativo, invocato alla fine del periodo di tempo dell'agente (impostato in base all'unità di tempo). È sempre invocato alla fine arrotondata dell'unità di tempo in ore intere (ad esempio, 24:00). IsCompleteRecord è true quando il periodo della metrica è terminato (in base al tempo reale del server applicazioni) ed è false quando si effettua un calcolo intermedio. Questo gestore eventi viene in genere utilizzato per i calcoli finali del periodo terminale in modo da preparare il terreno per il risultato finale che verrà fornito dalla funzione Result.
• OnTimeslotEnter (Time): facoltativo, invocato durante l'ingresso in un periodo di applicazione basato sulla definizione della metrica associata. Ad esempio, se la metrica è associata a una definizione del periodo di applicazione negli orari di ufficio, in cui ogni giorno alle 8:00 inizia il periodo di applicazione, quindi questo gestore eventi verrà attivato a tale ora ogni giorno.
• OnTimeSlotExit (Time): facoltativo, invocato durante l'uscita da un periodo di applicazione basato sulla definizione della metrica associata. Ad esempio, se la metrica è associata a una definizione del periodo di applicazione negli orari di ufficio, in cui termina ogni giorno alle 17:00, quindi questo gestore eventi verrà attivato a tale ora ogni giorno.
• Target(): facoltativo, invocato quando la metrica è specificata con una destinazione dinamica. Consente di determinare la destinazione del livello di servizio di una metrica durante l'esecuzione della business logic. Tali destinazioni possono includere il consumo dei componenti del servizio o le modifiche dell'infrastruttura. Presenta quattro valori, come la funzione Result, uno per ciascuna modalità. Questa funzione viene eseguita dopo la funzione Result durante la normale esecuzione.
• Forecast(): facoltativo, invocato una sola volta durante l'esecuzione di una conferma della versione di contratto; il motore di calcolo calcola il contratto una sola volta in modalità di previsione. La modalità di previsione esegue un ciclo completo del motore di calcolo nel contratto (dalla data di inizio e alla data di fine della versione del contratto). Lo scopo di questo ciclo è esclusivamente il calcolo dei valori di previsione. (Non viene eseguito alcun calcolo nella tabella T_RAW_DATA). Questa funzione viene invocata al posto della funzione Result durante questa modalità di esecuzione.
• Result(): obbligatorio, invocato dal motore di calcolo per ottenere il risultato del calcolo per un determinato periodo. La funzione Result viene invocata sempre dopo il gestore eventi OnPeriodEnd.

Di seguito sono riportati i passaggi del meccanismo di calcolo (servizio PslWriter) per l'elaborazione di una singola formula di business logic:

• PslWriter carica la formula in memoria ed esegue ogni istruzione presente nella sezione delle dichiarazioni (la sezione delle dichiarazioni corrisponde a tutto il codice all'esterno di una funzione o subroutine). Nota: inoltre, tutti i moduli e le librerie associati sono inclusi e compilati in questo modulo di codice singolo per l'esecuzione.
• PslWriter richiede il gestore eventi OnLoad.
• PslWriter richiede il gestore eventi OnRegistration.
• Il calcolo del periodo inizia con l'invocazione di OnPeriodStart.
• Per ogni evento di dati non elaborati registrato durante OnRegistration che rientra nell'intervallo di tempo del periodo, PslWriter invoca il gestore eventi definito dall'utente associato a tale evento.
• Se l'inizio o la fine del periodo di applicazione rientra in un intervallo di tempo del periodo, verrà invocato OnTimeslotEnter oppure OnTimeslotExit.
• Se è presente una modifica dell'infrastruttura pertinente entro l'intervallo di tempo del periodo, verrà invocato OnRegistration.
• Il calcolo del periodo termina con l'invocazione di OnPeriodEnd.
• Se è stata specificata una destinazione dinamica, verrà invocata questa funzione.
• PslWriter invoca la funzione Result per ottenere il risultato finale del periodo di calcolo.

  Nota: quando la versione del contratto viene prima confermata ed è stata selezionata una previsione, viene invocata la funzione Forecast invece della funzione Result. Tuttavia, questo caso si verifica solo una volta per ogni versione.

Durante ogni ciclo di calcolo, il motore valuta su cosa gli eventi del motore e gli eventi di dati non elaborati pertinenti si basano al momento del calcolo. Innanzitutto li ordina in base all'ora e in seguito li invia alle formule pertinenti per il calcolo. L'ora dell'evento di dati non elaborati corrisponde alla relativa data/ora, mentre l'ora dell'evento del motore corrisponde all'ora di attivazione. Entrambi i tipi di evento vengono quindi combinati in una sequenza temporale e inviati per il calcolo.

Gli intervalli degli eventi sono in base alla metrica locale associata, ma il parametro Time dei gestori eventi (es. OnPeriodStart (Time)) e la data/ora dell'evento di dati non elaborati è in base al valore di ora UTC. Il motore li confronta in base ai relativi valori di ora UTC, in modo da utilizzare un punto di riferimento costante.

Esempio:

Se la differenza di fuso orario di una metrica rispetto all'ora UTC è di due ore (ad esempio, GMT+2) e la data/ora in cui un evento ha aperto un incidente è alle ore 10:00, all'interno del motore l'ora utilizzata dal gestore eventi viene spostata di conseguenza e in realtà inizia alle ore 8:00 UTC. Supponendo che l'adapter è configurata per l'utilizzo di questo stesso fuso orario, quindi gli eventi di dati non elaborati verranno spostati indietro di 2 ore UTC anche nel database. Se gli eventi vengono trasferiti alla business logic, l'agente di calcolo responsabile del calcolo degli eventi per il periodo che inizia alle 10:00 utilizzerà effettivamente l'ora UTC per gli eventi, che diventa le 8:00 da quel momento in poi. Tuttavia, se si utilizza il messaggio out.log nel codice per stampare la data/ora, verrà mostrata la data/ora spostata all'ora UTC, quindi le 8:00, nonostante il periodo specificato (in base alla metrica) sia alle 10:00.

Nei requisiti di calcolo seguenti è importante convertire la data/ora dell'evento prima di utilizzarlo:

Se la metrica deve calcolare il numero di eventi chiusi nello stesso giorno in cui sono stati aperti, quindi è necessario confrontare l'ora di apertura e chiusura di ogni incidente. Se l'ora di apertura e di chiusura di un incidente sono comprese nello stesso giorno (e all'interno di un periodo di applicazione definito), l'incidente verrà contato.

Durante il processo di spostamento l'incidente all'ora UTC dall'ora locale originale, è possibile che il giorno cambi (ad esempio utilizzando GMT+2). Un incidente aperto alle ore 1:00, verrà spostato indietro alle ore 23:00 del giorno precedente in base all'ora UTC. Quindi, non verrà conteggiato anche se dovrebbe esserlo. Questa è una situazione in cui l'ora deve essere prima convertita in base all'ora locale della metrica e quindi confrontata. In questo caso, utilizzare il metodo GetLocaleTime(utcTime). Questo metodo converte una data ora specificata in un fuso orario UTC nel fuso orario della metrica locale.

Di seguito è riportato il codice del gestore eventi:
Sub OnIncidentEvent(eventDetails)
   If dateDiff("d",Tools.GetLocaleTime(eventDetails.time),_
     Tools.GetLocaleTime(eventDetails("ClosedAt)))=0 then
          CountIncidents=CountIncidents+1
   End If
End Sub