Transaction Notification¶

Meccanismo lato server, separato sia da UI API che da DI API — permette di intercettare (e potenzialmente bloccare) una transazione prima che venga scritta nel database, indipendentemente da come è stata generata (form SAP, DI API, un altro add-on, un'integrazione esterna).

Perché serve¶

Se la tua validazione vive solo nella UI API (es. blocchi il salvataggio con un controllo su ItemEvent), quella validazione si applica solo se il documento viene creato passando dalla UI che hai istrumentato. Se qualcun altro crea lo stesso documento via DI API o import diretto, il tuo controllo UI non scatta mai. Il Transaction Notification invece agisce a livello di database, quindi copre tutti i canali.

Come funziona concettualmente¶

sequenceDiagram
    autonumber
    actor Sorgente as Client UI / DI API / Import
    participant SAP as SAP Core Engine
    participant TN as SBO_SP_TransactionNotification
    participant DB as Database Aziendale

    Sorgente->>SAP: Creazione o modifica documento (A / U / D)
    SAP->>TN: Invoca procedura (object_type, transaction_type, key)
    alt Validazione Superata (@error = 0)
        TN-->>SAP: Esito OK (@error = 0)
        SAP->>DB: COMMIT transazione
        SAP-->>Sorgente: Documento salvato con successo
    else Validazione Fallita (@error > 0)
        TN-->>SAP: Segnala errore (@error, @error_message)
        SAP->>DB: ROLLBACK transazione
        SAP-->>Sorgente: Blocco operazione e messaggio d'errore
    end

SAP chiama una stored procedure (tipicamente chiamata SBO_SP_TransactionNotification) ogni volta che sta per confermare (COMMIT) una transazione su determinate tabelle.
La stored procedure riceve parametri come tipo di oggetto, numero documento, tipo di transazione (Add/Update/Delete/Cancel).
Se la stored procedure restituisce un errore, SAP annulla la transazione e mostra un messaggio all'utente — a prescindere da dove sia partita l'operazione.

Esempio concettuale (T-SQL, non C#)¶

ALTER PROCEDURE [dbo].[SBO_SP_TransactionNotification]
    @object_type NVARCHAR(20),
    @transaction_type NCHAR(1),
    @num_of_cols_in_key INT,
    @list_of_key_cols_tab_del NVARCHAR(255),
    @list_of_cols_val_tab_del NVARCHAR(255)
AS
BEGIN
    DECLARE @error INT
    DECLARE @error_message NVARCHAR(200)

    IF @object_type = '17' AND @transaction_type IN ('A', 'U') -- Es. Ordine di Vendita
    BEGIN
        -- Logica di validazione custom qui
        -- Se qualcosa non va:
        -- SET @error = 1
        -- SET @error_message = 'Validazione fallita: motivo'
    END

    IF @error > 0
    BEGIN
        SELECT @error, @error_message
    END
END

Relazione con l'add-on C¶

Il Transaction Notification non è scritto in C# — è T-SQL lato database. Ma un add-on può comunque avere bisogno di sapere che questo meccanismo esiste, perché:

Spiega perché certe validazioni "a prova di bomba" non possono vivere solo nella UI API.
Un add-on può ricevere feedback dall'utente su un errore che in realtà proviene dal Transaction Notification, non dal proprio codice — utile saperlo per non perdere tempo a debuggare nel posto sbagliato.

Differenza riassuntiva con UI/DI API¶

	UI API	DI API	Transaction Notification
Dove gira	Client (thread SAP)	Client/server (.NET)	Database (T-SQL)
Cosa intercetta	Interazioni utente su schermo	Operazioni programmatiche sui documenti	Ogni transazione DB, da qualunque fonte
Può bloccare il salvataggio?	Sì, ma solo se l'operazione passa da lì	No (è lei stessa a generare l'operazione)	Sì, sempre, a prescindere dalla fonte