В этой статье мы поделимся опытом создания кастомного контрола для поиска дублей контактов в системе Microsoft Dynamics 365. Этот проект оказался не таким простым, как кажется на первый взгляд. В ходе разработки нам пришлось решать множество технических вопросов, от потребностей клиента до специфических ограничений, с которыми мы столкнулись. Мы расскажем о ключевых этапах работы, проблемах, с которыми мы столкнулись, и решениях, которые были приняты в процессе.
А узнать больше про это решение можно в нашем видео:
Запрос клиента
Один из наших клиентов столкнулся с проблемой дублирования контактов в системе. У них уже был реализован стандартный контрол для удаления дублей, но пользователи считали его неудобным и сложным, поэтому часто игнорировали его. Мы получили задачу создать новый контрол с простым и удобным интерфейсом, который был бы интуитивно понятен и легок в использовании.
Вариации мокапов
На начальном этапе мы создали несколько мокапов для будущего контрола. Поскольку нам не были предоставлены четкие требования от клиента, мы предложили три варианта. Первый вариант был прост в реализации: мы использовали обычный сабгрид с фильтрацией значений по полям. Однако этот вариант имел несколько недостатков: поиск был неточным, и требовалось потерять фокус с поля для того, чтобы поиск начался. Второй и третий варианты включали использование API для поиска дублей, таких как Elasticsearch или Suggested Duplicates API от Microsoft. Эти варианты отличались лишь способом вывода результатов: во втором варианте они отображались в виде списка, а в третьем — в виде всплывающего окна.
Мозговой штурм
После того как мокапы и прототип первого варианта были показаны клиенту, мы провели мозговой штурм для выбора подходящего механизма поиска. Мы рассматривали два варианта: использование Elasticsearch и Suggested Duplicates API от Microsoft. В итоге мы выбрали последний вариант, так как он не требовал дополнительных настроек, подключения сторонних сервисов и был уже интегрирован в Dataverse через основной поиск. Это решение было проще с точки зрения внедрения и масштабирования.
Создание PCF
После выбора метода поиска мы приступили к созданию PCF (PowerApps Component Framework) контрола. Мы стремились сделать его универсальным, чтобы его можно было настроить под разные клиентов, окружения и сущности, такие как контакты, аккаунты или возможности. Однако из-за специфики требований клиента не удалось полностью реализовать этот подход. Мы настроили контрол так, чтобы можно было выбрать сущности, поля для запроса и контекст формы. В процессе разработки пришлось создать дополнительные компоненты для обеспечения совместимости с уже существующими системами клиента.
Как это работает
Когда мы внедрили PCF на форму, пользователи могут вводить данные в поле, и система автоматически запускает поиск с задержкой 700 мс после ввода символа. При фокусировке на поле, если введено более двух символов, также запускается поиск. Результаты поиска отображаются в выпадающем списке, и пользователи могут увидеть имя записи, поле, по которому был найден контакт, и дополнительную информацию о записи. Это значительно улучшило удобство поиска и избавило от необходимости переходить в другие поля для активации поиска.
Способ с получением большей информации
Следующим шагом было добавление функционала для получения более подробной информации о записи. Теперь все результаты поиска становятся кликабельными. Изначально мы хотели открыть отдельную форму для отображения информации, но, исходя из бизнес-логики клиента, все должно было быть в одной форме. Поэтому мы выбрали вариант с поп-апом, который позволяет отображать только необходимые поля. Однако этот подход ограничил универсальность решения, так как для редактирования формы нам пришлось бы вмешиваться в код контрола.
Добавление PCF на поле телефона
Далее мы столкнулись с задачей интеграции контрола на поле с номером телефона. Проблема заключалась в том, что на этом поле уже был установлен старый контрол, который использовался для дешифрования данных. Чтобы не нарушить работу системы, мы создали новый контрол, основанный на старом, и добавили в него наш функционал поиска. Это позволило сохранить старую логику и добавить новую, не нарушив текущую работу системы.
Проблемы разработки
Во время разработки мы столкнулись с рядом проблем, в первую очередь с документацией. Информация по работе с API была разбросана по различным разделам Microsoft Learn, и нам пришлось решать многие вопросы методом проб и ошибок. Кроме того, результаты поиска не всегда были точными. Например, одна и та же фраза с пробелом в конце и без него давала разные результаты. Еще одной проблемой было отсутствие возможности получения названия поля, по которому был найден контакт, что усложняло отображение информации. Несмотря на эти трудности, нам удалось найти решения для большинства из них.
Заключение
Создание кастомного контрола для поиска дублей контактов оказалось непростой задачей, но результат оправдал наши усилия. Мы смогли предоставить клиенту удобный инструмент, который значительно упростил процесс работы с данными. Хотя в ходе разработки нам пришлось столкнуться с рядом технических проблем, мы нашли оптимальные решения для большинства из них. Этот проект стал ценным опытом и показал важность гибкости в подходах к решению задач, а также необходимость учета всех нюансов работы с API и пользовательским интерфейсом.
Comentarios