Ü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 Konnektor kann Tabellen oder Aktionen bereitstellen. Einige Konnektoren stellen nur Tabellen bereit, andere nur Aktionen und wiederum andere bieten beides. Bei Ihrem Konnektor kann es sich außerdem um einen standardmäßigen oder einen benutzerdefinierten Konnektor 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. 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:

Items-Eigenschaft für Quelle mit einfachen Daten

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.

Items-Eigenschaft für Quelle mit erweiterten Daten

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

Hinweis

Zum Herstellen einer Verbindung mit Daten in einer Excel-Arbeitsmappe muss die Arbeitsmappe in einem Cloudspeicherdienst wie OneDrive gehostet werden. Weitere Informationen finden Sie im Artikel zum Verbinden mit Cloudspeicher aus 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 Artikel-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.

Items-Eigenschaft für Datenquelle für Aktionen

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 Sie an die Aktion binden.

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

Patch
Collect
Update

Hinweis

Power Apps funktioniert nicht mit dynamischem Schema. Der Ausdruck dynamisches Schema bezieht sich auf die Möglichkeit, dass dieselbe Aktion eine andere Tabelle mit unterschiedlichen Spalten zurückgibt. Zu den Bedingungen, die dazu führen können, dass sich die Spalten in den Tabellen unterscheiden, gehören unter anderem die Aktionseingabeparameter, der Benutzer oder die Rolle, die die Aktion ausführt, und die Gruppe, in der der Benutzer arbeitet. Beispielsweise können gespeicherte SQL Server-Prozeduren unterschiedliche Spalten zurückgeben, wenn sie mit unterschiedlichen Eingaben ausgeführt werden. Für Aktionen mit dynamischem Schema wird die Connector-Dokumentation angezeigt Die Ausgänge dieser Operation sind dynamisch. als der Rückgabewert. Im Gegensatz, arbeitet Power Automate mit einem dynamischen Schema und bietet möglicherweise eine Problemumgehung für Ihr Szenario.

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

         
Microsoft Dataverse Microsoft Dataverse   Cloudspeicher Cloudspeicher **
Dynamics AX Dynamics AX   Microsoft Excel Excel
Microsoft Translator Microsoft Translator   Office 365 Outlook Office 365 Outlook
Office 365-Benutzer Office 365 Benutzer   Oracle Oracle
Power BI Power BI   SharePoint-Logo SharePoint
SQL Server. SQL Server   Twitter-Logo Twitter

** 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 Registrieren und Verwenden von benutzerdefinierten Konnektoren.

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, werden Sie möglicherweise feststellen, dass Sie bei der Auswahl des Connectors verschiedene Authentifizierungsmethoden verwenden können. Mit dem SQL Server-Connector können Sie beispielsweise Azure AD 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.

Hinweis

Ausführliche Informationen zu Sicherheitsüberlegungen bei der Verwendung eines relationalen Datenbankservers (wie z. B. Microsoft SQL Server oder Oracle) als Datenquelle für eine App finden Sie unter Sichere Verwendung von Microsoft SQL Server mit Power Apps.

Azure AD Integriert

Dies ist eine sichere 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 Azure AD 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 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 Benutzer 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 Anwendungsbenutzer 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. Zum Beispiel Twitter verwendet diese Art der Authentifizierung. Wenn Sie eine Verbindung herstellen, müssen Sie Ihren Benutzernamen und Ihr Kennwort angeben. Als Autor können Sie mit Ihren Anmeldeinformationen Datenquelle 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.

SQL Benutzernamen- und Kennwort-Authentifizierung

Diese Art der Verbindung ist nicht sicher, da sie nicht auf der Endbenutzerauthentifizierung basiert. Es sollte nur in Fällen verwendet werden, in denen Sie davon ausgehen können, dass jeder, der Zugriff auf diese Verbindung hat, alle Daten sehen und verwenden kann, auf die die Verbindung Zugriff bietet. Sie können Teile der Daten, auf die innerhalb der Verbindung zugegriffen werden kann, nicht zuverlässig sperren. Wenn die Verbindung beispielsweise den Zugriff auf eine einzelne Tabelle ermöglicht, können Sie sich nicht darauf verlassen, dass eine Benutzer-ID nur filtert, um nur Daten für diesen bestimmten Benutzer in dieser Tabelle anzuzeigen. Verwenden Sie für eine zuverlässige Sicherheit eine sicherere Verbindung, wie Azure AD Integriert.

In SQL Server 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. Sie verwenden den Benutzernamen und das Kennwort, die Sie beim Erstellen der Anwendung angegeben haben. Die Verbindungsauthentifizierung zur Datenquelle lautet Implizit geteilt mit Ihren Benutzern. Nachdem die Anwendung veröffentlicht ist, ist auch die Verbindung veröffentlicht und für Ihre Benutzer verfügbar. Ihre Endbenutzer können auch Anwendungen erstellen, indem sie eine beliebige Verbindung mit SQL Server-Authentifizierung verwenden, die für sie freigegeben ist. Ihre Benutzer können den Benutzernamen oder das Kennwort nicht anzeigen, aber die Verbindung steht ihnen zur Verfügung. Es gibt gültige Szenarien für diesen Verbindungstyp. Zum Beispiel, wenn Sie eine schreibgeschützte Datenbank haben, die jedem im Unternehmen zur Verfügung steht. Für diese Art der Verbindung können Referenzdatenszenarien (z. B. ein Unternehmenskalender) hilfreich sein. Mehr Informationen: Microsoft SQL Server sicher mit Power Apps verwenden

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 Ihr 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 zusätzliche Funktionen zum Verwalten des Lebenszyklus von Datenquellen. Wenn eine Canvas-App eine Lösung ist, können Verbindungsreferenzen und Umgebungsvariablen erstellt werden, um Informationen über die Datenquellen zu speichern. Dies 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.

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 kann. Für Apps, die den Office 365 Benutzer-Connector, können dies z. B. folgende sein:

    • Diese App kann:
      • Ihr vollständiges Benutzerprofil lesen
      • Das vollständige Profil aller Benutzer lesen
    • Sie kann 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)?

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

Power Apps-Einwilligungsdialog

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.

Hinweis

Wenn ein Administrator den Einwilligungsdialog unterdrückt, die Plattform jedoch kein einmaliges Anmelden für einen Endbenutzer durchführen kann, wird der Dialog dem Benutzer angezeigt, wenn er die App startet.

Konnektortyp Einwilligungsdialog unterdrückbar? Verweis
Erstanbieter-Connectors von Microsoft, die einmaliges Anmelden unterstützen (wie z. B. SharePoint, Office 365-Benutzer) Ja Power Apps-Administrator-Cmdlet
Connector, der auf einen Drittanbieterdienst, der nicht von Microsoft stammt, wie Salesforce, zugreift Nein Nicht verfügbar
Benutzerdefinierte Connectors, die OAuth mit Azure Active Directory als Identitätsanbieter verwenden. Dies sind benutzerdefinierte Connectors, die von Organisationen erstellt wurden und auf die nur die Benutzer innerhalb der Organisation zugreifen können (z. B. erstellt von Contoso nur für Contoso-Benutzer) Ja Verbindungen verwalten

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. 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 Azure AD-Mandanten registrierten Anwendungen konfiguriert werden, die von benutzerdefinierten Connectors verwendet werden. Ein Administrator 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.