Огляд з'єднувачів для компонованих програм

Дані — це основа більшості програм, включно з даними, які ви створюєте в Power Apps. Дані зберігаються в джерелі даних, і ви отримуєте ці дані в програмі, створюючи підключення. Підключення використовує особливий з’єднувач для комунікації з джерелом даних. Power Apps має з’єднувачі для багатьох популярних служб і локальних джерел даних, зокрема SharePoint, SQL Server, Office 365, Salesforce і Twitter. Щоб розпочати додавання даних до компонованої програми, див. Додавання підключення даних у Power Apps.

З’єднувач може надавати таблиці з даними або дії. Деякі з’єднувачі надають лише таблиці, деякі з них забезпечують лише дії, а деякі підтримують обидва варіанта. Також ваш з’єднувач може бути стандартним або настроюваним з’єднувачем.

Таблиці

Якщо конектор надає таблиці, додайте джерело даних, а потім виберіть таблицю джерело даних, якою потрібно керувати. Power Apps Як дані таблиці завантажуються у ваш додаток, так і оновлюються автоматично для вас дані в джерело даних. Наприклад, ви можете додати джерело даних, яке містить таблицю з іменем Уроки, а потім задати в якості значення властивості Items для якого-небудь елемента керування, наприклад, галереї чи форми, рядок формули, як зазначено нижче.

Можна вказати дані, які отримує програма, настроюючи властивість Items елемента керування, в якому відображаються дані. Продовжуючи попередній приклад, можна відсортувати або відфільтрувати дані в таблиці Уроки, використовуючи це ім’я в якості аргументу функцій Search та SortByColumn. На цьому рисунку формула, задана для властивості Items, вказує, що дані сортуються та фільтруються на основі тексту в полі TextSearchBox1.

Додаткові відомості про налаштування формул за допомогою таблиць див. у таких статтях:

Ознайомлення з джерелами даних у Power Apps
Створення програми з даних Excel
Створення програми з нуля
Ознайомлення з таблицями та записами у Power Apps

Дії

Якщо з’єднувач надає дії, все одно необхідно вибрати джерело даних, як описано вище. Замість того, щоб вибирати на наступному кроці таблицю, слід вручну підключити елемент керування до дії, редагуючи значення властивості Items елемента керування, в якому відображатимуться дані. Формула, яку буде задано в якості значення властивості Items, визначатиме дію, яка отримуватиме дані. Наприклад, програма не отримає жодних даних, якщо ви підключитесь до Yammer, а потім встановите назву джерела даних як значення властивості Items. Щоб заповнити елемент керування даними, укажіть дію, наприклад GetMessagesInGroup(5033622).messages.

Якщо потрібно опрацьовувати настроювані оновлення даних для з’єднувачів з діями, створіть формулу, яка міститиме функцію Patch. У формулі визначте дію та поля, які потрібно зв’язати із дією.

Додаткові відомості про налаштування формул для настроюваних оновлень див. у таких статтях:

Patch
Collect
Оновлення

Динамічна схема є поширеним типом результату для з’єднувачів, заснованих на дії. Динамічна схема означає можливість того, що одна і та ж дія може повернути таблицю з різними стовпцями в залежності від того, як вона викликана. До умов, які можуть спричиняти різницю стовпців у таблиці, належать, зокрема, параметри вводу, користувач або роль, яка виконує дію, а також група, у якій працює користувач. Наприклад, збережені процедури SQL Server можуть повертати різні стовпці, які виконуються для різних вхідних параметрів, або екземпляр Azure DevOps може використовувати настроювані поля, недоступні за замовчуванням. Зауважте, що документація з’єднувача показує динамічні результати схеми з таким повідомленням : «Виходи цієї операції є динамічними». в якості повернутого значення.

Для отримання додаткових відомостей про те, як працювати з динамічною схемою в, перегляньте Power Apps статті Робота з нетипізованими та динамічними об’єктами для огляду та Підключення до від, Azure DevOps Power Apps щоб отримати докладний приклад.

Популярні з’єднувачі

У цій таблиці наведено посилання на додаткові відомості про найпопулярніші з’єднувачі. Повний список з’єднувачів наведено тут: Усі з’єднувачі.

** Застосовується до Azure Blob, Box, Dropbox, Google Drive OneDrive і OneDrive для бізнесу

Стандартні та настроювані з’єднувачі

Power Apps надає стандартні з’єднувачі для багатьох найуживаніших джерел даних. Якщо Power Apps має стандартний з’єднувач для типу джерела даних, яке необхідно використати, слід використовувати цей з’єднувач. Щоб підключитися до інших типів джерел даних, наприклад до послуги, яку було створено вами, див. Реєстрація та використання настроюваних з’єднувачів.

Усі стандартні з’єднувачі

Стандартні з’єднувачі не потребують спеціального ліцензування. Додаткову інформацію див. тут: Плани Power Apps.

Ви можете поставити запитання про конкретний конектор на Power Apps форумах, а також запропонувати сполучники, які ви хочете додати, або інші покращення, які можна внести в Power Apps Ideas.

Безпека та типи автентифікації

При написанні програми та створенні підключення до джерела даних ви можете побачити, що для вибраного з’єднувача доступні різні способи автентифікації. Наприклад, з’єднувач SQL Server дозволяє використовувати Microsoft Entra інтегровану автентифікацію SQL Server і автентифікацію Windows. Із кожним типом автентифікації пов’язані різні рівні безпеки. Важливо розуміти, які відомості та права ви передаєте користувачам, що використовують вашу програму. Основним прикладом у цій статті слугує SQL Server, проте принципи, що розглядаються, є застосовними до всіх типів підключень.

Ідентифікатор Microsoft Entra

Це безпечний тип підключення. Наприклад, SharePoint використовує такий тип автентифікації. SQL Server також підтримує цей тип автентифікації. Коли ви підключаєтеся, Microsoft Entra сервіс ідентифікує вас окремо від SharePoint вашого імені. Не потрібно вказувати ім’я користувача або пароль. Як автор, ви може створити джерело даних та працювати з ним, використовуючи ваші облікові дані. Після публікування програми користувачі входитимуть в програму зі своїми обліковими даними. Якщо дані належним чином захищено в серверній частині, користувачі зможуть бачити тільки те, що їм дозволено бачити на основі їхніх облікових даних. Цей тип безпеки дозволяє вам змінювати права для певних користувачів програми у внутрішньому джерелі даних після публікування програми. Наприклад, ви можете дозволити доступ, заборонити доступ або уточнити, який користувач або набір користувачів зможе бачити певні дані, і все це у внутрішньому джерелі даних.

Відкритий стандарт авторизації (OAuth)

Цей тип підключення також є безпечним. Наприклад, Twitter використовує такий тип автентифікації. Під час підключення ви повинні вказати своє ім’я користувача та пароль. Як автор, ви може створити джерело даних та працювати з ним, використовуючи ваші облікові дані. Після публікування програми, коли користувачі входитимуть в програму, вони також матимуть надати свої облікові дані. Тому такий тип підключення є безпечним, оскільки користувачі мають використовувати власні облікові дані для доступу до послуги джерела даних.

Спільні з’єднання / Безпечні неявні з’єднання

При спільному з’єднанні ім’я користувача і пароль для з’єднання вказуються автором Power Apps в момент створення джерело даних в додатку. Після цього автентифікація з’єднання з джерело даних неявно надається кінцевим користувачам. Після публікації програми підключення також буде опубліковано та стане доступним для користувачів.

До січня 2024 року кінцеві користувачі могли скористатися спільним з’єднанням і створити окремі нові програми. Ваші користувачі не бачитимуть ім’я користувача або пароль, але з’єднання буде доступним для них. Однак після січня 2024 року всі новостворені спільні з’єднання будуть захищені. Зверніть увагу, що старі додатки потрібно публікувати повторно, щоб бути безпечними. Це означає, що з’єднання більше не надається кінцевим користувачам. Опублікований додаток Power App спілкується з проксі-сервером підключення. Проксі-сервер підключення спілкуватиметься лише з певним додатком Power App, до якого він підключений. Проксі-сервер з’єднання обмежує дії, які надсилаються до з’єднань, тими, що містяться в Power App {Get, Put/Patch, Delete} для заданого джерело даних. Якщо у вас є додаток, який використовує підключення, опубліковані до січня 2024 року, повторно опублікуйте додаток і скасуйте доступ до всіх підключень із кінцевими користувачами, які їх не повинні мати.

У SQL Server прикладом такого типу підключення є SQL Server Authentication. Велика кількість інших джерел даних із базами даних передбачають аналогічну можливість. У разі публікації програми користувачам не потрібно вказувати унікальні ім’я користувача та пароль.

Сповіщення про оновлення додатків (безпечне неявне з’єднання)

Якщо у вас є програми, які можна оновити для використання цієї функції, ви побачите повідомлення на сторінці Програми. Він вказує на кількість програм, які потребують вашої уваги.

Виберіть посилання, і воно відкриє бічну панель, на якій будуть перераховані всі програми, які потребують уваги.

Натисніть значок відкриття праворуч від назви програми, щоб відкрити та повторно опублікувати її. Дивіться інструкції нижче.

Увімкнення безпечних неявних з’єднань для наявного додатка

Відкрийте наявну відкриту для редагування програму з неявно спільними з’єднаннями, яку було опубліковано раніше.

1. На панелі команд виберіть «Налаштування» та знайдіть « Безпечно».
2. Оновіть перемикач функцій відповідним чином, щоб увімкнути безпечні неявні з’єднання.
3. Збережіть та опублікуйте програму.

Скасування спільного доступу

Після публікації додатка виконайте наведені нижче дії, щоб переконатися, що спільний доступ працює правильно.

• Перевірте, чи поділяються зв’язки зі співвласниками. Якщо ви не хочете, щоб кінцевий користувач отримував з’єднання, зніміть прапорець Співвласник .

  

• Щоб переконатися, що функція працює правильно, поділіться нею з іншим користувачем, який не є власником. Після того, як ви поділилися програмою, перевірте список «Підключення» на вкладці Dataverse для Power Apps цього користувача. Переконайтеся, що в користувача немає доступного з’єднання.

• Відкрийте панель «Спільний доступ », щоб змінити право кінцевого користувача на підключення. Вибір X позбавить користувача доступу до з’єднання.

  

Використання програм із новим безпечним неявним з’єднанням

Коли ваш додаток буде повторно опубліковано та поширено, кінцеві користувачі не матимуть доступу до з’єднання, але працюватимуть із прихованим проксі-з’єднанням. Вони не зможуть створити новий додаток на основі вашого початкового з’єднання.

Обмеження

1. Працюють усі типи неявно спільних зв’язків, такі як дія та табличні.
2. Імена серверів і баз даних приховані в трасуванні мережі, але видимі в діалоговому вікні згоди. Назви стовпців не приховуються.
3. Для табличних сполучників ми обмежуємо лише дії CRUD, такі як Get, Post, Put або Delete. Якщо у вас є дозволи на Put, то у вас є доступ до Post.
4. Обмеження конекторів на основі дій залежить від конкретного API, що використовується в додатку.
5. Попередження все ще ввімкнено під час спільного доступу. Попередження про неявно спільні з’єднання все одно попереджає під час приватного попереднього перегляду. Однак, незважаючи на попередження, ваше з’єднання з цією функцією є безпечним.
6. Публікація для всього клієнта, а не для окремих груп чи окремих осіб, не підтримується.
7. Відома проблема під час імпорту неявно спільного захищеного з’єднання через посилання на підключення. Безпека не налаштована належним чином у цільовому середовищі.
8. Відома проблема імпортування рішення за допомогою реєстраційного запису служби, що спричиняє помилку імпортування. Щоб обійти цю проблему, потрібно надати спільний доступ до з’єднання з реєстраційним представником служби.

Автентифікація Windows

Такий тип підключення є небезпечним, оскільки він не базується на автентифікації кінцевих користувачів. Використовуйте автентифікацію Windows для підключення до джерела даних, яке є локальним. Наприклад, цей тип підключення можна використовувати при підключенні до локального сервера, на якому працює SQL Server. Підключення повинно проходити через шлюз. Якщо воно проходитиме через шлюз, з’єднувач матиме доступ до всіх даних у цьому джерелі даних. Внаслідок цього усі відомості, до яких можна отримати доступ із обліковими даними Windows, наданими вами, будуть доступні для з’єднувача. І після публікації програми підключення також буде опубліковано та стане доступним для користувачів. Така поведінка означає, що кінцеві користувачі також можуть створювати програми за допомогою цього самого підключення та отримувати доступ до даних на цьому комп’ютері. Підключення до джерела даних також надаються неявно користувачам, з якими спільно використовується ця програма. Цей тип підключення може використовуватись, якщо джерело даних використовується лише на локальному сервері, а даними з цього джерела можна ділитися з усіма.

Джерела даних у рішеннях

Рішення використовуються для управління життєвим циклом додатків і надають інші можливості для управління життєвим циклом джерел даних. Якщо компонована програма є в рішенні, для зберігання відомостей про джерела даних можна створити посилання на підключення та змінні середовища. Це гарантує, що джерела даних можна буде змінювати або повторно настроювати під час перенесення рішень у інші середовища.

Перейменування джерела даних у програмах

Щоб дізнатися про перейменування джерел даних у програмі, а також про різницю між джерелами даних на основі таблиць та дій, перейдіть до пункту Перейменування джерел Power Apps на основі дій.

Діалогове вікно запиту згоди на підключення

Коли користувачі вперше відкривають програму, яка використовує конектори, вони бачать діалогове вікно «згода на підключення» для наведених нижче цілей.

1. Проінформувати користувачів про джерела даних, до яких програма отримує доступ.

2. Описати структуру дій, які з’єднувачі можуть або не можуть виконувати в програмі. Наприклад, для програм, які використовують з’єднувач Користувачі Office 365, це може бути:

   • Ця програма може:
     • Прочитати повний профіль користувача
     • Прочитати повний профіль усіх користувачів
   • Вона не зможе:
     • Змінити або видалити будь-яку інформацію профілю користувача

3. Записати згоду кінцевого користувача на підключення до джерел даних, які використовує програма.

4. Полегшити ручну автентифікацію кінцевих користувачів за потреби.

Для деяких підключень Power Platform може автоматично автентифікувати користувача для доступу до джерела даних. Проте, якщо виконати автоматичний вхід не вдасться, у цьому діалоговому вікні відобразить пропозиція виправити підключення за допомогою входу в систему вручну. Power Platform може намагатися автоматично ввійти для підключення, лише якщо джерело даних попередньо авторизує реєстраційний запис служби підключень Azure API Microsoft, надаючи йому дозвіл виконувати єдиний вхід для користувача під час створення підключення. Додаткову інформацію про єдиний вхід див. у розділі Що таке єдиний вхід (SSO)?

Зверніть увагу, що для програм, керованих моделлю, які використовують спеціальні сторінки, якщо в програмі є кілька користувацьких сторінок, діалогове вікно згоди запитує дозволи на дані для всіх сполучників на всіх спеціальних сторінках, навіть якщо їх ще не відкрито.

Нижче наведено зображення з прикладом діалогового вікна запиту згоди на підключення для програми, що підключається до сайту SharePoint.

Для вибраних з’єднувачів адміністратори можуть приховати це діалогове вікно та надати згоду від імені кінцевих користувачів на підключення до джерела даних. У нижченаведеній таблиці описано, для яких типів з’єднувачів може бути приховане діалогове вікно запиту згоди для програми.

Microsoft Power Platform може приховати діалогове вікно запиту згоди для підключень до джерел даних, де:

1. Існує зобов’язання джерела даних відображати явний інтерфейс запиту згоди.
2. джерело даних попередньо авторизує принцип служби підключень Azure API від Microsoft, щоб увімкнути єдиний вхід.
3. Адміністратор налаштовує програму, щоб приховати згоду для попередніх підключень.

Попередня авторизація принципу служби з’єднань Azure API від Microsoft існує для основних джерел даних корпорації Майкрософт і може бути налаштована спеціальними програмами, зареєстрованими в Microsoft Entra клієнті, які використовуються настроюваними з’єднувачами. Адміністратор керує прихованням згоди на основі принципу «для кожної програми» (на відміну від принципу «на основі з’єднувачів»), тому приховання керується на більш деталізованому рівні програми. Цей рівень деталізації запобігає прихованню згоди для «затверджених програм» організації від випадкового приховання згоди для програм, які не затверджено або не перевірено.