Integrazioni governate dei Portali
Questa guida raccoglie le funzioni che richiedono una configurazione condivisa nel Progetto: package firmati, componenti trusted, BPMN, Power BI, Qlik e target remoti. I valori sensibili sono gestiti dagli amministratori e non devono mai essere copiati nei widget o nei file del Portale.
Esportare e importare un Portale
Esporta crea un package firmato della bozza con file e informazioni di integrità. Importa verifica il package, ne mostra provenienza e contenuto e crea un nuovo Portale nel Progetto scelto: non sovrascrive quello aperto.
Un package che contiene codice trusted deve essere firmato da una chiave riconosciuta dall'installazione. Se la verifica fallisce o un file è stato alterato, l'import viene interrotto prima della creazione.
Catalogo componenti e codice trusted
Per condividere un componente custom, selezionarlo e usare Invia al catalogo. Viene creata una versione firmata In revisione. Un Reviewer diverso dall'autore deve approvarla; dal catalogo del Progetto è poi possibile usare Importa e aggiungi.
I componenti sandboxed rimangono isolati. Un componente trusted viene accettato soltanto se versione e contenuto coincidono con il package approvato e il target HTTPS dedicato consente esplicitamente il codice trusted. Modificare i file dopo l'import provoca un errore di drift: inviare e approvare una nuova versione.
Diagramma BPMN
Il widget Diagramma BPMN mostra soltanto una versione deployata e read-only. La tendina include i BPMN accessibili del Progetto; la release conserva la versione scelta. Il Portale non concede nuovi permessi: se il lettore non può più accedere al BPMN, il widget mostra una diagnostica.
Power BI
Secure URL usa la sessione Microsoft del lettore e può quindi mostrare la login. App owns data usa invece un binding del Progetto e un token breve generato da Sybot. Il Project Owner configura profilo, binding, report ed endpoint tramite Gestisci profili e report e usa Diagnostica prima della Preview. Sono ammessi più profili per tenant o identità diverse.
Qlik
Secure URL mantiene l'iframe e l'autenticazione interattiva. OAuth
impersonation usa qlik-embed e un binding governato:
- un amministratore rende disponibile il Client Secret nel Credential Vault;
- il Project Owner crea e diagnostica un profilo con tenant, Client ID e mapping dell'identità;
- crea un binding con App ID e sceglie app, foglio o grafico;
- crea e diagnostica l'endpoint Authoring e quelli richiesti per i target;
- seleziona il binding nel widget e verifica Preview.
Il secret non viene inserito nel Portale. Allowed origins, autorizzazioni Qlik, licenza e Section Access devono essere verificati sul dominio pubblicato.
Target locale e Agent remoto
Un target Locale usa il runtime della stessa installazione. Un target Agent remoto richiede che l'amministratore abbia installato e collegato un Agent/BFF compatibile sulla destinazione. L'Owner seleziona il tipo di target, l'indirizzo pubblico e la credenziale Agent resa disponibile.
Dopo Deploy, un target remoto può restare In attesa dell'Agent mentre la destinazione verifica e attiva la release. La versione precedente resta attiva in caso di errore o Agent offline. Non ripetere il deploy: attendere la riconciliazione o comunicare la diagnostica all'amministratore.
Prima di pubblicare, diagnosticare tutti gli endpoint Power BI e Qlik usati dalla release. Una configurazione modificata dopo la build può richiedere una nuova release.