Відправлення сповіщень на електронні адреси з фільтрацією Blacklist

ЗМІСТ

1. Загальний опис
2. Валідаційні правила для електронної пошти та обробка помилок
3. Референтний бізнес-процес відправлення повідомлень на довільні електронні адреси
- 3.1. Моделювання структур даних
- 3.2. Моделювання бізнес-процесу
  - 3.2.1. Передумови
  - 3.2.2. Процес
4. Відображення у Кабінеті користувача

1. Загальний опис

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

Особливістю модуля є його інтегрований механізм фільтрації, який перевіряє всі електронні адреси на наявність їх доменів у чорному списку (blacklist). Цей список включає домени, заборонені для використання на території України. Фільтрація відбувається як на етапі введення даних на формі задачі, так і на етапі обробки даних делегатом бізнес-процесу.

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

2. Валідаційні правила для електронної пошти та обробка помилок

Валідаційні правила для електронної пошти включають наступні аспекти:

2.1. Валідація за регулярним виразом

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

Регулярний вираз, що використовується, виглядає так:

Приклад 1. regex

{{/^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/}}

Цей вираз перевіряє елементи, як-от:

Наявність символу @.
Валідність частини адреси до та після @.
Коректність доменних імен та доменів верхнього рівня.

2.2. Валідація згідно з blacklist

Цей аспект валідації перевіряє, чи не належить електронна адреса до списку заборонених доменів. Зокрема, перевіряються адреси, які належать до доменів компаній, які підпадають під санкції. До таких доменів належать:

mail.ru і його різновиди, такі як internet.ru, list.ru, bk.ru, inbox.ru, mail.ua, а також регіональні домени mail.kz та mail.md.
yandex та його домени, включаючи yandex.ru, yandex.ua, mail.yandex.ru, mail.yandex.ua, ya.ru, ya.ua, а також регіональні та міжнародні домени yandex.kz, yandex.by, та yandex.com.

2.3. Обробка валідаційних помилок

Неуспішна валідація: у випадку, коли валідація не проходить, делегат віддає подію-помилку (error event), яка містить опис помилки у форматі, зрозумілому для користувача, для подальшого відображення на формі.
Подвійна невідповідність: Якщо електронна адреса не відповідає як патерну, так і перебуває у blacklist, делегат повертає помилку валідації, яку моделювальник може використати для подальших кроків у бізнес-процесі.

3. Референтний бізнес-процес відправлення повідомлень на довільні електронні адреси

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

Шаблон повідомлення:

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

Вітаємо! Візьміть до уваги, що змінилася форма ветеринарного паспорту тварини. Для переоформлення паспорту зверніться в найближчу ветеринарну клініку.

3.1. Моделювання структур даних

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

Модель містить декілька основних changesets, які відображають етапи розвитку та розширення структури даних. Розгляньмо приклади більш детально.

Де можна знайти приклади моделі даних?

Приклади змодельованих структур даних ви зможете переглянути у регламенті демо-реєстру за шляхом:

data-model/feature/tablesConsent.xml
data-model/feature/createSearchConditions.xml

Приклад 2. Створення таблиці animals

<changeSet id="animal" author="registry owner">
	<createTable tableName="animals" ext:historyFlag="true">
		<column name="animal_id" type="UUID" defaultValueComputed="uuid_generate_v4()">
			<constraints nullable="false" primaryKey="true" primaryKeyName="pk_animal_id"/>
		</column>
		<column name="animal_license_id" type="UUID">
			<constraints nullable="false"
                             foreignKeyName="fk_animal_license_id"
                             referencedTableName="animal_license"
                             referencedColumnNames="animal_license_id"/>
		</column>
		<column name="animal_profile_id" type="UUID">
			<constraints nullable="false"
                             foreignKeyName="fk_animal_profile_id"
                             referencedTableName="animal_profile"
                             referencedColumnNames="animal_profile_id"/>
		</column>
		<column name="receipt" type="type_file"/>
		<column name="menu" type="type_file[]"/>
	</createTable>
</changeSet>

Цей changeset відповідає за створення основної таблиці animals. Вона включає наступні стовпці:

Назва стовпця Тип даних Опис

Назва стовпця	Тип даних	Опис
`animal_id`	`UUID`	Унікальний ідентифікатор тварини, є первинним ключем таблиці.
`animal_license_id`	`UUID`	Ідентифікатор ліцензії тварини, пов’язаний з таблицею `animal_license`.
`animal_profile_id`	`UUID`	Ідентифікатор профілю тварини, пов’язаний з таблицею `animal_profile`.
`receipt`	`File`	Поле, призначене для зберігання файлів, які можуть містити документацію.
`menu`	`File[]`	Поле для зберігання масиву файлів, що може включати різноманітні документи.

animal_id

UUID

Унікальний ідентифікатор тварини, є первинним ключем таблиці.

animal_license_id

UUID

Ідентифікатор ліцензії тварини, пов’язаний з таблицею animal_license.

animal_profile_id

UUID

Ідентифікатор профілю тварини, пов’язаний з таблицею animal_profile.

receipt

File

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

menu

File[]

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

Приклад 3. Створення композитної сутності nested_animals

<changeSet author="registry owner" id="animals info">
    <ext:createCompositeEntity name="nested_animals">
        <ext:nestedEntity name="animals" table="animals">
            <ext:link column="animal_license_id" entity="license"/>
            <ext:link column="animal_profile_id" entity="profile"/>
        </ext:nestedEntity>
        <ext:nestedEntity name="license" table="animal_license"/>
        <ext:nestedEntity name="profile" table="animal_profile"/>
    </ext:createCompositeEntity>
</changeSet>

Цей changeset створює композитну сутність nested_animals, яка включає в себе три вкладені сутності: animals, license, та profile. Вона дозволяє організувати зв’язки між різними таблицями, забезпечуючи легкий доступ до пов’язаної інформації.

Приклад 4. Додавання стовпця owner_email до таблиці animals

<changeSet author="registry owner" id="addColumn owner_email to animals">
    <ext:addColumn tableName="animals" ext:historyFlag="true">
        <column name="owner_email"
                type="varchar(50)">
        </column>
    </ext:addColumn>
</changeSet>

У цьому changeset до таблиці animals додається новий стовпець owner_email. Це поле містить електронні адреси власників тварин і має тип varchar(50). Цей стовпець є важливим для реалізації функціональності відправлення електронних повідомлень власникам тварин та демонструє валідацію електронних адрес згідно зі встановленими правилами.

Приклад 5. Додавання умови пошуку за стовпцем owner_email у таблиці animals.

<changeSet author="registry owner" id="create SC search_user_email_from_animals">
	<comment>CREATE search condition search_user_email_from_animals</comment>
	<ext:createSearchCondition name="search_user_email_from_animals">
		<ext:table name="animals">
			<ext:column name="owner_email"/>
		</ext:table>
	</ext:createSearchCondition>
</changeSet>

Цей changeset включає створення критерію пошуку (Search Condition, SC) під назвою search_user_email_from_animals. Основна мета цієї умови пошуку полягає у забезпеченні можливості пошуку за стовпцем owner_email у таблиці animals.

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

3.2. Моделювання бізнес-процесу

3.2.1. Передумови

Детально ознайомтеся з інструкцією Відправлення повідомлень користувачам через електронну пошту.

Скористайтеся референтними прикладами моделювання регламенту.

Де можна знайти приклад бізнес-процесу?

Адміністратор Платформи може розгорнути для вас демо-реєстр — еталонний реєстр, що містить референтні та інші приклади файлів для створення цифрового регламенту. Він містить різноманітні елементи для розробки моделі даних, бізнес-процесів, UI-форм, аналітичної звітності, витягів, сповіщень, зовнішніх інтеграцій та багато іншого.

Детальну інструкцію щодо розгортання демо-реєстру та отримання референтних прикладів моделювання ви знайдете на сторінці Розгортання демо-реєстру із референтними прикладами.

Приклад BPMN-схеми процесу буде доступний у регламенті демо-реєстру за пошуком по ключовим словам — feature-send-message-to-n-users-by-address.

Назви форм ви можете знайти всередині відповідних користувацьких задач (User Task) бізнес-процесу у полі Form key.

Виконайте підготовчі кроки.

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

Налаштування поштового сервера:
1. Налаштування внутрішнього SMTP-сервера: конфігурація внутрішнього SMTP-сервера, який буде займатися обробкою та відправленням електронних повідомлень (див. детальніше — Налаштування внутрішнього SMTP-сервера).
2. Налаштування підключення до поштового сервера:* встановіть та налаштуйте з’єднання із зовнішнім поштовим сервером, що буде використовуватися для відправлення електронних повідомлень (див. детальніше — Налаштування підключення до поштового сервера).
Налаштування шаблону повідомлення:
- Налаштування шаблону повідомлення: визначте та налаштуйте шаблон для електронних повідомлень, що включає текст, форматування та інші важливі параметри, які будуть використовуватися при відправленні повідомлень (див. детальніше — Налаштування шаблону повідомлення).

3.2.2. Процес

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

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

3.2.2.1. Моделювання форми для внесення адрес

Додайте користувацьку задачу, яка дозволить учасникам процесу на формі вводити довільні електронні адреси для відправлення повідомлень. Забезпечте, щоб форма була інтуїтивно зрозумілою та зручною для користувача.

bp send notifications blacklist 1

3.2.2.2. Сервісна задача для отримання сутностей у Фабриці даних

Додавання сервісної задачі:

У бізнес-процесі додайте нову сервісну задачу, використовуючи шаблон делегата Search for entities in data factory.

Детальніше про налаштування типового розширення для пошуку сутностей див. на сторінці Пошук сутностей у фабриці даних (Search for entities in data factory).

Результати отримання сутностей:

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

bp send notifications blacklist 2

3.2.2.3. Скрипт для формування переліку адрес

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

bp send notifications blacklist 3

def addressList = []

def email = submission('UserTask_FillingEmails').formData.prop('emailLatest').value()
def email1 = submission('UserTask_FillingEmails').formData.prop('emailLatest1').value()

addressList.add(email)
addressList.add(email1)

def ownerEmails = animalOwnerResponse.responseBody.elements()
ownerEmails.each {
    addressList.add(it.prop('ownerEmail').value())
}

set_transient_variable('hasNotificationErrors', false)
set_transient_variable('addressListVariable', S(addressList, 'application/json'))

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

Розглянемо цей скрипт детальніше:

Ініціалізація списку адрес:
- Створюється порожній список addressList для зберігання електронних адрес.
Отримання електронних адрес із форми:
- Витягується електронна адреса email з форми, що відповідає задачі UserTask_FillingEmails, конкретно властивості emailLatest.
- Аналогічно витягується друга електронна адреса email1, але з властивості emailLatest1.
Додавання адрес до списку:
- Обидві отримані адреси (email та email1) додаються до списку addressList.
Отримання електронних адрес власників тварин:
- Виконується звернення до відповіді animalOwnerResponse, з якої отримується список об’єктів ownerEmails.
- Для кожного елемента в цьому списку витягується властивість ownerEmail та додається до addressList.
Встановлення змінних процесу:
- Установлюється тимчасова змінна hasNotificationErrors зі значенням false, що може використовуватися для відстеження помилок відправлення повідомлень.
- Список addressList конвертується у формат JSON та зберігається у тимчасову змінну addressListVariable.

3.2.2.4. Моделювання підпроцесу та делегата для надсилання повідомлень

Після формування змінної з усіма електронними адресами, наступним кроком у бізнес-процесі є моделювання підпроцесу. Цей підпроцес залучений до послідовного відправлення повідомлень на адреси, підготовлені у скриптовій задачі.

Налаштування Sequential Multi-Instance:
- Налаштуйте підпроцес як sequential multi-instance, щоб забезпечити послідовну обробку кожної електронної адреси.
Використання типового розширення Send user notifications by address:
- У підпроцесі застосуйте шаблон делегата Send user notifications by address.
- Необхідно додати та налаштувати обов’язкові поля для цього розширення:
  - Notification channel: Встановіть email як єдиний доступний канал, обраний за замовчуванням.
  - Notification address: Вкажіть ідентифікатор адреси, який завжди буде електронною поштою для каналу EMAIL.
Заповнення додаткових полів:
- Заповніть також поля Notification message template та Notification template model для забезпечення правильної відправки повідомлень.

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

3.2.2.5. Користувацька задача з формою для заборонених адрес

Змоделюйте користувацьку задачу з формою, яка буде відображена у випадку, коли електронні адреси отримувачів нотифікації належать до переліку заборонених для використання на території України.

bp send notifications blacklist 6

4. Відображення у Кабінеті користувача

До бази даних заздалегідь були додані електронні адреси, домени яких входять у перелік заборонених для використання в Україні.

Після успішної автентифікації в Кабінеті Користувача, користувач ініціює бізнес-процес під назвою Відправка повідомлення на N emails. У ході цього процесу на формі користувачу відображаються поля для введення електронних адрес, на які будуть відправлені повідомлення.

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

bp send notifications blacklist 7

Після натискання на кнопку Далі, користувачеві відображається інформаційна форма, на якій вказується, що повідомлення не були відправлені на деякі адреси з бази даних, оскільки вони належать до доменів, заборонених для використання в Україні.

wn 1 9 7 15

bp send notifications blacklist 8

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

wn 1 9 7 16