Репорти у Salesforce та робота з даними: спроба переосмислення
Вітаю! Мене звати Євген Кисельов, я Salesforce-розробник. Хочу поставити вам кілька запитань.
- Як часто вам та вашим колегам доводиться стикатися з необхідністю вилучати дані хоча б для перегляду під час роботи із CRM-системами?
-
Як часто вам та вашим колегам доводиться змінювати критерії пошуку, фільтри, об'єкти, щоб знайти потрібну інформацію?
-
Як часто вам потрібно писати запити до бази даних, хай навіть у зручній консолі розробника?
-
У що згодом перетворюються всі ті запити у консолі і де ви їх зберігаєте? Чи втрачаєте, а згодом знову згадуєте, що ви шукали, чому та навіщо, і як саме будувалися запити, скрипти для вилучення даних? Знову ставите одне й те саме завдання розробнику, на яке він знову має витратити свій та ваш час?
-
Як часто взагалі для цього вам потрібні розробники, програмісти, які будують для вас запити, скрипти, та таблиці даних?
Буду намагатися представити свій погляд на тему, пов'язану з пошуком та відображенням даних. Оскільки я працюю з Salesforce-платформою, то буду апелювати до її особливостей, щоб пояснити, чому я ставлю всі ці та багато інших запитань собі.
Репорти у Salesforce
Одна з особливостей платформи — це репорти. Їх зазвичай використовують для відображення даних.
Але дозвольте поставити лише кілька запитань серед найбільш поширених:
- Скільки вкладених запитів до бази даних подтримують репорти? Чи для всіх випадків цього достатньо?
- Скільки записів виводиться у репорті?
- Чи всі об'єкти доступні у репортах?
- Чи можлива у репорті пагінація для більш зручного відображення виведених записів на невеликому моніторі?
- Чи можлива фільтрація за декількома об'єктами з використанням оператора OR, якщо у вас тип репорта <записи «A» можуть мати або не мати зв'язані записи «B»>?
- Що ви будете роботи, якщо вам потрібно оперативно змінити тип репорта з <кожний запис «A» повинен мати бодай один пов'язаний запис «B»> на <записи «A» можуть мати або не мати пов'язані записи «B»> для вже наявних репортів?
- Як обробляються третинні та четвертинні записи у репортах, якщо тип репорта <записи «A» можуть мати або не мати пов'язані записи «B»>?
- Чи можуть бути отримані дані з репортів у зручній формі для використання них деінде окрім дашбордів?
- Чи можете ви згрупувати дочірні записи за полем батьківських записів не всередині стовпчика, а витягнувши їх у рядки таблиці? Чи можливо згрупувати за полями двічі, тричі та більше разів?
Ці та інші питання можна вирішити завдяки користувацьких таблиць даних, що створюють розробники на вимогу клієнта.
Але що раптом ви бажаєте надалі оперативно змінювати фільтри для цієї таблиці або вилучені поля об'єктів? Знову доведеться змінювати код на бекенді, змінювати тестові методи, змінювати таблицю даних. Тобто доведеться змінювати абсолютно все, виконуючи повноцінну розробку.
Lightning data-table
Є ще одна особливість Salesforce, це lightning data-table — готовий компонент у бібліотеці Lightning Web Component. Досить зручний інструмент для швидкого розроблення таблиць з даними. Можна швидко підготувати розмітку таблиці за допомогою Lightning Web Component на фронтенді, швидко написати простий код на бекенді і отримати таблицю з даними.
Але є низка недоліків, як-от:
-
1
Неможливо використовувати pick-list поля та lookup поля об'єктів.
-
2
Підсвічування рядків неможливе.
-
3
Все, що пов'язане з доступом до DOM, неможливе.
-
4
Неможливо згрупувати рядки та переконфігурувати таблицю за бажанням користувача в режимі реального часу.
-
5
Для отримання даних за допомогою складних запитів до бази даних однаково потрібно писати складний код, який доведеться щоразу переписувати із зміною критеріїв для вибору даних.
-
6
Постійно доведеться переписувати код для стовпчиків самої таблиці, для того щоб вилучати в них саме те, що потрібно користувачу.
Пошук відповідей
У моїх спробах переосмислити запропоновані рішення «з коробки» у платформі Salesforce, потреби замовників, використані рішення у реальних проектах з боку інших розробників та з мого боку, я дійшов до спроби зробити комбінований продукт, який би вирішував низку завдань. Серед них відносно просте й наочне створення запитів до бази даних довільної складності та рівнів вкладеності, проста та швидка зміна логічних зв'язків та фільтрів всередині запитів, яка б вирішувала питання зберігання запитів всередині організації для повторного використання їх там, де потрібно. Водночас така зміна зробила б непотрібним постійно писати код для запитів до бази даних за принципом «клієнтський код не має піклуватися про отримання даних із бази даних, а має відповідати лише за бізнес-логіку».
На мій погляд, бажано розвивати продукт для отримання дедалі більших можливостей для користувачів та більшої гнучкості у використанні окремих частин продукту окрема один від одного.
У цьому відео ReportBuilder v0 англійською — демонстрація першого релізу продукту, у якого натепер чимало обмежень та недоліків, як-от:
-
1
Не надає можливості використання кількох вкладених запитів у кожному з рівнів вкладеності, а також логічних зв'язків між ними. Наприклад, неможливо сформувати подібний запит: SELECT Id FROM Contact WHERE EXPRESSION AND Id IN (SELECT ContactId FROM Case) AND OwnerId IN (SELECT Id FROM User). Такі запити неможливі для подальшого задання фільтрів через інтерфейс. Робота над вирішенням проблеми загальних запитів у БД довільної складності триває.
-
2
Відсутня валідація синтаксису загального запиту, зважаючи на який користувач може будувати свої фільтри та змінювати логіку AND/OR між рівнями загального запиту в БД.
-
3
Відсутня валідація величин, що вводять у фільтрах щодо відповідності їхнім типам даних полів фільтрів.
-
4
Немає можливості роботи з полями геолокації.
-
5
Немає перевірки на перевищення ліміту вилучених записів.
-
6
Не враховується локаль та мова.
-
7
Не надається можливість робити опис для записів із загальними запитами та для записів із запитами та фільтрами.
-
8
Перший реліз тільки у бета-версії, а отже, його можна використовувати тільки для тестування у девелоперських організаціях Salesforce.
Усі перелічені недоліки та обмеження, а також не перелічені будуть усуватися під час розроблення.
Дякую всім, хто дочитав до кінця і витримав мою нудну манеру оповіді.
