Übersicht über die Konnektoren für Canvas-Apps

Daten sind der Kern der meisten Apps, einschließlich der Daten, die Sie in Power Apps erstellen. Daten werden in einer Datenquelle gespeichert, und Sie bringen diese Daten in Ihre App, indem Sie eine Verbindung herstellen. Die Verbindung verwendet einen bestimmten Konnektor, über den mit der Datenquelle kommuniziert wird. Power Apps hat Konnektoren für viele häufig verwendete Dienste und lokale Datenquellen, darunter SharePoint, SQL Server, Office 365, Salesforce und Twitter. Die ersten Schritte zum Hinzufügen von Daten zu einer Canvas-App werden unter Hinzufügen einer Datenverbindung in Power Apps beschrieben.

Ein Connector kann Tabellen mit Daten oder Aktionen bereitstellen. Einige Konnektoren stellen nur Tabellen bereit, andere nur Aktionen und wiederum andere bieten beides. Bei Ihrem Connector kann es sich außerdem um einen standardmäßigen oder einen benutzerdefinierten Connector handeln.

Tabellen

Wenn Ihr Konnektor Tabellen bereitstellt, fügen Sie Ihre Datenquelle hinzu und wählen dann die Tabelle in der Datenquelle aus, die Sie verwalten möchten. Power Apps ruft die Tabellendaten in Ihre App ab und aktualisiert die Daten in Ihrer Datenquelle für Sie automatisch. Sie können z.B. eine Datenquelle hinzufügen, die eine Tabelle namens Lektion enthält, und dann in der Formularleiste die Artikel-Eigenschaft eines Steuerelements, etwa einen Katalog oder ein Formular, auf diesen Wert festlegen:

Sie können die Daten angeben, die von Ihrer App abgerufen werden, indem Sie die Artikel-Eigenschaft des Steuerelements anpassen, das Ihre Daten anzeigt. Als Fortführung des vorherigen Beispiels können Sie die Daten in der Tabelle Lektion sortieren oder filtern, indem Sie diesen Namen als Argument für die Funktionen Suche und SortByColumn verwenden. In dieser Abbildung wird durch die Formel, auf die die Artikel-Eigenschaft festgelegt ist, angegeben, dass die Daten basierend auf dem Text in TextSearchBox1 sortiert und gefiltert werden sollen.

Weitere Informationen zum Anpassen Ihrer Formel mit Tabellen finden Sie in den folgenden Artikeln:

Grundlegendes zu Datenquellen in Power Apps
Generieren einer App aus Excel-Daten
Eine App ganz neu entwerfen
Grundlegendes zu Tabellen und Datensätzen in Power Apps

Aktionen

Wenn Ihr Konnektor Aktionen bereitstellt, müssen Sie trotzdem weiterhin wie oben die Datenquelle auswählen. Sie wählen allerdings als nächsten Schritt keine Tabelle aus, sondern stellen manuell eine Verbindung zwischen einem Steuerelement und einer Aktion her, indem Sie die Artikel-Eigenschaft des Steuerelements bearbeiten, das Ihre Daten anzeigen soll. Die Formel, auf die Sie die Artikel-Eigenschaft festlegen, gibt die Aktion an, die Daten abruft. Die App ruft beispielsweise keine Daten ab, wenn Sie eine Verbindung mit Yammer herstellen und dann die Items-Eigenschaft auf den Namen der Datenquelle festlegen. Um ein Steuerelement mit Daten aufzufüllen, geben Sie eine Aktion an, wie z.B. GetMessagesInGroup(5033622).messages.

Wenn Sie benutzerdefinierte Datenupdates für Aktionsconnectors verarbeiten müssen, erstellen Sie eine Formel, die die Pflaster-Funktion enthält. Geben Sie in der Formel die Aktion und die Felder an, die an die Aktion gebunden werden.

Weitere Informationen zum Anpassen Ihrer Formel für benutzerdefinierte Updates finden Sie in den folgenden Artikeln:

Patch
Collect
Update

Dynamische Schemata sind ein häufiger Ergebnistyp für aktionsbasierte Konnektoren. Dynamisches Schema bezieht sich auf die Möglichkeit, dass dieselbe Aktion eine Tabelle mit unterschiedlichen Spalten zurückgeben kann, je nachdem, wie sie aufgerufen wird. Zu den Bedingungen, die dazu führen können, dass sich die Spalten in der Tabelle unterscheiden, gehören unter anderem die Eingabeparameter, der Benutzende bzw. die Rolle, der bzw. die die Aktion ausführt, und die Gruppe, in welcher der Benutzende arbeitet. Beispielsweise können gespeicherte SQL-Server-Prozeduren unterschiedliche Spalten zurückgeben, wenn sie mit unterschiedlichen Eingaben ausgeführt werden, oder eine Azure DevOps-Instanz kann benutzerdefinierte Felder verwenden, die standardmäßig nicht verfügbar sind.

Einen Überblick über die Arbeit mit dynamischen Schemata in Power Apps finden Sie unter Arbeiten mit nicht typisierten und dynamischen Objekten, ein detailliertes Beispiel unter Von Power Apps aus eine Verbindung mit Azure DevOps herstellen.

Gängige Connectors

Diese Tabelle enthält Links zu weiteren Informationen zu den am häufigsten verwendeten Connectors. Eine vollständige Liste der Konnektoren finden Sie unter Alle Konnektoren.

** Gilt für Azure Blob, Box, Dropbox, Google Drive, OneDrive und OneDrive for Business

Standardmäßige und benutzerdefinierte Konnektoren

Power Apps bietet Standard Anschlüsse für viele häufig verwendete Datenquellen. Wenn Power Apps einen Standardkonnektor für den von Ihnen gewünschten Datenquellentyp bietet, sollten Sie diesen Konnektor verwenden. Wenn Sie eine Verbindung mit anderen Arten von Datenquellen herstellen möchten, z. B. mit einem von Ihnen erstellten Dienst, finden Sie weitere Informationen unter Benutzerdefinierte Connectors registrieren und verwenden.

Alle Standardkonnektoren

Standard-Connectors erfordern keine spezielle Lizenzierung. Weitere Informationen finden Sie unter Power Apps Pläne.

In den Power Apps-Foren können Sie Fragen zu einem bestimmten Connector stellen, und unter Power Apps Ideas können Sie Vorschläge für neue Connectors oder anderen Verbesserungen einreichen.

Sicherheit und Authentifizierungarten

Wenn Sie Ihre App erstellen und eine Verbindung zu einem Datenquelle herstellen, stellen Sie möglicherweise fest, dass Sie bei der Auswahl des Connectors verschiedene Authentifizierungsmethoden verwenden können. Mit dem SQL Server-Connector können Sie beispielsweise Microsoft Entra Integrierte SQL Server-Authentifizierung und Windows-Authentifizierung verwenden. Mit jeder Art der Authentifizierung sind unterschiedliche Sicherheitsstufen verbunden. Es ist wichtig zu verstehen, welche Informationen und Rechte Sie mit Benutzern teilen, die Ihre Anwendung verwenden. Das Hauptbeispiel in diesem Artikel ist SQL Server. Die Prinzipien gelten jedoch für alle Arten von Verbindungen.

Microsoft Entra-ID

Bei dieser Authentifizierung handelt es sich um eine sichere Art der Verbindung. Zum Beispiel, SharePoint verwendet diese Art der Authentifizierung. SQL Server ermöglicht auch diese Art der Authentifizierung. Wenn Sie eine Verbindung herstellen, wird der Microsoft Entra Service Sie separat zu SharePoint in Ihrem Namen identifizieren. Sie müssen weder einen Benutzernamen noch ein Kennwort angeben. Als Autor können Sie mit Ihren Anmeldeinformationen die Datenquelle erstellen und damit arbeiten. Wenn Sie Ihre Anwendung veröffentlichen und sich Ihr Anwendungsbenutzer anmeldet, erfolgt dies mit seinen Anmeldeinformationen. Wenn die Daten auf einem Back-End angemessen gesichert sind, können Ihre Benutzenden nur das anzeigen, was sie basierend auf ihren Anmeldeinformationen anzeigen dürfen. Mit dieser Art von Sicherheit können Sie die Rechte für bestimmte Anwendungsbenutzende im Back-End Datenquelle ändern, nachdem die Anwendung veröffentlicht wurde. Sie können beispielsweise den Zugriff gewähren, den Zugriff verweigern oder verfeinern, was ein Benutzer oder eine Gruppe von Benutzern im Back-End Datenquelle sehen kann.

Open-Standard-Autorisierung (OAuth)

Dies ist auch eine sichere Verbindung. Twitter verwendet zum Beispiel diese Art der Authentifizierung. Wenn Sie eine Verbindung herstellen, müssen Sie Ihren Benutzernamen und Ihr Kennwort angeben. Als Autor können Sie die Datenquelle mit Ihren Anmeldeinformationen erstellen und damit arbeiten. Wenn Sie Ihre Anwendung veröffentlichen und sich Ihr Anwendungsbenutzer anmeldet, erfolgt dies dann mit seinen Anmeldeinformationen. Daher ist diese Art der Verbindung sicher, da Ihre Benutzer ihre eigenen Anmeldeinformationen verwenden müssen, um auf den Dienst Datenquelle zuzugreifen.

Freigegebene Verbindungen/Sichere implizite Verbindungen

Bei einer freigegebenen Verbindung werden der Benutzername und das Kennwort für die Verbindung vom Power Apps-Autor zum Zeitpunkt der Erstellung der Datenquelle in der Anwendung bereitgestellt. Die Verbindungsauthentifizierung zur Datenquelle lautet dann Implizit geteilt mit Endbenutzern. Nachdem die Anwendung veröffentlicht ist, ist auch die Verbindung veröffentlicht und für Ihre Benutzer verfügbar.

Vor Januar 2024 konnten Ihre Endbenutzenden die für sie freigegebene Verbindung nutzen und separate neue Anwendungen erstellen. Ihre Benutzer können den Benutzernamen oder das Kennwort nicht anzeigen, aber die Verbindung würde ihnen zur Verfügung stehen. Nach Januar 2024 sind jedoch, alle neu erstellten freigegebenen Verbindungen gesichert. Beachten Sie, dass alte Apps erneut veröffentlicht werden müssen, um sicher zu sein. Die Verbindung wird nicht mehr mit Endbenutzern geteilt. Die veröffentlichte Power App kommuniziert mit einem Verbindungsproxy. Der Verbindungsproxy kommuniziert nur mit der spezifischen Power App, für die er verknüpft ist. Der Verbindungs-Proxy beschränkt die Aktionen, die an die Verbindungen gesendet werden, auf diejenigen in Power App {Get, Put/Patch, Delete} für einen bestimmten Datenquelle. Wenn Sie eine App haben, welche die vor Januar 2024 veröffentlichten Verbindungen verwendet, sollten Sie sie erneut veröffentlichen und alle Verbindungen mit Endbenutzenden aufheben, die sie nicht haben sollten.

In SQL Server als Beispiel heißt dieser Verbindungstyp SQL Server-Authentifizierung. Viele andere Datenbankdatenquellen bieten eine ähnliche Funktion. Wenn Sie Ihre Anwendung veröffentlichen, müssen Ihre Benutzer keinen eindeutigen Benutzernamen und kein Kennwort angeben.

Benachrichtigung zur Aktualisierung Ihrer Apps (sichere implizite Verbindungen)

Wenn Sie über Anwendungen verfügen, die möglicherweise für die Verwendung dieser Funktion aktualisiert werden, wird eine Meldung auf der Seite „Apps“ angezeigt. Sie zeigt die Anzahl der Apps an, die Ihre Aufmerksamkeit erfordern.

Wählen Sie den Link aus, und es wird ein Seitenbereich geöffnet, in dem alle Apps aufgelistet sind, die Aufmerksamkeit erfordern.

Wählen Sie das Symbol Öffnen rechts neben dem Namen der App aus, um sie zu öffnen und erneut zu veröffentlichen. Folgen Sie den folgenden Anweisungen.

Sichere implizite Verbindungen für eine bestehende App aktivieren

Öffnen Sie eine vorhandene App, die zur Bearbeitung geöffnet ist, in der implizit freigegebene Verbindungen bereits veröffentlicht sind:

1. Wählen Sie in der Befehlsleiste Einstellungen aus und suchen Sie nach „Sicher“.
2. Aktualisieren Sie den Funktionsschalter entsprechend, um sichere implizite Verbindungen zu ermöglichen.
3. Sichern und veröffentlichen Sie die App.

Freigabe aufheben

Überprüfen Sie nach der Veröffentlichung der App mit den folgenden Schritten, ob die Freigabe ordnungsgemäß funktioniert:

• Überprüfen Sie, ob Verbindungen an Mitbesitzern freigegeben werden. Wenn Sie nicht möchten, dass ein Endbenutzer eine Verbindung erhält, deaktivieren Sie Mitbesitzer.

  

• Um zu überprüfen, ob das Feature ordnungsgemäß funktioniert, geben Sie die App für einen anderen Benutzer frei, der kein Besitzer ist. Nachdem Sie die App freigegeben haben, überprüfen Sie die Liste Verbindungen auf der Registerkarte Dataverse in Power Apps für diesen Benutzenden. Vergewissern Sie sich, dass keine Verbindung für den Benutzer verfügbar ist.

• Öffnen Sie das Fenster Freigabe, um die Berechtigung des Endbenutzers auf die Verbindung zu ändern. Durch Auswahl des X wird der Zugriff des Benutzers auf die Verbindung entfernt.

  

Apps mit einer neuen sicheren impliziten Verbindung verwenden

Wenn Ihre App erneut veröffentlicht und geteilt wird, haben Endbenutzende keinen Zugriff auf die Verbindung, sondern arbeiten mit der verborgenen Proxyverbindung. Benutzer können keine neue App basierend auf Ihrer ursprünglichen Verbindung erstellen.

Einschränkungen

1. Alle Typen von implizit gemeinsam genutzten Verbindungen funktionieren, z. B. Aktions- und Tabellenverbindungen.
2. Server- und Datenbanknamen sind in Netzwerkprotokollen ausgeblendet, aber im Einwilligungsdialog sichtbar. Spaltennamen werden nicht ausgeblendet.
3. Für tabellarische Connectors beschränken wir nur CRUD-Aktionen wie Get, Post, Put oder Delete. Wenn Sie Berechtigungen für Put haben, dann haben Sie Zugriff auf Post.
4. Grenzwerte für aktionsbasierte Connectors basierend auf der spezifischen API, die in der Anwendung verwendet wird.
5. Warnungen sind beim Teilen weiterhin aktiviert. Die Warnung bei implizit freigegebenen Verbindungen warnt auch während der Vorschauversion. Ihre Verbindung mit diesem Feature ist jedoch trotz der Warnung sicher.
6. Die Veröffentlichung an einen gesamten Mandanten, im Gegensatz zu bestimmten Gruppen oder Einzelpersonen, wird nicht unterstützt.
7. Es gibt ein bekanntes Problem beim Importieren einer implizit freigegebenen sicheren Verbindung über eine Verbindungsreferenz. Die Sicherheit ist in der Zielumgebung nicht richtig festgelegt.
8. Es ist ein bekanntes Problem, dass beim Importieren einer Lösung mithilfe eines Dienstprinzipals ein Importfehler auftritt. Eine Problemumgehung besteht darin, die Verbindung mit dem Dienstprinzipal zu teilen.

Windows-Authentifizierung

Diese Art der Verbindung ist nicht sicher, da sie nicht auf der Endbenutzerauthentifizierung basiert. Verwenden Sie die Windows-Authentifizierung, wenn Sie eine Verbindung zu einer Datenquelle herstellen müssen, die lokal ist. Ein Beispiel für diese Art der Verbindung ist ein lokaler Server mit einem SQL Server. Die Verbindung muss über ein Gateway erfolgen. Da es über ein Gateway geht, hat der Konnektor Zugriff auf alle Daten in dieser Datenquelle. Infolgedessen stehen dem Konnektor alle Informationen zur Verfügung, auf die Sie mit den von Ihnen angegebenen Windows-Anmeldeinformationen zugreifen können. Und wenn die Anwendung veröffentlicht ist, ist auch die Verbindung veröffentlicht und für Ihre Benutzer verfügbar. Dieses Verhalten bedeutet, dass Ihre Endbenutzer über dieselbe Verbindung Anwendungen erstellen und auf die Daten auf diesem Computer zugreifen können. Verbindungen zum Datenquelle sind ebenfalls Implizit geteilt mit Benutzern, mit denen die App geteilt wird. Diese Art der Verbindung ist möglicherweise gültig, wenn Ihre Datenquelle nur auf einem lokalen Server gespeichert ist und die Daten in dieser Quelle frei gemeinsam genutzt werden können.

Datenquellen in Lösungen

Lösungen werden für das Application Lifecycle Management verwendet und bieten andere Funktionen zum Verwalten des Lebenszyklus von Datenquellen. Wenn sich eine Canvas-App in einer Lösung befindet, können Verbindungsreferenzen und Umgebungsvariablen erstellt werden, um Informationen über die Datenquellen zu speichern. Dieser Prozess stellt sicher, dass Datenquellen geändert oder wiederhergestellt werden können, wenn Lösungen in verschiedene Umgebungen migriert werden.

Datenquellen in Apps umbenennen

Informationen zum Umbenennen von Datenquellen in einer App und zum Unterschied zwischen tabellarischen und aktionsbasierten Datenquellen finden Sie unter Aktionsbasierte Power Apps-Datenquellen umbenennen.

Verbindungseinwilligungsdialog

Wenn Benutzer eine App zum ersten Mal öffnen, die Connectors verwendet, wird für die folgenden Zwecke ein Dialog „Verbindungseinwilligung“ angezeigt.

1. Um Benutzer über die Datenquellen zu informieren, auf die die App zugreift.

2. Um die Aktionen zu skizzieren, die ein Connector in einer App ausführen darf oder nicht. Bei Apps, die zum Beispiel den Connector für Office 365-Benutzende verwenden:

   • Diese App kann:
     • Ihr vollständiges Benutzerprofil lesen
     • Das vollständige Profil aller Benutzer lesen
   • Die App kann Folgendes nicht:
     • Benutzerprofilinformationen ändern oder löschen

3. Um die Einwilligung des Endbenutzers zu erfassen, eine Verbindung zu den Datenquellen herzustellen, die die App verwendet.

4. Um die manuelle Authentifizierung des Endbenutzers bei Bedarf zu erleichtern.

Für einige Verbindungen, kann Power Platform einen Benutzer automatisch authentifizieren, um auf eine Datenquelle zuzugreifen. Wenn die automatische Anmeldung jedoch fehlschlägt, werden Benutzer in diesem Dialog aufgefordert, die Probleme bei der Verbindung durch manuelles Anmelden zu beheben. Power Platform kann nur die automatische Anmeldung für eine Verbindung versuchen, wenn eine Datenquelle den Microsoft-Dienstprinzipal für Azure-API-Verbindungen vorab autorisiert und ihm die Berechtigung erteilt, sich einmalig für einen Benutzer anzumelden, wenn eine Verbindung erstellt wird. Weitere Informationen zum einmaligen Anmelden finden Sie unter Was ist einmaliges Anmelden (SSO)?

Beachten Sie, dass bei modellgesteuerten Apps, die benutzerdefinierte Seiten verwenden, das Zustimmungsdialogfeld bei mehreren benutzerdefinierten Seiten in einer App nach Datenberechtigungen für alle Konnektoren auf allen benutzerdefinierten Seiten fragt, auch wenn diese nicht geöffnet sind.

Das folgende Bild zeigt ein Beispiel für den Verbindungseinwilligungsdialog für eine App, die eine Verbindung zu einer SharePoint-Website herstellt.

Bei ausgewählten Connectors können Administratoren diesen Dialog unterdrücken und im Namen der Endbenutzer einwilligen, eine Verbindung zu einer Datenquelle herzustellen. In der folgenden Tabelle wird erläutert, für welche Arten von Connectors der Einwilligungsdialog für eine App unterdrückt werden kann.

Microsoft Power Platform kann den Einwilligungsdialog nur für Verbindungen zu Datenquellen unterdrücken, wenn Folgendes zutrifft:

1. Es besteht keine Verpflichtung der Datenquelle, eine Benutzeroberfläche mit ausdrücklicher Einwilligung anzuzeigen.
2. Die Datenquelle autorisiert den Microsoft-Dienstprinzipal für Azure-API-Verbindungen vorab, um einmaliges Anmelden zu ermöglichen.
3. Ein Administrator konfiguriert eine App, um die Einwilligung für die vorherigen Verbindungen zu unterdrücken.

Die Vorautorisierung des Microsoft-Dienstprinzipals für Azure-API-Verbindungen existiert für die Erstanbieter-Datenquellen von Microsoft. Sie kann zudem von benutzerdefinierten, in einem Microsoft Entra-Mandanten registrierten Anwendungen konfiguriert werden, die von benutzerdefinierten Connectors verwendet werden. Ein Administrierender verwaltet die Einwilligungsunterdrückung pro App (und nicht pro Connector), sodass die Unterdrückung auf der detailliertesten App-Erfahrungsebene verwaltet wird. Diese Granularitätsebene verhindert, dass die Einwilligungsunterdrückung für die „genehmigten Apps“ einer Organisation versehentlich die Einwilligung für Apps unterdrückt, die nicht genehmigt oder überprüft wurden.