Упс! Не вдала спроба:(
Будь ласка, спробуйте ще раз.

Репорти у Salesforce та робота з даними: спроба переосмислення

Ievgen Kyselov
Ievgen Kyselov Salesforce developer
27 грудня 2022 6 хвилин читання

Вітаю! Мене звати Євген Кисельов, я 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.

Усі перелічені недоліки та обмеження, а також не перелічені будуть усуватися під час розроблення.

Дякую всім, хто дочитав до кінця і витримав мою нудну манеру оповіді.

Якщо ви хочете поділитися з читачами SPEKA власним досвідом, розповісти свою історію чи опублікувати колонку на важливу для вас тему, долучайтеся. Відтепер ви можете зареєструватися на сайті SPEKA і самостійно опублікувати свій пост.
50 UAH 150 UAH 500 UAH 1000 UAH 3000 UAH 5000 UAH
1
Прокоментувати
Настя Заря 27.12.2022, 06:59
Дякую за матеріал!
Інші матеріали

Сприйняття брендів після виходу з ринку рф: соціологія та медіааналітика

Платформа LOOQME 7 годин тому

Що треба знати про масштабування бізнесу в Україні. Кейс Uklon

Ivan Chornohor 13 годин тому

Data Science UA запустила аналог Tinder для спільноти AI-фахівців

Кіра Іванова 1 червня 2023 13:54

Apple інтегрувала ChatGPT в клавіатуру iPhone

Ганна Гілова 31 травня 2023 15:34

Найтиповіші помилки при відкритті бізнесу в Європі та як їх уникнути

Владислав Миронович 26 травня 2023 17:00