> For the complete documentation index, see [llms.txt](https://docs.opencityitalia.it/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opencityitalia.it/stanza-del-cittadino/installazione-e-manutenzione/open-city-crawler/gestione-da-tenant-manager.md). # Gestione da Tenant Manager Il Tenant Manager è la fonte di verità della configurazione dei tenant del crawler. Definisce quali siti devono essere scansionati, il tipo di sito e l'eventuale sitemap personalizzata. Il crawler non riceve aggiornamenti dal Tenant Manager in push. Usa invece un approccio *pull-based*. È il crawler che legge periodicamente la configurazione dal Tenant Manager. Questo evita dipendenze runtime bidirezionali. La sincronizzazione avviene manualmente o iin automatico prima di ogni crawl di tenant. Vale sia per i crawl manuali sia per quelli schedulati. In questo modo la configurazione usata dal crawler è sempre aggiornata. {% hint style="info" %} Il crawler legge dal Tenant Manager solo i tenant del proprio ambito. I dati vengono filtrati con `app='9qkaebmp6i7kvf7'` e `environment='prod'`. {% endhint %} ### Cosa viene sincronizzato Per ogni tenant, il crawler legge dal Tenant Manager i campi seguenti. #### Identificativi del tenant * `app_id` — viene usato come slug univoco del tenant nel crawler. * `name` — è il nome mostrato nelle dashboard operative. * `uuid` — è l'identificativo stabile cross-sistema. Serve anche per rilevare i tenant rimossi. #### Configurazione dei siti Il campo `config.sites[]` contiene la lista dei siti da crawlare. Per ogni sito vengono letti questi valori: * `url` — URL radice del sito. * `site_type` — tipo di sito, ad esempio `comune`, `asl`, `museo` o `custom`. * `sitemap_url_override` — se presente, disattiva la discovery automatica della sitemap. L'URL del sito viene normalizzato prima del salvataggio: * tutto in lowercase; * senza trailing slash; * senza query string. #### Frequenza di scansione * `config.default_scan_schedule` — definisce la frequenza di crawl. Il valore predefinito è `daily`. Il Tenant Manager può gestire più applicazioni e più ambienti. Il crawler legge solo i record che appartengono alla propria applicazione e al proprio ambiente. Il filtro applicato è `app='9qkaebmp6i7kvf7'` e `environment='prod'`. ### Come avviene la sincronizzazione La sincronizzazione avviene all'inizio del flow di crawl del tenant. #### Dettaglio delle scritture Per ogni tenant trovato: * se il tenant è nuovo viene creato; * se esiste già viene aggiornato; Se un sito non è più presente nella configurazione del tenant: * il collegamento viene rimosso al tenant; * il sito non viene cancellato dalla lista di siti generale; * se non ha più tenant attivi collegati, viene disabilitato con `enabled=false`. {% hint style="info" %} Se il Tenant Manager non è raggiungibile, il sync restituisce errore ma il crawl prosegue. Il crawler usa la configurazione già presente nel database {% endhint %} #### Tenant manuali I tenant creati manualmente dalla dashboard hanno `source='manual'`. Questi tenant non vengono mai aggiornati né rimossi dal sync del Tenant Manager. Lo stesso vale per le associazioni manuali tra tenant e siti. #### Disabilitazione e storico dati Quando un sito viene rimosso dal Tenant Manager: * l'associazione col tenant viene rimossa; * il sito può essere disabilitato; * le pagine già crawlate non vengono cancellate dal database. Questo approccio conserva lo storico operativo e riduce i rischi in caso di errori temporanei. ### Cosa non viene sincronizzato Il Tenant Manager non sovrascrive tutta la configurazione del crawler. Restano fuori dal sync questi elementi. #### Parametri operativi del crawler Non vengono letti né sovrascritti dal Tenant Manager: * `max_pages`; * `adaptive_crawl_delay`; * override manuali di `robots.txt`; * blocchi pagina; * altre impostazioni operative salvate nel database del crawler. #### Stato runtime Non vengono sincronizzati i dati operativi prodotti dal crawler: * `crawl_status`; * conteggi pagine; * metriche; * risultati e stato delle scansioni. Questi dati appartengono al runtime del crawler, non alla configurazione del tenant. ### Come lanciare una sincronizzazione manuale La sincronizzazione può essere avviata in tre modi. #### 1. Dalla dashboard monitor Usa il pulsante **Sync TM** nella barra superiore. #### 2. Tramite flow di crawl Lancia il flow di crawl per un tenant.. Il sync parte automaticamente come primo step, prima del crawl del tenant. Questa è la modalità normale per i crawl manuali per singolo ente. ### Cron schedulato Il cron giornaliero `scheduled_dispatch` itera su tutti i tenant abilitati presenti nel database. Per ogni tenant lancia il flow `flow_crawl_tenant`. La sincronizzazione col Tenant Manager avviene quindi ogni giorno, prima del crawl di ogni tenant. Se il Tenant Manager non è raggiungibile nel momento del cron, il crawl continua con i dati già presenti nel database. ### Variabili di configurazione | Variabile Windmill | Descrizione | Default | | ----------------------- | ------------------------------- | --------------------------------------------- | | `f/crawler/tm_base_url` | URL base API del Tenant Manager | `https://manager-qa.opencityitalia.it/v1/api` | ### Comportamento in caso di errori Il sync è progettato per essere robusto e conservativo. Se il Tenant Manager non è raggiungibile, il crawler registra un warning e procede con i dati già in database. Nessun dato viene cancellato o modificato. Se un tenant è configurato in modo parziale, ad esempio senza siti, il tenant viene comunque creato o aggiornato. I siti precedenti vengono rimossi dalla pivot. Se si verifica un errore su un singolo tenant, il sync degli altri tenant continua. L'errore viene tracciato nei log e incluso nel risultato finale. Tutte le scritture su database avvengono in una singola transazione. Se la transazione fallisce, nessuna modifica viene salvata. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.opencityitalia.it/stanza-del-cittadino/installazione-e-manutenzione/open-city-crawler/gestione-da-tenant-manager.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.