Філософія управління запитами в Salesforce. Як Query Manager економить час та гроші

Управління даними з Salesforce

Salesforce є грандіозним і прагне бути універсальним інструментом і платформою для підтримки будь-якого бізнесу і діяльності.

Він містить велику кількість інструментів, хмар даних та властивостей для побудови бізнес-процесів, співпраці компаній та налаштування всього, що ви створюєте всередині Salesforce, як, наприклад, бізнес-додатки, сайти тощо.

Коли інструментів та функцій адміністрування недостатньо, і людям потрібно щось більш специфічне, ніж готові рішення «з коробки», вони можуть використовувати нативні мови програмування Salesforce та front-end фреймворки. Це мова сервера Apex, мови баз даних SOQL та SOSL, Visualforce Pages та Lightning Components.

Але незалежно від того, що ми використовуємо, ми маємо справу з даними. Кожен крок може розглядатися як використання даних та / або управління ними.
Особливо ми маємо справу з управлінням даними під час створення коду. Під управлінням даними я маю на увазі зміну існуючих або створення нових даних.

Запити до бази даних всередені Salesforce

Щоб керувати даними, ми запитуємо їх у коду Apex, який використовує дані для перетворення даних для інших даних. Це забезпечується запитами до бази даних SOQL. Кожен запит може містити власні фільтри та вкладені запити зі своїми фільтрами та вкладеними запитами. Вкладені запити можуть бути комбінацією логічного виразу на кшталт 1 AND 2 AND 3.

Тож у загальному випадку ми можемо уявити, що кожен обсяг запитів SOQL до бази даних може бути представлений наступним чином (O# — означає якийсь об’єкт Salesforce, — стандартний або користувацький, FO# — означає поле пошуку об’єкта O#):

Загальна структура запитів

Тут на малюнку представлена ​​загальна структура пакета запитів. Зображено лише два рівні для вкладених запитів. Але насправді структура запитів може бути набагато складнішою з більшою кількістю вкладених рівней запитів.

Крім того, вона може мати зовсім іншу булеву логіку, як на цьому малюнку:

Варіант структури запитів

Крім того, lookup поле та поле ID міняються місцями в запиті залежно від того, що потрібно користувачеві:

Перестановка lookup полів всередені вкладеного запиту

Підсумуємо, що в залежності від вимог бізнесу:

• може бути багато вкладених запитів до бази даних і багато рівнів вкладеності;
• запити можуть мати різноманітні булеві логіки;
• lookup поля можуть помінятися місцями з полями ID у вкладеному запиті.

Обмеження мови бази даних Salesforce SOQL

Відомо, що Salesforce SOQL може підтримувати лише один рівень вкладеності для вкладеного запиту на один запит до бази даних.

Отже, як розробник обходить це обмеження?

Найпоширенішим способом є отримання ідентифікаторів пов’язаних записів у список ідентифікаторів для використання таких списків ідентифікаторів в цільовому запиті. Це можна зробити наступним чином:

Допоміжний код для отримання пов’язаного списку ідентифікаторів записів

Коли бізнес-логіка диктує більш складні умови для вибору записів розробник буде використовувати якийсь подібний код, як вище стільки разів, скільки потрібно.

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

І все це буде зроблено стільки разів, скільки будуть змінені вимоги бізнесу.

Величезні регулярні фінансові витрати на розробку

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

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

Саме тому рекомендується використовувати окремі класи і методи для отримання даних. Це принцип поділу логіки запитів даних і бізнес-логіки.

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

Рішення, що зберігає кошти (синхроний код)

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

Для цього я розробив Query Manager, який є універсальним інструментом для ізоляції запитів даних та коду бізнес-логіки.

Він складається з контролера запитів, UI конструктора запитів та об’єкта збереження параметрів запитів.

Конструктор запитів призначений для налаштування параметрів запитів та фільтрації.

Контролер запитів використовує збережені параметри запитів та фільтрації для отримання даних та передачі даних до коду бізнес-логіки клієнта.

Об’єкт збереження параметрів запитів — це об’єкт, записи якого зберігають налаштування запитів та фільтрації, і ці записи використовуються для роботи контролера запитів.

Query Manager дозволяє сконцентруватися на розробці та підтримці лише бізнес-логіки незалежно від змін логіки запитів даних.

Це шлях для економії грошей багатьма способами.

1. Не витрачається багато часу на дослідження існуючого коду який служить для отримання даних;
   
2. Ви не витрачаєте час на оновлення коду для отримання даних;
   
3. Не потрібно гаяти час на тестування та деплой оновлень на продакшені;
   
4. Ви можете підтримувати робочі процеси, розкриваючи цілі та роблячи коментарі прямо в спеціальних полях записів параметрів запитів. Також можна відстежувати дату останніх оновлень в логіці запитів і так далі.

Query Manager має два глобальних методи, які доступні для синхронного Apex:

• @AuraEnabled global static String getPagedRecordsForApex (String dataTableSettingsId, integer pgNum, integer pgSize);
• @AuraEnabled global static List <SObject> getAllRecordsForApex (String dataTableSettingsId).

Метод getPagedRecordsForApex повертає записи як рядок для певної сторінки пагінації даних.

Метод getAllRecordsForApex повертає всі записи, які доступні відповідно до нзбережених параметрів запитів та фільтрації.

Детальніше про те, як використовувати ці методи, дивіться у відео.

Допоміжні Batchable класи

Дехто може сказати: добре, ви надали рішення для синхронного Apex, але що до асинхронних класів Batchable?

Це питання виникає тому, що розробники використовують класи Batchable для роботи з великим обсягом записів через обмеження Salesforce для SOQL операцій (50 000 записів за транзакцію) і для операцій DML (10 000 записів за одну транзакцію).

Іноді в таких випадках з’являються допоміжні класи Batchable. Під допоміжними класами я маю на увазі ті, які виконують ту ж роль, що і допоміжний код для отримання відповідних ідентифікаторів записів (на малюнку вище).

Але на протиставлення синхронному Apex, де може бути використаний окремий метод, в асинхронному Apex необхідно використовувати додатковий окремий Batchable клас. І оскільки логіка запитів може бути складною і може змінюватися для різних процесів всередині організації, розробники повинні запроваджувати стільки Batchable класів, скільки потрібно для цих процесів, пов’язуючи їх кожного разу в потрібній послідовності згідно з логікою запитів потрібних даних.

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

Зберігаюче кошти рішення (асинхроний код)

Так само, як для синхронного Apex, є рішення для асинхронного коду, яке економить ваші гроші, пропускаючи розробку допоміжних Batchable класів за допомогою Query Manager.

З цією метою Query Manager має глобальний метод static void callByFilteringSettings (String className, String settingsId).

З цим методом ви можете пропустити всі допоміжні Batchable класиі отримати результат запитів до бази даних прямо в ваш цільовий Batchable клас з вашою індивідуальною логікою.

Докладніше про те, як використовувати метод callByFilteringSettings є відео.

Фундаментальні невирішені проблеми

Не дивлячись на те, що ми отримали принципово новий підхід до розробки, все ще залишаються деякі невирішені ключові проблеми.

Перша проблема полягає в тому, що для синхронного Apex все ще залишається ліміт у 50 000 для всіх SOQL запитів у межах однієї транзакції, а саме в цих межах існує виконання синхронного коду. І, мабуть, ми нічого не можемо з цим вдіяти.

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

Друга проблема — це heap size та CPU Time лімітів для асинхронного коду (для класів Batchable).

Це питання можна вирішити двома підходами. Перший заснований на розробці кодера і декодера ідентифікаторів записів. Цей кодер та декодер повинні приймати перший ідентифікатор, останній ідентифікатор, принцип впорядкування між першим та останнім ідентифікаторами та назву SObject-а.

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

Другий підхід полягає у використанні файлів CSV з ідентифікаторами для допоміжних класів Batchable. Це більш зрозуміло і може допомогти у вирішенні heap size та CPU Time лімітів.

Отже, друге питання також є пунктом вдосконалення у майбутньому.

Обмеження і недоліки, які мають місце на даному етапі

1. Немає обробки перевищення лімітів SOQL та інших лімітів. У деяких випадках це може бути незручно. Це також пункт для вдосконалення у майбутньому;
   
2. Тільки SObjects, які користувач може бачити в Object Manager всередині організації, доступні в Query Manager. Це зроблено з метою не перевантажувати користувачів і розробників додатковою інформацією в інтерфейсі Query Builder. Доступ до всіх об’єктів можна зробити для окремої розширеної версії.
   
3. Менеджер запитів взагалі не тестувався з Queable Classes. Це точка для майбутнього дослідження і вдосконалення.
   
4. Концепція управління запитами для управління розробкою та підтримкою проекту. На даний момент ця концепція не до кінця оформлена в могутню філософію розробки.
   
5. Таблиці даних з різними функціональними можливостями та адаптивні для користувацької функціональності, які трансформуються на будь-який смак користувача. Це також пункт для вдосконалення у майбутньому.
   
6. Деякі інші недоліки і помилки, які ви можете знайти, використовуючи Query Manager.

Заключення

Query Manager — це зручний, перспективний та трансформаційний продукт та філософія. Він безкоштовний.

Основна мета створення і розвитку — отримання корисних і економних концептів. Ваше використання та відгуки — дуже приємні та важливі інвестиції.

Цей текст з особистого блогу, опублікований з дозволу автора.