Модернизирайте приложенията с Power Platform

В днешния бързо развиващ се дигитален пейзаж организациите са изправени пред постоянното предизвикателство да модернизират своите наследени приложения, за да бъдат в крак с променящите се бизнес нужди. Модернизацията на приложенията е от решаващо значение за подобряване на оперативната ефективност, подобряване на изживяването на клиентите и изпреварване на конкуренцията. Microsoft Power Platform предлага изчерпателен набор от инструменти и технологии, които дават възможност на бизнеса да трансформира и модернизира своите приложения бързо и ефективно.

Тази бяла книга изследва ползите, стратегиите и най-добрите практики за модернизиране на приложенията Microsoft Power Platform. Той предоставя прозрения и насоки за това как платформата с нисък код на Microsoft може да ви помогне да осигурите успеха на усилията си за модернизиране на приложенията като част от цифровата трансформация на вашата организация.

Съвет

Можете да запишете или отпечатате тази бяла книга, като изберете Печат от вашия браузър и след това изберете Запиши като PDF.

Въведение

Наследените приложения представляват много предизвикателства за организациите. Тези приложения често са изградени върху остарели технологични стекове и рамки, което ги прави трудни за интегриране със съвременни системи и инструменти. Те често имат ограничения в мащабируемостта и производителността, които възпрепятстват способността на организацията да се справя с нарастващите работни натоварвания и изискванията на клиентите. На старите приложения им липсва гъвкавост и гъвкавост, което ограничава способността им да се адаптират бързо към променящите се бизнес нужди и динамика на пазара. Уязвимостите в сигурността, високите разходи за поддръжка, ограничените възможности за интеграция и рискът от зависимост от доставчика допълнително усложняват предизвикателствата на наследените приложения. За да ги преодолеят, организациите трябва да модернизират своята приложна инфраструктура, за да се възползват от новите технологии.

Възможностите Microsoft Power Platform за разработка с нисък код правят възможно изграждането и внедряването на модерни приложения по-бързо и по-рентабилно от всякога. Лесно интегрирайте съществуващите си системи и източници на данни за безпроблемен обмен на данни и сътрудничество. Добавете изкуствен интелект, за да подобрите потребителското изживяване, да автоматизирате процесите и да получите ценна информация от вашите данни. Независимо дали сте граждански разработчик, който се занимава с ръбовете, или професионален разработчик, работещ върху сложна персонализация, можете да управлявате дигиталната трансформация интуитивно, бързо и на по-ниска цена, отколкото при традиционните подходи.

Защо Power Platform?

Всеобхватните инструменти и технологии, които съставляват Power Platform , драстично намаляват дължината, разходите и изискванията за развитие на проектите за модернизация и дигитална трансформация. Неговият подход с нисък код намалява - и дори може да елиминира - необходимостта от скъпо кодиране, наука за данни и инженерни ресурси за изкуствен интелект. Гражданските разработчици и професионалните разработчици се възползват еднакво. Гражданските разработчици могат да поемат активна роля в процеса на модернизация, като изграждат приложения директно въз основа на техния опит в областта и намаляват зависимостта си от ИТ екипи. Професионалните разработчици могат да предоставят дори сложни решения за много по-малко време, което ги освобождава да преминат към следващия проект по-рано.

Power Platform Продукти и концепции

Всеки продукт в Power Platform семейството има уникална фокусна област. Организациите могат да внедрят продуктите поотделно или в комбинация, за да отговорят на техните специфични изисквания. Продуктите са свързани помежду си, образувайки едно безпроблемно цяло, независимо от това, че са комбинирани.

Следващата таблица предлага преглед на високо ниво на всеки Power Platform продукт.

Product	Описание
Power Apps	Създавайте персонализирани приложения в интуитивно платно с плъзгане и пускане. С повече от хиляда конектора, вътрешните и външните източници на данни и услуги са само на няколко кликвания. Приложенията ви могат да се изпълняват в браузър, на настолен компютър или на мобилни устройства.
Power Automate	Изградете работни потоци за автоматизиране дори на сложни процеси. Включете вътрешни и външни източници на данни и услуги с помощта на вградени и персонализирани конектори. Използвайте цифрова автоматизация на процесите (DPA), когато приложенията имат приложно-програмен интерфейс (API). Използвайте роботизирана автоматизация на процеси (RPA), за да автоматизирате повтарящи се задачи, изпълнявани в браузър или настолно приложение. Задействайте работни потоци да се изпълняват, когато възникнат събития в други системи и услуги, или планирайте да се изпълняват в определено време.
Copilot Studio	Създаване на разговорни агенти с помощта на графичен интерфейс без код. Можете да разположите агенти в множество канали, включително уебсайтове, мобилни приложения и платформи за съобщения като Microsoft Teams. Авторството с помощта на AI може да ускори създаването на теми. Генеративните отговори могат да намерят и представят информация от множество източници, без да изискват създаване на теми.
Power BI	Плъзнете диаграми, таблици и други визуални елементи върху платно, за да създавате лесно сложни отчети, които разкриват прозрения, заключени във вашите данни. Включете автоматизирано машинно обучение за прогнозно моделиране и визуализации на AI с дървета на разлагане за подробни детайли за анализ на първопричините. Изследвайте данните си, като задавате въпроси на естествен език в прост формат на въпроси и отговори.
Power Pages	Бързо създавайте атрактивни, управлявани от данни уебсайтове на сигурна платформа от корпоративен клас с нисък код софтуер като услуга (SaaS). С богати, адаптивни шаблони и плавно визуално изживяване създаването, хостването и администрирането на модерни външни бизнес уебсайтове е по-лесно.

Продуктовото Power Platform семейство разчита на няколко поддържащи възможности и концепции. Следващата таблица описва най-важните от тях, които трябва да разберете.

Концепция	Описание
Power Fx	Power Fx е език с нисък код, вдъхновен от формули на Excel. Строго типизиран, декларативен и функционален, с императивна логика и управление на състоянието, всички изразени в удобен за човека текст, Power Fx прави общите задачи за програмиране лесни както за гражданските разработчици, така и за професионалните разработчици. Той поддържа пълния спектър на разработка, от no-code за тези, които никога преди не са програмирали, до "pro-code" за опитен професионалист, давайки възможност на различни екипи да си сътрудничат и да спестят време и разходи.
Съединители	Конекторите са жизненоважни, за да позволят на нисък код и традиционното кодиране да работят заедно, за да предоставят модерни приложения. Конекторите са обвивка около API, която позволява Power Apps и Power Automate използва вътрешни и външни източници на данни и услуги. Налични са повече от хиляда предварително изградени конектора и можете да създадете свой собствен за всеки RESTful API. Дефиницията на конектора включва необходимите метаданни, за да улесни използването на API от приложения с нисък код.
Dataverse	Dataverse е хибридно хранилище за данни в облак, изградено върху услугите за управление на данни на Azure, но е повече от база данни. Това е основната платформа за данни както за Dynamics 365, така и Power Platform със сървърна логика под формата на работни потоци и плъгини, бизнес правила и потоци от процеси, изключително сложен модел за сигурност и разширяема платформа за разработка с вградена поддръжка за многоезични и мултивалутни приложения. Приложенията могат бързо да бъдат конструирани от модела на данни, което го прави един от най-бързите начини за внедряване на решение за форма върху данни.
AI Builder	AI Builder улеснява използването на изкуствен интелект Power Apps и Power Automate намирането на прозрения във вашите данни, автоматизира процесите и прави приложенията ви по-продуктивни. С AI Builder това не се нуждаете от умения за кодиране или наука за данни, за да получите достъп до силата на AI. Предварително изградените модели с възможност за персонализиране са готови до ключ за много често срещани бизнес сценарии и можете да изградите свои собствени модели, за да отговорите на конкретна бизнес нужда.
Втори пилот	Помощта на Copilot AI прави Power Platform потребителите и разработчиците, граждани или професионалисти, по-продуктивни, което им позволява да прекарват повече време в най-добрите части от работата си и по-малко време в обикновени задачи. Опишете вашия бизнес сценарий на Copilot и Power Automate той може да превърне описанието ви в автоматизиран работен процес. Кажете на Copilot Power Apps какво искате да направите или каква информация искате да видите и той може да създаде приложение за него. Copilot настройва връзки, създава и попълва таблици, генерира екрани и дори предлага предложения, за да подобри вашия поток или приложение. Вашите приложения ще имат вградени от втори пилот изживявания, така че потребителите ви да могат да откриват прозрения чрез разговор.
Среди и решения	Средите са граници, които съдържат и улесняват управлението и защитата Power Platform на ресурси. Те се използват и в управлението на жизнения цикъл на приложенията (ALM), при което решенията се разработват и тестват в отделни среди, преди да бъдат внедрени в производствена среда. Решенията са пакетни Power Platform персонализации и разширения. Решението може да включва приложения, потоци, таблици, диаграми, табла, конектори и други компоненти, от които се нуждае персонализирането или разширението. Решенията могат да бъдат разработени, тествани и внедрени в производство в отделни среди като част от политиката за ALM на организацията. Можете да експортирате решения, за да ги споделяте с други потребители или организации и да импортирате решения от други. Решенията са или управлявани, или неуправлявани. Неуправляваните решения се използват за разработка и тестване. Управляваните решения се използват за внедряване и разпространение на производството.

Основни предимства на модернизацията на Power Platform приложенията

Ползите от модернизирането на приложенията се Microsoft Power Platform простират отвъд първоначалната бизнес стойност на наличието на решение, което използва съвременни технологии.

• По-ниски разходи. Организациите могат да спестят пари от разработване и поддръжка на приложения. Поръчано проучване на Forrester Consulting установи, че организациите, които използват Power Platform , могат да видят 45% намаление на разходите за разработка на приложения и да реализират 140% възвръщаемост на инвестициите си.

• Разширете ресурсния пул и премахнете тесните места. Професионалните разработчици, специалистите по данни и инженерите по изкуствен интелект са високо платени и много търсени. Малките и средни организации често нямат лукса на вътрешния опит в кодирането, а аутсорсингът е скъп. Low-code Power Platform е по-достъпен чрез по-голям набор от ресурси. Експертите по темата и служителите с опит в бизнес процесите могат да помогнат за ускоряване на усилията за модернизация, дори ако никога не са писали ред код.

• Изградете количката, а не колелото. Традиционната разработка на софтуер започва на чисто всеки път, преоткривайки колелото с всеки нов проект. С интуитивни, удобни Power Platform за производителя продукти можете да се съсредоточите върху изграждането на по-добра количка – подобряване на вашите бизнес процеси – и да се насладите на предимствата на усилията си за модернизация по-рано.

• Намалете техническия дълг. Цената – както финансова, така и при пропуснати възможности – за надграждане на "бързи и мръсни" софтуерни решения и поддържане на наследена инфраструктура е висока. Power Platform намалява този технически дълг, като улеснява и поевтинява изграждането на решения още от първия път, опростява интеграцията и управлението на данни с общ модел на данни и конектори, осигурява централизирана платформа за управление на решения и поддържа непрекъснато подобрение с анализи и изкуствен интелект.

• Подобрете сигурността и осигурете съответствие. Всички Power Platform продукти включват напълно интегрирана защита от корпоративен клас, съответствие и управление извън кутията, като се започне от средите, в които работят. Управляваните среди са набор от инструменти, които позволяват на администраторите да управляват Power Platform в мащаб, с повече контрол и по-малко усилия. Наред с други възможности, можете да ограничите кой може да споделя кои потоци и приложения и с кого и да използвате правила, за да ограничите конекторите, които създателите могат да използват. Естествените, гъвкави модели за сигурност на данните означават, че всяко приложение не трябва да създава свое собствено.

• Модернизирайте в движение. Колкото по-значими са приложенията, които искате да модернизирате, толкова по-малка е вероятността да искате да ги замените всички наведнъж. Подходът с нисък код се поддава добре на изграждане на решения на управляеми стъпки.

• Интегрирайте наследени приложения. По-старите приложения често нямат API. Power PlatformВъзможностите на RPA могат да автоматизират класическите приложения и да ги включат във вашите нови модерни бизнес процеси. RPA също може да бъде полезна при постепенното модернизиране на големи и сложни приложения.

• Правете иновации, без да харчите повече. Power Platform способностите продължават да се подобряват. Приложенията, изградени на платформата, се възползват от иновациите на Microsoft без повече разходи за вас.

• Увеличете производителността на работниците на модерно работно място. Power Platform е част от модерното работно място на Microsoft. Приложенията, модернизирани на платформата, могат да се възползват от възможностите, включително Microsoft 365 ангажиращи мобилни изживявания и лесно, интуитивно сътрудничество. Авангардният AI като Copilot AI Builder и функциите, които скоро ще бъдат обявени, правят потребителите и разработчиците по-продуктивни с по-малко разочарование и по-плитки криви на обучение.

Иновации за служителите за пряка работа

Служителите за пряка работа се нуждаят от модерни приложения, които могат да използват на всяко устройство и навсякъде, където работят. Те се нуждаят от достъп до прозрения в реално време, за да вземат по-добри решения по-бързо. Те трябва да си сътрудничат с колеги и ръководство, за да поддържат всичко гладко. Когато American Airlines реши да модернизира аспекти от своите операции, те получиха всичко това и повече.

В партньорство с Microsoft American Airlines създаде ConnectMe, Microsoft Teams приложение, изградено върху Power Apps Azure. Използвайки приложението на всяко мобилно устройство, екипите на първа линия имат ключова информация за пристигане, качване, багаж и изход на една ръка разстояние в реално време, рационализирайки наземните операции, ускорявайки времето за завъртане на самолета и правейки пътуването по-приятно изживяване за клиентите. Научете повече за трансформацията на авиокомпанията.

Овластяване на ИИ за работниците на знанието

Работниците на знанието плуват в океан от данни - и твърде често се чувстват сякаш се давят. Почти всички приложения събират данни. Малко от тях помагат на потребителите да осмислят данните, които събират, камо ли да извлекат прозрения, които могат да помогнат на работниците да вършат работата си по-добре. Възможностите за изкуствен интелект могат да бъдат добавени към приложенията като част от модернизацията, като не само автоматизират събирането и анализа на данни, но и улесняват работниците на знанието да откриват модели и тенденции. Прогнозният анализ може да използва AI модели за прогнозиране на бъдещи резултати въз основа на исторически данни с висока точност, което позволява на лидерите да планират с увереност. Модернизираните приложения могат да включват copilot AI, действащ като партньор за генериране на съдържание в контекст – обобщаване на интервюта, изготвяне на целеви маркетингови и търговски съобщения и дори предлагане на полезна информация в реално време, докато представител за обслужване на клиенти или продавач разговаря по телефона с клиент.

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

Ако вашата организация е като повечето, имате нарастващо изоставане от остарели приложения, които биха се възползвали от модернизацията. Наследените приложения обикновено използват остаряла технология и са изградени върху инфраструктура – хардуер и софтуер – която вече не се поддържа. Често само няколко служители, обикновено тези, които наближават пенсионирането, знаят как работят. Новите служители не искат да имат нищо общо с тях, защото не могат да използват съвременните инструменти, с които са свикнали или с които искат да работят. Поддържането им, да не говорим за актуализирането им, изисква мащабиране на планина от технически дълг, който става все по-висок колкото повече се изкачвате. Години, може би десетилетия на пачуърк поддръжка, водят до кодова база, която никой не смее да докосне – особено когато голяма част от бизнеса разчита на нея.

Организациите често не могат лесно да заменят тези приложения наведнъж. Вместо това те се впускат в постепенно пътуване на модернизацията. Постепенният подход максимизира ползите от модернизацията, като същевременно смекчава някои от рисковете от еднократно усилие за модернизация.

Опции за модернизиране на приложения

Модернизацията не винаги означава възстановяване на наследено приложение от самото начало. Други опции са оттеглянето му, замяната му, рехостинга, рефакторинга и преструктурирането му.

Таблицата по-долу описва всяка опция, етапа на ALM, когато е най-подходяща, и драйверите, които могат да повлияят на нейния избор.

Край на живота

Миграция

Модернизация

Пенсионират

Заменям

Повторно настаняване

Рефакторинг

Реархитект

Възстановяване

Описание

Премахване на приложението

Замяна на приложение със SaaS или друго приложение

Повторно разполагане както е в облака

Оптимизиране на съществуващия код

Преместете кода към нова архитектура на приложението или го разбийте на микроуслуги

Пренапишете приложението от нулата с оригинален обхват и спецификации

Шофьори

Вече не е необходимо

Намалете разходите

Намалете капиталовите разходи

Възползвайте се от по-новите технологии

Намалете капиталовите разходи

Възстановяване на съхранението на данни

Бърза възвръщаемост на инвестициите в облака

По-бързи и по-кратки актуализации

По-преносим код

По-голяма ефективност в облака по отношение на ресурсите, скоростта, разходите

Подобряване на ефективността

Намаляване на техническия дълг

Подобрете мащабируемостта, надеждността и поддръжката

Улеснете приемането на нови възможности в облака

Смесване на технологични стекове

Ускоряване на иновациите

Ускоряване на развитието

Намаляване на оперативните разходи

Технологии на Microsoft

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Контейнери

Azure PaaS

Power Platform

Azure PaaS

Микроуслуги без сървър

Power Platform

Azure PaaS

Микроуслуги без сървър

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

Опция	Описание
Повторно настаняване	Повторното хостване премества приложението такова, каквото е, от по-стара среда в по-нова. Подходът с нисък код не се прилага директно, но повторното хостване може да бъде първата стъпка преди прилагането на други стратегии, които биха включвали решения с нисък код.
Рефакторинг или преобразуване	Рефакторингът променя кода, така че приложенията да могат да извлекат максимална полза от облачната среда. Преструктурирането значително променя кода. Може да включва капсулиране на съществуваща логика чрез преместването й в API, който може да бъде изложен на решения с нисък код чрез конектор.
Подмяна или възстановяване	Замяната на приложение се заменя с друго. Възстановяването пресъздава приложение от самото начало. Тази опция обикновено е мястото, където подходът с нисък код постига най-добрите бизнес резултати. Започването с приложение от Dynamics 365 или Microsoft AppSource може да помогне за бърз старт на модернизацията, когато случаят на употреба съответства на предварително изградена възможност. След това организациите могат да използват Power Platform компоненти, за да персонализират приложението за своите уникални нужди.

Power PlatformПодходът с нисък код има потенциала да предложи много повече от просто още един инструмент за разработка. Превръщането на low-code в част от вашата модерна стратегия за приложения също може да създаде основа за овластяване на не-разработчици, като експерти по темата, да участват във вашите усилия за модернизация. Организациите са открили, че създаването на Център за върхови постижения (CoE) около Power Platform и използването на инструменти като CoE Starter Kit за създаване на насоки и управление помага на потребителите да създават приложения и автоматизации с нисък код успешно и гарантира, че активи като API и компоненти могат да бъдат използвани повторно. Low-code може да ускори разработването на приложения и да помогне на организациите да извлекат стойност от своите данни по-бързо, независимо къде се намират. Всъщност много организации решават да интегрират мисленето с нисък код в своята култура.

Ръководство за вашето пътуване към модернизация

Лесно е да се претоварите, когато започнете да мислите за модернизиране на наследени приложения. Водачът може да ви помогне да планирате пътуването си и да ви държи на правилния път по пътя. Добро място да започнете е с тези три стъпки, като се има предвид всяка от тях с мислене с нисък код.

1. Планиране. Помислете внимателно за целите си за модернизиране на наследено приложение и определете стратегията си за постигането им. Имайте ясно изложение на проблема, който искате да реши модернизацията. Това е моментът да оцените приложенията и средите си с оглед на това какво не работи, какво работи, но може да бъде подобрено и най-важното – каква е ползата за бизнеса или за потребителите от всички промени. Оценете всяка възможност за модернизация за нейния потенциал да се възползва от подхода с нисък код. Приоритизирайте възможностите, които включват решения с нисък код. Използвайте оценителя на стратегията за приемане в облака, за да изградите бизнес казус за модернизация на приложенията.

2. Изпълнение. Модернизирайте приложенията си не само постепенно, но и итеративно. Итеративният подход дава на организациите гъвкавостта да променят обхвата или стратегията на проекта си, ако е необходимо. Power Platform решенията с нисък код могат да бъдат разработени и тествани по-бързо от традиционно разработените приложения, а внедряването в управлявани среди изисква само няколко стъпки. Въпреки че low-code изисква по-малко повишаване на квалификацията от традиционното кодиране, уверете се, че вашите служители са подходящо обучени как да работят като екипи за синтез, които съчетават low-code и традиционни ресурси.

3. Операции. Модернизацията на приложенията не спира с внедряването. С подход с нисък код, ориентиран към облака, можете да използвате услугите и инструментите на облачната платформа, за да защитите, управлявате, управлявате и оптимизирате вашите приложения.

Оценете възможностите за решения с нисък код

Организациите използват различни методи, от неформален преглед до подробни дървета на решенията, за да определят дали подходът с нисък код е правилният начин за модернизиране на наследено приложение. Най-важното нещо, което трябва да имате предвид, е, че low-code не е решение от типа "всичко или нищо". Изграждането на част от приложение от Power Platform компоненти и част от него от компоненти, разработени с помощта на традиционни техники за кодиране, е често срещано.

За да оцените дадено приложение, препоръчваме първо да определите дали то все още е необходимо и полезно или трябва да бъде оттеглено. Ако решите, че все още е необходимо, преценете дали решение с нисък код може да замени приложението като цяло. Ако цялото приложение не е подходящо за подмяна с нисък код, преценете дали едно или повече от работните натоварвания или компоненти на приложението може да са подходящи. Може да откриете, че решение с нисък код, разширено с традиционно разработен код, предоставя най-доброто от двата свята.

Например, ако определите, че дадено приложение не е подходящо, защото Power Apps липсва задължителна контрола, можете да използвате компонентната Power Apps рамка (PCF) и традиционния код, за да създадете персонализирана контрола. Друг пример е приложение, което има сложна логика. Можете да централизирате логиката в API, до който Power Apps има достъп чрез персонализиран конектор. И в двата примера Power Platform разширяемостта позволи по-голямата част от приложението да бъде изградено с компоненти с нисък код, преодолявайки пропуските с традиционно разработения код.

NSure.com, собствена платформа за онлайн пазаруване на застраховки, предлага пример от реалния свят. Първоначалното стартиране на компанията разчиташе на традиционно разработените услуги Angular, Xamarin, и Azure. Чрез добавяне Power Platform и Dynamics 365 NSure.com създаде решение от следващо поколение, използвайки както техники за кодиране с нисък код, така и традиционни техники за кодиране, както илюстрира следващата диаграма. Научете повече за пътя на компанията.

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

Предни сценарии, които не отговарят на подхода с нисък код

Сценарий	Предизвикателство
Потребителското устройство не е съвместимо	Power Platform разпознава мобилни устройства и специализирани устройства като баркод скенери. Устройствата, които зависят от конкретни API или драйвери, може да не се поддържат и ще изискват по-традиционен подход.
Голям обем данни от страна на клиента	Потребителското изживяване в някои приложения изисква големи количества данни, предизвикателство за всяка технология, а не само за low-code. Изтеглянето и обработката на толкова много данни може да натовари бекенд системите и да влоши производителността както на приложението, така и на устройството, на което работи. Потребителите не са толкова продуктивни, когато са принудени да се ориентират в море от данни. Преди да се обърнете към традиционните методи за кодиране, за да се справите с натоварването, проучете дали правилното филтриране и навигация могат да осигурят по-добро потребителско изживяване.
Сложни офлайн изисквания	Приложенията, които трябва да работят на места, където свързаността е слаба или не съществува, могат да бъдат предизвикателство за внедряване и поддръжка, независимо дали използват low-code или традиционен код. Power Apps предлага основна възможност за прости офлайн сценарии. Например приложение, което улавя потенциални клиенти по време на събитие и ги качва в маркетингова база данни след събитието, ще работи добре. За приложения, които изискват файлове и изображения, неконекториDataverse или сложно разрешаване на конфликти, трябва да погледнете традиционните техники за код.

Сценарии от задния край, които не отговарят на подхода с нисък код

Сценарий	Предизвикателство
Данни за висока скорост	Обикновено се поддържа импортиране на милиони редове данни като част от миграции и подобни събития. Въпреки това, работните натоварвания, които включват обработка на милиони редове данни почасово или дневно, трябва да бъдат обект на повече оценка. Например, събирането на големи обеми телеметрия Dataverse на Интернет на нещата (IoT) няма да има смисъл. Вместо това облачните услуги на Azure могат да се използват за събиране и анализиране на данните и съответните сигнали, добавени за Dataverse задействане на действия в приложението. Приложенията, които включват голям обем актуализации на Dataverse данни редовно, може да изискват помощта на традиционния код за мащабиране на актуализациите.
Фонови натоварвания със сложна логика	Фоновите работни натоварвания, които включват сложна логика или голям обем извиквания на API, може да не са подходящи за решение с нисък код. Вместо това логиката може да бъде централизирана в API, който може да извика решение с нисък код.
API, които използват протоколи, които не са RESTful	Power Platform конекторите поддържат само REST API. Ако трябва да се свържете с друг стил API като SOAP или gRPC, осигурете свой собствен REST API, който комуникира с несъвместимия.

Препоръчваме да сте в крак с Power Platform вълните на освобождаване, защото те продължават да запълват пропуските в това, което можете да правите с решения с нисък код. Създаването на доказателство за концепция с нисък код е добър начин да определите дали вашият сценарий е подходящ.

Приоритизирайте възможностите с нисък код

Докато оценявате портфолиото си от приложения, не е достатъчно да идентифицирате добри кандидати за трансформация с нисък код. Вашият екип трябва да ги приоритизира, за да увеличи максимално успеха на вашите усилия за модернизация.

Приоритизирането трябва да вземе предвид следните фактори:

• Зрялостта на нисък код на вашата организация
• Сложността на възможността
• Възвръщаемост на инвестициите за организацията, потребителите и ИТ
• Време за оценяване

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

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

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

Първите няколко модернизации са важни, защото позволяват на организацията да види въздействието на low-code решенията. Оценяването на ползите и рисковете за заинтересованите страни в приложението е важно, когато приоритизирате възможностите. Изборът на приложение, от което никой не се интересува или което има ниско въздействие върху организацията, няма да бъде най-добрата демонстрация на предимствата на решение с нисък код.

Важно е приемането на модернизираното приложение от страна на потребителите. Потребителите трябва да чувстват, че тяхното ново приложение с нисък код се вписва заедно с останалите приложения, които използват. Друг риск за приемането е степента на персонализиране, с която са свикнали. Ако очакват високо персонализирано изживяване, може да са по-малко склонни да приемат решение с нисък код, което се чувства по-малко лично.

Организирайте и подобрете уменията си

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

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

Въпреки че е лесно по подразбиране да възложите цялата работа на традиционните разработчици, усилията за модернизация с нисък код са добри възможности за разширяване на екипа на проекта. Много бизнес потребители правят отлични ресурси с нисък код. Те могат да ускорят работата на екипа, защото вече разбират бизнес проблема. Те просто трябва да се научат как да изпълняват видовете работа с нисък код, които екипът поема, и да са запознати с процедурите за тестване и ALM. Това може да означава да се научите как да вграждате приложения Power Apps или работни потоци Power Automate. Те също така трябва да разберат какво могат да разработят традиционните програмисти, за да улеснят усилията си с нисък код. Това не означава, че те трябва да знаят как да пишат традиционен код.

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

Както low-code, така и традиционните кодови ресурси трябва да разбират къде започват и свършват решенията с нисък код и традиционните кодови решения и къде се пресичат.

Съберете изисквания

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

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

Избягвайте да работите срещу подходи с нисък код

Организациите, които са нови в модернизирането на приложения с решения с нисък код, често правят грешката да разработват low-code по същия начин, по който разработват традиционния код. Например една организация може да приложи UX стандарти, написани за Angular приложения, към първото Power Apps си внедряване. Екипът на проекта ще прекара ненужно време, опитвайки се да отговори на стандартите, които са проектирани за възможностите на Angular framework, а не за бизнес нуждите.

Екипите, които са свикнали да работят с традиционен код, може да се опитат да сведат до минимум ниския код. Например, вместо да използва Power Apps контроли, екипът може да изгради приложение от Power Apps контроли на компонентната рамка, за да избегне използването на нисък код, доколкото е възможно. Най-добре е отборите да стигнат възможно най-далеч с low-code, докато не достигнат блокери, които не могат да бъдат заобиколени. Екипите, които се научават как да се възползват от възможностите на платформата, са по-успешни в постигането на максималните предимства на low-code. Low-code продължава да става все по-способен да поеме това, което преди беше възможно само с традиционния код. Често срещано предизвикателство в миналото беше засядането, защото low-code не можеше да възпроизведе някои необходими функционалности. Power Platform Адресира това предизвикателство с опции за разширяемост, които позволяват на приложенията с нисък код да включват специализирани компоненти, написани в традиционен код, когато е необходимо.

Подходите с нисък код могат да играят важна роля във вашите стратегии за модернизация. Най-добрите резултати изискват ясно формулиране на проблема, който усилията за модернизация са предназначени да решат, планиране, персонал, който надхвърля ролите по подразбиране, обучение и приоритизиране. Извършването на подходящи корекции в техните стандарти и процеси, ако е необходимо, също помага на организациите да реализират пълния потенциал на low-code. Правилно извършената модернизация трябва да подобри общата бизнес стойност на модернизираните приложения.

Платформите с нисък код се развиха бързо през последните години. Въпреки че винаги са били добри в поддържането на индивидуални сценарии за производителност, напоследък фокусът е върху възможностите на предприятието. Организациите изграждат приложения с нисък код, които поддържат модерното работно място, включително хибридна работа (отдалечена и на място) и съпътстващата нужда от начини за насърчаване на сътрудничеството. Платформите с нисък код вече Power Platform могат да се мащабират, за да обработват приложения, на които всички потребители в организацията могат да разчитат и които могат да се интегрират в корпоративните модели за сигурност. Чрез свързване на възможности с нисък код към корпоративната инфраструктура можете да използвате техники с нисък код рамо до рамо с традиционните методи. Low-code абстрахира голяма част от сложността и позволява на по-широк кръг от хора да участват в изграждането на решения.

Разбиране на структурата на разходите на подхода с нисък код

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

Power Platform Продуктите са лицензирани продукти. Можете да ги лицензирате индивидуално, за да отговарят на вашите изисквания. Можете да конфигурирате фактурирането на Azure за плащане по време на употреба, което позволява използване без предварителен ангажимент за лиценз или покупка и включва известно използване в приложението Power Automate . Power Automate също така има лицензиране за потребител и за поток за самостоятелна работа. Лицензирането на поток работи добре, когато имате автоматизация, която е от полза за цялата организация. Power Apps Лицензите могат да бъдат за потребител или за приложение. Power Pages Сайтовете се лицензират за потребител, сайт или месец. За удостоверени сайтове е необходим допълнителен лиценз. Всички лицензи включват използване на конектори и Dataverse с опция за лицензиране на повече място за съхранение и заявки за API за сценарии с голям обем.

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

Когато оценявате цената на low-code в сравнение с традиционния код, важно е да осъзнаете, че сравнението не е ябълки с ябълки. С low-code плащате за труда за внедряване на уникален бизнес процес в продукта с нисък код и за лиценза на продукта за използването му. Като цяло лицензът включва множество приложения и автоматизации, без всяко от тях да изисква повече разходи.

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

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

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

Поглед навътре Power Platform

Power Platform Компонентите са изградени върху същите Microsoft Azure облачни услуги, които са налични, ако използвате традиционни методи за кодиране. Интегрирането на тези компоненти помежду си и с функциите за сигурност, мащабируемост и възстановяване след бедствие е направено вместо вас.

Вътре Dataverse

Dataverse се захранва от повече от 25 напълно управлявани услуги на Azure, като функции, балансьор на натоварването, Cognitive Services, Synapse, DevOps, Active Directory и Microsoft Purview. Вградените възможности включват цялостна защита, мощни анализи, AI, разширена бизнес логика и обработка на събития, моделиране на данни и интеграция с Dynamics 365, Microsoft 365 Azure и др. Всички тези възможности са изградени върху полиглотен Dataverse слой за съхранение, който е базиран на Azure SQL DB (за релационни данни), Azure Cosmos DB (за NoSQL), Azure Blob Storage (за файлове) и Azure Data Lake Storage Gen 2 (за широкомащабен анализ и дългосрочно съхранение на данни). Те са достъпни за прозрачна употреба в Power Platform компонентите с нисък код и чрез Dataverse REST API.

Високата наличност и непрекъснатостта на бизнеса и възстановяването след бедствие (BCDR) са важни за критичните за бизнеса приложения. Dataverse Увеличава максимално наличността с услугите за надеждност на Azure. Репликацията на първични и вторични сървъри е синхронна, с структура отдолу, която може да открие повреди и да избере нов основен сървър, следвайки протоколите за коректност. Отказите с висока наличност, които се случват в регион на Azure, са безпроблемни и рядко се забелязват от потребителите, обикновено се случват за секунди. Те гарантирано ще имат нулева загуба на данни, независимо дали прекъсването е планирано или непланирано.

Аварийните възстановявания при бедствие се случват в два региона на Azure. За да се осигури по-бързо превключване при отказ с минимална загуба на данни, се поддържа непрекъснато копие за възстановяване след бедствие с помощта на асинхронна репликация. Планираните откази не водят до загуба на данни и за производствени среди обикновено могат да бъдат завършени за секунди или няколко минути.

В допълнение към техническото внедряване на висока наличност и BCDR, оперативният екип редовно тества готовността си да реагира на различни видове събития.

Вътре Power Automate

Power Automate Потоците в облака са изградени върху Azure Logic Apps. Power Automate осигурява абстракции и интеграция с други компоненти с нисък код, като Power Apps и използва двигателя за изпълнение на Logic Apps. Разработчиците, които са запознати с Logic Apps, ще намерят Power Automate подобни понятия, включително езика на израза.

Вътре Power Apps

Двигателят Power Apps за изпълнение е изграден върху рамката React. Приложенията са вградени в дизайнера Power Apps , който използва интерфейс за плъзгане и пускане за изграждане на екрани. Power Fx формулите имплементират логика. Конекторите разширяват достъпа на приложенията до други услуги и логика и компоненти, които позволяват многократна употреба на визуални разширения. Разработчиците могат да използват компонентната Power Apps рамка (PCF), за да създават персонализирани контроли. Въпреки че много UI рамки могат да се използват заедно с PCF, Power Apps има вградена поддръжка за React.

Вътрешни конектори

Конекторите използват Azure API Management за управление на идентификационни данни и връзки от всеки потребител.

Една и съща архитектура се използва за всички конектори, включително персонализирани конектори, които създавате за собствените си API. Използването на Azure API Management осигурява последователен интерфейс за Power Platform продукти като Power Apps и Power Automate с всички конектори.

Изключение прави конекторът Dataverse . Той се появява в списъка с конектори за приложения и потоци, но е внедрен по различен начин. Когато приложение или поток използва Dataverse данни или действия, взаимодействието обаче е директно Dataverse на OData API.

Power Platform Опции за разширяване

Разширяемостта е ключова характеристика, която се отличава Microsoft Power Platform от другите платформи с нисък код. Водещ принцип на платформата е "без скали" - не трябва да бъдете блокирани да постигнете нещо с помощта на нисък код, дори ако това изисква традиционен код. Можете да създадете цяло работно натоварване като част от по-голямо приложение, като използвате традиционен код, ако е необходимо. Платформата обаче предлага много опции за разширяемост, които позволяват нисък код и традиционен код да се използват заедно в едно и също работно натоварване.

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

Опция	Описание
API и персонализирани конектори	Персонализираните конектори за вашите REST API централизират логиката на приложението и й позволяват да бъде изложена на компоненти с нисък код по сигурен и управляван начин. Можете да използвате този подход в стратегия за модернизация на приложенията. Персонализираният конектор използва документ, OpenAPI за да определи как компонент с нисък код може да взаимодейства с REST API. Например можете да създадете API с помощта на функциите на Azure и да го публикувате в Azure API Management. Azure API Management може да експортира OpenAPI дефиниция за автоматично създаване на персонализиран конектор за използване в решение с нисък код. Този подход отделя клиентските приложения от API, което им позволява да се развиват независимо. API се управляват централно, добавяйки слой сигурност, като не излагат API директно и използват техники за удостоверяване като абонаментни ключове, токени, клиентски сертификати и персонализирани заглавки.
Power Apps Компонентна рамка	Рамката Power Apps Component е рамка за разширяване за създаване на персонализирани визуализации за Power Apps и Power Pages. Компонентите на кода се създават с помощта на HTML, JavaScript или TypeScript. Мислете за компонентите на кода като за градивни елементи на потребителския интерфейс, които могат да се използват повторно за изграждане на едно или повече приложения. Компонентите включват манифест, който определя как компонентът с нисък код може да взаимодейства с компонента на кода. Интерфейсът на компонента позволява на механизма за изпълнение на хостинга да съобщава събитията от жизнения цикъл на контейнера за хостинг. Това позволява на компонента на кода да изобразява своите визуализации, като използва контекстна информация, предоставена от хостинг контейнера. За идеи разгледайте галерията на общността на https://pcf.gallery.
Виртуални маси	Виртуалните таблици улесняват интегрирането на данни, които се намират във външни системи. Те безпроблемно представят външните данни като таблици Microsoft Dataverse, без да репликират данните и често без нужда от персонализирано кодиране. Dataverse доставя се с доставчици на данни за OData v4 и Azure Cosmos DB. Доставчик на виртуален конектор, който в момента е в предварителен преглед, разширява наличните доставчици на данни, за да включи подмножество от конекторите Power Platform , включително SharePoint и SQL Server. За по-сложни сценарии разработчиците могат да създават персонализирани доставчици на данни. Създаването на персонализирани доставчици на данни изисква задълбочени познания както за външните данни, така и Dataverse. Възможността за създаване Dataverse на плъгини, използващи Power Fx логиката, е в предварителен преглед.
Dataverse Плъгини	Добавката Dataverse е персонализиран манипулатор на събития, който се изпълнява в отговор на конкретно събитие. Мислете за плъгини като съхранени процедури в двигател на база данни, но написани на .NET. Например събитията се появяват по време на обработка на Microsoft Dataverse операция с данни или при поискване за персонализирани събития в API. Приставката е имплементирана като персонализиран клас, компилиран в сглобка на .NET framework, която може да бъде качена и регистрирана. Dataverse Използвайки дефиниран интерфейс, приставката може да получи контекстна информация за събитието, което се обработва. Добавките могат да се изпълняват като част от транзакцията Dataverse и могат да извършват други операции с данни, които са част от текущата транзакция. Плъгините са предназначени за малки работни единици. Тяхната производителност трябва да бъде оптимизирана, така че да не влияе негативно на цялостната производителност. Плъгините винаги се изпълняват, независимо от операциите от потребителския интерфейс или API, което ги прави мощен начин за последователно налагане на бизнес логика.

Изследване на сценарии за модернизация на архитектурата с нисък код

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

Опит с приложението

Модернизирането на потребителското изживяване може да направи голяма разлика за потребителите. Power Apps е основният начин за изграждане на вътрешни изживявания на Power Platform приложенията. Можете да използвате Power Pages за вътрешни уеб приложения, но е по-често за приложения, насочени към външни лица.

Power Apps

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

Таблицата по-долу описва двата типа приложения, с които можете да създавате Power Apps, приложения за платно и приложения, управлявани от модел.

Тип ap	Описание
Приложения за платно	Приложенията за платно са много адаптивни. Те се състоят от един или повече екрани, с които потребителите взаимодействат. Вие контролирате оформлението на всеки екран и навигацията между екраните. Приложенията за платно работят с данни с помощта на конектори. Едно приложение може да работи с множество конектори, което го прави добро за интегриране в множество източници на данни като съставно приложение.
Приложения, управлявани от модел	Приложенията, управлявани от модел, се използват Dataverse като основен източник на данни. Те се състоят от една или повече страници, които могат да бъдат Dataverse таблици или персонализирани страници. Страницата Dataverse на таблицата може да бъде разбита до страница с подробности за преглед и редактиране. Персонализираните страници могат да включват екран на приложение за платно и данни от конектори. Приложенията, управлявани от модел, имат персонализирана вградена навигационна структура. Той е последователен във всички приложения, управлявани от модел, което помага за приемането от потребителите.

Следващата диаграма илюстрира основна архитектура за приложение за платно или приложение, управлявано от модел, в което приложението се свързва директно с източници на данни.

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

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

Използването Power Apps с вашите хранилища на данни или API ви позволява да модернизирате потребителското изживяване, като същевременно минимизирате прекъсването на други части на наследено решение. Този подход може също така да ви позволи да свържете множество наследени системи в едно приложение, давайки на потребителите едно място за завършване на работата си.

Power Pages

Основният източник на данни за Power Pages е Dataverse. Когато добавяте страници към уеб сайт, вие съхранявате дефинициите на страниците в Dataverse. Страниците могат както да представят Dataverse данни, така и да събират данни от потребителите, които да съхраняват в таблица Dataverse .

Можете да конфигурирате страници за анонимен достъп или за удостоверен достъп, като използвате Microsoft Entra ИД за вътрешни потребители или доставчици на самоличност за външни потребители. Когато удостоверените потребители имат достъп до данни, са налични само данните, до които имат разрешение за достъп.

Често срещано приложение на сайта Power Pages е предоставянето на външни потребители на достъп на самообслужване до организационен бизнес процес. Вътрешните потребители могат да използват Power Apps приложение. Следващата диаграма илюстрира такава архитектура.

Управление на данни

Модернизацията на приложението изисква оценка на данните, които се използват в цялостното решение. Модернизираните приложения имат множество опции за обработка на данни. В много случаи множество приложения използват едно и също хранилище за данни. Става трудно да се мигрират данните в ново хранилище като част от модернизирането на едно от приложенията. Основен принцип Power Platform е, че данните могат да се използват там, където са, или да се внасят в платформата в едно Dataverse от тях или в езеро от данни.

Имате следните опции за архитектурата на данните на модернизираното приложение:

• Оставете данните на място: Използвайте конектори или API с персонализирани конектори за достъп до данните, където се намират. Когато данните са локални, шлюзът за данни може да улесни защитената свързаност. Използвайте виртуални таблици, за да интегрирате съвместими външни данни като таблица Dataverse .

• Мигриране към Dataverse: Dataverse е добър вариант за транзакционни данни и за консолидиране на множество източници в една система за запис. Данните могат да бъдат картографирани и мигрирани от много източници с помощта Power Query на автоматизирани потоци. Dataverse Поддържа и еластични таблици, предназначени за поглъщане на данни с голям обем, които се съхраняват в неструктурирани или полуструктурирани формати.

• Мигриране към езеро с данни: За исторически, аналитични или телеметрични данни използвайте езеро от данни. Данните в езерото могат да се използват за генериране Power BI на анализи или да се обработват за генериране на прозрения, задвижвани от AI.

Когато оценявате опциите за архитектурата на данните на модернизирано приложение, имайте предвид следните съображения:

• Въздействие върху други приложения: Въпреки че мигрирането към по-ефективно хранилище за данни може да е идеално за едно приложение, първоначалното въздействие върху други приложения, които използват данните, може да е твърде голямо. Някои организации обмислят да оставят данните в стари хранилища за данни и да създадат нови данни Dataverse, като мигрират от старото хранилище, тъй като все повече приложения се модернизират.

• Въздействие върху новите приложения: Оставянето на данни в старо хранилище за данни, макар и лесно, може да повлияе негативно на това колко лесно модернизираните приложения могат да ги използват. По-старите хранилища за данни може да нямат добра интеграция с други облачни услуги, което затруднява включването на данните в новата цялостна архитектура.

• Консолидация на данни: Обичайно е като част от модернизацията на приложенията да се идентифицират данни, които нямат ясна собственост или отговорност за гарантиране на правилното им използване. Чрез консолидиране на данните Dataverse си организациите могат да подобрят управлението си и по-добре да гарантират, че се използват правилно.

• Поверителност и сигурност на данните: Трябва да оцените поверителността и сигурността въз основа на текущите си нужди и целева архитектура за модернизация, а не само на начина, по който наследеното приложение се е справило с тях. Облачните решения имат повече възможности за прилагане на контроли за поверителност и сигурност. Често едно хранилище за данни може да ги опрости. Трябва също така да помислите как да внедрите унифицирана защита на данните в хибридни приложения, които разделят данните в множество хранилища.

• Проблеми с интеграцията. По-старите хранилища за данни може да нямат API, необходими за разрешаване на достъп, без да се мигрират данните или да се създава API, който приложенията могат да използват с персонализиран конектор. Свързаността от старото хранилище за данни към приложенията, които го използват, трябва да бъде оценена, за да се определи дали производителността би била приемлива.

Трябва да определите архитектура на данните за всяко приложение, което ще бъде модернизирано. Първата стъпка е да установите цялостна визия за това как вашите архитектури на данни се включват Dataverse. Ако целта е да увеличите максимално стойността на low-code, тогава трябва да го използвате Dataverse , когато е възможно. Наличието на визия в началото може да ви помогне да избегнете разпространението на повече силози от данни.

Външни данни и Dataverse

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

Виртуалните таблици се реализират с помощта на архитектура на доставчик на данни. Dataverse включва доставчик на OData, който може да се използва с уеб услуги на OData V4. Доставчик на данни за виртуален конектор, който в момента е в предварителен преглед, позволява използването на таблични Power Platform конектори като виртуални таблици.

Следващата диаграма илюстрира използването на виртуалния конектор.

Разработчиците могат също така да създават персонализирани доставчици за други външни източници на данни. Те обаче трябва да разберат и приложат всички Dataverse картографии и оперативна поддръжка.

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

• Всички външни източници на данни трябва да имат първичен ключ и доставчикът на данни трябва да го представи като GUID на Dataverse. Можете да поставите ключове, които не са GUID, с пълнеж, ако добавената стойност е стабилна и уникална.
• Защитата на данните се конфигурира на ниво виртуална таблица. Защитата на ниво ред и колона не е налична.
• Производителността на виртуалните таблици зависи от доставчика на данни, API на външния източник на данни и свързаността с източника на данни. В повечето случаи достъпът до виртуални маси е по-бавен, отколкото при локалните Dataverse таблици.
• Някои Dataverse функции като търсене, проверка, диаграми и табла и офлайн достъп не са налични за виртуални маси.
• Използването на виртуални таблици за референтни данни може да доведе до намалена синхронизация.

Файл и изображения

Когато модернизирате приложения, които използват файлове и изображения, е важно да вземете предвид къде ще ги съхранява новото решение. Dataverse има специализирани възможности за съхранение на файлове и изображения. И двете могат да се добавят към таблици като колона и се съхраняват в Azure Blob Storage, което се управлява от Dataverse. Приложенията могат да работят с тях с помощта на конектора Dataverse , не се изисква отделно удостоверяване или API.

Използването Dataverse на файлове и изображения е подходящо, когато те имат директна връзка с данните и не е необходимо множество потребители да си сътрудничат по тях; например снимка на продукт или местоположение или окончателно копие на правен договор. Въпреки това, ако няколко потребители трябва да променят правния договор едновременно, използването SharePoint ще осигури по-големи възможности за сътрудничество. Помислете за директно използване на хранилището за BLOB на Azure, ако трябва защитата да се управлява отделно от Dataverse или ако трябва да използвате определени функции, специфични за файла.

Интеграции

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

• Интегрирането на данни комбинира данни от различни източници, за да даде на потребителя унифициран изглед. Той предлага необвързан подход, но не позволява изграждането на логика или процеси в реално време. Производителността може да бъде по-добра, защото всички данни са локални.

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

• Интеграцията на процеси свързва множество различни системи, всяка от които е част от цялостния бизнес процес. Този тип интеграция е най-несвързана, позволявайки на участващите системи да се справят с всяка част от бизнес процеса. В сценарии за модернизация може да бъде полезно да разделите част от процеса за модернизация с low-code, интегриран с други части, които все още се обработват от наследена система.

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

Следните съображения могат да ви помогнат да прецените как да приложите съществуващите интеграции:

• Все още ли е необходима интеграция? Не е необичайно да разберете, че вече никой не използва резултатите от интеграцията и тя може да бъде пенсионирана.

• Има ли предизвикателства при свързаността, ако модернизираното приложение е в облака? Предизвикателствата могат да включват забавяне и достъп до локален API или хранилище за данни. В някои случаи локалният шлюз за данни може да помогне за достъп до услугата или данните от облака. Когато достъпът до данните или услугата е твърде бавен, помислете дали можете да направите данните локални за модернизираното приложение или да извършите интеграцията във фонов режим.

Интеграцията също може да помогне за правилния размер на модернизираното приложение. Можете да разделите една или повече части от наследеното приложение, за да ги оставите или да ги приложите в отделно приложение. Този подход би работил добре, когато потребители с различни роли използват различни части от наследеното приложение. Можете да внедрите една или повече от ролите с помощта на low-code и да използвате интеграция на процеси, за да позволите на съществуващото приложение да се справи с останалите части на процеса. Използвайки този подход, можете постепенно да модернизирате останалите части с течение на времето. Отделното прилагане на независими части от процеса също може да улесни по-гъвкавия начин за внедряване на подобрения, независимо от другите части на процеса.

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

• Microsoft TeamsПриложенията и Power Apps агентите на : Copilot Studio canvas могат да бъдат вградени в каналите на Teams. С помощта на конектора на Teams приложенията и потоците могат лесно да публикуват и консумират съобщения в Teams. Power Apps картите могат да се използват като микроприложения за споделяне на полезна информация в канал на Teams.

• SharePoint: Power Apps Приложенията, управлявани от модел, могат да бъдат конфигурирани да се свързват с документи, съхранявани в библиотека SharePoint , за да ги направят достъпни в Dataverse ред. Със списъци на Microsoft или SharePoint списък потребителите могат да изпълняват Power Automate потоци в контекста на елемент от списък.

• Power BI: Power BI insights може да се показва в контекста на Power Apps приложение за платно. Можете да вградите приложение, управлявано от модел, в отчет, Power BI за да позволите на потребителите да действат въз основа на статистиката, без да напускат Power BI.

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

• Dataverse персонализирани API могат да се използват за входяща интеграция на ниво приложение. Персонализираните API предоставят уникална операция, която е свързана с малко количество персонализирана логика на кода. Например, изпращащата система може да използва персонализирания RequestNewProject API и свързаната с него логика ще знае как да постави получените данни в съответните Dataverse таблици. Системата за изпращане ще бъде абстрахирана от структурата на таблицата Dataverse .

• Изходящата интеграция може да се извърши с помощта на възможностите за публикуване на събития на Dataverse. Dataverse може да бъде конфигуриран да публикува в Azure Service Bus, Azure Event Hubs или всеки приемник на Webhook. Например, когато се създаде нов Dataverse ред на таблица на проект, той може да бъде публикуван в опашка на служебна шина на Azure. Можете също така да публикувате повече концептуални събития, които съответстват на събитие на бизнес процес. Например можете да дефинирате и публикувате събития, когато проектът е завършен.

Следващата диаграма илюстрира пример за входящи и изходящи събития в среда Dataverse .

Организациите също трябва да обмислят предварително изградени опции за интеграция, достъпни от трети страни. Microsoft AppSource Например Microsoft има предварително изградено решение за организации, с които трябва да се интегрира SAP Power Platform. Това предварително изградено решение включва приложения и потоци и добавя нови функционалности, които улесняват комуникацията между SAP системата на вашата организация и Power Platform.

Например, Ernst & Young използва предварително изградената SAP интеграция, за да разработи бързо решение за оптимизиране на високочестотния глобален финансов процес. Следващата диаграма на решението PowerPost на компанията показва как финансовите потребители публикуват документи в нейната SAP ERP система на General Ledger. Power Platform

Опции за свързване на интеграцията

Тъй като решенията се преместват в облака, свързаността обратно към локалните ресурси може да бъде от съществено значение, за да се гарантира, че интеграциите все още работят с модернизираното приложение. Тези приложения също трябва да могат да се интегрират с други традиционни облачни ресурси, които могат да се намират в различни мрежови среди. Той Power Platform поддържа четирите основни опции за сигурна свързаност: шлюзове за данни, виртуални мрежови шлюзове за данни, частни връзки и ExpressRoute.

• Шлюзовете за данни позволяват компоненти с нисък код от Power Apps Power Automate и Power BI да достигат до локални ресурси, за да поддържат сценарии за хибридна интеграция. Шлюзовете предоставят бърз начин за модернизирани приложения с нисък код за достъп до източници на данни, които все още са локални. С шлюз можете да се свържете с локални данни от източници като локална файлова система, DB2, Oracle, SAP ERP, SQL сървър и SharePoint. Един шлюз може да поддържа множество потребители и достъп до множество източници. Можете също така да конфигурирате шлюзове за данни като клъстери, за да осигурите висока наличност.

  Поддръжката на шлюз е интегрирана в процеса на свързване на конектори, което позволява индикация кога е необходим шлюз и избор на конфигурирания шлюз. След като връзката е конфигурирана, приложенията и потоците могат да използват конектора точно като такъв без шлюз.

  

• Шлюзовете за данни на виртуална мрежа позволяват Power BI на Power Platform потоците от данни да се свързват с услуги за данни във виртуална мрежа на Azure, без да е необходим локален шлюз за данни на виртуална машина във виртуалната мрежа.

• Azure Private Link и частните крайни точки на Azure в мрежа позволяват на приложенията и потоците да имат защитен достъп Power BI . Частните крайни точки се използват за частно изпращане на трафик от данни с помощта на опорната мрежова инфраструктура на Microsoft, вместо да преминават през интернет. Частните крайни точки гарантират, че трафикът, Power BI влизащ в ресурсите на вашата организация, като например отчети или работни области, винаги следва конфигурирания път на мрежата за частна връзка на вашата организация.

• Azure ExpressRoute предоставя разширен начин за свързване на вашата локална мрежа с услуги в облака на Microsoft чрез частна връзка. Една връзка с ExpressRoute може да получи достъп до множество онлайн услуги като Power Platform Dynamics 365 Microsoft 365 и облачни услуги на Azure, без да обхожда публичния интернет. ExpressRoute изисква значително планиране и конфигуриране и включва повече разходи за услугата ExpressRoute и доставчика на свързаност.

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

Бизнес логика

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

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

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

• Поставянето Power Apps на бизнес логика в приложението с нисък код е най-простият подход, но предоставя ограничени възможности за повторна употреба или за налагане на последователност между приложенията и автоматизациите. Като цяло трябва да ограничите този подход до некритична, проста логика, която други приложения или автоматизации не трябва да използват. Инструментите с нисък код не предоставят изживяване за отстраняване на грешки ред по ред. Ако логиката обхваща повече от един екран или е трудна за четене, трябва да обмислите други подходи, които биха били по-поддържани. Не е необичайно някаква бизнес логика да се дублира локално в приложението и в облака. Например, ако потребител въвежда хотелска резервация, бизнес правилото е, че датата на напускане не може да бъде преди датата на настаняване. Ако приложението не потвърди това, потребителят ще стигне до края и ще изпрати резервацията само за да открие, че персонализираният конектор я е отхвърлил. Обработката на валидирането локално в приложението и в облака осигурява много по-добро потребителско изживяване.

• В облачен Power Automate поток: Можете да изразите бизнес логика в действията в поток и потокът може да се задейства в отговор на събитие или заявка за изпълнение при поискване от други приложения и потоци. Потокът може да осигури подход с нисък код за централизиране на логиката. Стъпките в потока са независими и не са част от транзакция; Потоците обаче могат да прилагат компенсация, за да се справят с връщане, ако възникнат грешки. Потоците могат да изпълняват стъпки, използвайки връзки, които имат разрешения извън това, което потребителят на приложението може да направи, предоставяйки начин за повишаване на разрешенията. Този подход също така позволява минимизиране на разрешенията, от които потребителят на приложението може да се нуждае.

• В Dataverse добавка: Добавките се изпълняват в отговор на събитие на ред с данни, като създаване, актуализиране или изтриване. Тази логика се изпълнява всеки път, когато възникне събитието, независимо кое приложение или поток е извършило действието или дали е извършено директно от Dataverse API. Предимството на това поведение е, че осигурява последователност при всички употреби. Освен това всички Dataverse промени в данните от логиката на приставката са транзакционни и или всички са завършени, или всички връщане назад. Приставката трябва да бъде кратка и ефективна и да не се опитва да прилага дългосрочна работа. Понякога добавките за събития не са най-добрият подход, ако трябва да слушате събития на няколко маси, за да завършите едно бизнес събитие, като например "Затваряне на проверката". Например можете да помислите за персонализиран Dataverse API, вместо да имате приставки в няколко таблици. Добавките могат да изпълняват логика с повишени разрешения, които потребителят обикновено няма. Този подход също така позволява минимизиране на разрешенията, от които потребителят на приложението може да се нуждае. Приставките могат да се внедряват в решение Dataverse заедно с приложения и потоци.

• В Dataverse персонализирани API: Dataverse персонализираните API ви позволяват да внедрите свое собствено персонализирано API съобщение, което може да изпълнява логика. Например можете да създадете персонализиран API за затваряне на проверката, който се извиква, за да свърши цялата работа по проверка и затваряне на проверка. Няма да се управлява от събития, а ще се използва при поискване от приложенията и потоците, които се нуждаят от него. Подобно на управляваните от събития приставки, промените в данните, извършени в персонализираната приставка за API, са транзакционни. Персонализираният API е най-добър, когато единствената услуга, която използва, е Dataverse API за друга работа с данни. Добавките за персонализирани API могат да се внедряват в решение Dataverse заедно с приложения и потоци.

Внедряване на API за код

Можете да внедрите API в любимата си среда за изпълнение на хостинг на API, като например функции на Azure, Azure Container Apps или всяка услуга, която може да хоства REST API. Тези персонализирани API могат да внедрят всякаква логика и както приложенията с нисък код, така и традиционните кодове могат да ги използват. Персонализираните API не предоставят никаква поддръжка за транзакции, освен тази, която може да бъде предоставена от използвания от тях API. Например персонализиран API може да използва конструкции за транзакции на SQL Server, ако използва SQL Server. Внедряването на API за код ще бъде независимо от ресурсите с нисък код, които могат да го използват. Можете да използвате Azure API Management, за да управлявате използването на тези API и да ги направите по-откриваеми.

Защита

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

Power Platform използва многопластов подход към защитата, който можете да използвате, за да изградите вашата архитектура за защита. Основен принцип на тези възможности е, че решенията с нисък код трябва да се интегрират със съществуващия ви апарат за сигурност, за да се сведе до минимум въздействието от въвеждането им.

Нека да разгледаме на високо ниво множеството нива на сигурност, които съставляват модела на Power Platform сигурност.

• Потребителите се удостоверяват с Microsoft Entra ИД и използването може да бъде ограничено с помощта на правила за условен достъп.
• Лицензирането е първата контролна врата за разрешаване на достъп до Power Platform компоненти.
• Възможността за създаване на приложения и работни потоци се контролира от ролите за защита в контекста на средите.
• Способността на потребителите да виждат и използват Power Platform ресурси се контролира чрез споделяне на приложението с тях. Ресурсите се споделят директно с потребителя или групата Entra ID.
• Средите действат като граници на сигурността, позволявайки да се прилагат различни нужди за сигурност във всяка от тях.
• Power Automate Приложенията за потоци и платно използват конектори. Конкретните идентификационни данни за връзка и свързаните с тях права за услуги определят разрешенията, когато приложенията използват конекторите.
• Среди с Dataverse екземпляр поддържат по-усъвършенствани модели за защита, които са специфични за контролиране на достъпа до данни и услуги в този Dataverse случай.
• Използването на конектора може да бъде допълнително ограничено с политики за предотвратяване на загуба на данни (DLP). Към съединителите могат да се приложат и ограничения за входящи и изходящи наематели.

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

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

Проектирайте своя модел за защита

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

• Самоличност на потребителя: Как потребителите се удостоверяват и това вече е съпоставено в Microsoft Entra ID в сценарии, идващи от локално? Това включва картографиране на групи, необходими за поддържане на присвояване на група или екип в облачни хранилища за данни като Dataverse.

• Идентичност на връзката на конектора: Когато приложенията използват един или повече конектори, какъв тип удостоверяване се извършва за връзката и осигурява ли нивото на контрол, необходимо за внедряване на необходимите контроли за сигурност? Например приложенията, които използват принципал на услугата за свързване, не изискват потребителят на приложението да има директен достъп до конектора, което може да бъде от полза в някои сценарии. Отделните потребителски връзки могат да бъдат подходящи за приложения, които трябва да знаят кой потребител е извършил операция или да обхванат отговорите на конкретни потребители.

• Преносимост на конструкцията за сигурност: Тъй като вашите приложения използват повече конектори и хранилища за данни, важно е да запомните, че не всички конструкции за сигурност на една карта се съпоставят директно с друга. Например Dataverse има няколко начина, по които потребителят може да получи достъп до ред с данни, включително споделяне на реда с потребителя. Ако дадено приложение свърже библиотека с SharePoint документи с реда, защитата, която дава достъп до библиотеката с документи, е отделна от защитата, която контролира Dataverse достъпа. Те не картографират директно. Модернизираните приложения трябва да се съобразяват с тези видове несъответствия между конекторите и хранилищата за данни, които използват.

Изкуствен интелект

През последните няколко години AI намери своя път в усилията за модернизация на приложенията. Когато модернизират приложенията, организациите трябва да обмислят използването на изкуствен интелект, за да направят потребителите по-продуктивни и по-способни да вземат информирани решения. Резултатите от вливането на AI могат също да се превърнат в по-добро изживяване на клиентите, което влияе положително на бизнес резултатите.

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

Microsoft въведе Copilots в основните продукти и услуги, за да улесни достъпа до усъвършенствана AI технология. Copilot използва съвременни техники за изкуствен интелект и големи езикови модели и може да взаимодейства с потребителите в приложенията, които използват всеки ден, като Microsoft 365 Windows, Dynamics 365 и Power Platform.

Разширете с плъгини

Потребителите на приложения, задвижвани от Copilot, могат да поискат помощ от Copilot с често срещани задачи в приложението. Можете да разширите Copilots, за да включите данни и задачи, които все още не знаят и които са извън обхвата на приложението, с което потребителят работи. Microsoft 365 Copilot може да включва Power Platform съхранявани Dataverse данни, така че потребителите да не трябва да превключват напред-назад между приложенията. Например от Outlook потребителят може да поиска от Copilot да генерира актуализация на състоянието за всички неуспешни проверки, завършени днес. Microsoft 365 Copilot автоматично наследява вградената рамка за сигурност и управление и Dataverse прилага потребителска сигурност и разрешения по време на изпълнение.

Конектори като плъгини

Power Platform конекторите също са важни за изживяването на Copilot. Конекторите могат да се свързват като плъгини, за да разширят възможностите на Copilot. Например, Microsoft 365 Copilot с конектора Power Platform за Jira Software може да позволи на ръководителя на проекта да поиска състоянието на билет за поддръжка на Jira и да действа въз основа на отговора, като например да го насочи за повече одобрение или да започне поръчка за покупка на нов хардуер. С помощта на плъгини можете да интегрирате вашите бизнес процеси и данни с Copilot, за да дадете възможност на потребителите да взаимодействат от всички приложения, които използват.

Създайте свой собствен втори пилот

Тъй като потребителите свикват да имат помощ за изкуствен интелект в своите приложения, те я очакват във всички приложения. Можете да направите съвременните си приложения по-ангажиращи, като включите втори пилоти, които създавате с Copilot stack, рамка за разработка на AI.

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

Управление на жизнения цикъл на приложение

Важна част от всяко усилие за модернизация е създаването на подходящ процес на управление на жизнения цикъл на приложението. Организациите често искат усилията им да се впишат в начина, по който работят с традиционния код ALM. Power Platform предоставя ALM инструменти, така че да можете да включвате артефакти с нисък код в или заедно с процесите, които обикновено използвате.

ALM започва Power Platform с начина, по който изграждате ресурсите си с нисък код. Ресурсите, които изграждате, са в контекста на Power Platform среда. Средата може да има едно Dataverse хранилище за данни. Можете да използвате множество среди – обикновено разработчици, тестове и производство – за да внедрите целеви зони в ALM процес, който включва low-code. Броят и предназначението на средите са гъвкави и организациите могат да ги адаптират, за да отговорят на индивидуалните нужди на проекта. Dataverse Решението е контейнер за свързани low-code ресурси, улесняващ контрола на версиите и транспортирането от една среда в друга.

Power Platform тръбопроводите осигуряват подход с нисък код за автоматизиране на внедряването и внедряване на непрекъсната интеграция и непрекъсната доставка (CI/CD). Power Platform управлява процеса, когато конвейерите са конфигурирани. Администраторите могат централизирано да управляват и управляват тръбопроводите.

Организациите могат също да използват CI/CD инструменти по свой избор. Power Platform CLI е инструмент за команден ред, който можете да използвате с повечето инструменти за автоматизация на CI/CD. Power Platform Build Tools предоставя действия за GitHub и задачи за Azure DevOps това предоставят всички общи действия, необходими за изграждане на CI/CD автоматизации, които включват артефакти с нисък код.

Следващата диаграма илюстрира пример за тийм, който изгражда приложение за инспекция. Във вътрешния си цикъл те работят в среда за разработка и съхраняват работата си в Git хранилище. Външният цикъл се състои от тестова среда и производствена среда. Тръбопроводът за изграждане взема решението, контролирано от версията, извършва всички необходими проверки и произвежда артефакт на решение за проверка. След това тръбопроводът за издание внедрява решението за тестване, където тестерите могат да проверят дали е готово за производство. След като бъде одобрен, конвейерът за издание внедрява решението в производството.

Когато експортирате решение от Dataverse него, то се експортира като един компресиран файл. За да съхранявате ресурсите с нисък код в контрола на версиите, можете да използвате инструмента за изграждане, за да разопаковате файла с решение в отделни файлове на компоненти. По време на автоматизацията на компилацията инструментите за изграждане комбинират отделни файлове от контрола на версиите в един компресиран файл.

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

Когато вашето модернизирано приложение включва ресурси с нисък код и традиционни кодови ресурси, можете да ги комбинирате в един CI/CD процес или да ги управлявате независимо. С независимо управление ресурсите могат да се използват индивидуално и проектните екипи могат да постигнат по-голяма гъвкавост. Например, API, който използва приложение с нисък код, може да се разгърне независимо, ако екипът не въведе извънредни промени.

Мониторинг и прозрения

Модернизираните приложения трябва да се интегрират в оперативни среди, които предоставят възможност за диагностициране на проблеми в различни среди, от разработката до производството. Application Insights, разширение на Azure Monitor , събира телеметрия от Power Apps и Dataverse. Тази информация не само помага при идентифицирането и разрешаването на проблеми, но също така предоставя информация за това какво правят потребителите в приложението. Можете да използвате тези прозрения, за да помогнете за подобряването на приложенията и процесите във вашето модернизирано приложение.

Докато дадено Power Apps приложение е в процес на разработка, разработчиците могат да включат логика за регистриране на персонализирани събития. След като свържете разположеното приложение Application Insights, разширението автоматично събира основна телеметрия, включително повече контекст от регистрирани събития, докато потребителите взаимодействат с приложението.

Администраторите могат също да конфигурират Dataverse среди за експортиране на Application Insights телеметрия. Данните, които се регистрират, могат да включват Dataverse извиквания на API, изпълнение на приставки, операции с SDK и изключения. Разработчиците, създаващи персонализирана логика на добавката, могат да регистрират повече персонализирани телеметрични данни директно Application Insights.

Използването Application Insights във вашите приложения може да улесни свързването на проблеми с множество ресурси. Оперативният персонал може да създава предупреждения в Azure Monitor, които да се задействат, когато бъдат открити голям брой изключения. Редовният анализ на вашите модернизирани приложения може да идентифицира тенденции, които изискват повече проучване.

Заключение

В тази бяла книга разгледахме ползите, стратегиите и най-добрите практики за модернизиране на вашите наследени приложения Microsoft Power Platform. Получихте Power Platform прозрения и насоки относно възможностите за използване на нисък код, за да гарантирате успеха на усилията си за модернизация като част от дигиталната трансформация на вашата организация.

Наследените приложения представляват много предизвикателства за организациите. За да ги преодолеят, организациите трябва да предприемат инициативи за модернизация на приложенията, за да съживят инфраструктурата си и да се възползват от модерните технологии. В тази бяла книга видяхте как да възприемете подход с нисък код към усилията си за модернизация – по-специално как възможностите Microsoft Power Platform за разработка с нисък код ви позволяват бързо да създавате и внедрявате модерни приложения.

Low-code отваря вратата за по-широк кръг от хора от традиционните програмисти. Ключов фактор за организациите, които успяват с подход с нисък код, е да се уверят, че хората, участващи в модернизирането на приложенията, имат обучение за разработка с нисък код, независимо дали са професионални разработчици или бизнес потребители. Бизнес потребителите са по-близо до решавания бизнес проблем и могат да допринесат за спестяване на време. Традиционните разработчици на код могат да прилагат техниките и уменията, които вече имат, за да изградят разширения, за да запълнят всички пропуски в нисък код. Организациите могат да бъдат най-ефективни, като смесват бизнес и технически ресурси в това, което обичаме да наричаме "сливащи екипи".

Тази бяла книга създава основата за вас. Следващите стъпки са ваши. Ето няколко предложения:

• Отделете няколко минути, за да разберете какво вече прави вашата организация с нисък код. Може да ви изненада!
• Оценете възможностите си за модернизация на приложенията.
• Идентифицирайте и приоритизирайте добър първи кандидат.
• Персонал екип, който модернизира приложението. За най-добри резултати се уверете, че това е екип за синтез.
• Уверете се, че екипът има необходимото обучение, за да бъде успешен.
• Позволете на екипа да модернизира приложението.
• Помислете върху усилията за модернизация. Прецизирайте и мащабирайте го до други наследени приложения.

Пътят на всяка организация към модернизация на приложенията е уникален. Вашият екип за акаунти или Power Platform партньор в Microsoft може да ви помогне да планирате пътуването си и да ви държи на правилния път по пътя.

Ресурси

• Общото икономическо въздействие™ на Microsoft Power Platform премиум възможностите
• Приложението American Airlines ConnectMe създава по-гладко пътуване за клиентите и по-добри технологични инструменти за членовете на екипа
• Power Fx хранилище с отворен код в GitHub
• Стартов комплект на CoE
• Power Platform Оценка на приемането
• Дигиталната застрахователна агенция автоматизира сложен процес на покупка с помощта на Power Platform
• Галерия на PCF
• EY помага да се даде възможност за навлизане при източника на глобален финансов процес с Power Platform 95%
• Azure Private Link
• Майкрософт Azure ExpressRoute
• Power Platform Планиране на изданието
• Microsoft Power Platform Ръководство за лицензиране
• Microsoft очертава рамка за изграждане на AI приложения и втори пилоти; разширява екосистемата от плъгини за изкуствен интелект