Общ преглед на конектори за приложения за платно

Данните са в основата на повечето приложения, включително данните, които създавате в Power Apps. Данните се съхраняват в източник на данни и вие въвеждате тези данни в приложението си, като създавате връзка. Връзката използва специфичен конектор , за да комуникира с източник на данни. Power Apps има конектори за много популярни услуги и локални източници на данни, включително SharePoint, SQL Server, Office 365, Salesforce и Twitter. За да започнете да добавяте данни към приложение за платно, вижте Добавяне на връзка с данни Power Apps.

Конекторът може да предоставя таблици с данни или действия. Някои конектори предоставят само таблици, други предоставят само действия, а други предоставят и двете. Също така вашият конектор може да бъде стандартен или персонализиран конектор.

Бележка

Препоръчително е да поддържате броя на конекторите в приложение за платно на максимум 10, а препратките към връзката на не повече от 20. Надхвърлянето на тези ограничения може да доведе до по-дълго време за зареждане на потребителите при стартиране на приложението и може да причини проблеми при запазването на приложението.

Таблици

Ако конекторът ви предоставя таблици, добавяте източник на данни и след това избирате таблицата в източника на данни, който искате да управлявате. Power Apps И двете извличат данни от таблицата в приложението ви и автоматично актуализират данните в източник на данни за вас. Например можете да добавите източник на данни, който съдържа таблица с име Уроци , и след това да зададете свойството Елементи на контрола, като например галерия или формуляр, на тази стойност в лентата с формули:

Можете да зададете данните, които вашето приложение извлича, като персонализирате свойството Елементи на контролата, която показва вашите данни. Продължавайки предишния пример, можете да сортирате или филтрирате данните в таблицата Уроци , като използвате това име като аргумент за функциите Търсене и SortByColumn . В тази графика формулата, на която е зададено свойството Items , указва, че данните се сортират и филтрират въз основа на текста в TextSearchBox1.

За повече информация как да персонализирате формулата с таблици, вижте тези статии:

Разбиране на източниците на данни в Power Apps
Генериране на приложение от данни на Excel
Създаване на приложение от нулата
Разбиране на таблиците и записите в Power Apps

Бележка

За да се свържете с данни в работна книга на Excel, тя трябва да бъде хоствана в услуга за съхранение в облак, като например OneDrive. За повече информация вижте Свързване към място за съхранение в облака от Power Apps.

Действия

Ако вашият конектор осигурява действия, все пак трябва да изберете вашия източник на данни, както сте правили преди. Вместо да избирате таблица като следваща стъпка обаче, вие ръчно свързвате контрола към действие, като редактирате свойството Елементи на контролата, която ще показва вашите данни. Формулата, на която задавате свойството Елементи , указва действието, което извлича данни. Например приложението не извлича никакви данни, ако се свържете с Yammer и след това зададете свойството Елементи на името на източника на данни. За да попълните контрола с данни, задайте действие, като например GetMessagesInGroup(5033622).messages.

Ако трябва да обработвате актуализации на персонализирани данни за конектори за действия, създайте формула, която включва функцията Patch . Във формулата идентифицирайте действието и полетата, които се свързват с действието.

Бележка

За конектори, базирани на действия, галериите и другите контроли не въвеждат автоматично повече данни по същия начин, както за табличните конектори. Например, ако свържете табличен източник на данни с галерия, той ще извлече първия набор или страница със записи (напр. 100 записа). И след това ще въведе повече данни, когато контролът ги поиска. За конектор, базиран на действия обаче, той ще извлече "страница" с данни. Но ако заявените данни надвишават размера на страница с данни, тогава контролата няма автоматично да извлече следващата страница.

За повече информация как да персонализирате формулата за персонализирани актуализации, вижте тези статии:

Кръпка
Събирам
Актуализирам

Динамичната схема е често срещан тип резултат за конектори, базирани на действия. Динамичната схема се отнася до възможността едно и също действие да върне таблица с различни колони в зависимост от начина, по който се извиква. Условията, които могат да доведат до различаване на колоните в таблицата, включват входни параметри, потребителя/ролята, изпълняваща действието, и групата, в която потребителят работи, наред с други. Например съхранените процедури SQL Server може да върнат различни колони, ако се изпълняват с различни входни данни, или екземпляр Azure DevOps може да използва персонализирани полета, които не са налични по подразбиране.

Бележка

Документацията на конектора показва резултатите от динамичната схема със следното съобщение "Изходите от тази операция са динамични". като връщана стойност.

За повече информация как да работите с динамична схема в Power Apps, вижте Работа с нетипизирани и динамични обекти за общ преглед и Свързване с Azure DevOps от Power Apps за подробен пример.

Популярни конектори

Тази таблица съдържа връзки към повече информация за най-популярните ни конектори. За пълен списък на конекторите вижте Всички конектори.

Microsoft Dataverse	Облачно съхранение **
Динамика AX	Превъзхождам
Microsoft Преводач	Office 365 Възглед
Office 365 Потребители	Оракул
Power BI	SharePoint
SQL Сървър	Туитър

** Отнася се за Azure Blob, Box, Dropbox, Google Drive OneDrive и OneDrive за бизнеса

Стандартни и персонализирани конектори

Power Apps Предоставя стандартни конектори за много често използвани източници на данни. Ако Power Apps има стандартен конектор за типа източник на данни, който искате да използвате, трябва да го използвате. Ако искате да се свържете с други типове източници на данни, като например услуга, която сте създали, вижте Регистриране и използване на персонализирани конектори.

Всички стандартни конектори

Стандартните конектори не изискват специално лицензиране. За повече информация вижте Power Apps Планове.

Можете да задавате въпроси за конкретен конектор във форумите Power Apps и можете да предлагате конектори, които искате да добавите, или други подобрения, които да направите в Power Apps Идеи.

Защита и видове удостоверяване

Докато създавате приложението си и създавате връзка с източник на данни, може да видите, че изборът на конектор ви позволява да използвате различни начини за удостоверяване. Например, конекторът SQL Server ви позволява да използвате Microsoft Entra интегрирано, SQL удостоверяване на сървъра и удостоверяване на Windows. Всеки тип удостоверяване има различни нива на сигурност, свързани с него. Важно е да разберете каква информация и права споделяте с потребители, които използват приложението ви. Основният пример в тази статия е SQL Server, но принципите се прилагат за всички видове връзки.

Бележка

• За подробна информация относно съображенията за защита при използване на сървър на релационна база данни (като Microsoft SQL Server например или Oracle) като източник на данни за приложение, вижте Използване Microsoft SQL Server по защитено съдържание с Power Apps.
• Power Apps не поддържа самоличности на външни членове . За повече информация вижте Свойства на Microsoft Entra потребител на B2B сътрудничество.

Microsoft Entra ID

Това удостоверяване е сигурен тип връзка. Например, 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 Удостоверяване на сървъра. Много други източници на данни от база данни предоставят подобна възможност. Когато публикувате приложението, не е необходимо потребителите да предоставят уникално потребителско име и парола.

Известие за актуализиране на вашите приложения (защитени скрити връзки)

Ако имате приложения, които може да бъдат надстроени, за да използват тази функция, ще видите съобщение на страницата Приложения. Той показва броя на приложенията, които се нуждаят от вашето внимание.

Изберете връзката и тя отваря страничен панел, който изброява всички приложения, които се нуждаят от внимание.

Изберете иконата за отваряне вдясно от името на приложението, за да го отворите и публикувате отново. Продължете със следните указания.

Разрешаване на защитени неявни връзки за съществуващо приложение

Отворете съществуващо приложение, отворено за редактиране , с вече публикувани неявно споделени връзки:

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 може да опита автоматично влизане за връзка само когато източник на данни предварително упълномощи Microsoft's Azure API Connections принципал на услугата, предоставяйки му разрешение да извършва еднократно влизане за потребител, когато се създава връзка. За повече информация относно еднократната идентификация вижте Какво е единна идентификация (SSO)?

Имайте предвид, че за приложения, управлявани от модел, които използват персонализирани страници, когато в дадено приложение има няколко персонализирани страници, диалоговият прозорец за получаване на съгласие изисква разрешения за данни за всички конектори във всички персонализирани страници, дори ако не са отворени.

Следващото изображение е пример за диалога за съгласие за връзка на приложение, свързващо се със сайт на SharePoint.

За избрани конектори администраторите могат да потиснат този диалог и да дадат съгласие от името на крайните потребители за връзка с източник на данни. Таблицата по-долу обяснява кои типове конектори може да бъде потиснат диалоговият прозорец за съгласие за дадено приложение.

Бележка

Ако администраторът потисне диалога за съгласие, но платформата не може да извърши еднократна идентификация за краен потребител, диалогът ще се покаже на потребителя при стартиране на приложението.

Тип на конектор	Може ли да се потисне диалогът за съгласие?	Препратка
Microsoft конектори, които поддържат еднократна идентификация (като SharePoint потребители Office 365 )	Да	Power Apps Кратка команда на администратора
Конектор за достъп до партньорска услуга, която не е на Microsoft, като например Salesforce	No	Неприложимо
Персонализирани конектори, използващи OAuth с Microsoft Entra ИД като доставчик на самоличност. Тези персонализирани конектори са създадени от организации и са достъпни само за потребителите в организацията (например създадени от Contoso само за Contoso потребители)	Да	Управление на връзките

Microsoft Power Platform може да потисне диалога за съгласие за връзки към източници на данни само когато:

1. Източникът на данни няма задължение да показва ПИ с изрично съгласие.
2. източник на данни предварително упълномощава Microsoft's Azure API връзки на принципала на услугата, за да разреши еднократна идентификация.
3. Администраторът конфигурира приложение, за да потисне съгласието за предходните връзки.

Предварителното упълномощаване на принципала на услугата Microsoft's Azure API connections съществува за източниците на данни на Microsoft и може да бъде конфигурирано от персонализирани приложения, регистрирани в клиент Microsoft Entra , които се използват от персонализирани конектори. Администраторът управлява потискането на съгласието за всяко приложение (за разлика от конектора), така че потискането се управлява на най-детайлното ниво на работа с приложенията – това ниво на детайлност предотвратява потискането на съгласието за "одобрените приложения" на организацията от неволно потискане на съгласието за приложения, които не са одобрени или прегледани.