Методы интеграции специализированных информационных систем

Дегтярева А.М.

Методы интеграции специализированных информационных систем

09.04.02 Информационные системы и технологии

Информатика

Диссертации

Вуз: Белгородский государственный университет - национальный исследовательский университет (НИУ «БелГУ»)

ID: 5c1a54b87966e104f6f85306

UUID: c8599240-e5c7-0136-fd4e-525400005860

Язык: Русский

Опубликовано: больше 5 лет назад

Просмотры: 57

Дегтярева А.М.

Источник: Федеральное государственное автономное образовательное учреждение высшего образования «Белгородский государственный национальный исследовательский университет»

Комментировать 0

Рецензировать 0

Скачать - 1,3 МБ

Поделиться работой

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» ( Н И У « Б е л Г У » ) ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК КАФЕДРА ИНФОРМАЦИОННЫХ И РОБОТОТЕХНИЧЕСКИХ СИСТЕМ МЕТОДЫ ИНТЕГРАЦИИ СПЕЦИАЛИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Магистерская диссертация обучающегося по направлению подготовки 09.04.02 Информационные системы и технологии очной формы обучения группы 07001635 Дегтяревой Анастасии Михайловны Научный руководитель доцент, Гахов Р. П. Рецензент к.т.н., доцент, Зайцева Т. В. БЕЛГОРОД 2018

СОДЕРЖАНИЕ ВВЕДЕНИЕ .............................................................................................................. 3 1. Анализ существующих подходов для интеграции информационных систем ....................................................................................................................... 6 1.1 Интеграция на уровне данных ......................................................................... 6 1.2 Интеграция с помощью корпоративных приложений .................................. 7 1.3 Интеграция с помощью web-служб и web-API .............................................. 8 2. Проектирование интеграции информационных систем ............................... 10 2.1 Информационная модель интеграции систем .............................................. 10 2.2 Проектирование разделов интеграции систем ............................................. 15 2.2.1 Проектирование раздела «Заказы питания» .............................................. 16 2.2.2 Проектирование раздела «Журнал взаимодействия» ............................... 19 2.3 Проектирование интеграции информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-сервиса по средствам API .... 21 2.3.1 Загрузка данных в раздел «Заказы питания» ............................................ 21 2.3.2 Загрузка данных по учащимся .................................................................... 23 2.3.3 Выгрузка квитанций по лицевым счетам .................................................. 26 2.3.4 Выгрузка данных по состоянию баланса лицевого счета ........................ 29 3. Программная реализация интеграции информационных систем ................ 31 3.1 Разработка в ПП «Парус 8» ............................................................................ 31 3.2 Разработка web-API......................................................................................... 41 ЗАКЛЮЧЕНИЕ ..................................................................................................... 44 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ................................................. 45 ПРИЛОЖЕНИЯ ..................................................................................................... 48 2

ВВЕДЕНИЕ В настоящий момент взаимодействие информационных систем друг с другом является основой для существования и успешного развития компаний. Для пользователей интеграция систем решаем проблемы, связанные с приемом и передачей данных, со временем обработки информации, с доступностью к данным и д.р. Информационные системы стали неотъемлемой частью современной экономики. К интеграции систем относится сбор различных подсистем в единое целое с физической или функциональной точки зрения. Глобализация вопроса о передаче данных привела к вынужденному обмену информацией между системами. Научная новизна заключается в модернизации метода интеграции специализированных информационных систем «Виртуальная школа» и программного продукта (ПП) «Парус 8». Объектом исследования выбран процесс учета оплаты питания в образовательных учреждениях. Предметом исследования являются методы и средства интеграции информационных систем. Цель магистерской диссертации – совершенствование учета оплаты школьного питания за счет его автоматизации путем интеграции специализированной информационной системы образовательных услуг (ИСОУ) «Виртуальная школа» и программного продукта (ПП) «Парус 8». К задачам магистерской диссертации относится:  анализ методов интеграции информационных систем;  проектирование интеграции специализированных информационных систем;  разработка интеграции специализированных информационных систем. На сегодняшний момент существуют различные методы интеграции информационных систем. Для начала необходимо рассмотреть факторы, влияющие на интеграцию: 3

Безопасность – если данные передаются не из рук в руки, а передаются по каналам связи, вопрос о шифровании данных становится более актуальным. Мобильность – пользователям необходимо реагировать и передавать данные мгновенно, за кроткий промежуток времени, пользователь должен принять информацию, обработать и отправить ответ. Непрерывность цикла работы – синхронизация и обновление систем не должно влиять на работу пользователей и функционирование системы в целом. Высокая загруженность – количество пользователей, работающих в системе одновременно, поток обрабатываемой и передаваемой информации. Интерактивность – пользователь системы всегда ожидает от системы большей скорости реагирования, быстродействия и оперативности обработки данных. Межсистемная интеграция – взаимосвязь между системами партнеров, клиентов, поставщиков и т.д . При решении задачи, связанной с межсистемной интеграцией сложность, заключается в следующих параметрах: Концептуальные различия систем. Разработчики систем на этапе проектирование изначально использовали разные решения. Технологические различия систем. Использование разных форматов данных, связей взаимодействия и сервисов. Для решения сложных вопрос интеграции необходимо использовать следующий набор средств: Стандартизация – использовать международные, государственные, отраслевые стандарты разработки. Интеграция на уровне брокеров. Выбор этого средства имеет преимущество в том, что можно разработать дополнительный блок, к которому могут обращаться все системы и разными способами, например, 4

через базу данных и RPC. Недостатком такого средства является сложность и трудоемкость разработки. Интеграция на уровне данных – возможность, при которой системы могут обращаться в одну базу данных. Преимущества такого средства заключаются в низкой стоимости интеграции. К недостаткам следует отнести тот факт, что если изменится структура базы данных, необходимо будет переписывать программный код всех процедур, приложений и отчетов. Интеграция с помощью сервисов – современный и быстро совершенствующий подход интеграции систем. К преимуществам можно отнести взаимодействие интерфейсов и форматов данных, что способствует быстрой передачи данных. При разработке интеграции информационной системы образовательных услуг (ИСОУ) «Виртуальная школа» и программного продукта (ПП) «Парус Бюджет 8» используется интеграция при помощи webAPI. Управление информацией сервиса полностью основывается на протоколе передачи данных HTTP. Магистерская диссертация выполнена на 48 листах, включает в себя 3 раздела, введение, заключение, список используемых источников и приложения. 5

1 Анализ существующих подходов для интеграции информационных систем Интеграция – это взаимодействие разных систем, их блоков, передача данных в разных форматах. Интеграция может проходить на уровне данных, сетевых устройств, программных приложений, пользовательских интерфейсов и различных сервисов [1]. Рассматривая вопрос о межсистемной интеграции самой главной задачей становится найти оптимальный способ интеграции. Чистая система интеграции – трудоемкий и дорогостоящий процесс. Затраты на такую интеграцию увеличиваются за счет сопровождения чистой системы. Поэтому, для выбора оптимального способа интеграции необходимо рассмотреть возможные варианты и оценить их преимущества и недостатки. 1.1 Интеграция на уровне данных При интеграции на уровне данных возникает много вопросов по типам и форматам данных. Преобразование разновидной информации доставляет много проблем со сбором данных, их структурированием, обработкой, хранением и передачей [2]. Для интеграции на уровне данных, как правило используют стандартные протоколы и интерфейсы, такие как SQL. Преимущества интеграции на уровне данных заключаются в низкой стоимости интеграции. К недостаткам следует отнести тот факт, что если изменится структура базы данных, необходимо будет переписывать программный код всех процедур, приложений и отчетов. Самым простым примером, где используется такой вид интеграции – системы электронного документооборота, CRM и ERP-системы. Такие системы используют, изменяют информацию друг друга, как раз за счет интеграции данных. 6

1.2 Интеграция с помощью корпоративных приложений Интеграция корпоративных приложений (EAI) это использование технологий и функций по всему предприятию, возможность интеграции программных приложений и аппаратных систем. Многие несвободные и открытые проекты обеспечивают поддержку решения EAI [3]. Развивающиеся связующие технологии EAI включают веб-службы интеграции, сервис ориентированные архитектуры, интеграции контента и бизнес-процессов. Взаимосвязь между приложениями предприятия (EA), такие как управления отношениями с клиентами (CRM), управление цепочками поставок (SCM) и бизнес-аналитики не автоматизированы. Таким образом EAs не разделяют общие данные или бизнес-правила. EAI позволяет упростить и автоматизировать бизнес-процессы без применения чрезмерных изменений структуры приложения или данных [4]. При EAI возникают проблемы с несовместимостью операционных систем, архитектур баз данных и/или языков программирования, а также другие ситуации, где унаследованных систем больше не поддерживаются производителем. Эти проблемы возникают, если следующие вопросы решаются с помощью EAI: Интеграция данных - обеспечивает последовательную информацию между различными системами; Независимость поставщиков - бизнес-политики или правила, касающиеся конкретные бизнес-приложения не должны осуществляться заново при замене части приложений. Использование EAI при интеграции систем и/или приложений — это создание «брокера» информации, блок, к которому могут обращаться все системы и разными способами, например, через базу данных и RPC. Недостатком такого средства является сложность и трудоемкость разработки. 7

1.3 Интеграция с помощью web-служб и web-API Для начала необходимо определиться чем web-API отличается от других web-служб. Все веб-службы являются API-интерфейсами, но не все API-интерфейсы являются веб-службами. Web-API и веб-службы часто путаются друг с другом, однако web-API - это эволюция веб-сервисов. Оба облегчают передачу информации, но web-API более динамичны, чем вебсервисы [9]. По определению, веб-служба представляет собой программное обеспечение, которое доступно с помощью браузера. Клиент вызывает вебслужбу, отправляя запрос, как правило в форме XML-сообщения, и служба отправляет ответ, также в формате XML. Связь между клиентом и вебслужбой обычно создается с помощью HTTP. Типичный веб-API определяет, как программные компоненты должны взаимодействовать друг с другом с использованием протокола HTTP. Клиенту не нужно знать, какую процедуру вызывать на сервере. Вместо этого он использует набор команд, которые встроены в HTTP, и когда команда поступает с другого конца, система получает информацию о том, что с ней делать [11]. Главным преимуществом веб-API является гибкость. Клиентская система и обслуживающая система («поставщик») настолько независимы друг от друга, что каждый из них может использовать разные языки (Java, Python, Ruby и т. Д.). Для своей части общая реализация. Кроме того, полезная нагрузка данных может быть нескольких типов, таких как JSON или XML. API-интерфейсы RESTful чаще всего используют протокол HTTP. API определяет, как компоненты разных систем должны взаимодействовать друг с другом. API представляет собой набор протоколов и подпрограмм; ответы, как правило, возвращаются как данные JSON или XML. API могут использовать какой-либо протокол ограничиваться только им. тем же способом, что и веб-служба. 8 связи и не

Веб-API и веб-службы служат средством интеграции систем. Оба поддерживают данные на основе XML, но JSON – это более распространенный текстовый формат обмена данными для веб-API. При сравнении веб-сервисов с веб-API значимость заключается в объеме работы, которую должны обработать сервисы. Процессы обработки данных называют сериализацией и десериализацией. Сериализация и десериализация JSON в сценарии веб-API обычно требует гораздо меньше работы, что, в свою очередь, приравнивается к лучшей производительности и меньшему количеству циклов вычисления. Это одна из причин, почему веб-API отлично подходят для передачи информации на мобильных устройствах и планшетах; в отличие от настольных компьютеров и служб, где они имеют ограниченные среды обработки. Веб-службы облегчают взаимодействие между двумя системами и почти всегда зависят от интерфейса, подобного XML-RPC. SOAP - преемник XML-RPC, определяет упомянутый выше обмен на основе XML и более связан с архитектурой клиент - сервер [17]. На данный момент веб-сервисы являются сервисом интеграции от одного устройства к другому; они обмениваются данными через Интернет и оптимизированы для связи между машинами, что означает, что машиночитаемые файлы и форматы (например, XML) легко переносятся. API-интерфейсы представляют собой программные интерфейсы с абстрактным набором функций для доступа к веб-приложениям. Рассмотрев различные факторы, влияющие на выбор средства интеграции и изучив возможные методы интеграции специализированных информационных систем, можно сделать вывод, что для достижения поставленной цели в работе необходимо рассматривать интеграцию с помощью web-API. Выбор данного метода обеспечивает доступную и быструю разработку системы интеграции, а также обслуживание с использованием минимальных, как трудовых, так и финансовых затрат, за счет использования в разработке простого интерфейса управления информацией без использования дополнительных внутренних прослоек. 9

2 Проектирование интеграции информационных систем 2.1 Информационная модель интеграции систем Перед тем, как приступить к проектированию интеграции специализированных информационных систем ИСОУ «Виртуальная школа» и «Парус 8» необходимо построить информационную модель «Как должно быть» (рисунок 1): Технические задания Закон.база Бел.област и С тандарты API База начислений для банка Интеграция ПП Парус-8 и ИСОУ Виртуальная школа Реест р оплат от банка 0? Бух галт ер 0 П ользоват ельские процеду ры П ользоват ельские задания С пециалисты кмпании ФИТ П ользоват ельские функции N ODE: TITLE: A-0Рисунок Интеграция ПП Парус-8 и ИСОУ Виртуальная школа N UMBER: 1 – Информационная модель «Как должно быть» Процесс «Интеграция ПП Парус-8 и ИСОУ Виртуальная школа» имеет входные данные в виде реестров оплат от банка. К выходным данным процесса относится база начислений для банка. Управление включает в себя следующее: законодательная база Белгородской области; технические задания, стандарты API. К механизму, в процессе «Интеграция ПП Парус-8 и ИСОУ Виртуальная школа» относится: бухгалтер, пользовательские задания, пользовательские функции, пользовательские процедуры и специалисты компании «ФИТ». 10

Декомпозиция процесса «Интеграция ПП Парус-8 и ИСОУ Виртуальная школа» выглядит следующим образом (рисунок 2): NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLIC ATION Закон.база Бел.област и A-0 Стандарты API Технические задания База начислений для банка Процессы ПП "Парус 8" Реест р оплат от банка 0? Данные о сост оянии л/с 1 Данные для формир. квит анций Квитанция для оплаты web-API 0? Данные по т ипам пит ания Пользоват ельские задания 2 Данные о заказам питания Ответ на запрос Пользоват ельские функции Факт ический баланс по л/сОтвет на запрос Данные по у чащимся Информация по т ипам пит ания Процессы ИСОУ "Вирт уальная школа" 0? Информация по заказам пит ания Бух галт ер NODE: Пользоват ельские процеду ры Специалисты кмпании ФИТ Информация по у чащимся ПП Парус-8 и ИСОУ Виртуальная школа Рисунок 2 –Интеграция Декомпозиция процесса «Интеграция Парус-8 и ИСОУ TITLE: A0 3 NUMBER: Виртуальная школа» Декомпозиция процесса «Интеграция Парус-8 и ИСОУ Виртуальная школа» включает в себя следующие процессы: «ПП «Парус 8», «web-API», «ИСОУ «Виртуальная школа». К входным данным процесса «ПП «Парус 8» относится реестры оплат от банка, данные по типам питания, данные по учащимся и данные по заказам питания. К выходным данным процесса «ПП «Парус 8» относится база начислений для банка, данные о состоянии лицевого счета, данные для формирования квитанций. Управление включает в себя законодательную базу Белгородской области, и технические задания. 11

Механизмом, в процессе «ПП «Парус 8» выступает бухгалтер, пользовательские задания, пользовательские функции и пользовательские процедуры. Процесс «web-API» имеет входные данные в виде данных о состоянии лицевого счета, данных для формирования квитанций, информации по типам питания, информации об учащихся и информации о заказах питания, и ответа на запрос от ИСОУ «Виртуальная школа». К выходным данным в процессе «web-API» относятся квитанции на оплату, фактический баланс по лицевым счетам, ответ на запрос, данные по учащихся, данные по типам питания и данные о заказах питания. Управлением в процессе «web-API» выступают технические задания и стандарты API. К механизму в процессе «web-API» относятся пользовательские задания, пользовательские функции и пользовательские процедуры. Процесс «ИСОУ «Виртуальная школа» имеет следующие входные данные: квитанции на оплату, фактический баланс по лицевым счетам, ответ на запрос. К выходным данным относится информация по учащимся, информация по типам питания, информация по заказам питания и ответ на запрос от web-API. Управлением в процессе «ИСОУ «Виртуальная школа» выступает законодательная база Белгородской области и технические задания. Механизмом в данном процессе являются специалисты компании «ФИТ». Декомпозиция процесса «Парус 8» представлена на рисунке 3. 12

U SED AT: AUTH OR: DATE: 08.06.2018 WORKIN G PROJEC T: Инт еграия П П П ару с-8 и ИС ОУ Вирт уальная школа REV: 15.06.2018 DRAFT DATE C ON TEXT: REC OMMEN DED N OTES: 1 2 3 4 5 6 7 8 9 10 PUBLIC ATION A0 Технические задания Закон.база Бел.област и Данные по учащимся READER ФИО, л/с, принадлежност ь у чащегося П роцессы раздела "Личные карт очки" 0? 1 Данные о состоянии л/с Данные о заказам питания П роцессы раздела "Заказы питания" База начислений для банка Данные по типам питания 0? Данные для формир. квитанций 2 Данные по оплате П ользоват ельские задания Реест р оплат от банка П роцессы раздела "Реест ры на зачисление" П ользоват ельские процеду ры 0? Бух галт ер П ользоват ельские функции N ODE: Процессы ПП "Парус 8" TITLE: 3 N UMBER: Рисунок 3 – Декомпозиция процесса «ПП "Парус 8» Декомпозиция представлена в виде трех процессов: «Раздел «Личные карточки», «Раздел «Заказы питания» и «Раздел «Реестры на зачисление». Процесс «Раздел «Личные карточки» имеет выходные данные в виде данных по учащимся. К выходным данным относятся ФИО, лицевой счет и принадлежность учащегося. Управлением в процессе выступает законодательная база Белгородской области и технические задания. К механизму относится бухгалтер, пользовательские задания, пользовательские функции и пользовательские процедуры. В процессе «Раздел «Заказы питания» к входным данным относятся данные о заказах питания, данные по типам питания, ФИО, лицевой счет и принадлежность учащегося, и данные по оплате. Выходные данные в этом процессе заключаются в данных о состоянии лицевого счета, базе начислений для банка и данных для формирования квитанций. К управлению в процессе «Раздел «Заказы питания» относится законодательная база Белгородской области и технические задания. К 13

механизму - бухгалтер, пользовательские задания, пользовательские функции и пользовательские процедуры. Процесс «Раздел «Реестры на зачисление» имеет входные данные в виде реестра оплат от банка. К выходным данным относятся данные по оплате за питание учащихся. Управлением в процессе «Реестры на зачисление» выступает законодательная база Белгородской области и технические задания. Механизмом выступает бухгалтер. U SED AT: DATE: 08.06.2018 WORKIN G READER Декомпозиция процесса «web-API» изображена на рисункеDATE4. C ON TEXT: AUTH OR: PROJEC T: Инт еграия П П П ару с-8 и ИС ОУ Вирт уальная школа REV: 11.06.2018 REC OMMEN DED N OTES: 1 2 3 4 5 6 7 8 9 10 Технические задания DRAFT PUBLIC ATION A0 С тандарты API Информация по т ипам пит ания Обработ чик посту пающей информации Информация по у чащимся Ответ на запрос Информация по заказам питания 0? 1 Квитанция для оплаты Данные для формир. квитанций Данные по типам питания Данные по учащимся Обработ чик исходящей информации Ответ на запрос 0? Данные о заказам питания Факт ический баланс по л/с 2 Кальку лят ор баланса Данные о состоянии л/с 0? 3 С формированные данные о балансе П ользоват ельские процеду ры П ользоват ельские функции П ользоват ельские задания Рисунок 4 – Декомпозиция процесса «Web-API» Декомпозиция процесса «Web-API» включает следующие процессы: «Обработчик поступившей информации», «Обработчик исходящей информации» и «Калькулятор баланса». Процесс «Обработчик поступившей информации» имеет входные параметры такие как информация по типам питания, информация по учащимся, информация по заказам питания. К выходным параметрам этого процесса относится ответ на запрос. 14

К управлению в процессе «Обработчик поступившей информации» относятся технические задания и стандарты API. Механизмом в процессе выступают пользовательские задания, пользовательские функции и пользовательские процедуры. В процессе «Обработчик исходящей информации» входными данными являются данные для формирования квитанций и ответ на запрос. К выходным данным относятся квитанции для оплаты, данные по типам питания, данные по заказам питания, данные по учащимся и фактический баланс по лицевому счету. Управлением и механизмом выступает тоже, что и в процессе «Обработчик поступившей информации». Процесс «Калькулятор баланса» имеет входной параметр в виде данных о состоянии лицевого счета. К выходным параметрам относятся сформированные данные о балансе. К управлению в процессе «Калькулятор баланса» относятся технические задания и стандарты API. Механизмом в процессе выступают пользовательские задания, пользовательские функции и пользовательские процедуры. Таким образом, была изложена модель «Как должно быть» процесса «Интеграция Парус-8 и ИСОУ Виртуальная школа». 2.2 Проектирование разделов интеграции систем Согласно, техническому заданию заказчика, см. приложение А, необходимо разработать раздел «Заказы питания», раздел «Журнал взаимодействия» и интеграцию специализированных информационных системам. Раздел «Заказы питания», который должен отражать информацию из штатного раздела «Личные карточки» в частности ФИО, лицевой счет, дату начала и дату конца действия, подведомственное учреждение и класс, в котором числится ученик. Также, раздел «Заказы питания» должен хранить 15

информацию по типам питания, начислению и списанию денежных средств и оплатах. Раздел «Журнал взаимодействия» для хранения и обработки данных в результате интеграции с «ИСОУ «Виртуальная школа» с помощью API сервиса. Интеграцию специализированных информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-сервиса по средствам API. 2.2.1 Проектирование раздела «Заказы питания» Описание раздела. Раздел «Заказы питания» должен вызываться в меню «Учет» и иметь каталожную структуру, делиться по учреждениям. Заголовок раздела должен иметь следующие поля:  «Личная карточка» - ссылка на раздел «Личные карточки»;  «ФИО» - заполняется автоматически из полей Фамилия, Имя, Отчество раздела «Личные карточки» по связи с номером личной карточки;  «Номер лицевого счета» - заполняется автоматически из поля «Лицевой счет» раздела «Личные карточки» по связи с номером личной карточки;  «Учреждение» - ссылка на заголовок раздела «Учреждения»;  «Класс» - ссылка на спецификацию «Группы» раздела «Учреждения»;  «Региональный бюджет» - числовое поле, рассчитывается путем сложения значений поля «Региональный бюджет» спецификации «Питание»;  «Муниципальный бюджет» - числовое поле, рассчитывается путем сложения значений поля «Региональный бюджет» спецификации «Питание»;  «Родительская оплата» - числовое поле, рассчитывается путем сложения значений поля «Родительская оплата» спецификации «Питание». 16

Спецификация раздела «Заказы питания» должна имеет четыре вкладки: «Питание», «Начисления», «Оплаты» и «Расчет за месяц». Спецификация «Питание» должна состоять из следующих полей:  «Дата» - поле формата ДД.ММ.ГГГГ;  «Наименование блюда» значение - соответствует полю «Примечание» из доп.словаря «Виды блюд»;  «Тип питания» - значение из доп.свойства «Тип питания» соответствующего «Вида блюда»;  «Региональный бюджет» значение - из доп.свойства «Региональный бюджет» соответствующего «Вида блюда»;  «Муниципальный бюджет» - значение из доп.свойства «Муниципальный бюджет» соответствующего «Вида блюда»;  «Родительская оплата» - значение из доп.свойства «Родительская оплата» соответствующего «Вида блюда». В спецификации «Питание» должны быть стандартные действия: «Добавить», «Изменить», «Удалить». Спецификация «Начисления» формируется на основании спецификации «Питание», должна состоять из следующих полей:  «Наименование» - поле соответствует полю «Наименование» спецификации «Питание»;  «Месяц» - строковое поле, заполняется из параметра Расчетный период;  «Год» - числовое поле, заполняется из параметра Расчетный период;  «Количество» - числовое поле, значение поля соответствует количеству записей данного наименования в спецификации «Питание» в текущем расчетном периоде;  путем «Региональный бюджет» - числовое поле, поле вычисляется суммирования значений поля 17 «Региональный бюджет» в

спецификации «Питание» да данному наименованию в данном расчетном периоде;  путем «Муниципальный бюджет» - числовое поле, поле вычисляется суммирования значений поля «Муниципальный бюджет» в спецификации «Питание» да данному наименованию в данном расчетном периоде;  «Родительская оплата» - числовое поле, поле вычисляется путем суммирования значений поля «Родительская оплата» в спецификации «Питание» да данному наименованию в данном расчетном периоде. В спецификации «Начисления» стандартные действия отсутствуют. Спецификация «Оплаты» должна имеет следующие поля: «Год», «Месяц», «Сумма», задолженности», «Дата платежа», «Тип «Документ-основание», «Тип оплаты», «Погашение документа-основания», «Номер документа», «Дата документа-основания», «Примечание». В спецификации «Оплаты» должны быть стандартные действия: «Добавить», «Изменить», «Удалить». Сумма в поле «Входящий остаток» - поле заполняется автоматически, путем переноса значения из поля «Исходящий остаток» прошлого периода. Сумма в поле «Начислено» - поле заполняется автоматически из поля «Начислено» (Родительская оплата) спецификации «Начисления»; Сумма в поле «Оплачено» - поле заполняется автоматически, путем сложения значений поля «Сумма» в спецификации «Оплаты», у которых Тип оплаты - Оплата. Сумма в поле «Возвращено» - поле заполняется автоматически, путем сложения значений поля «Сумма» в спецификации «Оплаты», у которых Тип оплаты - Возврат. Сумма в поле «Исходящий остаток» - значение поля рассчитывается автоматически путем вычитания значения из поля «Оплачено» значение поля «Начислено». 18

В спецификации «Расчет за месяц» стандартные действия отсутствуют. Действия в разделе. Заголовок документа должен содержать стандартные действия «Добавить», «Размножить», «Исправить», «Удалить». Данные в разделе должны отображаться в рамках одного периода (месяца). Создать действие «Сменить расчетный период». При выполнении действия отображается форма для задания нового расчетного периода (месяц, год). После выбора периода и нажатия ОК изменяются данные, отображаемые в спецификациях "Начисления" и "Оплаты". В разделе «Заказы питания» отображаются только те записи, в личных карточках которых срок действия включает в себя хотя бы один день текущего расчетного периода. 2.2.2 Проектирование раздела «Журнал взаимодействия» Раздел должен вызываться в меню «Учет», иметь каталожную структуру и делиться по учреждениям. Заголовок раздела должен содержать следующие поля:  «Пользователь» - учетное имя пользователя, по которым выполняется пользовательское задание;  «Вид операции» - текстовое поле, может принимать следующие значения: «Получение данных о заказах питания», «Получение данных об учениках», «Передача данных по оплатам», «Передача квитанций», «Получение данных о типах питания»;  «Идентификатор документа» - числовое поле, значение номера обработки данных на сервисе;  «Дата начала действия» - поле в формате ДД.ММ.ГГГГ ЧЧ.ММ.СС, дата и время запуска пользовательского задания; 19

 «Дата окончания действия» - поле в формате ДД.ММ.ГГГГ ЧЧ.ММ.СС, дата и время окончания работы пользовательского задания;  «Количество сообщений» - числовое поле, для записи количества сообщений, возникших при передаче данных с сервиса;  «Количество ошибок» - числовое поле, для записи количества ошибок, возникших при передаче данных с сервиса;  «Время выполнения» - поле в формате ЧЧ.ММ.СС, для записи фактического времени выполнения пользовательского задания;  «Дата документа» - поле в формате ДД.ММ.ГГГГ ЧЧ.ММ.СС, для записи времени, когда поступили данные от ИСОУ «Виртуальная школа». Спецификация раздела «Журнал взаимодействия» должна иметь следующие поля:  «Тип сообщения» - текстовое поле, которое может принимать следующие значение: «Сообщение», «Ошибка»;  «Вид операции» - текстовое поле, значение соответствует полю «Вид операции» заголовка раздела;  «Учреждение» - текстовое поле, для записи Id учреждения, по которому возникла ошибка на этапе обработки данных;  «Лицевой счет» - текстовое поле, для записи лицевого счета учащегося, по которому возникла ошибка на этапе обработки данных;  «Текст ошибки» - текстовое поле, для записи полного текста ошибки при обработке данных.  Раздел «Журнал взаимодействия» должен иметь следующие действия:  «Получить тип питание» - действие по которому выполняется обращение на сервис, для получения данных по типам питания;  «Отправить квитанции» - действие по которому формируется массив данных по квитанциям и отправляется на сервис; 20

 «Отправка оплат» - действие по которому формируется массив данных по оплатам и отправляется на сервис;  «Синхронизировать» - действие, по которому идет обращение к сервису и выполняются пользовательские задания по загрузке данных;  «Отработать» - действие повторной отработки записей, по котором были ошибки в предыдущих загрузках. 2.3 Проектирование интеграции информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-сервиса по средствам API 2.3.1 Загрузка данных в раздел «Заказы питания» Параметры загрузки. Данные по заказам питания передаются в следующем формате, таблица 1. Таблица 1 - Формат данных заказов питания Тип Размерность Наименование данных schoolId Int Идентификатор школы classId Int Идентификатор класса checkingAccount String Лицевой счет [dd.MM.yyyy dateTime String HH:mm:ss] Дата и время заказа Параметр studentFullName String ФИО ученика foodTypeId Int Идентификатор типа питания regionalBudget Int Региональный бюджет municipalBudget Int Муниципальный бюджет parentalPayment Int Родительская оплата Данные загружаются из сервиса по API [21]. Параметры API: PUT/provders/{providerId}/food_orders Тело запроса объектов в json описано в приложении Б. Данные должны загружаться в раздел «Заказы питания». 21

Алгоритм добавления данных: На первом шаге (а) нужно в разделе «Заказы питания» осуществлять поиск по полю «Номер лицевого счета», значение поля «Номер лицевого счета» равно значению поля «checkingAccount». Иначе, в п.d. На втором шаге (b) смотрим поле «dateTime». Если значение поля меньше «текущая дата минус один», то по записям найденных в п.1 обращаемся к спецификации «Заказы питания (Питание)» и удаляем записи, у которых значение поля «Дата» в спецификации равно значению поля «dateTime». Иначе, у найденной записи в п. а смотрим поле «Признак активности». Если «Признак активности» = Да, то переходим к спецификации «Заказы питания (Питание)» пункт c. Иначе переходим к п.d. На третьем шаге (с) в спецификацию «Заказы питания (Питание)» добавляем записи, где  в поле «Дата» записываем значение из поля «dateTime»;  в поле «Наименование блюда» записываем значение, у которого значение поля «foodTypeId» равно значению «Мнемокода» словаря «Заказы питания (Блюда)».  поля «Тип питания», «Региональный бюджет», «Муниципальный бюджет» и «Родительская оплата» заполняются соответственно из словаря «Заказы питания (Блюда)» спецификации «Периоды действия» в зависимости от заполнения поля «Наименование блюда». На четвертом шаге (d) в заголовке раздела «Заказы питания» должна добавляться новая запись, в которой в поле «Период» записываем период, который определяется по полю «dateTime», например, «dateTime» = 05.09.2017, то период – Сентябрь, записываем в формате 09/2017. Личная карточка должна выбираться по лицевому счету. Значение поля «checkingAccount» равно значению поля «Номер лицевого счета» в разделе «Личные карточки». 22

Значение поля «Учреждение», «Класс» и «Признак активности» заполняются автоматически из спецификации «История» раздела «Личные карточки» по полю «Признак активности» = «Да». Поля «Тип питания», «Региональный бюджет», «Муниципальный бюджет» и «Родительская оплата» заполняются соответственно из словаря «Заказы питания (Блюда)» спецификации «Периоды действия» в зависимости от заполнения поля «Наименование блюда». На пятом шаге (e) должна заполняться спецификация «Заказы питания (Питание)». Алгоритм заполнения спецификации описан в пункте c. 2.3.2 Загрузка данных по учащимся Параметры загрузки. Данные по учащимся передаются в следующем формате, таблица 2. Таблица 2 - Формат данных по учащимся Параметр Тип Размерность данных Наименование schoolId schoolName classId className checkingAccount Int String Int String String ID школы Наименование школы ID класса Наименование класса Лицевой счет studentFullName String ФИО ученика Рекомендованный платеж Признак активности studentActive Boolean ученика enrollmentDate Date [ddMMyyyy] Дата зачисления dismissalDate Date [ddMMyyyy] Дата выбытия Данные загружаются из сервиса по API [22]. Параметры API: recommendedPayment Int PUT/provders/{providerId}/students Тело запроса объектов в json описано в приложении В. 23

Данные должны загружаться в раздел «Контрагенты» и «Личные корточки». Алгоритм добавления данных: В разделе «Контрагенты» осуществляем поиск в поле «Мнемокод» по значению «checkingAccount» если запись контрагента найдена, то обновляем поля: Фамилия («studentFullName»), Имя («studentFullName»), Отчество («studentFullName»), (Наименование studentFullName). Далее определяем наличие личной карточки по checkingAccount если запись существует, то в спецификацию «История» добавляем запись, у которой:  «Дата обновления» - дата загрузки данных;  «Дата постановки на учет» - значение поля «enrollmentDate»;  «Дата снятия с учета» - значение поля «dismissalDate»  «Наименование школы» - определяем по полю «schoolId». Значение поля «schoolId» ищем в разделе «Учреждения» в поле «Мнемокод». Если запись найдена, то в поле «Наименование школы» записываем мнемокод контрагента найденной записи. Иначе, поле остается пустым.  «Наименование класса» - определяем по полю «classId». Значение поля «classId» ищем в спецификации «Группы» учреждения, выбранного в поле «Наименование школы». Если соответствия не найдено, то поле остается пустым.  «Признак активности» - значение соответствует полю «studentActive». Если значение поля «studentActive» = true, то «Признак активности» = Да, иначе «Признак активности» = Нет. Если личная карточка не определена, то добавляем (описание см.ниже). После этого переходим к следующей записи в загружаемом файле. если запись контрагента не найдена, то должна создаваться новая запись, в которой:  поле «Тип» - «Физическое лицо»; 24

 поле «Фамилия» - значение 1 подстроки поля «studentFullName» загружаемого файла, (разделитель пробел);  поле «Имя» - значение 2 подстроки поля «studentFullName» загружаемого файла, (разделитель пробел);  поле «Отчество» - значение 3 подстроки поля «studentFullName» загружаемого файла, (разделитель пробел);  поле «Мнемокод» - значение поля «checkingAccount»;  поле «Наименование» - значение поля «studentFullName»  добавление личной карточки  после добавления контрагента переходим к добавлению личной карточки (в разделе «Личные карточки»):  поле «Номер» - текущий номер по порядку;  поле «Контрагент» - записываем контрагента, добавленного в раздел «Контрагенты» (по значению «checkingAccount»);  поле «Номер лицевого счета» – в префикс записываем «ВШ», в номер записываем значение поля «checkingAccount» загружаемого файла;  поле «Дата постановки на учет» - значение поля «enrollmentDate»; Далее заполняем спецификацию «История»: добавляем запись, у которой:  «Дата обновления» - дата загрузки данных;  «Дата постановки на учет» - значение поля «enrollmentDate»;  «Дата снятия с учета» - значение поля «dismissalDate»  «Наименование школы» - определяем по полю «schoolId». Значение поля «schoolId» ищем в разделе «Учреждения» в поле «Мнемокод». Если запись, найдено, то в поле «Наименование школы» записываем мнемокод контрагента найденной записи. Иначе, поле остается пустым.  «Наименование класса» - определяем по полю «classId». Значение поля «classId» ищем в спецификации «Группы» учреждения, выбранного в 25

поле «Наименование школы». Если соответствия не найдено, то поле остается пустым.  «Признак активности» - значение соответствует полю «studentActive». Если значение поля «studentActive» = true, то «Признак активности» = Да, иначе «Признак активности» = Нет. 2.3.3 Выгрузка квитанций по лицевым счетам Параметры выгрузки. Данные выгружаются с сервиса по API. Параметры API: PUT/food_providers/{providerId}/receipts Тело запроса объектов в json описано в приложении Г. Данные для выгрузки: В поле «Получатель платежа» записываем значение из поля "Учреждение" раздела «Заказы питания» В поле «ЛС» записываем значение, которое определяется по связи: «Учреждения»- «Контрагенты» - «Реквизиты лицевых счетов в финансовых учреждениях». (Определяем поле «Номер счета». В спецификации «Реквизиты лицевых счетов в финансовых учреждениях» ищем строку у которой поле «Код строки»= «*ицевой*», в найденной строке считываем значение «Номер счета» и записываем его в поле «ЛС» ). В поле «ИНН» записываем значение из поля «Идентификационный номер налогоплательщика» заголовка раздела «Контрагенты» по значению указанного в поле «Получатель платежа». В поле «OKTMO» записываем значение из поля «Код ОКТМО» заголовка раздела «Контрагенты» по значению указанного «Получатель платежа». Описание заполнения полей "Счет", "Банк", "БИК". 26 в поле

Значение полей "ЛС", "Счет", "Банк" и "БИК" брать из строки, указанной в поле "Банковские реквизиты контрагента" в разделе "Учреждения". Если в поле "Банковские реквизиты контрагента" указано значение, у которого заполнено поле "Казначейство", то по связи: «Казначейство» «Реквизиты казначейства в банке». В поле «Счет» записываем значение из поля «Счет», в поле «Банк» записываем значение из поля «Наименование», в поле «БИК» записываем значение из поля «Код банка (БИК)». Если в поле "Банковские реквизиты контрагента" указано значение, у которого заполнено поле "Казначейство", то в поле «ЛС» записываем значение из поля «Номер счета» по связи: «Контрагент» -«Реквизиты лицевых счетов в банковских учреждениях» - поле «Номер счета» (вкладка Реквизиты). Иначе, л/с организации выбираем из поля "Лицевой счет" заголовка раздела "Учреждения". Значение полей "Счет", "Банк" и "БИК" брать из строки, указанной в поле "Банковские реквизиты контрагента" в разделе "Учреждения". В Л/с организации записывать значение поля "Номер счета" строки реквизита, которая указана в Учреждении только тогда, когда у строки реквизита указанной в Учреждении заполнена вкладка "Казначейства". Иначе, л/с организации выбираем из поля "Лицевой счет" заголовка раздела "Учреждения". Иначе, в спецификации «Реквизиты лицевых счетов в финансовых учреждениях» ищем строку, у которой поле «Код строки» = «азначейс», в найденной строке считываем значение «Номер счета» и записываем его в поле «Счет»; в поле «Банк» записываем мнемокод учреждения, записанного в поле «Банковское учреждение»; в поле «БИК» записываем значение из поля «БИК» вкладка «Банк». Если найдено больше одного значения, то выбираем первое найденное. Если данных не найдено, поля в квитанции оставляем пустые. 27

В поле «КБК» записываем значение, указанное в параметре экранной формы «Код бюджетной классификации». В поле «Код причины постановки на учет» записываем значение из поля «Код причины постановки на учет» заголовка раздела «Контрагенты» по контрагенту, указанному в поле «Получатель платежа». В поле «Назначение платежа» записываем выражение «Код субсидии» плюс значение из параметра экранной формы «Код субсидии». В поле «Лицевой счет учащегося» записываем значение из заголовка раздела «Заказы питания» из поля «Номер лицевого счета». В поле «ФИО» записываем значение из заголовка раздела «Заказы питания» из поля «ФИО». В поле «Класс» записываем значение из заголовка раздела «Заказы питания» из поля «Класс». В поле «Месяц» записываем значение из заголовка раздела «Заказы питания» из поля «Период». Пример квитанции представлен на рисунке 5. Рисунок 5 – Пример квитанции для выгрузки Формат данных для ДШК представлен в таблице 3. 28

Таблица 3 - Формат данных квитанции К-во Псевдоним символов Наименование поля в файле выгрузки Name 160 Получатель платежа+(ЛС) PersonalAcc 20 Счет BankName 100 Банк BIC 9 БИК В файле выгрузки отсутствует. Заполняется CorrespAcc 20 нулями. Обязателен для Сбербанка PayeeINN 11 ИНН PersAcc 10 Лицевой счет ребенка TechCode 60 Значение равно 02 2.3.4 Выгрузка данных по состоянию баланса лицевого счета Выгрузка осуществляется по всем каталогам и по всем записям в разделе «Заказы питания». Формат данных для выгрузки оплат представлен в таблице 4. Таблица 4 - Формат данных по балансу Параметр Тип Размерность данных checkingAccount String dateTime balanceBefore incoming writeOff: Int balance Данные String Int Int Int Int Наименование лицевой счет [dd.MM.yyyy дата и время совершения HH:mm:ss] операции баланс до начала операции поступило денег списано денег баланс после операции выгружаются с сервиса по API. Параметры PUT/food_providers/{providerId}/ payments Тело запроса объектов в json описано в приложении Д. Заполнение полей для выгрузки данных: 29 API:

 checkingAccount - «Лицевой счет» - значение из поля «Номер лицевого счета» раздела «Заказы питания»;  dateTime - дата выгрузки, формат ДД.ММ.ГГГГ;  incoming - «Оплачено» - значение из поля «Оплачено» вкладки «Расчет за месяц» раздела «Заказы питания»;  writeOff - «Начислено» - значение из поля «Начислено» вкладки «Расчет за месяц» раздела «Заказы питания»;  balance - «Исходящий остаток» - значение из поля «Исходящий остаток» вкладки «Расчет за месяц» раздела «Заказы питания». В данном разделе была смоделирована интеграция информационных систем и построена диаграмма «Как должно быть». Данная диаграмма показывает взаимодействие всех объектов ПП «Парус 8» и ИСОУ «Виртуальная школа» при интеграции. На основе данной модели были спроектированы объекты в ПП «Парус 8» и web-сервис для обмена данными с ИСОУ «Виртуальная школа». Далее следует описать процесс программной реализации интеграции специализированных информационных систем. 30

3 Программная реализация интеграции информационных систем 3.1 Разработка в ПП «Парус 8» Разработка разделов в ПП «Парус 8» производится в интегрированной среде разработки - Oracle SQL Developer. Oracle PL/SQL Developer - это бесплатная интегрированная среда разработки, которая упрощает процесс разработки и управления базой данных Oracle как в традиционных, так и в облачных развертываниях. PL/SQL Developer - комплексное решение для моделирования данных и платформ интеграции Oracle со сторонними базами данных. Разработка разделов производится в модуле «Администратор» ПП «Парус 8». Добавили структуру раздела «Заказы питания», рисунок 6. Рисунок 6 – Структура раздела «Заказы питания» В спецификацию «Питание» и «Оплаты» добавили следующие действия, рисунок 7 - 8. Рисунок 7 – Действия для спецификации «Питание» 31

Рисунок 8 – Действия для спецификации «Оплаты» Для раздела «Заказы питания» необходимо создать три таблицы данных: «UDO_T_ORF_MONTH_CALC», «UDO_T_ORF_FOOD» и «UDO_T_ORF_PAY». Создание таблицы данных «UDO_T_ORF_MONTH_CALC» представлено на рисунках 9 – 12. Рисунок 9 – Вкладка «Главная» таблицы «UDO_T_ORF_MONTH_CALC» 32

Рисунок 10 – Вкладка «Колонки» таблицы «UDO_T_ORF_MONTH_CALC» Рисунок 11 – Вкладка «Ключи» таблицы «UDO_T_ORF_MONTH_CALC» Рисунок 12 – Вкладка «Индексы» таблицы «UDO_T_ORF_MONTH_CALC» Создание таблицы данных «UDO_T_ORF_FOOD» представлено на рисунках 13 – 16. 33

Рисунок 13 – Вкладка «Главная» таблицы «UDO_T_ORF_FOOD» Рисунок 14 – Вкладка «Поля» таблицы «UDO_T_ORF_FOOD» Рисунок 15 – Вкладка «Ключи» таблицы «UDO_T_ORF_FOOD» 34

Рисунок 16 – Вкладка «Индексы» таблицы «UDO_T_ORF_FOOD» Создание таблицы данных «UDO_T_ORF_PAY» представлено на рисунках 17 - 21. Рисунок 17 – Вкладка «Главная» таблицы «UDO_T_ORF_PAY» Рисунок 18 – Вкладка «Поля» таблицы «UDO_T_ORF_PAY» 35

Рисунок 19 – Вкладка «Ключи» таблицы «UDO_T_ORF_PAY» Рисунок 20 – Вкладка «Проверки» таблицы «UDO_T_ORF_PAY» Рисунок 21 – Вкладка «Индексы» таблицы «UDO_T_ORF_PAY» Таким образом был разработан раздел «Заказы питания». Внешний вид раздела представлен на рисунках 22 – 25. Рисунок 22 – Раздел «Заказы питания» Раздел «Заказы питания» содержит 4 спецификации: «Питание», «Начисления», «Оплаты» и «Расчет за месяц». 36

Рисунок 23 – Спецификация «Оплаты» Спецификация «Оплаты» отображает данные о поступивших денежных средствах. Реестры платежей от Сбербанка загружаются в раздел «Реестры на зачисления» после чего отрабатываются в раздел «Заказы питания». Рисунок 24 – Спецификация «Начисления» В спецификации «Начисления» суммарно отображаются заказы питания за текущий месяц. Рисунок 25 – Спецификация «Расчет за месяц» Спецификация «Расчет за месяц» наглядно отображает информацию о начислениях, поступивших платежах и об остатках за месяц. 37

Разработка раздела «Журнал взаимодействия» производится также в модуле «Администратор» ПП «Парус 8». Структура раздела представлена на рисунке 26. Рисунок 26 – Структура раздела «Журнал взаимодействия» Для раздела «Журнал взаимодействия» необходимо создать таблицу данных «UDO_T_ORF_MONTH_CALC». Создание таблицы данных «UDO_T_ORF_MONTH_CALC» представлено на рисунках 27 – 31. Рисунок 27 – Вкладка «Главная» таблицы «UDO_T_ORF_MONTH_CALC» 38

Рисунок 28 – Вкладка «Колонки» таблицы «UDO_T_ORF_MONTH_CALC» Рисунок 29 – Вкладка «Ключи» таблицы «UDO_T_ORF_MONTH_CALC» 39

Рисунок 30 – Вкладка «Отметка» таблицы «UDO_T_ORF_MONTH_CALC» Рисунок 31 – Вкладка «Индексы» таблицы «UDO_T_ORF_MONTH_CALC» Таким образом был разработан раздел «Журнал взаимодействия». Внешний вид раздела представлен на рисунках 32 - 34. Рисунок 32 – Заголовок раздела «Журнал взаимодействия» Рисунок 33 – Спецификация раздела «Журнал взаимодействия» 40

Рисунок 34 – Действия в разделе «Журнал взаимодействия» 3.2 Разработка web-API Создание web-сервиса API производится с помощью программного обеспечения Visual Studio компании Microsoft. Visual Studio – интегрированная среда разработки программного обеспечения, позволяющая создавать, как консольные приложения, так и приложения с графическим интерфейсом. Для решения задачи, связанной с разработкой интеграции необходимо выполнить следующее: [19;20]  Создать новый проект в Visual Studio. Для этого выполнить действие File - New – Project.  Далее необходимо выбрать шаблон ASP.NET Web Application. Проект интеграции систем назовём «VirtualSchool». Рисунок 35. Рисунок 35 – Создание шаблона ASP.NET Web Application 41

 Далее в окне Новый проект выбираем Web API для ASP.NET 5 Preview Templates. Рисунок 36. Рисунок 36 – Создание проекта Web API  Далее необходимо добавить модельные классы, для представления данных в системе интеграции. Для этого необходимо по модели VirtualScholl кликнуть правой кнопкой мыши и выбрать Add - New Item. В открывшемся окне выбрать шаблон Class [20].  После чего, необходимо добавить классы репозитория. Класс репозитория необходим для хранения данных и логики их получения и отправки.  Для внедрения репозитория в контрейлер, необходимо зарегистрировать репозиторий с помощью DI-контейнера.  Для получения и/или отправки данных от сервиса ИСОУ «Виртуальная школа» необходимо создать соответствующие методы (GET, RUT, UPDATE,) в классе контрейлера. Методы описаны в приложении Е. При обращении к сервису, данные будут возвращаться в зависимости от типа файла в описанном формате json. [23].  Для проверки подлинности и авторизации используем функцию OAuth, она позволяет хранить учетные данные клиента и отправлять маркеры. В OAuth используется переменная «issuer», которая является 42

уникальным идентификатором для сущности, также используется переменная «secret» - секретный ключ, используемый для маркера безопасности.  Для загрузки данных в ПП «Парус 8» необходимо написать запрос для обращения на web-сервис, см. приложение Е [25]. В данном разделе были разработаны разделы ПП «Парус 8» и web-API для интеграции информационной системы образовательных учреждений «Виртуальная школа» и программного продукта «Парус 8». Разработанная интеграция прошла успешное тестирование и была внедрена в деятельность компании «Парусник-Белгород». Положительный результат тестирования показывает успешное выполнение поставленных задач и как следствие достижение поставленной цели. Разработанная интеграция информационных систем обеспечивает ведение учета оплаты питания. 43

ЗАКЛЮЧЕНИЕ Интеграция информационных систем - это взаимодействие разных систем, их блоков, передача данных в разных форматах. От того, как налажен обмен данными, зависит эффективность работы систем, целостность и непротиворечивость передаваемой свидетельствует том, о что информации. разработанная Данный система фактор интеграции информационной системы образовательных учреждений «Виртуальная школа» и программного продукта «Парус 8» является актуальной. Цель магистерской диссертации заключалась в совершенствовании учета оплаты школьного питания за счет его автоматизации путем интеграции ИСОУ «Виртуальная школа» и ПП «Парус 8». Для достижения поставленной цели, в работе были выполнены следующие задачи:  провели анализ существующих методов и средств интеграции специализированных ИС;  выбрали метод реализации интеграции ИС;  спроектировали интеграцию ИС;  разработали интеграцию ИС. Разработанная интеграция ИС обеспечивает:  обмен данными об учащихся в образовательных учреждениях;  обмен данными по заказам питания в образовательных учреждениях;  обмен данными по поступившим оплатам от родителей;  обмен данными по состоянию лицевого счета ребенка;  передачу квитанций для оплаты школьного питания. В дальнейшем разработанную интеграцию можно расширить путем описания новых форматов для обработки и передачи информации в рамках взаимодействия ИСОУ «Виртуальная школа» и ПП «Парус 8». 44

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 1 Степанов, Д.Ю. Перспективные направления развития корпоративных информационных систем на примере программных решений компании SAP / Д. Ю. Степанова // Аспирант и соискатель. – 2013. – Т.66. 2 Лодон, Дж. Управление информационными системами./ Дж. Лодон, К. Лодон. - Пер. с англ. под ред. Трутнева Д.Р. – СПб.: Питер. – 2005. 3 Кусов, А.А. Проблемы интеграции корпоративных информационных систем / А.А. Кусов // Управление экономическими системами: электронный научный журнал. – 2011. – Т. 28, №4. 4 Anica, P. A Framework for Enhancing Competitive Intelligence Capabilities using Decision Support System based on Web Mining Techniques. / P. Anica // Int. J. of Computers, Communications & Control. – 2009. 5 Guido, A.L. Semantic Integration of Information Systems. / A.L. Guido // International Journal of Computer Networks & Communications. – 2011. 6 Hohhof, B. Developing Information Systems for Competitive Intelligence Support. B. Hohhof // Library Trend. – 2012. 7 Дли, М. И. Способы интеграции информационных систем субъектов экономической деятельности при использовании аутсорсинга. М.И. Дли // Национальный исследовательский университет «МЭИ», г. Смоленск. – 2017. 8 Морозова, О.А. Интеграция корпоративных информационных систем. / О.А. Морозова // М.: Финансовый университет, – 2014. – 140 с. 9 Enterprise Connectivity Patterns: Implementing integration solutions with IBM. Электронный ресурс // Режим доступа: http://www.ibm.com/developerworks/webservices/library/wsenterpriseconnectivitypatterns/index.html?S_TACT=105AGX99&S_CMP=CP. 10 Gamma et al. Design Pattern – Elements of Reusable Object Orientated Software. / Addison-Wesley. – 2001. 11 Integration Patterns Overview. Электронный ресурс // Режим доступа: http://www.enterpriseintegrationpatterns.com/eaipatterns.html. 45

12 Microsoft Message Queuing (MSMQ) - промежуточная среда обмена сообщениями // Microsoft. Режим - доступа: http://www.intuit.ru/department/se/msfdev/6/1.html. 13 OASIS Web Services Business Process Execution Language (WSBPEL) TC Режим // доступа: www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsbpel. 14 Артамонов, И. Современные стандарты описания и исполнения бизнес-процессов. Электронный ресурс // Режим доступа: URL: http://ecmjournal.ru/post/Sovremennye-standarty-opisanija-i-ispolnenija-biznesprocessov.aspx. 15 Бин, Д. XML для проектировщиков. Повторное использование и интеграция /Д. Бин // М.: КУДИНЦ-ОБРАЗ. – 2004. 16 Волкова, И.А. Системы программирования: учебное пособие /Д. Бин // М.: Издательский отдел факультета ВМК МГУ. – 2009. 17 Гандерлой, М. Освоение Microsoft SQL Server: пер с англ / М. Гандерлой // М.: ИД «Вильямс». – 2009. 18 Горин, С.В. Поддержка разработки распределенных приложений в Microsoft .NET Framework / С.В. Горин // М.: МГТУим. Баумана. – 2006. 19 Зайден, М. XML для электронной коммерции /М. Зайден// М.: Бином: Лаборатория знаний. – 2010. 20 Разработка Web-сервисо41в XML и серверных компонентов на Visual Basic .NET и Visual C# .NET. / М.: Русская. –2011. 21 Руководство Microsoft по проектированию архитектуры приложений / Электронный ресурс // Корпорация «Майкрософт». – 2009. Режим доступа: https://www.microsoft.com/en-us/download 22 Самуйлов, К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными компаниями /К.Е. Самуйлов // М.: Альпина Паблишерз. – 2009. 23 Хабибулин, И.Ш. Самоучитель XML /И.Ш. Хабибулин // СПб.: БХВ-Петербург. – 2003. 46

24 Хоп, Г. Шаблоны интеграции корпоративных приложений: пер с англ / Г. Хоп // М.: ИД «Вильямс». – 2007. 25 Хохгуртль, Б. C# и Java: межплатформенные Web-сервисы /Б. Хохгуртль // М.: КУДИНЦ-ОБРАЗ. – 2013. 26 Эммерих, В. Конструирование распределенных объектов. Методы и средства программирования интерпортабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI: пер.с англ / В. Эммерих // М.: Мир. – 2012. 47

ПРИЛОЖЕНИЯ 48

ПРИЛОЖЕНИЕ А Техническое задание на разработку системы интеграции специализированных информационных систем ПП «Парус 8» и ИСОУ «Виртуальная школа» 1. Общие сведения 1.1 Наименование системы 1.1.1Полное наименование системы Интеграция специализированных информационных систем ПП «Парус 8» и ИСОУ «Виртуальная школа». 1.1.2Краткое наименование системы Система, интеграция. 1.2 Основания для проведения работ Работа выполняется в рамках трудового договора между ООО «Парусник-Белгород» и Дегтяревой А.М. 1.3 Наименование организаций – Заказчика и Разработчика 1.3.1Заказчик Заказчик: ООО «Парусник - Белгород» Адрес: г. Белгород, Белгородский проспект 77 1.3.2Разработчик Разработчик: Дегтярева Анастасия Михайловна – экспер-аналитик ООО «Парусник-Белгород» Адрес: г. Белгород, Белгородский проспект 77 1.4 Плановые сроки начала и окончания работы Начало работ – сентябрь 2017 Окончание работ – май 2018 1.5 Источники и порядок финансирования Финансирование осуществляется в рамках трудового договора между ООО «Парусник-Белгород» и Дегтяревой А.М. 49

1.6 Порядок оформления и предъявления заказчику результатов работ Работы по созданию системы интеграции сдаются разработчиком поэтапно в соответствии с планом-графиком. По окончанию выполнения каждого из этапов производится внедрение системы интеграции. 2. Назначение и цели создания системы 2. 1 Назначение системы Интеграция специализированных систем ПП «Парус 8» и ИСОУ «Виртуальная школа» предназначена для бухгалтерского учета безналичной оплаты школьного питания. 2.2 Цели создания системы Интеграция реализуется с целью перехода на безналичную оплату школьного питания в рамках выполнения губернаторской программы «Безналичный мир Белогорья». В результате создания интеграции систем: - нет движения наличных денежных средств между детьми и учителями; - для родителей доступна информация по питанию ребенка за любой период времени; - возможна безналичная оплата питания; - доступна информация по движению и остаткам денежных средств в разрезе лицевого счета в бухгалтерском учете. 3. Характеристика объектов автоматизации Компания «Парусник-Белгород» является генеральным дилером корпорации «Парус». Основным видом деятельности является комплексная автоматизация бухгалтерского учета в бюджетных учреждениях. Также, компания «Парусник-Белгород» занимается автоматизацией кадрового учета, финансового планирования и электронным документооборотом. 50

Компания «Парусник Белгород» - имеет следующую организационную структуру: Руководство разработки; компании; Отделы Бухгалтерия; обслуживания Управление клиентов; Отдел анализа и продаж и корпоративного развития; Отдел договоров и товарной логистики. Разработка интеграции специализированных информационных систем проводится совместно с Управлением анализа и разработки. 4. Требования к системе Для интеграции систем в ПП «Парус 8» должно быть реализовано следующее: - Разработан раздел «Заказы питания», который должен отражать информацию из штатного раздела «Личные карточки» в частности ФИО, лицевой счет, дату начала и дату конца действия, подведомственное учреждение и класс, в котором числится ученик. Также, раздел «Заказы питания» должен хранить информацию по типам питания, начислению и списанию денежных средств и оплатах. - В раздел «Заказы питания» должна осуществляться загрузка данных от «ИСОУ «Виртуальная школа» и выгрузка данных для «ИСОУ «Виртуальная школа» и банка. - Загрузка данных по учащимся: персональные данные, принадлежность к учреждению и состоянию лицевого счета. - Выгрузка квитанций по лицевым счетам. - Выгрузка данных по состоянию баланса лицевого счета. - Разработан раздел «Журнал взаимодействия» для хранения и обработки данных в результате интеграции с «ИСОУ «Виртуальная школа» с помощью API сервиса. - Разработана интеграция специализированных информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-сервиса по средствам API. 51

5. Состав и содержание работ по созданию системы Работы по созданию интеграции должны выполняться по следующему графику: Сентябрь 2017 – Октябрь 2017 – разработка раздела «Заказы питания», написание загрузки данных от «ИСОУ «Виртуальная школа». Ноябрь 2017 – Январь 2018 – разработка раздела «Типы питания» и «Журнал взаимодействия». Февраль 2018 – Апрель 2018 – разработки выгрузки данных из ПП «Парус 8». Настройка интеграции через веб-сервис. Май 2018 – Полное внедрение системы интеграции, устранение ошибок на этапе внедрение. Передача функционала клиентам компании «Парусник - Белгород». Написание технической документации. Заказчик: ООО «Парусник - Белгород» Ген. Директор_________ Максимов А.А. Исполнитель: ____________Дегтярева А.М. 52

ПРИЛОЖЕНИЕ Б Тело запроса объектов в json для заказов питания { "title": "Food Orders", "description": "JSON schema for Food Orders", "type": "array", "items": { "type": "object", "properties": { "SchoolId": { "type": "integer" }, "ClassId": { "type": "integer" }, "CheckingAccount": { "type": "string", "maxLength": 10 }, "DateTime": { "type": "string", "format": "date-time" }, "StudentFullName": { "type": "string", "maxLength": 770 }, "FoodTypeId": { "type": "integer" }, "RegionalBudget": { "type": "integer" }, "MunicipalBudget": { "type": "integer" }, "ParentalPayment": { "type": "integer" } } } } 53

ПРИЛОЖЕНИЕ В Тело запроса объектов в json для учеников { "title": "Students", "description": "JSON schema for Students", "type": "array", "items": { "type": "object", "properties": { "SchoolId": { "type": "integer" }, "SchoolName": { "type": "string", "maxLength": 256 }, "ClassId": { "type": "integer" }, "ClassName": { "type": "string", "maxLength": 256 }, "CheckingAccount": { "type": "string", "maxLength": 10 }, "StudentFullName": { "type": "string", "maxLength": 770 }, "RecommendedPayment": { "type": "number" }, "StudentActive": { "type": "boolean" }, "EnrollmentDate": { "type": "string", "format": "date-time" }, "DismissalDate": { "type": "string", "format": "date-time" } } } } 54

ПРИЛОЖЕНИЕ Г Тело запроса объектов в json для квитанций { "title": "Receipts", "description": "JSON schema for Receipts", "type": "array", "items": { "type": "object", "properties": { "Payee": { "type": "string" }, "PayeePersonalAccount": { "type": "string" }, "PayeeInn": { "type": "string" }, "Oktmo": { "type": "string" }, "BankName": { "type": "string" }, "Bic": { "type": "string" }, "CheckingAccount": { "type": "string" }, "Cbc": { "type": "string" }, "Purpose": { "type": "string" }, "ChildFullName": { "type": "string" }, "ChildPersonalAccount": { "type": "string" }, "PaymentType": { "type": "string" }, "ClassNum": { "type": "string" }, "PaymentPeriod": { "type": "string" }, "Sum": { "type": "number" } 55 } } }

ПРИЛОЖЕНИЕ Д Тело запроса объектов в json для оплат { "title": "Payments", "description": "JSON schema for Payments", "type": "array", "items": { "type": "object", "properties": { "CheckingAccount": { "type": "string", "maxLength": 10 }, "DateTime": { "type": "string", "format": "date-time" }, "BalanceBefore": { "type": "number" }, "Incoming": { "type": "number" }, "WriteOff": { "type": "number" }, "Balance": { "type": "number" } } } } 56

ПРИЛОЖЕНИЕ Е Запрос для обращения на web-сервис create or replace procedure bel_p_food_types_load_api(p_company in number) as begin /* Loading food types */ bel_pkg_virtualscholl_api.loadFoodTypes(p_company => p_company, p_food_types_endpoint => '/api/v1/food_types'); end; create or replace procedure bel_p_food_orders_load_api(p_company in number) as begin /* Loading food orders */ bel_pkg_virtualscholl_api.loadFoodOrders(p_company => p_company, p_food_orders_endpoint => '/api/v1/food_orders/' || Bel_TDateTimeOffset.toUnixTimeMilliseconds()); end; create or replace procedure bel_p_students_load_api(p_company in number) as begin /* Loading students */ bel_pkg_virtualscholl_api.loadStudents(p_company => p_company, p_students_endpoint => '/api/v1/students/' || Bel_TDateTimeOffset.toUnixTimeMilliseconds()); end; create or replace procedure bel_p_payments_unload_api(p_company in number) as begin /* Unload payments */ bel_pkg_virtualscholl_api.unloadPayments(p_company => p_company, p_payments_endpoint => '/api/v1/payments'); end; 57

Магистерская диссертация выполнена мной совершенно самостоятельно. Все использованные в работе материалы и концепции из опубликованной научной литературы и других источников имеют ссылки на них. «___» ________________ _____ ____________________ (подпись) _________________ (Ф.И.О.) 58

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв