Boreon MCP Layer · Migrazioni
La maggior parte delle nostre migrazioni porta Tableau Server su Tableau Cloud, a prezzi fissi, perché per la maggior parte dei team Tableau è casa. Spostiamo anche un sito Tableau Cloud in un altro, ricostruiamo in Tableau le dashboard AI/BI di Databricks, portiamo i contenuti Tableau anche su Databricks, Snowflake o Tableau Next, ogni volta che li vuole anche lì, e trasferiamo in Tableau Next le dashboard di Salesforce CRM e di CRM Analytics. Ogni spostamento è pianificato con lei, provato prima e confrontato con l'originale.
Da Tableau ServerDa qui parte la maggior parte dei team
Per la maggior parte dei team Tableau è casa. Spostiamo tutto il suo sito Tableau Server su Tableau Cloud a prezzi fissi: contenuti ed estrazioni, persone e autorizzazioni, pianificazioni e sottoscrizioni.
Veda come funziona
Da Tableau Cloud
Sposti i contenuti da un sito Tableau Cloud a un altro, o li promuova da sviluppo a test a produzione, anche tra progetti dello stesso sito. Un nuovo passaggio porta solo ciò che è cambiato dall'ultimo.
Veda come funziona
Da Databricks
Una dashboard AI/BI di Databricks diventa una cartella di lavoro Tableau con la sua dashboard, che legge le stesse tabelle in tempo reale tramite un'origine dati Tableau pubblicata.
Veda come funziona
Da Tableau Server o Tableau Cloud
Le dashboard diventano dashboard AI/BI con Genie integrato. I flussi Prep diventano viste materializzate.
Veda come funziona
Da Tableau Server o Tableau Cloud
Le dashboard diventano app Streamlit in Snowflake. I flussi Prep diventano tabelle dinamiche.
Veda come funziona
Da Tableau Server o Tableau Cloud
I fogli di lavoro Tableau, i report di Salesforce CRM e i widget di CRM Analytics diventano visualizzazioni Tableau Next, e le loro dashboard diventano dashboard Tableau Next, dentro Salesforce.
Veda come funziona
La maggior parte delle nostre migrazioni è questa. Leggiamo tutto il suo sito Tableau Server, pianifichiamo lo spostamento con lei e lo proviamo per intero senza scrivere nulla. Parte solo quando lei approva; poi rileggiamo entrambi i siti e li confrontiamo, e lei riceve un report per il suo registro delle modifiche.
Leggiamo il suo sito
Ogni progetto, cartella di lavoro, origine dati e pianificazione, prima di spostare qualsiasi cosa.
Lei legge il piano
Cosa si sposta, dove arriva e cosa richiede il suo intervento.
Lo proviamo
Una prova generale completa che non scrive nulla.
Lei approva
Lo spostamento parte solo quando lo dice lei.
Confrontiamo i due siti
Riletti e verificati, con un report per i suoi archivi.
Spostiamo i contenuti da un sito Tableau Cloud a un altro, o li promuoviamo da sviluppo a test a produzione, con lo stesso piano, la stessa prova e la stessa approvazione. Ogni vista viene confrontata con l'originale, e un nuovo passaggio porta solo ciò che è cambiato dall'ultimo.
Alcuni team vogliono portare il lavoro fatto in Databricks davanti alle persone che vivono in Tableau. Una dashboard AI/BI diventa una cartella di lavoro Tableau con la sua dashboard, che legge le stesse tabelle in tempo reale tramite un'origine dati Tableau pubblicata. Ogni foglio viene confrontato con l'originale prima di poter essere pubblicato, e la pubblicazione avviene solo con l'approvazione di un amministratore dalla sua parte.
| Su Databricks | In Tableau |
|---|---|
| Una dashboard AI/BI | Una cartella di lavoro Tableau con la sua dashboard |
| Widget contatore, a barre, a linee, ad area, a torta, a dispersione e tabella | Fogli Tableau, ciascuno confrontato con l'originale |
| Caselle di testo e layout a griglia | Gli stessi, sulla dashboard |
| Le tabelle della dashboard | Un'origine dati Tableau pubblicata, letta in tempo reale |
Se vuole dashboard anche su Databricks o Snowflake, ecco dove finisce ogni elemento.
| Su Tableau | Su Databricks | Su Snowflake |
|---|---|---|
| Dashboard | Dashboard AI/BI, con Genie integrato | App Streamlit in Snowflake |
| Flussi Prep (.tfl) | Viste materializzate | Tabelle dinamiche, oppure una vista materializzata dove Snowflake lo consente |
| Origini dati pubblicate (.tds) | Le tabelle Unity Catalog in cui risiedono già i dati | Le tabelle Snowflake in cui risiedono già i dati |
| Misure, colori e formati numerici | Identici, fino agli assi doppi | Identici, fino a indicatori e ordinamento |
| Filtri | Gli stessi filtri, sulla dashboard | Selettori interattivi nell'app |
| Accesso e ruoli | Ruoli SSO propagati, senza un secondo accesso | Coppia di chiavi, OAuth, oppure ogni persona tramite Snowflake OAuth |
Un workbook e il flusso Prep che lo alimenta migrano insieme. Prima si costruisce e si verifica la tabella o la vista, poi vi si ricostruisce sopra la dashboard. Non si pubblica nulla finché ogni foglio non torna.
I piani cambiano, e a volte cambia anche il warehouse. Il Boreon MCP Layer sposta tabelle, viste e SQL da Databricks a Snowflake, o da Snowflake a Databricks, e riscrive l'SQL per l'altro dialetto strada facendo. Poi lo stesso layer semantico copre entrambi i warehouse, e le sue persone continuano a fare le loro domande come hanno sempre fatto.
Databricks Tabelle, viste e SQL Snowflake
Cominci da lì. Mettiamo il layer sopra e rispondiamo alle sue domande in linguaggio naturale, e se un giorno la vorrà anche su un'altra piattaforma, ogni numero viene prima verificato rispetto a Tableau.