Intégrer une App

Une App s’intègre comme une requête enregistrée ou un dashboard — via le Web Component <saiku-embed> — mais comme une seule unité portée par un jeton. Un unique jeton accorde l’App entière : sa navigation et toutes ses pages voyagent sur cette seule concession, et l’invité la parcourt en lecture seule, en changeant de page sur place.

Le balisage

Mettez kind="app" et pointez path vers le document .saikuapp :

<saiku-embed
  server="https://YOUR-WORKSPACE.saiku.bi"
  token="tx-..."
  kind="app"
  path="homes/admin/sales-portal.saikuapp"
  height="800px"
></saiku-embed>

Tout le reste du composant — méthodes d’installation, événements, theming via les variables --saiku-embed-*, les wrappers React et Vue — fonctionne exactement comme documenté sur la page Intégrer Saiku. Une intégration d’App est purement présentationnelle par-dessus le chemin de requête d’intégration existant ; elle n’ajoute aucune mécanique nouvelle côté hôte.

Émettre un jeton d’App

Émettez un jeton d’App comme un jeton de dashboard, mais avec resourceKind: "app" et un chemin .saikuapp :

curl -X POST 'https://YOUR-WORKSPACE.saiku.bi/rest/saiku/api/embed/tokens' \
  -u admin:admin \
  -H 'Content-Type: application/json' \
  -d '{
    "resourceKind": "app",
    "resourcePath": "homes/admin/sales-portal.saikuapp",
    "ttlHours": 72,
    "label": "Customer sales portal"
  }'

Celui qui émet doit avoir un accès en lecture à l’App. Le jeton épingle exactement une App : le rejouer contre n’importe quelle autre ressource renvoie le même EMBED_INVALID opaque — un jeton pour l’App A ne peut lire ni l’App B ni aucun autre chemin du dépôt.

Sécurité : RLS et PII sont appliqués côté serveur

Les tuiles de chaque page exécutent la même requête gardée par tuile qu’utilise une intégration de dashboard. Le corps de la requête est récupéré côté serveur depuis le document d’App épinglé — jamais depuis le client — donc :

Les filtres de sécurité au niveau des lignes portés par le jeton sont appliqués en dernier et échouent en fermeture : s’ils ne peuvent pas être greffés dans la requête d’une tuile, la tuile part en erreur plutôt que de laisser fuir des lignes non filtrées.
Le caviardage des PII reste actif : si une colonne référencée est annotée PII, le jeton est élevé au caviardage forcé au moment de l’émission, comme pour un dashboard. L’inspecteur résout chaque hiérarchie et mesure référencée face aux annotations saiku.semantic.pii du cube, et échoue en fermeture — s’il n’arrive pas du tout à résoudre la ressource, il refuse la concession plutôt que de supposer la ressource propre. La ligne d’audit distingue les deux cas (« annotated columns » vs « unresolvable resource ») pour qu’une concession refusée puisse être diagnostiquée.
Un filter surchargé côté client ne peut que restreindre la requête d’une tuile, jamais l’élargir.

Tuiles de plugin dans une App intégrée

Si une page d’App contient une tuile de plugin, le plugin est servi porté par le jeton : l’invité peut charger exactement les plugins référencés par l’App intégrée et rien d’autre. Le même bac à sable et le même confinement CSP s’appliquent à l’intérieur de l’intégration.

Liens connexes

Intégrer Saiku — la référence complète de <saiku-embed> : jetons, événements, theming, concessions publiques, React / Vue.
Vue d’ensemble d’App Builder — construire l’App que vous intégrez.
Plugins — le modèle de confinement des tuiles à JS en bac à sable.