Entity Linking
🚨 ВАЖЛИВА ПРИМІТКА 🚨 Завжди розглядайте можливість використання checkponts замість використання зв’язування сутностей. Checkpoints - це новіша функція, метою якої є повне заміщення зв’язування сутностей, тому зв’язування сутностей може бути видалено з Blackbird у майбутньому.
Тепер, коли ви вивчили концепцію зв’язаної сутності між різними системами та платформами в попередньому посібнику, настав час розглянути, як можна зв’язувати сутності без необхідності покладатися на певну можливість системи для зберігання користувацьких значень. А саме, Blackbird пропонує вам можливість зв’язувати ці сутності через спеціальний оператор з відповідною назвою Link entities. Але спочатку короткий виклад попереднього посібника:
Короткий опис: що таке зв’язані сутності?
При з’єднанні різних систем ми часто виявляємо, що щось представлене в одній системі є семантично тим самим, що щось представлене в іншій системі. Подумайте про статтю в CMS, яка представлена файлом в TMS, клієнта у вашій BMS, який представлений клієнтом у вашій CRM, або навіть повідомлення в Slack, яке представляє проект перекладу!
Якщо взяти приклад статті CMS <> файлу TMS, ми можемо визначити дуже поширену модель: коли створюється проект TMS, ми додаємо файли, що відповідають статтям CMS. Потім, коли переклади завершені, нам потрібно оновити кожну статтю правильним перекладеним файлом. Припускаючи, що робочий процес завершення перекладу відрізняється від робочого процесу створення проекту перекладу, ми повинні задати собі питання: враховуючи цей перекладений файл, отриманий від мого TMS, якій статті він відповідав? Нам потрібна відповідь на це питання, щоб помістити переклад у потрібне місце.
Якщо ми не використовуємо підхід користувацьких властивостей, як було показано в останньому посібнику, нам потрібно використовувати нативний оператор Blackbird Link entities.
Якщо система дозволяє користувацькі властивості, ми завжди рекомендуємо використовувати їх замість нативних зв’язаних сутностей Blackbird, щоб у вас було більше контролю над редагуванням цих властивостей за необхідності.
Наш сценарій
Ми розглянемо цей оператор крок за кроком. Але спочатку визначимо робочий процес, який ми збираємося побудувати. Ми припустимо, що це розділений робочий процес, тобто частина робочого процесу базується на одному тригері, а друга частина - на іншому. Ми можемо визначити це наступним чином:
Коли створюється новий тікет Jira, візьміть вкладення та іншу інформацію і додайте їх до завдання Phrase.
Потім:
Коли це завдання Phrase завершено, оновіть тікет Jira і завантажте переклади.
Не вдаючись у деталі, перша частина робочого процесу виглядає так:
Ми використовуємо цикл для всіх вкладень у тікеті, потім завантажуємо вкладення і створюємо з них завдання Phrase, разом з мовою, яка була вибрана з випадаючого списку в Jira.
Тоді друга частина робочого процесу виглядатиме так:
Ми завантажуємо перекладений файл, і тепер ми хочемо додати його до нашого тікета Jira. Однак тепер ми стикаємося з точно такою ж проблемою, яку згадували раніше: враховуючи це завершене завдання, якому тікету воно відповідало?
Усі випадки використання зв’язування сутностей мають однакову форму: x відповідає y, у мене є x, що таке y?
1. Зв’язування сутностей при їх створенні.
Щоб відповісти на це питання, нам потрібно додати ще один крок до нашого першого робочого процесу. А саме, нам потрібно встановити зв’язок між цими двома сутностями.
Натисніть на іконку + і виберіть Operator. Потім у меню праворуч виберіть Entity connection.
Потім для типу виберіть Link entities. Тепер нам потрібно визначити імена та ID наших двох сутностей. Ми рекомендуємо використовувати впізнавані імена. У нашому випадку ми використовуємо Jira_issue і вибираємо Issue key (який є ID для тікета, який ми хочемо в нашому другому птаху), і зв’язуємо його з Phrase_job і додаємо UID завдання Phrase, яке ми щойно створили.
Готово! Тепер ми можемо запустити цього птаха і перевірити, що він це успішно зробить. Коли ми додали оператор Link entities до нашого птаха, ми можемо використовувати цей зв’язок у нашому іншому птаху.
Примітка: Ви повинні успішно запустити птаха зі зв’язаною сутністю принаймні один раз, щоб імена сутностей з’явилися на наступному кроці!
2. Використання зв’язку сутностей.
Повернемося до птаха, відповідального за повернення перекладів у Jira. Між діями Phrase та Jira ми можемо знову додати оператор Entity connection. Цього разу, замість вибору Link entities як типу, ми виберемо Get linked entity.
Коли ми натиснемо на name, ми побачимо випадаючий список з усіма різними типами сутностей, які Blackbird зберіг для вас. Ми знаємо, що у нас є завдання Phrase і ми хочемо тікет Jira, тому вибираємо Phrase_job і вводимо ID завдання, яке ми отримали через подію. Потім для зв’язаної сутності вибираємо Jira_issue.
Ура! Тепер ми отримали зв’язану сутність!
Тепер ми можемо використовувати цей ID (який у нашому випадку представляє ключ тікета Jira) у нашій фінальній дії для завершення птаха.
От і все, коли завдання Phrase завершено, ми тепер бачимо наші вкладення, повернуті в правильний тікет Jira! 🎉
Ми працюватимемо над функцією пізніше цього року, яка може замінити багато з цих сценаріїв з розділеними робочими процесами. Ми прагнемо додати так звані in-bird-events, які дозволять вам продовжити розділений робочий процес так, ніби це був один. У більшості (якщо не у всіх) випадках це може усунути потребу в зв’язуванні сутностей.