Admin workspace

Data Studio: notebook voor datasource- en Element-drafts

Data Studio is een tenant- en user-scoped adminroute onder Administration voor gebruikers met datasource-management toegang. Je gebruikt het als notebook om SQL, Python-cellen, Dashbot-prompts, spreadsheetachtige rijen en widget-cellen naast elkaar te onderzoeken. Python-cellen kunnen als begrensde runtime-preview draaien via de bestaande geisoleerde Element runner-grens, maar het runner-proces ontvangt geen user bearer tokens of service credentials. Runs vereisen naast datasource-management dezelfde Element edit/tenant Element authoring approval gate als normale Element-authoring.

Scope Workspace Celtypes Promotie Governance Beperkingen

1. Waarvoor gebruik je Data Studio?

Gebruik Data Studio voor analyse- en bouwvoorbereiding: een SQL-query uitproberen, een Python-Element ontwerpen, een Dashbot-vraag naast de data bewaren, een kleine rijenschets maken of een tussenresultaat visualiseren met dezelfde widgets als dashboards. De notebook zelf is een draft workspace die per tenant/gebruiker wordt opgeslagen onder userData. Je kunt meerdere notebooks openen, bewaren, verwijderen en later opnieuw uitvoeren. Python-celuitvoer is preview/runtime-output; publiceren, productiegebruik en definitieve validatie blijven bij de eigenaar van het doelobject: Datasources, Elements, Autoflow, dashboards, data API's of agent-skills.

Tenant en gebruiker

De werkruimte draait binnen de actieve tenant en gebruikt de rechten van de huidige gebruiker. Je ziet geen datasources buiten je datasource-scope; de adminroute vereist datasource-management toegang.

Draft, geen productie

Notebookdefinities zijn tenant/user-scoped drafts in backend userData. Beschouw een notebook niet als een gepubliceerd of gedeeld productieartefact.

Onderzoek naar hergebruik

Gebruik cellen en secties om een reproduceerbare stap te verzamelen en daarna bewust te promoten naar de juiste Dashview-surface.

2. Notebookworkspace en uitvoerstatus

De Data Studio pagina is opgezet als notebookworkspace: links staat een outline van cellen, in het midden werk je aan de actieve cellen en rechts staat de tenant-scoped schemabrowser. Deze hulpmiddelen veranderen niets aan de rechten; ze maken alleen zichtbaar welke cellen, bronnen en previews je binnen je eigen tenant/user-scope gebruikt.

De outline toont alle cellen met type, status, rijen/runtime en fouten; klik een cel om die direct te focussen.
Elke cel heeft een result status bar met draft/running/ready/stale/error, target engine, runtime, rijtelling, rowsRef en truncation-indicatoren waar beschikbaar.
De schemabrowser zoekt in zichtbare datasources en kolommen. Je kunt tabelnamen, SELECT-snippets en kolommen kopiëren of invoegen in de actieve SQL-cel.
Import en Export werken met notebook-JSON voor deze draft workspace. Controleer na import altijd tenant, bronnen en celverwijzingen.
Cel dupliceren kopieert de definitie van een cel zonder runtime-output, zodat stale of scoped previewdata niet per ongeluk wordt meegenomen.
Promotiepreview toont eerst welk datasource-, Element-, automation-, widget-, data API- of agent-skill-spec voorbereid zou worden voordat je de eigenaarssurface opent.

3. Celtypes

Celtype	Wat werkt	Belangrijke grens
SQL	Voer queries uit tegen geselecteerde tenantdatasources via de bestaande `QueryPreviewService`. De preview gebruikt browser DuckDB of query-engine en kan rowsRef/parquet-backed previewpaden gebruiken. Eerdere notebook-output boven de SQL-cel kan in browser DuckDB worden bevraagd via `rows`, `notebook_rows`, `cell_1`, `rows_1`, `sql_1` of titel-aliassen zoals `rows_draft`.	De query mag alleen bronnen gebruiken waarvoor de gebruiker toegang heeft.
Python runtime preview	Schrijf Python-code en voer de cel uit via de tenant-scoped backend/runtime Element-isolatiegrens. De output is een notebook-preview of runtime-resultaat, geen automatisch gepubliceerd Element. Python-cellen gebruiken bij voorkeur dezelfde vorm als Elements: `def run(params): return ...`. Runtime helpers zoals `getVar()`, `setVar()`, `emitProgress()`, `appendRows()` en `timeBlock()` zijn beschikbaar. Python-runs exporteren een begrensde JSON-veilige `pythonState`, zodat een latere Python-cel variabelen zoals `results` kan gebruiken zonder de eerdere cel opnieuw uit te voeren. Preview-runs volgen hetzelfde default requirements-gedrag als normale Element-publishes.	Data Studio draait code niet rechtstreeks in de browser of in het FastAPI-proces. Runs vereisen ook de Element edit/tenant Element authoring approval gate. In-process datasource query helpers zoals `queryDataSources`, `query_datasources`, `dataSources` en `datasources` falen gesloten voor Data Studio Python-cellen totdat er een veilige out-of-process proxy bestaat.
Dashbot prompt	Stel vragen aan Dashbot via de bestaande streaming endpoint met dezelfde tenant- en usercontext als de rest van Dashbot.	Dashbot mag geen data teruggeven buiten bestaande datasourcepermissies en forced filters.
Rows / spreadsheet draft	Bewaar kleine handmatige rijenschetsen of tabelvormige input naast je SQL en prompts.	Dit is conceptmateriaal. Productiedata of gedeelde output moet via een datasource, Element, automation, dashboard of API worden vastgelegd.
Widget preview	Plaats een echte Dashview widget als notebook-cel om upstream output te visualiseren. Widget-cellen kunnen SQL-, Python- of Rows-output boven de cel gebruiken en renderen met de bestaande table, chart, KPI, timeline en map widgetcomponenten. Kies expliciet de broncel en de velden, of laat de cel de dichtstbijzijnde beschikbare output erboven gebruiken.	Een widget-cel is notebook-previewstate. De widget wordt mee opgeslagen in de notebook, maar is geen gepubliceerd dashboardwidget totdat je hem bewust naar een dashboard of andere owner-surface overzet en daar valideert.

4. Promotie naar Dashview-onderdelen

Promotie betekent dat Data Studio een doelartefact voorbereidt of een draft/spec genereert. De daadwerkelijke publicatie, refresh, test-run of deploy blijft in de eigenaarssurface.

SQL naar datasource

Bereid een SQL-cel voor als reviewed custom datasource draft/spec.
Bewaar expliciete brondatasources, zodat query-engine en parquetrefresh de juiste scope kennen.
Controleer daarna de datasource in Datasources.

Cellen naar Element draft

Zet Python-code, runtime-previewresultaten, SQL-context of notebooksecties om naar een Element-draft.
Promotie maakt een ongepubliceerde Element-draft; publiceer een actieve Element-versie pas in Elements.
Gebruik rowsRef voor grote rij-input in plaats van grote inline payloads.

Specs voor runtime-surfaces

Genereer specs voor een automation node, dashboard widget, data API of agent-skill.
Gebruik widget-cellen om notebookresultaten visueel te toetsen voordat je een dashboardwijziging voorbereidt.
Controleer generated specs in de doelmodule voordat je ze opslaat of activeert.
Data Studio publiceert deze doelen niet automatisch.

Bewijsmateriaal bewaren

Leg SQL, geselecteerde datasources, voorbeeldresultaten en rowsRef/parquet-referenties vast.
Gebruik dit als overdracht naar admins of reviewers die de publicatie uitvoeren.
Houd raw rows beperkt tot wat de gebruiker al mocht zien.

5. Governance en datatoegang

Data Studio is tenant-scoped en user-scoped. Beschrijf het dus niet als een globale of platformbrede notebook.
Gebruik snake_case cell IDs zoals python_test; deze IDs zijn de referenties voor cellen eronder.
Cellen tonen of output beschikbaar is voor volgende cellen. Na openen moet upstream output opnieuw worden uitgevoerd; aangepaste cellen houden hun vorige output als stale preview tot je ze opnieuw runt.
Je kunt cellen herordenen en met Run alle cellen de notebook op volgorde uitvoeren.
Widget-cellen gebruiken de actuele output van een broncel of de dichtstbijzijnde upstream output. Run de broncel opnieuw na wijzigingen en render de widget daarna opnieuw.
Widget-cellen kunnen bestaande widgettypes zoals table, chart, KPI, timeline en map gebruiken, maar blijven notebook-previewstate tot je ze via de dashboard/page tooling opslaat.
Datasourcepermissies, user rights en forced filters blijven leidend voor SQL-previews, source-data handoffs naar Python-cellen, Dashbot-cellen en gegenereerde specs.
Het geisoleerde Python runner-proces ontvangt geen user bearer token en geen service credentials.
Top-level rowsRef wordt aan Python doorgegeven als rowsRef, rows_ref en in params.
Data Studio Python-cellen accepteren Element-style def run(params) of def run(context, params). Oude notebookstijl met result = ... blijft werken voor bestaande concepten.
Python preview-runs volgen hetzelfde default requirements-gedrag als normale Element-publishes.
Geef geselecteerde inline rows of rowsRef/parquet-referenties mee aan Python-cellen voor source-data werk; bestaande services dwingen source access en forced filters af voordat de handoff plaatsvindt.
In-process datasource query helper names, waaronder queryDataSources, query_datasources, dataSources en datasources, falen gesloten voor Data Studio Python-cellen tot er een veilige out-of-process proxy bestaat.
RowsRef/parquet-backed previewpaden zijn de voorkeursroute voor grotere resultaten en bewijs; voorkom onnodig inline kopiëren van raw rows.
Een notebook mag geen raw-data leakage veroorzaken naar gebruikers, Dashbot-prompts, generated specs of Elements buiten bestaande rechten.
Gebruik de doelmodule om definitief te valideren: datasource validatie, Element publish/test, Autoflow test-run of dashboard widget preview.

6. Wat Data Studio niet doet

Geen directe procesruntime

Python-cellen draaien via de bestaande geisoleerde Element runner-grens, niet rechtstreeks in de browser of in het FastAPI-proces, en zonder user bearer tokens of service credentials in de runner.

Geen datasource helper-bypass

In-process datasource query helpers falen gesloten in Data Studio Python-cellen. Gebruik geselecteerde inline rows of rowsRef/parquet-handoffs die al door bestaande services zijn gefilterd.

Geen automatische deploy

Promotie maakt drafts of specs. Publiceren, refreshen, runnen en deployen blijven expliciete stappen in de juiste Dashview-module.

Geen access bypass

Data Studio geeft geen extra datasource-, tenant- of userrechten. Forced filters blijven altijd van kracht.

Timeouts en outputlimieten

Python-runs zijn begrensde previews. Rijen, logs, result, stdout en stderr kunnen worden afgekapt met metadata; gebruik rowsRef/parquet-handoff voor grotere duurzame output.