Пример запроса к папкам и содержащихся в ним описаниям словарей изображен на рисунке 3.2.

Пример запроса к элементам справочника изображен на рисунке 3.3.

Все примеры созданы с помощью сервиса GraphiQL. Это open-source приложение, позволяющее писать запросы на приложения GraphQL. Также, с помощью этого приложения тестировался новый функционал, прежде чем записать его в Postman (в Postman пишется post-запрос, который генерируется этим приложением).

Рисунок 3.2. Запрос папок справочников

Рисунок 3.3. Запрос элементов справочника

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

Рисунок 3.4. Диаграмма кода основного приложения

3.2 Реализация сервисов, окружающих основное приложение

Всего, на текущий момент, реализовано 3 сервиса: сервис авторизации, сервис экспорта и сервис FLC. Про сервис авторизации тут не будет рассказано из соображений безопасности, хотя, с алгоритмической точки зрения, он надежен.

Сервис экспорта реализует экспорт трех типов: стандартный, экспорт иерархии и экспорт иерархии с отображением версий.

Стандартный режим экспортирует данные динамического формата в MS Excel или XML. Он допускает экспорт сразу нескольких файлов и в таком случае архивирует их (либо архивирует один файл, если пользователь установил соответствующую галочку).

Экспорт иерархии экспортирует элементы, некоторым образом выделяя иерархию: элементы первого уровня становятся листами, элементы второго уровня выделяются жирным шрифтом, элементы 3-его уровня и всех остальных курсивом, а листья отмечаются серым цветом. Листья также содержат связанные элементы другого справочника, которые отображаются после вывода соответствующего им листа и пишутся обычным шрифтом без выделения.

В случае версионного экспорта, листья также содержат в себе связанные элементы другого справочника, но они выводятся в зависимости от предыдущей версии этого листа. Причем каждый лист сравнивается с его последней версией, и связанные элементы, которых не было выделяются жирным шрифтом, а элементы, которые были до этого, но перестали существовать в новой версии выделяются зачеркнутым шрифтом. Если элемент изменился, то он выводится два раза: как зачеркнутый (исчез в этой версии) и как обычный.

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

Экспорт в XML осуществляется достаточно просто, так как данные автоматически конвертируются в XML в нужном формате с помощью converter.

Экспорт в Excel выполнен с помощью библиотеки OpenXML. Данная библиотека была выбрана, т. к. она не требует наличия на компьютере сервера MS Excel. Также поверх это библиотеки была написана библиотека для наиболее распространенных операций, таких как: создание листа со стилями, добавление ячейки, добавление строки (вместе с текстом и указанием стиля из листа со стилями), merge нескольких ячеек, создание нового листа MS Excel и т. д.

Данные для экспорта получаются при помощи основного сервиса GraphQL. При запросе экспорта пользователь присылает запрос, который после этого пересылается на основной сервис, а его результаты собираются в экспорт. Это позволяет гибко задавать экспортируемые данные (при помощи фильтров, сортировок, пейджинга, флажков и т.д.). Также благодаря такому подходу, логика работы хорошо распределена между сервисами, т. к. сервису экспорта нужно только запаковать полученные данные из основного сервиса в выбранный формат.

Примеры всех видов экспорта приведены в Приложении Б.

Сервис FLC принимает на вход ID формы. С этой формой по Id связано несколько правил, содержащий JS скрипты. Сервис FLC отправляет запрос основному сервису и получает тексты скриптов этих правил. После этого он пишет их в отдельные файлы, генерирует файл main, в который встраиваются зависимости от этих файлов и собирает его, используя команду npm run build Node.js. После этого, когда файл собран, сервис просто возвращает его текст как результат работы.

3.3 Тестирование и развертывание

Тестирование системы можно поделить на четыре части:

1. Модульное тестирование.

2. Endpoint тестирование.

3. Интеграционное тестирование.

4. Ручное тестирование.

Модульное тестирование производится с помощью фреймворка XUnit, а также принципа Dependency Inversion при написании кода. Благодаря этому принципу, код разбит на достаточно маленькие части, которые можно тестировать отдельно, используя Mock зависимостей.

Endpoint тестирование также производится с помощью фреймворка XUnit, но вместо использования прямых Mock зависимостей, код тестируется почти полностью, за исключением обращений к внешним сервисам и базе данных. Это достигается при помощи переконфигурации IoC-контейнера.

Интеграционное тестирование написано на Java и должно проверять работу системы в целом, с учетом всего окружения. В процессе разработки было решено от данного метода отказаться, чтобы сервисы можно было публиковать отдельно и сократить их зависимости.

Ручное тестирование предполагает тестирование новой функциональности перед показом заказчику. Также ручное тестирование покрывает все замечания, оставшиеся от заказчика после показа программы заказчику, и формулирует на их основе test-case, который далее должен быть учтен.

Все тесты, кроме ручного тестирования проходят или проходили (т. к. от интеграционного тестирования было решено отказаться) перед публикацией программы на сервера. Это реализовано с помощью Jenkins.

Как уже было сказано ранее, в рамках проекта была использована методология git-flow. В данном случае ветка dev является рабочей, а ветка master показывается заказчику. Ветка master обновляется в том случае, когда изменения из ветки dev стабилизируются и команда уверена в корректности работы добавленной функциональности (а также в отсутствии регресса, но это покрывается тестами и может быть отслежено даже до публикации в ветку dev.

Таким образом, все сервисы системы (в том числе база данных и клиент) существуют в двух вариантах: dev и master. Но на самом деле, было решено добавить еще 2 варианта, в которых отсутствует аутентификация. Эти варианты наиболее удобны для тестирования и отладки работы системы.

Таким образом, варианты без аутентификации не имеют сервиса аутентификации, но в систему без аутентификации также дополнительно добавляется сервис GraphiQL. Этот сервис позволяет отправлять и тестировать запросы на языке GraphQL к основному сервису. Именно с помощью этого сервиса выполнены иллюстрации примеров запроса к основному сервису GraphQL.

Архитектура системы без аутентификации изображена на рисунке 3.5., а архитектура системы с аутентификацией изображена на рисунке 3.6.

рис. 3.5. Архитектура системы без аутентификации

рис. 3.6 Архитектура системы с аутентификацией

Чтобы обеспечить подобную гибкость развертывания, был использован конфигурируемый .net core pipeline. Он позволяет влиять на конвейер обработки запроса на моменте запуска приложения на основе файла конфигурации. Это позволяет не запускать повторную сборку приложения.

Конвейер обработки запросов изображен на рисунке 3.7.

Рисунок 3.7. Конвейер обработки запроса

Стоит отметить, что каждый из этих слоев может отключаться/подменяться другим. Так, например, когда сервис в состоянии Dev, обработка ошибок возвращает полную информацию об ошибке (stack trace и т. д.), а когда сервис в состоянии master, только пользовательскую информацию. Либо, если конфигурация не требует аутентификации, то слой проверки аутентификации просто убирается. Подобная подстановка выполнена с помощью сочетания функциональности IoC - контейнера .net core и .net core pipeline.

Также, с помощью этого pipeline (а именно слоя обработки ошибок) был создан единый протокол взаимодействия между сервисами. Этот протокол написан поверх HTTP и позволяет восстанавливать состояние возникновения ошибки (в случае ее возникновения) именно в том сервисе, где она изначально возникла, так как ошибки могут подниматься вверх по этому протоколу вплоть до вызова первой операции на клиентской части.

3.4 Результаты разработки

В качестве основного результата этой работы было создано рабочее приложение, предоставляющее динамический API-интерфейс GraphQL. API обеспечивает доступ к данным, метаданные которых основаны на словарях с различными полями. Метаданные могут быть преобразованы путем изменения структуры словарей. Кроме того, реализованная система обеспечивает контроль версий словарей и их элементов.

Приложение должно помочь органам внутренних дел Российской Федерации в формировании и сборе статистических данных о преступлениях и правовой системе.

Кроме того, некоторые из них основаны на созданном API-интерфейсе GraphQL, чтобы обеспечить различные функциональные возможности, связанные с созданной системой.

Одним из таких сервисов является сервис экспорта, который обеспечивает функциональность экспорта в xml/xlsx/rar динамических данных на основе структуры словарей.

Другой сервис компилирует файлы Javascript для экранов различных автоматов, созданных для сбора или работы с данными из этой системы. Компиляция этих файлов сценариев Javascript основана на правилах для различных полей и экранов. Сервис собирает различные правила из базы данных в рабочий код сценария Java.

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

Эта система сервисов предоставляет API для интерфейса государственной автоматической системы правовой статистики.

Кроме того, эта система ценна тем, что ее легко поддерживать благодаря хорошо организованной кодовой базе и автоматической системе обновления. Она содержит модульные и интеграционные тесты, которые важны для поддержания и обновления: они обнаруживают деградацию системы и повышают уверенность в её надежности [14].

Заключение

Основным результатом этой работы является работающее приложение, соответствующее требованиям заказчика. Оно было разработано и одобрено заказчиками в ходе показов приложения. На момент написания работы, в приложение еще вносятся некоторые изменения. Преимущественно, это изменения, специфические для предметной области (например компиляция с кода на языке, специально разработанном для работников органов внутренних дел в SQL на основании некоторых правил и данных из базы данных), но к API для доступа к данным с динамической структурой это прямого отношения не имеет.

Более того, в данной работе демонстрируется реальный пример использования некоторых малоизученных технологий. Например, идея динамической схемы GraphQL еще не была раскрыта, в то время как в ходе этой работы она была создана, и было выявлено несколько преимуществ и недостатков.

Также, с учетом специфики предметной области, особое внимание в системе отделено безопасности. К сожалению, рассказать о системе безопасности в рамках публичной работы невозможно.

Также, в данной работе, была подтверждена и протестирована возможность создания динамической схемы GraphQL для работы с данными. Подобное решение имеет более широкое применение, чем просто API для доступа к некоторым динамическим данным.

Этот подход может быть использован при прототипировании приложения. Возможно разработать один такой API и разворачивать его под разные приложения с разными предметными областями. Необходимо только задать эту предметную область в метаданные приложения, чтобы получить готовый API доступа к статическим данным. Конечно, он будет менее оптимален, нежели явное API к этим статическим данным, но в рамках прототипирования это не является большой проблемой и позволяет сэкономить ресурсы.

Подобная широта применения обуславливается простотой поддерживания и надежностью приложения.

Простота поддерживания и надежность обеспечиваются за счет того, что данное решение использует фреймворк GraphQL, который косвенно способствует и принуждает к группировке кода на небольшие блоки, а также создает понятную структуру этих блоков. Это позволяет лучше понимать структуру приложения, а также облегчает покрытие его модульными и интеграционными тестами. В свою очередь .net Core обеспечивает гибкое и легко конфигурируемое развертывание приложения, что также повышает простоту поддерживания.

Практическая значимость данной работы заключается в том, что эта система должна заменить существующую, на основе платформы Prognoz. Обновленная система должна стать быстрее и удобнее. К примеру, серверная часть предыдущей системы не удовлетворяла требованиям maintainability и надежности, а также не решала проблемы с over и under fetching. Это привело к тому, что при увеличении нагрузки на систему, она стала работать очень медленно. Из-за низкой maintainability, решить эту проблему (например, введя кэширование или некоторые другие оптимизации) практически невозможно, не заменив всю систему.

Научная значимость данной работы заключается в предложенном новом способе организации доступа к динамически изменяемым данным. Также данная работа помогает раскрыть ранее не исследованные возможности GraphQL, такие как использование динамической схемы. Более того, следует отметить, что несмотря на большое количество работ, связанных с GraphQL, количество примеров реальных enterprise приложений на основе этого взаимодействия в публичном доступе крайне мало. Зачастую, для демонстрации работы используются некоторые вымышленные абстрактные примеры, что не позволяет полностью раскрыть возможности и обнаружить недостатки GraphQL.

Кроме того, были исследованы некоторые нестандартные способы применения этих технологий, такие как создание динамической схемы запросов в GraphQL, а также организация взаимодействия устаревших технологий (32-битных Oracle) с современными (.net Core).

Библиографический список

1. Антонов К. О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами // ZametkiNaPolyah.ru. 2016. URL: https://zametkinapolyah.ru/servera-i-protokoly/o-modeli-vzaimodejstviya-klient-server-prostymi-slovami-arxitektura-klient-server-s-primerami.html (дата обращения: 01.02.2019).

2. Дизайн GraphQL-схем // Github.com. 2019. URL:https://github.com/nodkz/conf-talks/tree/master/articles/graphql/schema-design (дата обращения: 01.02.2019).

3. Построение Enterprise-приложения // Java-course.ru. 2019. URL: http://java-course.ru/student/book2/scheme/ (дата обращения: 01.02.2019).

4. Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. 2018. URL: http://stepanovd.com/science/30-article-2015-1-erpappl (дата обращения: 01.02.2019).

5. AGILE - гибкая система управления проектами // 4brain.ru. 2017. URL: https://4brain.ru/blog/agile/ (date of accessed: 01.02.2019).

6. Driving commerce to the Web--Corporate Intranets and the Internet: Bitbucket. Gitflow Workflow // Atlassian.com. 2019. URL: https://ru.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow (date of accessed 01.02.2019).

7. Driving commerce to the Web--Corporate Intranets and the Internet: Microsoft. System Namespace // Microsoft.com. 2019. URL: https://docs.microsoft.com/ru-ru/dotnet/api/system?view=netframework-4.7.2. (date of accessed 01.02.2019).

8. Driving commerce to the Web--Corporate Intranets and the Internet: Oracle. Procedures and Packages // Oraclle.com. 2019. URL: https://docs.oracle.com/cd/A97630_01/appdev.920/a96590/adg10pck.htm (date of accessed 01.02.2019).

9. Fateev D.S., Klochkov K.S., Saburova V.V. Class Design Principles. Russian Federation: Young Scientist, 2016. p. 175-177.

10. Fielding R. Architectural Styles and the Design of Network-based Software Architectures//Ics.uci.edu. 2000. URL: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (date of accessed 01.02.2019).

11. Gutsch, J., Driving commerce to the Web--Corporate Intranets and the Internet: DZone. GraphiQL for ASP.NET Core // Dzone.com. 2017. URL: https://dzone.com/articles/graphiql-for-aspnet-core (date of accessed 01.02.2019).

12. Hartig, O., Pйrez, J. An Initial Analysis of Facebook's GraphQL Language, 2017. p. 20-27.

13. Kalinichenko, G.A., Skorokhod, S.V. Comparison of GraphQL and REST API technologies in the development of modern costumer-server applications, Russian Federation: Internauka, 2017. p. 47-52.

14. Martin, R. The Clean Coder: A Code of Conduct for Professional Programmers. Russian Federation: Peter, 2017. p. 153-187.

15. Eltaeib, T., Venna, T.-V.-S.-N., Madasu, V. SOLID Principles in Software Architecture and Introduction to RESM Concept in OOP. Journal of Engineering Science and Technology, 2015. p. 18-25.

Приложение А. Функциональные диаграммы

Рисунок А.1. Создание справочника AS-IS

Рисунок А.2. Редактирование справочника AS-IS

Рисунок А.3. Удаление справочника AS-IS

Рисунок А.4. Создание справочника AS-TO-BE

Рисунок А.5. Редактирование справочника AS-TO-BE

Рисунок А.6. Удаление справочника AS-TO-BE

Приложение Б. Иллюстрация экспорта

Пример обычного экспорта с сортировкой по ordinalNumber изображен на рисунке А.1.

Рисунок Б.1. Обычный экспорт

Пример экспорта с учетом иерархии изображен на рисунке A.2

Рисунок Б.2. Экспорт с учетом иерархии

Пример экспорта с учетом версий изображен на рисунке А.3.

Рисунок Б.3. Экспорт с учетом версий

Размещено на Allbest.ru