Application Jobs: catalogo, template e runtime

Il modello operativo degli Application Jobs ABAP, dalla classe corrente agli artefatti trasportabili e all'istanza schedulata.

Riferimento tecnicoAggiornato il 3 settembre 20266 min di lettura

In breve

Un Application Job nasce dall’incontro di quattro entità, non da una singola chiamata di scheduling. La classe contiene il lavoro; il catalog entry descrive come esporlo; il template propone valori iniziali; l’istanza runtime registra una pianificazione concreta. Separare questi livelli evita due errori: trattare i default come regole immutabili e confondere un artefatto trasportato con un’esecuzione riuscita. Per nuovi sviluppi SAP raccomanda IF_APJ_RT_RUN; le precedenti IF_APJ_DT_EXEC_OBJECT e IF_APJ_RT_EXEC_OBJECT sono interfacce legacy (Implementing the Business Logic).

Quattro entità, due tempi

Entità	Momento	Responsabilità
Classe `IF_APJ_RT_RUN`	Design time	Espone parametri pubblici ed esegue la logica
Catalog entry	Design time	Collega la classe e configura la selection screen
Template	Design time	Riferisce il catalogo e fornisce valori iniziali
Job	Runtime	Fissa orario, parametri effettivi, stato e chiave

Catalog entry e template sono repository object assegnati a package e trasporto; si creano e modificano normalmente con gli editor ADT. Il job è invece un’istanza operativa. La sua identità è la coppia jobname e jobcount, da conservare per status, cancellazione e riconciliazione (Working with Application Job Objects).

Con IF_APJ_RT_RUN, gli attributi pubblici compatibili sono candidati che il catalog entry può selezionare come parametri della selection screen. Il framework valorizza prima di EXECUTE soltanto quelli esposti. I default possono stare nella dichiarazione, nel costruttore oppure in IF_APJ_DT_DEFAULTS; il template può poi sovrascriverli. Non sono quindi un confine di autorizzazione o validazione.

Un esecutore corrente

Il seguente scheletro mostra soltanto il contratto tra parametri e logica. Il servizio applicativo chiamato è un segnaposto da sostituire con codice del dominio.

CLASS zcl_demo_recon_job DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_apj_rt_run.
    DATA dry_run     TYPE abap_bool VALUE abap_true.
    DATA cutoff_date TYPE d.
ENDCLASS.

CLASS zcl_demo_recon_job IMPLEMENTATION.
  METHOD if_apj_rt_run~execute.
    zcl_demo_reconciliation=>run(
      dry_run     = dry_run
      cutoff_date = cutoff_date ).
  ENDMETHOD.
ENDCLASS.

La versione corrente consente agli editor del catalogo di organizzare i parametri in gruppi e sezioni, abilitarli in funzione di altri campi e limitarne il comportamento. Sono possibilità che il vecchio contratto basato su GET_PARAMETERS non offre (Creating an ABAP Class with IF_APJ_RT_RUN).

Scheduling, chiave e stato

CL_APJ_RT_API programma un template esistente e usa la coppia jobname e jobcount per interrogare lo stato. Un client che deve riconciliare i retry genera prima la chiave con GENERATE_JOBKEY e la passa a SCHEDULE_JOB: così, dopo un timeout, può verificarla senza creare alla cieca una seconda pianificazione. Parametri passati all’API sostituiscono quelli del template per quella esecuzione (Maintaining Application Jobs Using an API).

Per codice eseguito dentro un RAP business object, la documentazione avverte di non usare l’avvio immediato: il percorso sottostante effettua un commit implicito. Una pianificazione a timestamp rende il confine più esplicito, ma timezone, calendario e ricorrenza restano parte del contratto. Le periodicità dovrebbero usare le costanti leggibili di CL_APJ_RT_API, non codici ricostruiti a memoria (Periodic Application Jobs).

Cancellare non significa sempre la stessa cosa

CANCEL_JOB interrompe un job in esecuzione; se non è ancora partito, lo elimina. Su un job periodico elimina l’intera catena. Questa semantica richiede una conferma applicativa prima di cancellare una serie. Inoltre, stato tecnico e risultato di dominio non coincidono: un job completato può aver scartato record o prodotto avvisi. Un Business Application Log correlato conserva l’evidenza consultabile dalla vista del job.

Limiti

IF_APJ_RT_RUN, editor e opzioni di scheduling dipendono dalla release e dalla modalità di estensibilità; non vanno trasferiti automaticamente a sistemi on-premise precedenti. Il framework è pensato per lavori lunghi o ricorrenti, non per invocazioni brevi ad alta frequenza (Application Jobs). Servono autorizzazioni applicative, catalogo e template attivi, una strategia di idempotenza e gestione esplicita degli errori. Lo scheletro non è un job pronto: non implementa validazione, logging, concorrenza né recupero da esecuzioni parziali.