Асинхронна обробка каскадних транзакцій
Ви можете налаштувати каскадне поширення певних транзакцій на всі пов’язані записи. Це означає, що зміни в батьківському записі передаються (каскадом вниз) по всіх дочірніх записах. Каскадні зв’язки налаштовуються на рівні таблиці. Для отримання додаткових відомостей про каскадні зв'язки див. Налаштування поведінки каскадних зв'язків таблиць.
Синхронний та асинхронний режими
За замовчуванням каскадна операція виконуються як синхронна транзакція. Під час синхронної каскадної транзакції в системі визначаються всі записи, які зазнали впливу. Під час обробки записів система блокує їх. Після застосування всіх змін вони розблоковуються та транзакція завершується.
Синхронні транзакції з великою кількістю записів можуть спричинити проблеми з продуктивністю середовищ, коли тривалі транзакції завершуються невдачею через тайм-аути сервера. Записи блокуються, що запобігає виконанню інших завдань і транзакцій користувачів, які працюють із тими самими записами. Крім того, тривалі транзакції можуть призвести до відставання незавершених транзакцій і запитів, що знижує продуктивність системи та може спричинити зупинку роботи.
Якщо в середовищі спостерігається очікування підключення або зниження продуктивності під час виконання синхронних каскадних операцій, увімкнення асинхронного режиму може вирішити ці проблеми. Основні відмінності між режимами описані в наступній таблиці.
| Синхронний режим | Асинхронний режим |
|---|---|
| Під час виконання каскадної операції не можна виконувати жодні інші завдання з цілим набором вибраних записів (прямим або каскадним). | Для функцій «Призначити», «Видалити» та «Об’єднати» каскадні зміни групуються, блокуючи лише записи, які обробляються в пакеті. Це дає змогу виконувати інші завдання під час каскадного застосування зміни. |
| Після завершення завдання всі дані показують нове бажане значення. | Під час виконання завдання кожен завершений пакет відображає бажане значення. Це означає, що є час, коли деякі дані показують потрібне значення, а деякі – початкове значення, доки не буде завершено повну операцію. Це називається «остаточною послідовністю». |
| Якщо стається помилка одного запису, значення всіх даних відкочуються до вихідних. Відкат вимагає повторного редагування всіх завершених записів, що займає більше часу. | Якщо станеться помилка одного завдання, буде здійснено кілька спроб завершити його. Якщо завдання не вдається виконати, помилка реєструється в області системних завдань. Зверніть увагу: успішно оброблені записи зберігають нове значення. |
| Якщо один із записів у каскадному списку має значення, відмінне від очікуваного, завдання завершується помилкою та відкочується. Наприклад, припустимо, що початковий запис належить власнику 1 , а каскадна операція хоче змінити його на власника 2. Якщо один із нижчих пов’язаних записів змінився на Owner 3 або був видалений до того, як відбудеться блокування, все завдання буде відкочено. | Для параметра «Призначити» операція завжди працює в режимі перезапису, змінюючи поточне значення на нове на основі відношення «батько-нащадок». Невідповідність вихідного значення не призводить до помилок виконання завдання. Для параметра «Видалити», якщо відсутній запис, який очікувався як частина набору, усі записи до точки відмови вважаються завершеними. Користувач або адміністратор може повторно виконати невдале завдання, яке перерахує завдання для продовження без пропущеного запису. Для Merge, якщо виникає проблема з відсутнім записом, завдання повторюється і виконується без пропущеного запису. |
Асинхронний режим і компоненти plug-in
Якщо каскадна транзакція відповідає пороговому значенню для включених записів і не має жодних плагінів, пов’язаних із записами, записи обробляються асинхронно.
| Операція | Поріг |
|---|---|
| Призначити | 1000 записів |
| Delete | 10 000 записів |
| Злиття | 1000 записів |
Якщо в асинхронному пакеті запису призначено компонент plug-in, оновлення або видалення одного запису разом із усіма пов’язаними плагінами для цього запису запускаються синхронно. Це відбувається в рамках транзакції до переходу до наступного запису в асинхронному пакеті.
Якщо плагін всередині асинхронної транзакції ініціює нове каскадне видалення або призначення, нова каскадна транзакція завжди виконується синхронно в поточній асинхронній транзакції. Це запобігає утворенню кількох рівнів асинхронних транзакцій.
Відстеження перебігу асинхронної операції
Адміністратори можуть відстежувати виконання асинхронних операцій в області Настройки.
Авторизуйтесь в Power Platform Центрі адміністрування.
Виберіть Середовища в області переходів. Потім виберіть потрібне середовище.
Виберіть Параметри, розгорніть розділ Відстеження та журнали, потім виберіть Системні завдання.
Каскадні операції буде показано на панелі перегляду «Системні завдання».
Щоб переглянути лише каскадні операції, у селекторі Подання виберіть Каскадні операції.
Каскадна операція може мати будь-який із таких станів:
- Завершено: Усі пакети каскадної транзакції успішно завершені.
- Тривають: Каскадні зміни тривають.
- Помилка: після кількох спроб деякі каскадні зміни зазнали невдачі.
Нотатка
Не можна скасувати виконання асинхронного каскадного завдання. Слід дочекатися його завершення, указавши стан Виконано або Не вдалося.
У вікні каскадної операції можна переглянути такі відомості:
Кількість повторних спроб виконання конкретної транзакції.
Дата й час створення та виконання транзакції.
Автор завдання.
Усі повідомлення, пов’язані із завданням, наприклад причини помилок або винятки.
Які каскадні транзакцій можна обробляти в асинхронному режимі?
Обробка призначення, видалення та злиття каскадних транзакцій може здійснюватися асинхронно.
Нотатка
Інші транзакції, такі як share/unshare, rollup view та re-parent, наразі розглядаються на предмет асинхронної обробки.
Пошук і виправлення неполадок при асинхронних послідовних операціях
Коли синхронні каскадні завдання зазнають невдачі, вони зупиняють і відкочують усі зміни, щоб жоден із записів не містив запитуваних змін. Це може зайняти багато часу, оскільки відкат може тривати стільки ж часу, скільки і початкова спроба, а повторна спроба операції починається знову з першого запису.
При виникненні збою асинхронні операції повторюються багато разів. У більшості випадків повторне виконання завдання буде успішним, і завдання зможе продовжуватися до його завершення. У деяких рідкісних випадках повторна спроба не вирішує проблему. Коли це відбувається, асинхронне завдання призупиняється, і адміністратор і користувач можуть усунути проблему та відновити роботу з того моменту, коли вона була призупинена.
Поширені причини збоїв послідовних операцій
Поширені причини збоїв при обробці послідовних операцій включають наведені далі.
- Винятки плагінів
- Винятки з системи безпеки
Винятки плагінів
Компоненти plug-in додаються до обробки каскадних операцій для виконання певних дій у разі внесення змін до запису, наприклад надсилання повідомлення електронної пошти або ініціювання іншого оновлення інших записів. Їхніми постачальниками можуть бути сторонні особи, або вони можуть розроблятися організацією самостійно. Якщо плагін генерує виняток, каскадна операція завершується помилкою. Повторна спроба може вирішити проблему, залежно від її причини. Якщо завдання асинхронного каскаду призупинено через збої, перевірте всі плагіни, пов’язані з операціями, щоб переконатися, що вони не генерують винятків. Після виправлення проблеми виконання завдання можна відновити.
Винятки з системи безпеки
Винятки системи безпеки виникають, коли користувач, який виконав послідовну операцію, має недостатні права для внесення зміни до одного запису або більше, або цього користувача вимкнено чи видалено із системи.
Якщо користувач все ще перебуває в системі, переконайтеся, що він має необхідні привілеї для внесення змін до записів і що він має дозвіл на виконання вказаних дій. Після того, як це буде вирішено, відновіть роботу.
Якщо користувача було вимкнено або видалено з системи, повторне ввімкнення або повторне додавання користувача вирішує проблему, і завдання можна відновити. Однак якщо необхідно видалити або вимкнути цього користувача або якщо не передбачається, щоб цей користувач мав дозволи для виконання дій або операцій із записами, завдання слід скасувати, після чого інший користувач, який має відповідні дозволи, повинен повторно почати виконання завдання.
У разі виникнення інших проблем, що стосуються збоїв при виконанні завдань зверніться до служби підтримки Microsoft. Додаткові відомості: Огляд підтримки
При об’єднанні послідовних операцій виникли проблеми з видаленням файлу пошуку та виправлення неполадок
При виникненні збоїв під час об’єднання послідовних операцій через видалення файлів, коли завдання запущено, можна пропустити перевірку зв’язків із батьківськими об’єктами. Це забезпечить продовження об’єднання, навіть якщо буде видалено запис із набору, коли завдання виконується в фоновому режимі. Якщо вибрано об’єднання записів, у нижній частині вікна злиття зніміть прапорець Батьківський контроль, який увімкнуто за промовчанням. Зніміть позначку з цього, щоб проігнорувати параметр перевірки батьківства.
Приклад об’єднання записів
Уявіть собі, що у вас є бізнес-партнери із зв'язком із контактною особою, яка має відношення до замовлень. Ви бажаєте об’єднати записи двох бізнес-партнерів.
Якщо завдання виконується успішно, функція об’єднання призначає всіх пов’язаних контактних осіб і їхні замовлення цільовому бізнес-партнеру.
Якщо під час процесу злиття записів інший користувач видаляє пов’язаний запис контактної особи, але записи про замовлення, пов’язані з записом контактної особи, все ще існують, завдання злиття не виконується, оскільки відсутній батьківський запис дочірнього елемента. Якщо під час злиття записів пропустити перевірку батьківського контролю, замовлення з відсутнім записом контактної особи буде об’єднано із записом цільового облікового запису. Однак цільовому обліковому запису не призначаються пов’язані записи контактів, і робота завершується.
Злиття викликає блокування, які запобігають внесенню інших змін до доступу
Операція каскадного злиття надає доступ до нового відповідального за залежну таблицю. Для цього операція Каскадного злиття (Cascade Merge) отримує доступ і вносить зміни в таблицю головних об’єктів, які потребують блокування. Якщо операція злиття містить багато записів (це залежить від каскадного зв'язку), то це блокування може тривати протягом досить довгого часу. Це може призвести до помилки, якщо операція намагається надати або відкликати доступ до непов’язаного запису під час злиття. Якщо таке станеться, спробуйте виконати злиття у неробочий час, щоб знизити час блокування.