Атрибут required

1. Проблематика

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

2. Впровадження

Атрибут required в елементі <ext:column> вказує, чи є значення параметра обов’язковим під час виконання пошукового запита.

Атрибут приймає наступні значення:

  • true

  • false

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

2.1. true

true (обов’язково) означає, що відповідний параметр повинен бути переданий у запиті, інакше система поверне помилку.

XML-схема (2 параметри обов’язкові, 1 необов’язковий)
<ext:createSearchCondition name="search_condition">
        <ext:table name="customer_data">
            <ext:column name="customer_id" required="true"/>
            <ext:column name="email" required="true" searchType="equal"/>
            <ext:column name="phone_number" required="false" searchType="contains"/>
        </ext:table>
</ext:createSearchCondition>

Опис таблиці customer_data

  • customer_id — ідентифікатор клієнта

  • email — електронна адреса клієнта

  • phone_number — номер телефону клієнта

Що відбувається, якщо параметр обов’язковий?

Якщо атрибути required="true" встановлені для параметрів, система вимагає їх передання під час виконання запита. Наприклад, якщо параметри customer_id і email є обов’язковими, запит без вказаних значень поверне помилку. Це допомагає забезпечити цілісність даних і зменшує ризики неправильного виконання запита.
SQL-скрипт (пошуковий запит)
SELECT * FROM customer_data
WHERE customer_id = 'значення_пошуку' AND email = 'значення_пошуку'
-- Пошук у полях "customer_id" та "email" таблиці "customer_data" за обов'язковими параметрами.
HTTP-запит із параметром required=true і необов’язковим параметром
GET https://.../search-condition?customer_id=значення_пошуку&email=значення_пошуку&phone_number=значення_пошуку

У цьому HTTP-запиті параметри customer_id і email є обов’язковими, тоді як phone_number може бути відсутнім. Якщо обов’язкові параметри не передані, запит поверне помилку.

2.2. false

false (необов’язково) означає, що відповідний параметр може бути відсутнім у запиті. У цьому випадку запит виконуватиметься з наявними параметрами без вимоги передавати необов’язковий параметр.

XML-схема (1 параметр обов’язковий, 2 необов’язкові)
<ext:createSearchCondition name="search_condition_optional">
        <ext:table name="employee_data">
            <ext:column name="employee_id" required="true"/>
            <ext:column name="first_name" required="false" searchType="startsWith"/>
            <ext:column name="last_name" required="false" searchType="contains"/>
        </ext:table>
</ext:createSearchCondition>

Опис таблиці employee_data

  • employee_id — ідентифікатор працівника

  • first_name — ім’я працівника

  • last_name — прізвище працівника

Коли використовувати required="false"?

Значення required="false" застосовується, коли параметр є необов’язковим для виконання запита. Це дозволяє використовувати пошук із неповним набором параметрів, що надає гнучкість і зменшує потребу в додаткових гілках бізнес-процесів.
SQL-скрипт (пошуковий запит із необов’язковими параметрами)
SELECT * FROM employee_data
WHERE employee_id = 'значення_пошуку'
-- Пошук у полі "employee_id" таблиці "employee_data" з можливими додатковими фільтрами за "first_name" та "last_name".
HTTP-запит із обов’язковим та необов’язковими параметрами
GET https://.../search-condition?employee_id=значення_пошуку&first_name=значення_пошуку&last_name=значення_пошуку

У цьому запиті employee_id є обов’язковим параметром, тоді як first_name і last_name є необов’язковими. Запит може виконуватися навіть за відсутності цих додаткових параметрів.

3. Переваги

Запровадження можливості визначати обов’язкові та необов’язкові параметри під час формування пошукових умов дозволяє:

  • Скоротити кількість гілок у бізнес-процесах, спрощуючи їхню логіку.

  • Підвищити безпеку системи, запобігаючи несанкціонованому доступу до конфіденційних даних.

  • Гнучко налаштовувати пошукові умови залежно від доступних параметрів.

Крім того, тепер можна використовувати один делегат замість декількох гілок у бізнес-процесі:

  • Якщо це сервісне завдання, достатньо використати делегат Search entities in data factory для пошуку сутностей за параметрами.

  • Якщо це завдання користувача, можна використовувати делегат User Form із компонентом Select для вибору параметрів на формі завдання.

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