Разработка механизма обмена данными между ИС "Сервер Расчёт Квартплаты" и "1С Бухгалтерия предприятия"

В настоящее время разработано большое количество типовых и специализированных решений на платформах 1С: Предприятие различных версий, которые могут работать в тесной интеграции с другими решениями, как на этой платформе, так и с программным обеспечением сторонних производителей. Опыт внедрения прикладных решений показывает, что система позволяет решать задачи различной степени сложности - от автоматизации одного рабочего места до создания информационных систем масштаба предприятия с большим количеством удалённых рабочих мест.

Большое значение в сложившейся ситуации имеет возможность организации обмена между различными информационными системами.

Классификация технологий интеграции

На уровне отдельной организации проблема интеграции возникает сразу, как только в ней внедряется несколько корпоративных приложений. На уровне страны, региона или города она ещё более актуальна.

Можно дать следующую классификацию технологий интеграции:

- Системы интеграции корпоративных приложений (EnterpriseApplications Integration, EAI) -- технологии, ориентированные на решение проблем интеграции различных систем, приложений и данных внутри отдельной организации. Иногда для этих технологий используется аббревиатура A2A (Application-to-Application -- приложение-приложение).

- Системы интеграции между организациями (Business-to-Business Integration, B2Bi) -- технологии, ориентированные на обеспечение безопасного, надёжного информационного обмена между различными организациями и их информационными системами. Эти технологии обеспечивают пересылку информации за пределы сетевых экранов (firewall) и дают возможность автоматизировать бизнес-процессы в рамках «расширенных организаций», которые включают поставщиков, партнёров, потребителей продуктов и услуг и т. д.

- Технологии управления бизнес-процессами (BusinessProcessManagement, BPM), являющиеся результатом естественной эволюции классических систем документооборота и делопроизводства (workflowsystems) и систем класса EAI и B2Bi. Традиционные системы управления документами ориентировались в основном на пересылку информации между людьми, выполнявшими определённые действия. В отличие от технологий B2Bi, которые ориентированы на интеграцию данных в межорганизационной среде, технологии BPM интегрируют данные, приложения и людей через единые бизнес-процессы. Это отражает современную точку зрения, что основой интеграции должны быть бизнес-процессы. Причина здесь состоит в том, что бизнес-процессы организации «пересекают» границы различных приложений, департаментов и организаций.

Таблица .Следующая таблица показывает разницу между упомянутыми классами систем

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

Технологическим фундаментом брокера сообщений является, как правило, программное обеспечение промежуточного слоя пересылки сообщений (Messaging-OrientedMiddleware, MOM), которое обеспечивает транспорт доставки информации и данных между прикладными системами. Примером такого программного обеспечения является «сервер очередей сообщений» MSMQ (MicrosoftMessageQueuing). Продукты этого класса обеспечивают транспорт гарантированной доставки сообщений между приложениями в территориально распределённой среде. Подход к интеграции приложений на основе продуктов класса MOM стал стандартным в области интеграции корпоративных информационных систем в конце 90-х годов.

Базовая идея этой технологии заключается в следующем. Пусть имеется несколько приложений, связанных некоторой коммуникационной средой, но, возможно, не очень надёжной. Одно приложение (например, система документооборота A) должно переслать информацию/документ другому приложению (системе документооборота B). Система A передает документ серверу пересылки сообщений и «забывает» о нем. Сервер пересылки сообщений обеспечит гарантированную и однократную доставку информации в систему B.

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

Если интегрируются приложения, находящиеся в разных организациях, то принцип «очереди сообщений» и гарантированной доставки, который реализуется MOM-продуктами, обеспечивает асинхронное взаимодействие и так называемое «слабое связывание». Приложение организации A не вправе ожидать мгновенной доступности приложения организации B, но программное обеспечение гарантированной доставки сообщений берет на себя ответственность за доставку информации между ними.

Базовые принципы интеграции с использованием XML и веб-служб

Итак, основой межорганизационной интеграции может служить интеграционное программное обеспечение и системы управления бизнес-процессами (BPM), такие как, например, MicrosoftBizTalkServer. При этом XML претендует на роль универсального формата данных при такой интеграции. А сами ИС, как вновь разрабатываемые, так и унаследованные, могут быть реализованы в виде так называемых веб-служб или могут сделать свои интерфейсы доступными в виде веб-служб.

Чтобы прояснить суть этих подходов взаимодействия и интеграции ИС, рассмотрим простые базовые понятия, связанные со стандартами XML и веб-службами. Первое и главное, что следует отметить, -- это то, что все описываемые ниже стандарты являются открытыми, а в их разработке принимают участие такие ведущие ИТ-компании, как Microsoft и IBM, а также органы стандартизации Интернет-сообщества в лице консорциума WorldWide Web Consortium (W3C) и организации UDDI.org.

Второе. Данные технологии не зависят от платформы и не требуют от организаций, чьи приложения интегрируются, использовать такие общие платформенные продукты, как операционные системы и СУБД.

По своей сути XML -- это мета-язык для представления данных. Термин «мета» используется потому, что XML-документ не только содержит в себе данные, но также несёт информацию, описывающую эти данные. XML является такой же универсальной и базовой технологией для представления, трансформации и обмена данными, как транспортный протокол Transmission Control Protocol/Internet Protocol (TCP/IP) для Интернета.

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

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

При этом XML-данные имеют текстовый формат и могут анализироваться сетевыми экранами и проходить за границы организаций.

Таким образом, XML предлагает единое решение как для интеграции корпоративных приложений (EAI или A2A), так и для межорганизационной B2Bi-интеграции.

Одна из тенденций состоит в том, что наиболее передовые продукты интеграции класса систем управления бизнес-процессами (BPM), такие как MicrosoftBizTalkServer, не только используют XML как формат обмена данными, но также используют синтаксис языка XML для описания бизнес-логики и контроля маршрутов и потоков прохождения сообщений и документов. В частности, Microsoft, IBM и ряд других поставщиков разработали язык BusinessProcessExecution Language for Web Services (BPEL4WS) в качестве стандартного XML-языка описания бизнес-процессов. Это обеспечивает то, что новые приложения будет ещё легче интегрировать в общие бизнес-процессы, а сама логика бизнес-процессов может быть легко доступна для модификации. Это также даёт возможность создания репозитария стандартных государственных бизнес-процессов, что лежит в основе электронных административных регламентов.

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

В этом плане системы управления бизнес-процессами (BPM) и технология веб-служб прекрасно дополняют друг друга. Интегрируемые прикладные системы и их модули могут быть реализованы в качестве чёткоопределённых служб. Системы BPM обеспечивают выполнение потоков работ как цепочек взаимосвязанных служб, «склеивая» вместе службы в единые бизнес-процессы.

Ниже приводится информация о ключевых стандартах веб-служб: XML, SOAP, WSDL и UDDI. Но вначале рассмотрим вкратце процесс взаимодействия приложений в децентрализованной, распределённой среде. Приложение, которому требуется доступ к другому приложению как к веб-службе, использует регистр (каталог) UDDI для обнаружения нужной ему веб-службы (информация в регистре UDDI предварительно должна быть опубликована организацией, желающей сделать свою веб-службу публично доступной). В этом же регистре приложение определяет необходимые для взаимодействия интерфейсы. Интерфейсы публикуются с использованием стандарта WSDL. После этого с помощью интерфейса WSDL приложение вызывает веб-службу и применяет SOAP и XML как конверты и форматы для передачи информации, а протоколы HTTP и SMTP -- в качестве транспорта для ее доставки.

Таким образом, технология веб-служб предоставляет общий формат данных (XML), способ доставки и транспортировки данных по Интернету и интранет-сети (SOAP), а также способ обнаружения (UDDI) и описания (WSDL) служб.

Основные стандарты XML и веб-служб

Интеграция информационных систем на основе веб-служб связана с использованием четырёх ключевых стандартов:

Extensible Markup Language (XML) -- расширяемый язык разметки информации. Описывает информацию, пересылаемую по Интернету. Запрос на получение каких-либо данных или выполнение определённых действий другим приложением требует наличия способов передачи параметров и получения обратно определённых результатов. При использовании веб-служб эта информация описывается с помощью языка XML, являющегося международным общепринятым стандартом для описания произвольных данных, которыми в свою очередь могут обмениваться информационные системы.

SimpleObjectAccess Protocol (SOAP) -- простой протокол доступа к объекту. Этот стандарт описывает протокол вызова веб-службы (удалённый процесс доступа к услугам/информации некоторой прикладной системы). То есть передаваемые параметры описываются с помощью языка WSDL, а сам процесс вызова описывается с помощью SOAP. Другими словами, этот протокол как бы описывает конверт с информацией для вызова веб-службы. И этот конверт может быть доставлен от одного приложения к другому с помощью таких транспортных протоколов как HTTP или протоколов электронной почты наподобие SimpleMailTransfer Protocol (SMTP). В типичной ситуации взаимодействия система одной организации может вызвать систему другой организации, используя протокол SOAP. Запрос, который обычно содержит ту или иную форму бизнес-документа, посылается инициатором к запрашиваемой системе. Последняя принимает запрос, и входящий документ, содержащийся в запросе, обрабатывается. В результате запрошенная система генерирует ответ, который возвращается инициатору взаимодействия. Инициатор также информируется о статусе (успех или иное) запроса. Протокол SOAP основан на стандарте XML и состоит из трёх частей: формат конверта, который описывает содержимое сообщения и то, как оно должно обрабатываться; набор правил кодирования для определения типов данных конкретного приложения и соглашения по выполнению удалённых вызовов процедур.

Web Services Description Language (WSDL) -- языкописаниявеб-служб.Это основанный на стандарте XML язык, который определяет способ доступа к веб-службам. Он описывает функциональные возможности веб-служб и группирует операции взаимодействия в определённые интерфейсы, задающие способы выполнения операций и те параметры, которые должны быть на входе и выходе.

Universal Description, Discovery, and Integration (UDDI) -- универсальный метод описания, обнаружения и интеграции. Технология UDDI предоставляет средства, с помощью которых можно сделать так, чтобы любые приложения или услуги, описанные в терминах веб-служб, могут быть распознаны другими приложениями и/или организациями. Т.е. это стандарт создания регистра, используя который, можно описать организации и предоставляемые ими услуги в виде, доступном для динамического обнаружения и взаимодействия. Основные объекты информационной модели UDDI -- это организации (businessEntity), услуги (businessService) и связующий шаблон (bindingTemplate), соответствующие, по аналогии с обычным телефонными справочниками, так называемым белым страницам (адресная и контактная информация), жёлтым страницам (предоставляемые услуги) и зелёным страницам. В традиционных телефонных справочниках наличие зелёных страниц, описывающих способы получения услуги, не являлось необходимым, поскольку предполагается, что телефонная связь является единственным способом доступа. Спецификацией UDDI предусматривается произвольное множество методов обращения к каждой веб-услуге, для описания которых и служит связующий шаблон.

Механизмы обмена данными в среде 1С: Предприятие

В рамках данном курсовом проекте будет решаться задача интеграции данных в двух различных ИС на платформе 1С: Предприятие 8 внутри отдельной организации, т.е. на основе технологий класса EAI.

Механизм XDTO (XML Data Transfer Objects)

Механизм XDTO представляет собой гибкое средство моделирования данных, которое широко используется в технологии web-сервисов 1С: Предприятия. XDTO является механизмом объектного моделирования данных, описываемых с помощью схемы XML.

Центральным понятием механизма XDTO является понятие объекта переноса данных. Объект переноса данных можно представить как одиночный объект или замкнутый граф объектов, который может быть перенесён с одного компьютера на другой. Объект переноса данных характеризуется двумя основными свойствами: возможностью сериализации/десериализации в формат передачи данных (как правило, в XML) и свойством замкнутости.

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

Свойство замкнутости позволяет объекту переноса данных обеспечить необходимый уровень целостности, т.к. если бы какая-либо его часть ссылалась на другие объекты, то после переноса и десериализации эта ссылка стала бы недействительной, из чего следовало бы, что и сам объект переноса данных был бы непригоден для дальнейшего использования. Свойство замкнутости не запрещает иметь ссылки внутри объекта переноса данных, т.к. объект сериализуется/десериализуется как единой целое и механизм сериализации обеспечивает правильное преобразование ссылок внутри объекта переноса данных.

Механизм XDTO позволяет определять объекты переноса данных, которые могут образовывать строгую иерархию и могут сериализоваться в XML. Эти свойства позволили использовать объекты XDTO в качестве параметров и возвращаемых значений операций web-сервисов.

Специализированная конфигурация «1С: Конвертация данных 2.0»

Выпуск восьмой версии платформы «1С: Предприятие» стал значительным шагом в развитии систем автоматизации. При проектировании платформы «1С: Предприятие 8» учтён огромный опыт использования решений на платформе «1С: Предприятие 7.7»: были серьёзно переработаны встроенный язык платформы и типовые конфигурации, изменена структура хранения и доступа к данным, созданы новые отраслевые решения, реализующие преимущества новой платформы. Применение прежних конструкций языка в новой платформе стало нецелесообразным.

Для облегчения решения данной задачи (перенос данных из версии 7.7 в версию 8) фирмой «1С» выпущена специализированная конфигурация «Конвертация данных 2.0». Она создана для помощи специалистам в решении различных задач переноса данных. Фирмой «1С» выпущены готовые правила переноса данных из однотипных конфигураций, например из «1С: Бухгалтерии 7.7» в «1С: Бухгалтерию 8», но пользователям нетиповых или изменённых типовых конфигураций при переходе на платформу «1С: Предприятие 8» придётся создавать правила переноса данных самостоятельно.

При всем многообразии частных методов решения задач переноса данных круг решаемых вопросов практически остаётся неизменным:

Синхронизация справочной информации (создание новых, обновление существующих элементов справочников, удаление, сохранение или изменение иерархии, ветвление данных, перенос истории изменения значений периодических реквизитов);

Синхронизация документов и операций (создание, изменение документов или преобразование одних видов документов в другие, слияние или размножение);

Создание достаточных начальных условий по учётным регистрам для ведения хозяйственной деятельности (перенос остатков товаров и пр.).

Структуры хранения данных в «1С:Предприятии» разных версий и/или конфигураций различаются, поэтому перенос данных -- это не простое копирование файлов или таблиц, а их преобразование. Чтобы преобразование было однозначным и корректным, для переноса данных необходимо создать и настроить правила. Создание и настройка правил переноса данных между различными информационными базами возможны, если известна структура хранения данных в базе-источнике и базе-получателе. Описание структуры метаданных конфигураций должно быть унифицировано. Конфигурация «Конвертация данных 2.0» служит для создания и настройки правил переноса данных на основе описаний структуры метаданных конфигурации источника и получателя.

Процесс переноса данных между информационными базами, состоит из следующих этапов:

1. Создание файлов описания метаданных.

2. Создание Конфигураций в «Конвертации данных».

3. Создание самой конвертации.

4. Последовательное создание правил конвертации данных.

5. Последовательное создание правил выгрузки данных.

6. Собственно процедура выгрузки и загрузки данных из одной конфигурации в другую.

Т.к. использование данной специализированной конфигурации является одним из наиболее эффективных на данный момент способов решения задач такого рода, а кроме того и источника очень полезного в образовательных целях личного опыта, то для разработки механизма обмена данными между ИС «Сервер: Расчёт Квартплаты» и «1С: Бухгалтерия предприятия» для ООО «ООО» был выбран метод, основанный на использовании конфигурации «Конвертация данных 2.0».

Технико-экономическое обоснование (ТЭО)

Характеристика объекта автоматизации

Общая характеристика.

Проект автоматизации создаётся позаказу директораРЭУ «Идеал Хаус» Олейника Станислава Михайловичадля бухгалтерии. В непосредственном подчинении у главного бухгалтера находятся три специалиста, имеющих доступ к базам данных ИС.

Характеристика существующей системы управления.

В организации существует две ИС на платформе «1С: Предприятие 8». Первая - «Сервер: Расчёт Квартплаты» - локальная ИС, предназначенная для расчёта квартплатыикоммунальных услуг на предприятиях ЖКХ, ТСЖ и поставщиков услуг. Вторая - это распределённая ИС «1С: Бухгалтерия предприятия», подключение к которой происходит удалённо к серверу головной компании, находящейся в г. Москва.<подготовить уточнённый устный ответ на случай вопроса на защите о средствах и методах передачи данных>

Недостатки существующей системы управления.

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

Цели, критерии и ограничения

Характеристика целей внедрения программных модулей в ИС.

Разработка и внедрение в ИС модуля обмена данными для автоматизации введения данных в удалённую ИС посредством конвертации уже введённых данных в ИС локальную.

Функции и задачи внедряемых программных модулей.

Внедряемыйв ИС программный модуль включает в себя следующие функции:

· выгрузка исходных данных из ИС-источника;

· конвертация данных по сформированным правилам обмена данными из формата ИС-источника в данные в формате ИС-приёмника;

· загрузка преобразованных данных в ИС-приёмник.

Ожидаемые технико-экономические результаты внедрения системы.

Уменьшение временных затрат и повышение эффективности, сокращение рисковпотери информации или неправильного составления документации.

Предполагаемые затраты: составление правил обмена данными, программирование модулей под требования заказчика с сохранением привычного интерфейса.

Данный проект позволит бухгалтерии справляться с задачами, на решение которых ранее требовалось достаточно много времени, трата которого увеличивалась пропорционально объёмам информации. После внедрения программного решения процесс дублирования информации в различных по структуре представления данныхинформационных системах (это обусловлено их различными предназначениями) в считанные минуты, а также вносить необходимые изменения в настройки модуля обмена данными, используя регулировку параметров выгрузки.Всё это облегчит работу персонала и сэкономит рабочее время сотрудников, добавит программный контроль за корректностью, полнотой и соответствиивносимыхданных в ИС-приёмник исходным данным из ИС-источника.

Разработка концепции разрабатываемого программного решения.

Организационная диаграммапредставлена на рис. 1.

Рис. 1.

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

Т.к. разрабатываемое программное решение затрагивает далеко не всех сотрудников организации, а только бухгалтерский отдел и в некоторой степени экономиста, то они выделены в диаграмме в отдельную группу.

Суть обмена данных между различными ИС при данном подходе состоит в том, что сначала необходимо выгрузить в XML-файлах структуры метаданных обеих конфигураций (источника и приёмника), затем при помощи конфигурации «1С: Конвертация данных 2.0» создать правила обмена, после чего другая внешняя обработка на основе правил обмена преобразует конкретные выгруженные данные в формат, соответствующий структуре метаданных ИС-приёмника, и далее последний шаг - загрузка уже преобразованных данных в конечную ИС.

Схема взаимодействия между конфигурациями представлена на рис. 2.

Рис. 2.

Основная задача курсового проекта сконвертировать данные из журнала документов «Оплата» в ИС «Сервер: Расчёт квартплаты» и создать в ИС «1С: Бухгалтерия предприятия» документы «Приходной кассовый ордер» для оплаченных через кассу счетов и документы «Платёжное поручение входящее» для счетов, оплаченных через банк.

У каждого из документов есть порядка 20-30 реквизитов и табличных частей, поэтому на рисунке отображены только наиболее важные из них. При переносе этих значений надо быть очень осторожным, т.к. они часто берутся из различных справочников, а, следовательно, в ИС-приёмнике (ввиду другой структуры) эти значения, а очень часто и сами справочники, могут иметь другие обозначения или даже отсутствовать.

Всё вышенаписанное приводит к необходимости также конвертировать связанные таким образом с документами справочники.

На рис. 3. изображена принципиальная логика обмена между документами.

Рис. 3.

Техническое задание (ТЗ). Общие сведения о проекте

Назначения и цели внедрения программных модулей в ИС

Назначение внедрения:

Программные модули обмена данными разработаны для автоматизации работы и решения задач и проблем РЭУ.

Цели внедрения:

- использовать рабочее время более рационально;

- обеспечить быстрые пути ввода и получения данных;

- повышение эффективности деятельности организации в целом;

- введение программного контроля за корректным вводом данных.

Характеристики объекта автоматизации

Объект автоматизации: деятельность бухгалтерского отдела ООО «ООО».

РЭУ (ремонтно-эксплуатационное управление) оказывает полный спектр услуг по эксплуатации инженерных систем зданий и профессиональной уборке зданий, офисов, коттеджей, квартир.

Перечень подлежащих разработке документов:

- технико-экономическое обоснование;

- технический проект;

- программа и методики испытаний;

- текст модулей программы, подлежащих доработке под требования заказчика;

- описание правил конвертации данных.

Источники разработки

Документы и информационные материалы, на основании которых разрабатывается ТЗ и система:

- ГОСТ 34.601-90-Стадии создания АС;

- ГОСТ 34.602-89- ТЗ на создание АС;

- ГОСТ 34.603-92- виды испытаний АС;

- РД 50-34.698-90- требования к содержанию документа;

- ISO/IEC12207:1995-08-01.

Календарный план

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

Задачи, в свою очередь тоже необходимо правильно структурировать, т.е. выделить среди всех задач основные и разбить их на более мелкие. В данном случае в проекте будут следующие основные работы: «Предпроектные исследования», «Разработка проекта внедрения», «Ввод в действие», «Сопровождение».

Предпроектные исследования делятся на 3 этапа. Все три проходят в одно и то же время, т.е. непосредственно в день встречи с заказчиком выясняется род его деятельности, установленное у него ПО и т.д. В это же время начинается формирование ТЗ.

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

Ввод в действие необходимо начинать с организационной подготовки, после чего можно обучить персонал и провести пуско-наладочные работы, провести тестирование и отладку ПО.

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

Календарный план разрабатывался в MicrosofProject 2010, диаграмма Ганта с отслеживанием приведена на рис. 4.

Рис. 4.

Технический проект. Общие положения