La classe Log implementa il pattern di progettazione factory, descritto al paragrafo 5.1.1. Questo ci ha permesso di riutilizzare lo stesso codice di base per gestire i diversi tipi di log.
La classe Log implementa diversi handler, gli oggetti derivati dalla classe astratta di base, tra i quali:
console: invia i log direttamente alla console di sistema.
display: stampa i log direttamente sul browser.
error_log: invia i log alle funzione error_log() di PHP.
file: stampa i log su file.
mail: aggrega i log di un’unica sessione e li invia a uno specifico indirizzo email tramite la funzione mail() di PHP.
syslog: invia i log a un servizio di logging come il syslog di Unix o l’Event Log di Win-dows, utilizzando la funzione syslog() di PHP.
win: invia i log in una finestra browser separata.
mysql: salva i log in un database MySQL.
Inoltre, la classe implementa dei metodi per “comporre” i diversi handler in uno unico.
Creare un oggetto Log
La classe definisce tre metodi per creare un oggetto Log: 1. metodo factory;
2. metodo singleton; 3. direct instantiation.
Il metodo factory, come suggerisce il nome, implementa il Factory Pattern. Esso fornisce un metodo parametrizzato per la costruzione di istanze concrete di oggetti Log. Il primo parametro, infatti, determina lo specifico handler da creare. Gli altri parametri dipendono dall’handler che si vuole creare. Per esempio il seguente codice realizza un Log che stampa su file:
$file = Log::factory('file', 'out.log', 'TEST');
Il metodo singleton implementa il Singleton Pattern. Il Singleton Pattern assicura che nello stesso momento esista un unico tipo e configurazione di oggetto Log. Ciò ha due benefici: il primo è che previene la duplicazione di diverse istanze di Log; il secondo è che tutto il codice ha accesso alla stessa istanza di Log. La sua costruzione è del tutto analoga alla precedente:
$file = Log::singleton('file', 'out.log', 'TEST');
È infine possibile instanziare direttamente i diversi handler usando i loro costruttori. Tuttavia que-sto metodo è sconsigliato proprio perché vanificherebbe i vantaggi dell’utilizzare i diversi design pattern e creerebbe un accoppiamento più stretto del necessario tra l’applicazione e il pacchetto di Log usato.
112
Configurare l’handler
La configurazione degli handler è determinata dagli argomenti passati nel costruttore. Di seguito è data una breve descrizione dei vari parametri:
Parametro Tipo Descrizione
$handler Stringa Il tipo di Log da costruire.
$name Stringa
Il nome della risorsa di log su cui registrare l’evento. L’utilizzo di que-sto parametro dipende dalla specifica implementazione dell’handler. Il valore di default è la stringa vuota.
$ident Stringa
Una stringa identificativa dello specifico handler. Questo valore è impostato di default a stringa vuota, e può essere modificato in run-time usando il metodo setIdent().
$conf Array Array associativo di coppie (chiave, valore) utilizzate dalle impostazio-ni specifiche dell’handler.
$level Integer Sono loggati solamente i messaggi fino al livello (incluso) indicato da questo parametro. Il valore di default include tutti i livelli.
I livelli di log sono gli stessi elencati come priorità alla sezione 7.1.1, ma utilizzano una nomenclatu-ra diversa: Priorità Nome log_emerg PEAR_LOG_EMERG log_alert PEAR_LOG_ALERT log_crit PEAR_LOG_CRIT log_err PEAR_LOG_ERR log_warning PEAR_LOG_WARNING log_notice PEAR_LOG_NOTICE log_info PEAR_LOG_INFO log_debug PEAR_LOG_DEBUG
La motivazione dietro questa nomenclatura è dovuta all’uso di costanti definite dalla classe Log: define('PEAR_LOG_EMERG', 0); /* System is unusable */
define('PEAR_LOG_ALERT', 1); /* Immediate action required */
define('PEAR_LOG_CRIT', 2); /* Critical conditions */
define('PEAR_LOG_ERR', 3); /* Error conditions */
define('PEAR_LOG_WARNING', 4); /* Warning conditions */
define('PEAR_LOG_NOTICE', 5); /* Normal but significant */
define('PEAR_LOG_INFO', 6); /* Informational */
define('PEAR_LOG_DEBUG', 7); /* Debug-level messages */
Registrare un evento
Gli eventi vengono registrati utilizzando il metodo log():
$logger->log('Message', PEAR_LOG_NOTICE);
Il primo argomento riceve il messaggio da salvare. Anche se il messaggio viene sempre salvato come stringa, esso può ricevere anche oggetti. Se l’oggetto implementa un metodo toString() o analogo,
log() utilizza quel metodo per rappresentare l’oggetto, altrimenti viene utilizzata la versione serializ-zata dello stesso. Il secondo parametro, opzionale, determina il livello di priorità del messaggio. Il valore di default è impostato a PEAR_LOG_INFO.
113
7.2.1 L’handler mysql
L’handler mysql si connette a una specifica configurazione di database, grazie al file di configurazio-ne descritto al paragrafo 6.3.1. Il costruttore utilizza il parametro $name per determinare il nome della tabella su cui salvare i record. Il metodo log() non fa nient’altro che inserire un nuovo record alla tabella log_table.
Per quanto riguarda invece l’audit trail, si è preferito fare uso di un metodo diverso per la registra-zione dei record. Come abbiamo visto, infatti, l’audit trail necessita di un gran numero di informa-zioni strutturate, che vanno inserite in maniera logica nel database. Per tale motivo è stato realizzato il metodo auditRecord($event, $partic, $source, $object = null). Tale funzione riceve quat-tro array in argomento che fanno riferimento rispettivamente all’evento che ha generato l’audit, i partecipanti attivi, la sorgente dell’evento e gli eventuali oggetti coinvolti. Ogni array è indicizzato con i nomi dei parametri indicati dal profilo IHE (vedi tabella 4.3.1), alcuni dei quali sono obbliga-tori e altri opzionali. Il metodo controlla automaticamente l’assenza dei campi obbligaobbliga-tori e solleva un’eccezione se ne mancano uno o più. In più, gli array $partic e $object, rappresentando elemen-ti mulelemen-tivalore, possono essere anche mulelemen-ti-dimensionali (per ogni partecipante atelemen-tivo od oggetto coinvolto è presente una riga diversa nell’array). La struttura degli array è quindi assimilabile alle seguenti tabelle:
$event
EventID EventActionCode EventDateTime …
#1 Valore Valore Valore …
$partic
UserID AlternativeUserID Username …
#1 Valore Valore Valore …
#2 Valore Valore Valore …
… … … … …
$source
AuditEnterpriseSiteID AuditSourceID AuditSourceTypeCode
#1 Valore Valore Valore
$object
Part..TypeCode Part..TypeCodeRole Part.DataLifeCycle …
#1 Valore Valore Valore …
#2 Valore Valore Valore …
… … … … …
Dopo aver eseguito tutti i controlli necessari, inizia la scrittura del file XML, secondo lo schema previsto. La scrittura utilizza la classe per documenti HTML e XML, DOMDocument, fornita dalle librerie PHP. Ogni XML adotta come filename, il timestamp dell’evento che lo ha generato, per evitare sovrascritture accidentali tra audit diversi.
Il metodo auditRecord() è anche responsabile di chiamare un altro metodo, auditStore(), che ha lo scopo di salvare nel database l’evento di audit.
114
Il metodo auditStore($event, $partic, $source, $object), riceve in ingresso gli stessi parametri del metodo auditRecord(). Ogni singolo valore viene quindi validato prima di essere inserito nel database. L’inserimento crea prima un master record nella tabella log_tables, quindi inserisce i vari elementi che compongono l’evento nelle relative tabelle, utilizzando come chiave esterna proprio l’id del master record appena creato. Se durante la procedura di inserimento, qualcosa va storto, per evitare inconsistenze nelle informazioni, l’intera procedura subisce un rollback che elimina il master record e tutti i suoi sotto-elementi. L’audit così perso è facilmente recuperabile dall’XML e reinseri-bile nel database.