Ієрархії й двобічні дані

🌐 Також доступно 28 мовами

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 5 з 6 розділу Основні дані та ідентичність, розділ 6 курсу Data Architect. Кожен модуль самостійний. Попередній: Карта — це не рішення · Наступний: Контрольна точка 1: Steve Trucking

Питання, на яке відповідає цей модуль: Як керувати даними, які підтримує більш ніж одна система?

Легка архітектура: ERP володіє клієнтом, Salesforce отримує копію, готово. Справжні підприємства не такі охайні. ERP володіє юридичним клієнтом, а Salesforce — стосунками продажів; один підрозділ живе в SAP, придбаний — в іншій ERP; потенційні клієнти існують лише в Salesforce. А потім хтось хоче, щоб користувачі Salesforce оновлювали поле, яке контролює ERP, і стрілки починають вказувати в обидва боки. Як я кажу, коли це викладаю: «The hardest thing are the bi-directionals» (найскладніше — двобічні інтеграції). Не тому, що надсилати дані в обидва боки технічно важко, а тому, що щойно обидві системи беруть участь у змінах, треба бути надзвичайно точним щодо авторитетності.

Двобічні дані не означають двох майстрів

ERP володіє адресою для рахунків, яку копіюють у Salesforce. Продавець дізнається від клієнта, що вона змінилася, і бізнес хоче, щоб він оновив її, не виходячи із Salesforce. Розумно. Тепер дані течуть ERP → Salesforce і Salesforce → ERP. Чи став Salesforce співвласником адреси для рахунків? Ні. Напрямок інтеграції не вирішує авторитетності. Продавець не змінює копію Salesforce. Архітектурно він просить змінити авторитетне значення. Ви не змінюєте поле ERP; ви просите його змінити. Salesforce — інтерфейс; ERP досі майстер.

Це змінює дизайн. Якби полем володів Salesforce — зберегти і готово. Якщо ним володіє ERP, «зберегти» означає: Salesforce надсилає запропоновану адресу, ERP перевіряє й приймає її, оновлює свого майстра і надсилає назад авторитетне значення. Лише тоді кероване значення змінилося: запит → перевірка → прийняття → публікація, а не «оновити обидві системи і сподіватися, що вони лишаться синхронними».

Click to enlarge

Двобічна інтеграція не створює двобічної авторитетності.

Коли майстер каже «ні»

ERP відхиляє зміну: клієнт неактивний, адреса порушує правило ERP, користувачеві не дозволено змінювати юридичні адреси, ERP недоступна або хтось інший тим часом змінив клієнта. Якщо Salesforce уже показав нову адресу, у нас дві істини, а модуль 1 уже сказав, котра перемагає: ERP. Тож архітектурі потрібен стан «запитано, ще не прийнято»: окреме запропоноване значення, позначка «зміна в очікуванні» або очікування підтвердження, перш ніж показувати. Механізм залежить від сценарію. Правило — ні: ніколи не дозволяйте відхиленому запиту стати конкурентною істиною.

Цикли й колізії

Ось класика. ERP оновлює Salesforce; інтеграція Salesforce бачить зміну й надсилає її в ERP; ERP бачить оновлення й надсилає його назад. Ви збудували дуже дорогий цикл. Добрий двобічний дизайн знає, де почалася зміна, чи прийняв її майстер і чи це нова бізнес-зміна, чи лише відлуння вже обробленої: ідентифікатори джерел, мітки часу, метадані інтеграції, ідемпотентна обробка. Розділ про інтеграцію іде вглиб. Принцип основних даних простий: знайте, чи ви ініціюєте зміну, чи відображаєте її.

Потім колізії. Одну ви вже бачили в розділі 5: менеджер просить Steve’s Plumbing LLC, а хтось в ERP набирає Steve’s Plumbing L.L.C. (Захистіть керований запис). Ось ще одна. Salesforce пропонує 125 Main Street; майже в ту саму мить користувач ERP змінює на 130. Хто перемагає? Універсальної технічної відповіді немає. Можливо, ERP завжди перемагає, бо володіє полем; можливо, запит Salesforce іде в чергу на перегляд; можливо, перемагає пізніше прийнята зміна; можливо, ERP відхиляє будь-яке оновлення, чиє початкове значення змінилося. Це паралельність, але під нею — рішення про авторитетність, і жоден інтеграційний шаблон не врятує, якщо ніхто не вирішив, хто може робити авторитетну зміну.

І одне поле — це простий випадок. Адреса — це вулиця, місто, поштовий індекс. Salesforce надсилає нову вулицю, а ERP щойно змінила місто. Ви пропускаєте вулицю саму по собі? Чи вважаєте адресу однією транзакцією, щоб усі поля йшли разом або жодне, і відхиляєте всю зміну? Вирішіть, які поля їдуть групою, до першої колізії, а не після.

Щоразу, бачачи двобічну інтеграцію, я питаю: що станеться, коли обидві сторони змінять ті самі дані? Якщо відповідь «навряд чи таке станеться», ми не закінчили. Хто перемагає, відхиляємо, ставимо в чергу, порівнюємо версії, переглядаємо? Чи взагалі має поле бути редагованим в обох місцях? Іноді найкращий двобічний дизайн прибирає один напрямок для певного атрибута: Salesforce може просити; лише ERP публікує прийняте значення. Дані досі рухаються в обидва боки, але полем керує лише одна система. У цій різниці все.

Ієрархії — теж основні дані

Основними даними можуть бути й зв’язки. Глобальна материнська компанія з регіонами Північної Америки та Європи, у кожного — дочірні компанії за країнами: сама ієрархія несе зміст. Хто материнська компанія? Яка дочірня під якою юридичною особою? Які акаунти зводяться до глобального клієнта? Це керує звітністю, територіями, цінами, договорами, кредитними ризиками, сервісом, доступом до даних і аналітикою. Ієрархія може бути так само важливою, як записи в ній, і їй потрібне те саме врядування. (Іспит називає керування ієрархіями; про це легко забути.)

У Salesforce ієрархії акаунтів будують полем Parent Account. Перегляд ієрархії в Lightning показує до 2 000 акаунтів, і лише ті, які користувачеві дозволено бачити; персональні акаунти не підтримуються в ієрархії; а Account Site розрізняє місця компанії (Considerations for Using Account Hierarchy (opens in a new tab)). Але поле Parent Account не відповідає на архітектурне запитання: хто володіє ієрархією?

Варто знати для іспиту. Знайте основи ієрархії акаунтів: вона будується через Parent Account; подання Lightning показує до 2000 акаунтів, лише тих, які користувач може бачити; персональні акаунти не підтримуються; а Account Site розрізняє місця розташування компанії.

Одна ієрархія, кілька майстрів

З мого досвіду, ієрархії мають розділену авторитетність. Північноамериканські юрособи приходять із SAP, європейські — з іншої ERP, нових потенційних клієнтів будують у Salesforce, а придбана дочірня компанія ще не мігрувала. Хто володіє ієрархією? Залежить від гілки. Кожна ERP контролює свою гілку; Salesforce контролює зв’язки потенційних клієнтів, доки їх не перетворено. Це легітимна архітектура, доки всі знають, де межі. Вирішуйте для кожної гілки.

Click to enlarge

Авторитетність в ієрархії можна призначати гілка за гілкою.

Тож не дайте полю Parent Account сховати авторитетність. Користувач перепідпорядковує дочірню компанію в Salesforce. Технічно тривіально. Архітектурно — чи змінив він щойно юридичну структуру компанії? Якщо цією гілкою керує ERP, мабуть, ні, тож Salesforce має це заблокувати або перетворити на запит на зміну. А може, Salesforce легітимно веде комерційну ієрархію, а ERP — юридичну. Тоді, можливо, це взагалі не мають бути той самий зв’язок.

Компанія може мати кілька легітимних ієрархій: юридичну, для рахунків, продажів, сервісу, географічну. Глобальна материнська компанія підписує договір, регіони отримують сервіс окремо, рахунки йдуть через спільну фінансову юрособу, продажі керують за регіонами. Котра справжня ієрархія? Усі; вони відповідають на різні запитання. Помилка — припускати, що вона мусить бути одна. Має бути ясна авторитетність для кожного виду зв’язку: принцип атрибутів із модуля 1, застосований до зв’язків.

І не кожен зв’язок «батько — дочірній» — основні дані. Групування сьогоднішніх доставок в один маршрут — зв’язок, але транзакційний, операційна подія. Ієрархія клієнтів описує тривалі бізнес-стосунки. Обидва в моделі виглядають як «батько — дочірній»; життєвого циклу вони не поділяють. Питайте, що означає зв’язок і як довго цей зміст триває.

Один клієнт, дві ERP

Коли я викладаю це, то питаю залу: хто працював із клієнтом, у якого один Salesforce і більше ніж одна ERP? Руки піднімаються щоразу. Запитайте чому, і виявиться, що ERP поділені за регіонами (одна для Північної Америки, одна для Європи), за функціями (сантехнічна компанія купує електротехнічну, і кожна зберігає власну ERP) або просто історично: бізнес придбали, і ніхто ще його не мігрував.

Візьмімо клієнтом Steve’s Plumbing. Він працює в Північній Америці, тож північноамериканська ERP має для нього запис клієнта. Потім він відкриває офіс у Мюнхені, і європейська ERP створює власний запис клієнта з власним номером клієнта. Та сама компанія, два записи, два ID. Як мені представити це в одній org Salesforce? Я бачив три способи.

Ієрархія акаунтів. Steve’s Plumbing — батьківський акаунт, а Steve’s Plumbing North America і Steve’s Plumbing Europe — дочірні, кожен дочірній відповідає запису однієї ERP. Підступ: дочірні — це вже насправді не Steve’s Plumbing. Це Steve’s Plumbing, що веде бізнес у певному регіоні, а як ми щойно бачили, ієрархія несе зміст.

Рівноправні акаунти. Два акаунти поруч, кожен із полем, яке каже, якій ERP він належить: код компанії, регіон. Нічого не приховано. Ціна виявляється у звітності: щоб побачити Steve’s Plumbing по всьому світу, вам потрібне щось, що каже, що ці два акаунти — одна компанія.

Один акаунт із дочірнім записом на кожну ERP. Один Steve’s Plumbing і дочірній об’єкт із записом для кожної ERP, що містить ID клієнта в цій ERP. Дві ERP чи десять. Продавці бачать одного клієнта й оформлюють одне замовлення; за лаштунками потоки вирішують, у яку ERP іде кожен рядок: електротехнічні роботи — в електротехнічну ERP, сантехніка — в сантехнічну. Але тепер вам треба вирішити, яка ERP основна для спільних значень, як-от назва й адреса, і що стається, коли клієнт існує в одній ERP, але не в іншій.

Click to enlarge

Один клієнт, дві ERP: три способи представити його в Salesforce.

Запитайте, як вони синхронізують ERP

То який обрати? Спершу: скільки структури ERP мають бачити продавці? Якщо вони завжди знали, що Північна Америка і Європа — окремі бізнеси, бо входять в одну чи іншу ERP, не ховайте цього від них. Перенесіть цю структуру в Salesforce як рівноправні акаунти. Якщо бізнес хоче, щоб перед продажами був один Steve’s Plumbing, вам підходить один акаунт із дочірнім записом на кожну ERP.

А потім запитання, яке насправді все вирішує, і вирішується воно не в Salesforce. Я питаю клієнта: як ви синхронізуєте ці два записи між своїми ERP? Не те, що локальне для кожної ERP, як-от баланс; це транзакційні дані. Я маю на увазі основні дані: юридичну назву, адреси. Якщо в них є команда, що синхронізує дві ERP, ми можемо звести їх разом в один акаунт. Якщо вони не можуть синхронізувати їх у власних ERP, як вони можуть очікувати, що ми синхронізуємо їх у Salesforce? Тоді це рівноправні акаунти або ієрархія.

Пам’ятайте, що таке ERP. Це величезні системи, які впроваджують роками, і вони приходять зі своїм способом керувати основними даними. Salesforce ними не керуватиме. Ми не контролюємо ERP. Ми контролюємо те, як представляємо їх у Salesforce.

MDM посередині

Деякі клієнти вже розв’язали це до нашого приходу. Велика компанія, багато років на ринку, кілька ERP: вони натрапили на цю проблему задовго до Salesforce і поставили посередині спеціалізований продукт MDM, щоб посередничати між ERP. Це MDM співіснування чи централізоване MDM із модуля 2. Тепер Salesforce не під’єднується до кожної ERP. Він вказує на одне місце, хаб MDM, і отримує єдине представлення клієнта. Але не очікуйте зустрічати таке часто. Це великі впровадження самі по собі; за всі мої роки я працював із таким лише два чи три рази. І навіть із хабом вам може все одно знадобитися той дочірній об’єкт, щоб кожне замовлення знало, в яку ERP воно йде.

Click to enlarge

MDM посередині: Salesforce вказує на одне місце.

Steve Trucking: чия ієрархія?

Роздрібний партнер має власну структуру: материнська компанія, регіональні підрозділи, розподільчі центри, магазини. Чи володіє Steve Trucking цією ієрархією? Ні; партнер — авторитет щодо власної організації. Але Steve Trucking може потребувати власного комерційного погляду на ті самі місця — для договорів, керування акаунтами, сервісу й звітності, — можливо, дочірній акаунт для кожного DC під партнером. Дві легітимні ієрархії, дві авторитетні системи. Назвіть їх і не вдавайте, що одне дерево представляє кожен зв’язок.

Зробіть межі видимими

Щоразу, коли авторитетність розділена, я хочу, щоб межу було видно: назви полів, метадані записів, ідентифікатори систем-джерел, дозволи, поведінка інтеграцій, документація. Чого я не хочу — це розробника, що читає п’ять інтеграцій, щоб відкрити: «ці значення Parent Account приходять із SAP, крім потенційних клієнтів, крім Європи». Це не підтримувана модель авторитетності. Якщо ієрархія має розділену авторитетність, задокументуйте розділення. Якщо авторитетність змінюється при перетворенні, задокументуйте зміну. Якщо Salesforce може просити, але не робити зміну, зробіть це очевидним у досвіді.

У Salesforce це починається з одного поля. Потрібне поле, яке чітко каже, що це основні дані: ключ ERP або позначка «це основні дані». Керуйте можливістю редагування полів від цього поля, а не від типу запису; з Dynamic Forms вам більше не потрібен тип запису, щоб показати поля ERP лише для читання (розділ 5, Тип запису для кожного потоку). Можна дозволити створювати записи поза майстром, але стежте за редагуваннями.

За межами іспиту: що змінює ШІ. Клієнт каже агентові: «змініть нашу адресу для рахунків на 125 Main Street». Поле просто тут, у Salesforce. Чи має агент його оновити? Ні, якщо ним володіє ERP. Агентові потрібне право запису, а не лише доступ до поля: його дія має кодувати погоджений шлях, подаючи запит на зміну і кажучи «я подав зміну на обробку», а не хибно повідомляти «я оновив вашу адресу для рахунків».

Що тут вирішує архітектор

• Чи змінює редагування в Salesforce авторитетні дані, чи просить зміни в системи, що ними володіє.
• Як двобічні потоки відрізняють ініційовані зміни від відлунь і обробляють відхилення, колізії, затримку і збої.
• Хто володіє кожною ієрархією, за потреби — гілка за гілкою.
• Для одного клієнта, що є в кількох ERP: ієрархія, рівноправні акаунти чи один акаунт із дочірнім записом на кожну ERP, і вирішує це те, наскільки добре клієнт синхронізує свої ERP.
• Чи конкурентні ієрархії насправді є різними легітимними зв’язками: юридичним, для рахунків, продажів, сервісу.
• Як межі авторитетності й погоджені шляхи запису стають видимими для користувачів, інтеграцій, розробників і агентів.

Спільна авторитетність — не проблема. Проблема — неоднозначна авторитетність. Кілька ERP можуть керувати різними гілками, Salesforce може керувати одними атрибутами й просити змін інших, а кілька ієрархій можуть описувати одне підприємство. Усе це працює, доки для кожного важливого атрибута і зв’язку ви можете сказати, хто ним володіє, хто може його змінювати, де робиться авторитетна зміна і що стається, коли системи розходяться. Якщо не можете, ще одна двобічна стрілка на діаграмі цього не виправить.

Додаткові матеріали

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (англійською, перевірено 2026-10-14).