Створити виправлення для простішого оновлення рішень

Якщо додати таблицю до рішення та експортувати рішення, таблиця та всі пов’язані з нею активи експортуються в цьому рішенні. До таких ресурсів належать стовпці (атрибути), форми, подання, зв’язки та візуалізації, а також будь-які інші активи, які входять до таблиці. При експортуванні усіх цих об'єктів варто розуміти, що існує ризик ненавмисного змінення об'єктів у цільовому розгортанні або перенесення небажаних залежностей.

Щоб усунути залежності, можна створювати та публікувати патчі рішень, які містять підкомпоненти таблиць, а не публікують усю таблицю та всі її ресурси. Вихідне рішення та одне чи більше пов'язаних виправлень можуть додаватися (вливатися) пізніше до оновленої версії рішення, яка у подальшому замінить вихідне рішення у цільовій організації Microsoft Dataverse.

Виправлення

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

Патчі зберігаються в Dataverse базі даних у вигляді Solution записів таблиць. Ненульове значення атрибуту ParentSolutionId означає, що це рішення є виправленням. Патчі можна створювати та керувати ними через SDK для .NET або Web API, які корисні для розробки автоматизації, наприклад, сценарію встановлення продукту. Тим не менш, веб-програма Dataverse надає різноманітні веб-форми для інтерактивного створення виправлень та керування ними.

• Виправлення можуть створюватися тільки з батьківського рішення з використанням CloneAsPatchRequest або CloneAsPatch Action.
• Батьківський елемент латки не може бути латкою.
• Виправлення може мати тільки одне батьківське рішення.
• Латка створює залежність, на рівні розв’язку, від свого батьківського рішення.
• Виправлення можна інсталювати лише тоді, коли присутнє батьківське рішення.
• Ви не можете інсталювати виправлення, якщо унікальне ім’я та номер основної або проміжної версії батьківського рішення, як визначено ParentSolutionId, не збігаються з назвами батьківського рішення, встановленого в цільовій організації.
• Версія виправлення повинна мати точно такі основний та проміжний номери, але номери збірки та випуску вищі, ніж такі номери для версії батьківського рішення. Коротке ім'я може відрізнятися.
• Якщо рішення має виправлення, наступні виправлення повинні мати у номері версії більші числа, ніж в будь-якого існуючого виправлення для цього рішення.
• Виправлення підтримують такі ж операції, як і рішення, як-от неповне оновлення, але не видалення. Ви не можете видалити компоненти з розчину за допомогою пластиру. Щоб видалити компоненти з рішення, слід виконувати перехід на наступну версію.
• Виправлення, що експортуються як керовані, повинні імпортуватися поверх керованих батьківських рішень. Як правило, захист виправлення (керованого або некерованого) повинен співпадати із батьківським рішенням.
• Не використовуйте некеровані виправлення для виробничих цілей.

Інструменти SolutionPackager та PackageDeployer підтримують виправлення рішень. Параметри командного рядка, пов'язані із виправленнями, шукайте у онлайн-довідці для відповідного засобу.

Створення виправлення

Створіть патч із некерованого рішення в середовищі за допомогою CloneAsPatchRequest повідомлення або дії CloneAsPatch, або за допомогою веб-програми. Як тільки ви створюєте патч, оригінальне рішення стає заблокованим, і ви не можете змінити або експортувати його, доки в середовищі існують залежні латки, які ідентифікують рішення як батьківське. Правила створення номерів версій для виправлень є такими ж, як для рішень; номери вказуються у такому форматі: основна.проміжна.збірка.випуск. Ви не можете вносити зміни до наявних основних або проміжних версій рішень під час створення виправлення.

Експорт та імпорт виправлень

Використовуйте SDK для .NET або веб-API, веб-додаток або Package Deployer інструмент для експорту та імпорту виправлень. Відповідними SDK для класів .NET запитів є ImportSolutionRequest and ExportSolutionRequest. Відповідні дії для API веб-служб такі: ImportSolution Action та ExportSolution Action.

Приклади виправлення

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

Ім’я виправлення	Опис
SolutionA, версія 1.0 (некерована)	Містить entityA з шістьма полями.
SolutionA, версія 1.0.1.0 (некерована)	Містить entityA шість полів (три оновлено), а додає entityB з 10 полями.
SolutionA, версія 1.0.2.0 (некерована)	Містить entityC 10 полів.

Процедуру імпорту наведено нижче.

1. Розробник або кастомайзер спочатку імпортує базове рішення (SolutionA 1.0) у середовище. В результаті виходить entityA шість полів в оточенні.
2. Далі SolutionA імпортується патч 1.0.1.0. Середовище тепер містить entityA шість полів (три були оновлені), плюс entityB 10 полів.
3. Нарешті, SolutionA патч 1.0.2.0 імпортується. Середовище тепер містить entityA шість полів (три оновлені), entityB 10 полів, плюс entityC 10 полів.

Ще один приклад виправлення

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

Ім’я виправлення	Опис
SolutionA, версія 1.0 (некероване, базове рішення)	Містить Account таблицю, в якій довжина колонки номера рахунку скоригована від 20 до 30 символів.
SolutionB, версія 2.0 (некерований, інший постачальник)	Містить таблицю, Account в якій довжина колонки з номером рахунку скоригована до 50 символів.
SolutionA, версія 1.0.1.0 (некерована, патч)	Містить оновлення таблиці, Account де довжину стовпця з номером рахунку змінено до 35 символів.

Процедуру імпорту наведено нижче.

1. Розробник або кастомайзер спочатку імпортує базове рішення (SolutionA 1.0) у середовище. В результаті виходить Account таблиця з колонкою з номером рахунку в 30 символів.
2. SolutionB імпортується. Середовище тепер містить Account таблицю зі стовпцем номера рахунку з 50 символів.
3. SolutionA Патч 1.0.1.0 імпортовано. Середовище, як і раніше, містить Account таблицю зі стовпцем номера рахунку з 50 символів, що застосовується за SolutionB.
4. SolutionB видалено. Середовище тепер містить Account таблицю зі стовпцем номера рахунку з 35 символів, що застосовується патчем SolutionA 1.0.1.0.

Видалення виправлення

Видалити виправлення або основне (батьківське) рішення можна, використовуючи DeleteRequest або, для API веб-служб, скориставшись методом HTTP DELETE. Процес видалення відрізняється для керованого або некерованого рішення, яке має один або кілька патчів, що існують у середовищі.

Для некерованого рішення необхідно спочатку видалити усі виправлення для основного рішення у зворотному порядку версій, а тоді видаляти основне рішення.

Якщо рішення кероване, ви просто деінсталюєте основне рішення. Система Dataverse автоматично деінсталює виправлення у зворотному порядку версій, перш ніж деінсталювати основне рішення. Можна також деінсталювати одне виправлення.

Оновити рішення

Оновлення рішення передбачає зведення (злиття) усіх виправлень для рішення із новою версією цього рішення. Пізніше це рішення розблоковується і може знову змінюватись (тільки некероване рішення) або експортуватись. Якщо рішення є керованим, жодні подальші змінення рішення не дозволяються, за винятком створення виправлень з оновлених рішень. Щоб звести виправлення у некероване рішення, використовуйте CloneAsSolutionRequest або CloneAsSolution Action. Клонування рішення створює нову версію некерованого рішення із вищим основним.проміжним номером версії, що об'єднує у собі усі виправлення і має таке ж унікальне ім'я та коротке ім'я.

У керованому рішенні все вирішується дещо інакше. Ви спершу клонуєте некероване рішення (A), вносячи до нього усі виправлення, а потім експортуєте його як кероване рішення (B). У цільовій організації, де міститься керована версія рішення (A) та його виправлення, ви імпортуєте кероване рішення (B), а тоді виконуєте DeleteAndPromoteRequest або DeleteAndPromote Action, щоб замінити кероване рішення (A) та його виправлення оновленим керованим рішенням (B), яке має вищий номер версії.

Статті за темою:

Використовуйте сегментовані рішення