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

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

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

Таблици

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

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

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

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

Бележка

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

Действия

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

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

Бележка

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

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

Patch
Collect
Актуализиране

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

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

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

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

Microsoft Dataverse	Място за съхранение в облак **
Dynamics AX	Excel
Microsoft Translator	Office 365 Outlook
Потребители на Office 365	Oracle
Power BI	SharePoint
SQL Server	Twitter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. В командната лента изберете Настройки и потърсете "Secure".
2. Актуализирайте превключвателя на функциите по подходящ начин, за да разрешите защитени неявни връзки.
3. Записване и публикуване на приложение.

Премахване на споделянето

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

• Проверете дали връзките са споделени със съсобствениците. Ако не искате крайният потребител да получи връзка, изчистете отметката от квадратчето Съсобственик .

  

• За да проверите дали функцията работи правилно, споделете приложението с друг потребител, който не е собственик. След като сте споделили приложението, проверете списъка Връзки в Dataverse раздела Power Apps в за този потребител. Проверете дали потребителят няма налична връзка.

• Отворете панела за споделяне, за да промените правото на крайния потребител върху връзката. Избирането на X ще премахне достъпа на потребителя до връзката.

  

Използване на приложения с нова защитена подразбираща се връзка

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

Ограничения

1. Всички типове имплицитно споделени връзки работят като действие и таблични.
2. Имената на сървърите и базите данни са скрити в проследяванията на мрежата, но са видими в диалоговия прозорец за съгласие. Имената на колоните не са скрити.
3. За таблични съединители ограничаваме само CRUD действия като "Получаване", "Публикуване", "Поставяне" или "Изтриване". Ако имате разрешения за поставяне, тогава имате достъп до "Публикуване".
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, които поддържат еднократна идентификация (като потребители на SharePoint, Office 365)	Да	Кратка команда на администратор на Power Apps
Конектор за достъп до услуга на трета страна, която не е на Microsoft, като Salesforce	No	Неприложимо
Потребителски съединители, използващи OAuth с Microsoft Entra ID като доставчик на самоличност. Това са персонализирани конектори, изградени от организации и достъпни само за потребителите в организацията (например, изградени от Contoso само за потребители на Contoso)	Да	Управление на връзки

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

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

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

Бележка

Можете ли да ни споделите повече за езиковите си предпочитания за документацията? Попълнете кратко проучване. (имайте предвид, че това проучване е на английски език)

Проучването ще отнеме около седем минути. Не се събират лични данни (декларация за поверителност).