Business Application Log: persistenza e confini LUW

Come modellare, salvare e rileggere log applicativi ABAP senza confondere diagnostica, transazione e retention.

Riferimento tecnicoAggiornato il 3 settembre 20266 min di lettura

In breve

Il Business Application Log non è una semplice destinazione per stringhe. Un log appartiene a un oggetto e, facoltativamente, a un suboggetto definiti a design time; possiede un identificatore esterno, un handle stabile e item tipizzati. La decisione più importante arriva al salvataggio: il log può partecipare alla Logical Unit of Work del chiamante oppure essere persistito e committato su una connessione separata. Le API CL_BALI_* rendono esplicita questa scelta; il modulo XCO BAL offre un’astrazione diversa e non va trattato come un alias (Runtime API).

Identità prima del messaggio

L’oggetto repository APLO stabilisce il dominio del log; il suboggetto lo suddivide per processo. L’external_id correla il log a un’esecuzione o documento applicativo, mentre l’handle identifica quella specifica istanza. Header e item hanno responsabilità diverse:

Parte	Contenuto utile	Vincolo operativo
Header	object, subobject, external ID, scadenza, contesto	Va impostato prima di una persistenza utile
Item	message T100, testo libero o eccezione, severity, detail level	Dopo l’aggiunta, la copia nel log non segue ulteriori modifiche al setter
Handle	UUID del log	Permette una rilettura puntuale senza ricerca testuale

La scadenza guida i programmi standard di pulizia. keep_until_expiry impedisce loro di cancellare prima della data, ma non impedisce all’applicazione proprietaria di farlo. External ID, contesto e testi devono contenere soltanto dati necessari: sono superfici diagnostiche, non depositi per segreti o payload completi.

Due persistenze, due esiti

Con CL_BALI_LOG_DB, SAVE_LOG usa la connessione predefinita: il dato diventa definitivo soltanto con il COMMIT WORK della LUW e può scomparire dopo un rollback. SAVE_LOG_2ND_DB_CONNECTION usa invece una service connection e committa subito. È adatto quando la diagnosi deve sopravvivere al fallimento applicativo, ma rompe deliberatamente l’atomicità con i dati di business (Writing Application Logs to the Database).

API	Quando persiste	Effetto di un rollback successivo
`SAVE_LOG`	Al commit della LUW principale	Può annullare anche il log
`SAVE_LOG_2ND_DB_CONNECTION`	Subito, sulla connessione di servizio	Il log resta
XCO BAL `for->memory( )`	Mai nel database	Il log resta solo in memoria
XCO BAL `for->database( )`	A ogni messaggio o eccezione	Ogni aggiunta esegue un commit separato

L’ultimo comportamento appartiene al modulo XCO BAL e al suo modello di persistence/profile; non va combinato implicitamente con il ciclo crea-aggiungi-salva di CL_BALI_* (XCO Business Application Log).

Un log correlato al job

Questo frammento sceglie consapevolmente la seconda connessione affinché la diagnosi sopravviva a un rollback. I nomi sono dimostrativi e l’oggetto APLO deve esistere nel sistema target.

DATA(log) = cl_bali_log=>create_with_header(
  header = cl_bali_header_setter=>create(
    object      = 'ZDEMO_LOG'
    subobject   = 'IMPORT'
    external_id = 'RUN-000042' ) ).

log->add_item( item = cl_bali_free_text_setter=>create(
  severity = if_bali_constants=>c_severity_information
  text     = 'Elaborazione completata' ) ).

cl_bali_log_db=>get_instance( )->save_log_2nd_db_connection(
  log                        = log
  assign_to_current_appl_job = abap_true ).

assign_to_current_appl_job crea il collegamento solo quando il codice gira dentro un application job. Non certifica che il job sia riuscito: rende il log raggiungibile dalla sua vista operativa.

Lettura selettiva e concorrenza

Una ricerca dovrebbe restringere almeno object e subobject, poi aggiungere intervallo temporale e massimo numero di risultati. LOAD_LOGS_VIA_FILTER può caricare soltanto gli header; gli item completi vanno richiesti quando servono. La lettura verifica S_APPL_LOG con attività 03, la cancellazione con attività 06; i log non autorizzati possono essere esclusi dal risultato (Read Application Logs from the Database).

Se più processi aggiornano la stessa istanza, ENQUEUE e DEQUEUE evitano che un salvataggio sovrascriva l’altro. Anche l’header restituito è uno snapshot: dopo nuovi item va richiesto di nuovo per ottenere contatori aggiornati.

Limiti

Disponibilità e stato di rilascio delle API cambiano tra ABAP Platform, SAP BTP ABAP environment e release. Gli esempi non definiscono autorizzazioni, retention o classificazione dei dati per un sistema reale. Le eccezioni con messaggio T100 possono essere convertite internamente in message item. Prima dell’uso occorre quindi verificare firme, oggetto APLO, strategia di commit, lock, volume e accessi nel target.