Color scheme: Light
You are here: start » de » Dokumentation » Datenintegration und Datenzugriff » WKL Database Gateway » Anleitungen » So trennen Sie Berichte und Aktualisierung

So trennen Sie Berichte und Aktualisierung

Eine Controllerin arbeitet in Access mit Lese- und Schreibrechten, analysiert in Excel und Power BI Desktop und hat einen Power-BI-Bericht, der sich jede Nacht selbst aktualisiert. Jeder dieser Wege soll nur bekommen, was er braucht, und einzeln abschaltbar sein.

Lösungsübersicht

Der Dienst kann Excel und Power BI Desktop nicht auseinanderhalten: Beide senden über Power Query dieselbe Kennung (gemessen). Unterscheiden lässt sich aber der Zugang, den Sie jedem Weg geben. Ein Schlüssel je Zweck trennt, was am Programm nicht erkennbar ist.

WegZugangCodeWarum
Access über den ODBC-TreiberWindows-Konto oder persönlicher Schlüssel, Rechte der Personja, von außenDer Treiber fragt den Code im Dialog ab
Excel, Power BI Desktop (interaktiv)eigener Schlüssel „Analyse“: nur lesend, ein Alias, befristet, totpExemptneinPower Query kann keinen Code abfragen; totpExempt ist nur für nur lesende Schlüssel zulässig
Power-BI-Dienst über das lokale Datengateway (geplante Aktualisierung)eigener Schlüssel „Aktualisierung“: nur lesend, nur die Sichten des Berichts, totpExempt, auf das Netz des Datengateways gebundenneinDie Anfragen kommen vom Rechner des Datengateways mit dem dort hinterlegten Zugang, nicht von der betrachtenden Person

Umsetzung

  1. Regel für Berichte mit den Sichten, die Berichte brauchen, nur lesend, und der Person zuordnen; siehe Rechte je Objekt.
  2. Schlüssel „Analyse“ mit issue-key:

    { "person": "Clara Controlling", "label": "Excel/Power BI Analyse", "expiresAt": "2027-03-31T00:00:00Z",
      "readOnly": true, "totpExempt": true, "databases": [ "fachdaten" ], "delivery": "link" }
  3. Schlüssel „Aktualisierung“ für das Datengateway, gebunden an dessen Adresse:

    { "person": "Clara Controlling", "label": "Power BI Aktualisierung", "expiresAt": "2027-03-31T00:00:00Z",
      "readOnly": true, "totpExempt": true, "databases": [ "fachdaten" ], "from": [ "10.1.5.20/32" ], "delivery": "link" }

    Im Power-BI-Dienst tragen Sie ihn bei der Datenquelle des Datengateways als Standard/Basic mit Benutzername pkuser ein.

  4. Für Vorführungen einen Schlüssel auf Abruf ("onDemand": true): Er ruht, bis die Verwaltung ihn für ein paar Stunden freischaltet (activate-key), siehe Schlüssel auf Abruf.
  5. Prüfen: In PersonalKeys zeigt jeder Schlüssel „zuletzt benutzt“ mit Herkunft; der Aktualisierungsschlüssel erscheint nur mit der Adresse des Datengateways. Eine Anfrage mit ihm von anderswo beantwortet der Dienst mit 403 „… gilt nicht für diese Herkunft“.

Ergebnis: Drei Zugänge, je mit eigener Bezeichnung, Laufzeit und Herkunft im Protokoll. Endet die nächtliche Aktualisierung, sperren Sie ihren Schlüssel, ohne Excel oder Access zu berühren.

Hinweise

  • totpExempt befreit nur vom Code, nicht von einer Ablehnung: Eine Regel „nur aus Deutschland“ gilt auch für diese Schlüssel.
  • Die betrachtende Person ist bei der geplanten Aktualisierung unbekannt. Wer im Power-BI-Dienst welchen Bericht sieht, regelt Power BI; der Dienst sieht nur den Zugang des Datengateways.
  • Daten im Bericht bleiben in Power BI und in Excel-Dateien erhalten, auch nach dem Sperren des Schlüssels; die nächste Aktualisierung scheitert dann.

Verwandte Themen

de/wiki/data-conectivity/database-gateway/how-to/separate-reports-from-refresh.txt · Last modified: by Wolfgang van der Stille