# Esempio di adattatore per il sistema di licenze del commerciante

Questo esempio Python 3.10+ implementa il bridge HTTP esterno di Launch con persistenza di eventi/nonce in SQLite e un worker di ripristino. **Non** genera licenze, non convalida le funzionalità protette e non sostituisce il sistema di licenze dell'utente.

Implementare un modulo Python con questi hook:

```python
def apply_snapshot(snapshot):
    # Call your licensing system with snapshot["event_id"] as its durable
    # idempotency key. Apply desired_state and the absolute purchased dates.
    # Return only after confirming the original operation was applied.
    # Raise ValueError for a result requiring manual review.
    ...

def delivery(snapshot):
    # Read an existing result owned by this purchase; do not issue here.
    return {"type": "instructions", "value": "Your own delivery instructions", "expires_at": None}
```

Sostituire `...` con un'integrazione reale prima di configurare un backend. Se non viene configurato un modulo backend, gli hook inclusi sollevano `NotImplementedError`; gli eventi passano alla revisione manuale e non dichiarano mai che sia stata rilasciata un'autorizzazione. Il worker dell'esempio può riprovare un hook dopo un arresto anomalo o un errore dall'esito incerto; il backend delle licenze deve quindi eseguire la deduplicazione o il ripristino usando lo stesso ID evento.

Configurare l'adattatore tramite variabili d'ambiente, tenendo la chiave fuori dal controllo di versione e dalla cronologia della shell:

- `CUSTOM_LICENSING_KEY`: codifica Base64 standard di 32–128 byte casuali, corrispondente a quella configurata in Launch.
- `CUSTOM_LICENSING_KEY_ID`: `key-1` oppure l'identificativo della chiave configurato.
- `CUSTOM_LICENSING_CONNECTION_REF`: riferimento della connessione corrispondente.
- `CUSTOM_LICENSING_ENVIRONMENT`: `sandbox` oppure `live`.
- `CUSTOM_LICENSING_DATABASE`: percorso SQLite privato e scrivibile, esterno alla directory di lavoro del repository; conservarlo tra i riavvii.
- `CUSTOM_LICENSING_BACKEND`: modulo importabile che implementa gli hook indicati sopra.
- `CUSTOM_LICENSING_PORT`: porta di ascolto locale, predefinita `18883`.

Eseguire `python server.py`. Per i test locali in sandbox, configurare `http://127.0.0.1:18883` in Launch e abilitare esplicitamente l'eccezione HTTP per il loopback. In produzione, usare la terminazione HTTPS, la supervisione dei processi, backup protetti del database e le verifiche dell'SDK/runtime del proprio backend. Dichiarare soltanto i tipi di acquisto/consegna effettivamente supportati dal backend e adattare `capabilities` di conseguenza.

Dopo aver risolto un problema del backend, `python server.py --retry-event ORIGINAL_EVENT_UUID` rimette localmente in coda lo stesso payload salvato. Nella pagina delle attività di autorizzazione di Launch, riprovare anche l'evento originale. Non cambiare gli ID e non aggiungere nuovamente tempo per recuperare una risposta.

L'esempio è un punto di partenza e non costituisce una certificazione di idoneità alla produzione. Il lease del worker dura 60 secondi: limitare le chiamate agli hook con un timeout più breve oppure rinnovare il lease. Prima di accettare acquisti live, aggiungere monitoraggio, procedure di rotazione, controlli più rigorosi delle regole applicative e dello schema, nonché i controlli operativi della propria distribuzione. La [guida all'integrazione](/it/launch-documents/external-licensing/) e l'[OpenAPI](/it/assets/launch/external-licensing-openapi.json) definiscono il protocollo. Non usare mai una risposta di stato di Launch come permesso di eseguire codice protetto.