Размещено на http://www.allbest.ru/

Оглавление

• Введение
• Глава 1. Особенности MS SQL варианта 1С Предприятие 8.2
• 1.1 Варианты работы
• 1.1.1 Файловый вариант работы
• 1.1.2 Клиент-серверный вариант работы (КСВР)
• 1.1.2.1 Архитектура клиент - сервера
• 1.1.2.2 Задачи кластера серверов
• 1.1.2.3 Отличительные особенности КСВР версии 8.1 и 8.2
• 1.1.2.4 Логика работы сервера 1С
• 1.1.2.5 Варианты расположения компонентов КСВР 8.2
• 1.1.2.6 Администрирование КСВР 8.2
• Глава 2. Механизмы обмена данными
• 2.1 Универсальный механизм обмена данными
• 2.1.1 Средства чтения и записи документов xml
• 2.1.2 XML-сериализация
• 2.1.3 Планы обмена
• 2.1.3.1 Узлы планов обмена
• 2.1.3.2 Инфраструктура сообщений
• 2.1.3.3 Служба регистрации изменений
• 2.2 Распределенные информационные базы
• 2.2.1 Планы обмена
• 2.2.1.1 Главный и подчиненные узлы
• 2.2.1.2 Решение коллизий
• 2.2.1.3 Начальный образ узла распределенной ИБ
• 2.2.1.4 Сообщение обмена данными в распределенной ИБ
• Глава 3. Реализация проекта выгрузи
• 3.1 Постановка задачи обмена данными
• 3.2 Реализация
• Глава 4. Безопасность жизнедеятельности
• 4.1 Организационные основы безопасности труда
• 4.1.1 Обучение, инструктаж и проверка знаний по охране труда
• 4.1.2 Аттестация рабочих мест
• 4.1.3 Расследование и учет несчастных случаев на производстве
• 4.1.4 Ответственность за нарушение требований по безопасности труда
• Глава 5. Экономическое обоснование
• 5.1 Сметная калькуляция на разработку проекта
• 5.2 Затраты на материалы, отладку программы и прочие расходы
• 5.3 Расчет стоимости программного обеспечения (ПО)
• 5.4 Расчет стоимости оборудования
• 5.5 Прочие затраты, накладные расходы
• 5.6 Годовые эксплуатационные расходы
• 5.7 Приведенные затраты
• 5.8 Годовой экономический эффект
• Заключение
• Список использованных источников

Введение

Зачастую при работе с 1С Предприятие перед нами встает вопрос: "Как сделать выгрузку или перенос данных?" При возникновении необходимости осуществлять обмен данными между различными конфигурациями 1С следует учесть сопутствующие факторы: версии конфигураций, тип данных (например, серверный - SQL, файловый - DBF...), вид данных, которые необходимо получить в базе-преемнике (документы, проводки, справочники, операции, остатки…), наличие стандартных средств, выгрузок позволяющих провести обмен по определенным правилам, автоматические выгрузки (например, в клиент-банк) между определенными конфигурациями и другими программными объектами. Многие продукты 1С Предприятие имеют множество встроенных средств для переноса данных.

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

Следует отметить, что такой обмен (в случае невозможности провести его стандартными средствами) будет заведомо являться одной из самых трудоемких задач, касающихся обработок 1С: ведь здесь придется учесть специфические особенности каждой из конфигураций, а также, возможно, создавать промежуточный объект хранения данных 1С, которые, будучи выгружены из конфигурации, должны храниться по крайней мере до момента загрузки в другую конфигурацию

Целью данного дипломного проекта является автоматизация процесса выгрузки из 1с предприятие 8.2 редакции 1.6 бухгалтерия на платформе MS SQL SERVER 2005.

Для решения поставленной задачи в дипломном проекте необходимо:

Исследовать среду разработки решаемой задачи.

Определить методы решения поставленной задачи.

Обосновать экономическую эффективность проекта.

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

Во второй главе описаны механизмы

В третий главе описана постановка задачи и реализация проекта выгрузки

В четвертой главе БЖД.

В пятой главе описана экономическая часть БЖД.

Глава 1. Особенности MS SQL варианта 1с Предприятие 8.2

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

1.1 Варианты работы

1.1.1 Файловый вариант работы

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

Преимущества:

- Легкость установки и эксплуатации автоматизированной системы.

- Не требуются дополнительные программные средства, достаточно иметь операционную систему и 1С:Предприятие.

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

Недостатки:

- Размер базы ограничен (4Гб для версии 7.7, для версии 8 - файл 1Cv8.1CD имеет специальный формат, в котором данные каждой таблицы хранятся в трех внутренних файлах, и по технологическим причинам размер каждого из них не может превышать 4 Гб).

- Не обеспечивается сохранность данных при сбоях.

- Использование табличных блокировок базы данных: возникновении конфликтов блокировок при одновременной интенсивной работе большого количества пользователей.

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

1.1.2 Клиент-серверный вариант работы (КСВР)

Предназначен для использования в рабочих группах или в масштабе предприятия. Он реализован на основе трехуровневой архитектуры, которая подразумевает наличие клиентского приложения, сервера «1С:Предприятия 8.2» и сервера баз данных (в данном случае MS SQL Server).

Преимущества:

- Для пользователя - дополнительное обучение не требуется. Для программиста - дополнительно обучение не обязательно.

- Единственный возможный способ для работы очень большого числа пользователей или для работы с очень большой базой данных (более 4-х Гб).

- Пользователей не предоставляется прямой доступ к БД, что позволяет оградить ее от несанкционированного копирования и изменения (подмены) существующих данных.

- "Горячее" резервное копирование - то есть в любой момент рабочего дня без отключения пользователей.

- Быстрое выполнение отчетов, если эти отчеты написаны с учетом того, что данные находятся на SQL-сервере.

- Снижение нагрузки с сети и компьютера пользователя (клиентского приложения), т.к. все операции по обработке данных производятся на кластере серверов 1С:Предприятия 8.2.

- Масштабируемость: при возникновении потребностей в увеличении производительных ресурсов достаточно просто увеличить мощность (ресурсы, объемы) кластера серверов, а не обновлять весь парк ПК пользователей.

- Механизм запросов 1С:Предприятия 8.2 оптимизирован под MS SQL Server для выполнения расчетов и составления отчетов. Например, просмотр больших динамических списков выполняется с минимальным количеством обращений к СУБД, и при этом пользователь может осуществлять эффективный поиск, а также настройку отбора и сортировки данных.

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

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

- При умеренной нагрузке и небольших объемах вычислений, выполняемых на сервере «1С:Предприятия», его возможно размещать на одном компьютере с MS SQL Server. Такой вариант является более дешевым, но менее производительным.

Недостатки:

- Платформа 8.2 не предоставляет возможности использовать несколько серверов 1С:Предприятия для одновременной работы с одной и той же информационной базой. Таким образом, количество эффективно обслуживаемых клиентских соединений с одной ИБ напрямую зависит как от технологических особенностей сервера 1С:Предприятия 8.2, так и от производительности компьютера, на котором он функционирует.

- Стоимость внедрения значительно дороже.

1.1.2.1 Архитектура клиент - сервера

Рисунок 1.1.2.1.1 Архитектура клиента - сервера

Клиентская часть

Программа, работающая у пользователя, (клиентское приложение) взаимодействует с кластером серверов 1С:Предприятия 8.2, а кластер, при необходимости, обращается к серверу баз данных (MS SQL Server или PostgreSQL). Работа с клиентским приложением возможна через веб-сервер или напрямую с кластером. При подключении к кластеру толстый клиент и тонкий клиент непосредственно используют для передачи данных протокол TCP/IP. Если подключение осуществляется через веб-сервер тонкий клиент и веб-клиент используют протокол HTTP или HTTPS.

Кластер серверов 8.2

Основным компонентом системы 1С:Предприятия 8.2, с помощью которого взаимодействуют пользователи с системой баз данных при работе с клиент сервером, является кластер серверов.

Под понятием "кластер серверов" понимается несколько компьютеров (серверов) выполняющих общую задачу.

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

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

Еще одна ключевая особенность кластера серверов состоит в том, что взаимодействие процессов кластера серверов между собой, а также с клиентскими приложениями и серверами баз данных осуществляется не с использованием механики COM+, а на основе протокола TCP/IP. Благодаря этому, в частности, кластер серверов может объединять в себе компьютеры, работающие под управлением разных операционных систем, как Windows, так и Linux.

1.1.2.2 Задачи кластера серверов 1С:Предприятие 8.2

Рисунок 1.1.2.2.1 - Задачи кластера серверов

1.1.2.3 Отличительные особенности КСВР версии 8.1 и 8.2 представлены на (рис 3)

Рисунок 1.1.2.3.1 Разница между КСВР 8.1 и 8.2

Сервер баз данных

В качестве сервера баз данных используются:

- База Microsoft SQL Server

- База PostgreSQL

- База IBM DB2

- База Oracle Database

1.1.2.4 Логика работы сервера 1с

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

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

Командный интерфейс формируется аналогично на сервере, и все отчеты выводятся на клиенте

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

На сервере выполняются следующее:

- Запросы к базам данных

- Запись всех данных

- Проводка документов

- Разные расчеты

- Проведение обработок

- Формирование готовых отчетов

- Подготовка форм к показу.

На клиенте выполняется следующее:

- Передача и открытие форм

- Показ форм

- Получение пользователем сообщений, предупреждений, т.е. информирование

- Проведение быстрых расчетов по простым формулам (цена Х количество)

- Операции с локальными файлами

- Операции с торговым оборудованием.

- Использование встроенного языка версии 8.2 на клиенте

Управлять всеми функциями форм возможно как на сервере, так и на клиенте. Клиент поддерживает работу встроенного языка программирования.

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

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

Отдельно следует остановиться на том, что средства встроенного языка «1С:Предприятия» при работе в КСВР позволяют организовать выполнение различных процедур и функций прикладного решения либо на клиенте, либо на сервере «1С:Предприятия». Для этого используются специальные свойства модулей и операторы препроцессора #Если Сервер Тогда и #Если Клиент Тогда

Кратко остановимся на некоторых деталях реализации клиент-серверного варианта работы. Как уже говорилось, сервер «1С:Предприятия 8.2» представляет собой рабочий процесс, который выполняется на некотором компьютере. Этот процесс может обслуживать сразу несколько соединений с клиентскими приложениями и несколько соединений с серверами баз данных. Таким образом, сервер «1С:Предприятия» позволяет различным пользователям одновременно работать с разными ИБ. При этом в локальной сети могут существовать несколько компьютеров, на которых функционирует сервер «1С:Предприятия». В этом случае каждый из них будет обслуживать собственный набор ИБ. Это позволяет распределять нагрузку между различными компьютерами при работе с разными информационными базами.

Однако платформа 8.2 не предоставляет возможности использовать несколько серверов «1С:Предприятия» для одновременной работы с одной и той же информационной базой. Таким образом, количество эффективно обслуживаемых клиентских соединений с одной ИБ напрямую зависит как от технологических особенностей сервера «1С:Предприятия», так и от производительности компьютера, на котором он функционирует. Например, серверу «1С:Предприятия» доступно не более 2 или 3 Гбайт виртуального адресного пространства, причем это адресное пространство делится между всеми пользователями, которых он обслуживает. Понятно, что при достаточно большом количестве пользователей может снижаться эффективность работы сервера из-за нехватки памяти.

1.1.2.5 Варианты расположения компонентов КСВР 8.2

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

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

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

При умеренной нагрузке и небольших объемах вычислений, выполняемых на сервере «1С:Предприятия», его возможно размещать на одном компьютере с MS SQL Server. Такой вариант является более дешевым, но менее производительным. Работа обоих серверов на одном компьютере предъявляет, в частности, повышенные требования к объему оперативной памяти, которая активно используется как одним, так и другим приложением.

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

1.1.2.6 Администрирование КСВР 8.2

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

Утилита администрирования клиент-серверного варианта предназначена для решения следующих задач: мониторинг серверов 1С: Предприятия; просмотр списка информационных баз; создание и удаление информационных баз; мониторинг соединений пользователей с информационными базами; отключение пользователей от информационной базы. Утилита представляет собой подключаемый модуль MMC (Microsoft Management Console), и может быть использована на компьютерах, на которых установлено соответствующее программное обеспечение (для операционных систем Windows 2000/XP/Server 2003 это программное обеспечение является стандартным).

Все функции администрирования сервера 1С: Предприятия также доступны средствами встроенного языка.

Глава 2. Механизмы обмена данными

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

Рисунок 2.0.1 Общая структура обмена данными

2.1 Универсальный механизм обмена данными

Преимущества:

- Как следует из названия, этот механизм более универсальный по сравнению с РИБ, и при обмене данными между информационными базами 1С:Предприятия 8.2 не накладывается ограничений на идентичность конфигурации и структуры конкретных объектов.

- Кроме этого, обмен данными может быть реализован не только с информационными базами 1С:Предприятия, но и с другими информационными системами.

Недостатки:

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

- Любой обмен данных является критической точкой возникновения различных коллизий и сбоев в работе. В отличие от РИБ данный вариант не содержит готовых решений на случай некорректной работы (например, по техническим причинам, ошибок программирования или «человеческого фактора»). Т.е. возникновение различных нештатных ситуаций неизбежно и для быстрого восстановления работоспособности системы требуется наличие в штате специалиста обеспечивающего поддержку и сопровождение системы.

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

Кроме того, универсальные механизмы обмена данными могут использоваться для организации обмена с программами, не основанными на системе 1С:Предприятие 8.2.

Этому способствуют следующие факторы:

- формат обмена данными основан на языке XML, являющемся на сегодняшний день общепринятым средством представления данных.

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

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

Рисунок 2.1.0.1 Составные части универсального обмена данными

К универсальным механизмам обмена данными могут быть отнесены:

- средства чтения и записи документов XML;

- XML-сериатизация;

- планы обмена.



Рисунок 2.1.0.2 Схема универсального обмена данными

Рисунок 2.1.0.3 схема взаимодействия составляющих обмена

2.1.1 Средства чтения и записи документов XML

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

Средства чтения и записи документов XML обеспечивают работу с документами XML в самом общем виде. Данный набор средств не определяет способов представления данных системы 1С:Предприятие 8 в формате XML.

К средствам чтения и записи документов XML, предоставляемым системой 1 С:Предприятие 8.2, относятся объекты: ЧтениеХМL, ЗаписьХМL и ПреобразовалиeXSL. Также платформа предоставляет возможность работать с XML-данными в формате Fastlnfoset, для чего существуют объекты ЧтениеFast Infoset и 3anucьFastInfoset.

2.1.2 XML-сериализация

Основная задача XML-сернализации -- поддержка чтения записи объектов данных системы 1С:Предприятие 8.2 в из XML.

Базовые средства чтения и записи документов XML не предоставляют достаточной основы для решения данной задачи. Они не определяют форматов представления данных системы 1С:Предприятие 8.2 в XML и не предоставляют средств для чтения/записи объектов данных в из XML в принятом формате как единого целого.

2.1.3 Планы обмена

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

Предполагается, что форматы данных основаны на XML, но благодаря гибкости языка XML и наличию развитых средств работы с XML в системе 1С:Предприятие 8 остается достаточно большое пространство для творчества в области способов представления данных.

В планах обмена можно выделить две значимые составляющие:

- инфраструктура сообщений,

- служба регистрации изменений.

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

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

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

Таким образом, планы обмена определяют набор механизмов, предназначенных для организации обмена данными. Рассмотрим эти механизмы подробнее.

2.1.3.1 Узлы планов обмена

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

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

Предположим, требуется организовать обмен данными между двумя информационными базами по плану обмена с именем УдаленныеСклады. Одна из этих информационных баз выполняет функции центрального офиса, а другая -- удаленного склада.

В этом случае было бы целесообразно в качестве значения кода этого узла плана обмена УдаленныеСклады в первой информационной базе задать значение Офис (если, конечно, позволяет длина кода), а во второй -- Склад1. Таким образом, эти узлы будут поименованы. Но этого недостаточно, ведь надо еще задать узлы, с которыми будет производиться обмен данными. Для этого в первой информационной базе в плане обмена УдаленныеСклады следует создать узел с кодом Склад1, а во второй информационной базе -- узел с кодом Офис.

Таким образом, первая информационная база будет «знать», что в рамках плана обмена УдаленныеСклады ее саму «зовут» Офис и она будет вести обмен с узлом по имени Склад1; а вторая -- что ее «зовут» Склад1, а обмениваться данными она будет с узлом Офис.

2.1.3.2 Инфраструктура сообщений

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

Все сообщение находится внутри элемента XML с именем Message, относящимся к пространству имен http://v8.2c.ru/messages. Сообщение делится на заголовок и тело сообщения. Соответственно, элемент Message содержит два вложенных элемента с именами Header и Body. Оба относятся к пространству имен http://v8.2c.ru/me4sages.

Элемент Header содержит заголовок сообщения. Структура заголовка жестко задана. Информация заголовка представлена в нескольких элементах XML, вложенных в элемент Header. Все элементы, вложенные в элемент Header, относятся к пространству имен http://v8.2c.ru/messages:

- ExchangePlan содержит имя плана обмена, к которому относится сообщение.

- То содержит код узла-отправителя.

- From содержит код узла, для которого предназначено сообщение.

- MessageNo содержит номер данного сообщения. Помер сообщения является положительным целым числом и присваивается узлом-отправителем. Номер каждого последующего сообщения равен номеру предыдущего отправленного сообщения плюс 1.

- Received/No содержит максимальный номер сообщения, которое узел-отправитель данного сообщения принял от узла-получателя данного сообщения. Данное значение включено в состав заголовка сообщения для подтверждения приема сообщений.

Тело сообщения содержится в элементе XML с именем Body, относящимся к пространству имен http://v8.2c.ru/messages.

Данный элемент может иметь произвольное содержимое, определяемое прикладными потребностями. Инфраструктурой сообщений содержимое тела сообщения никак не регламентируется.

2.1.3.3 Служба регистрации изменений

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

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

Непосредственно после выполнения регистрации изменения номер сообщения имеет значение NULL. При первой отправке изменения в данное поле помещается номер сообщения, в котором изменение отправлено.

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

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

2.2 Распределенные информационные базы

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

Но при этом данный вариант также имеет ряд преимуществ по сравнению с Универсальным механизмом обмена данных:

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

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

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

- Передача данных возможна между любыми точками, а не только через центральную базу данных.

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

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

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

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

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

Рисунок 2.2.0.1 Схема распределенного обмена данными

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

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

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

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

2.2.1 Планы обмена

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

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

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

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

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

- ПриОтправкеДанныхПодчиненному,

- ПриОтправкеДанныхГлавному,

- ПриПолученииДанныхОтПодчиненного,

- ПриПолученииДанныхОтГлавного.

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

2.2.1.1 Главный и подчиненные узлы

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

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

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

2.2.1.2 Решение коллизий

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

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

2.2.1.3 Начальный образ узла распределенной ИБ

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

При создании начального образа выполняются следующие действия:

- из главного узла в начальный образ без изменений переносится конфигурация;

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

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

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

2.2.1.4 Сообщение обмена данными в распределенной ИБ

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

Глава 3. Реализация проекта выгрузи

3.1 Постановка задачи обмена данными

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

Рисунок 3.1.1 Схема обмена

Трудности

1. Документы в конфигурации имеют различный набор и состав реквизитов

2. Некоторые реквизиты документов составного типа (справочники).

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

4. Возможно дублирование элементов в том случае, если справочники заполнялись в двух базах одновременно. Как вариант, при наличие дублей в справочнике (элементов справочника с одинаковым набором реквизитов), в документ попадет "ненужный" элемент - например, давно не используемый и помеченный на удаление.

Методы решения

Этап 1. Регистрация измененных объектов

В платформе 1С:Предприятие 8.2 существует объект метаданных, специально предназначенный для организации обмена - План обмена. Планы обмена содержат информацию об узлах, которые могут участвовать в обмене данными, определяют состав данных, которыми будет производиться обмен, и указывают, следует ли задействовать механизм распределенной информационной базы при обмене. В одном прикладном решении может существовать несколько планов обмена. каждый из которых может описывать свой порядок обмена данными. Например, если выполняется обмен данными с удаленными складами и удаленными офисами, то, скорее всего, будет существовать два плана обмена (один для обмена со кладами, другой - для офисов), поскольку состав данных, которыми производится обмен со складами, будет значительно "уже", чем состав данных, предназначенных для обмена с офисами.

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

Этап 2.Транспорт

Топологии обменов данными очень причудливы. Возможен как прямой доступ к базе-Приемнику из Источника, так и опосредованный. В первом случае возможно использовать ADO-соединение - прямое подключение из Источника к Приемнику. Вариант очень удобный с пользовательской точки зрения: один раз настроив параметры обмена и авторизацию пользователя в Приемнике, одним нажатием кнопки (или по расписанию) провести обмен.

Когда прямой доступ к Приемнику невозможен, данные выгружаются в промежуточный файл XML, передаются на сторону приемника и загружается. Также, возможно, использование общего ftp-pecypca.

Перед тем как настроить обмен - избавьтесь от дублирующихся элементов в справочниках. Удалите объекты, помеченные на удаление.

Заключение

В итоге, создание схемы обмена выглядит следующий образом:

1. Создается и инициализируется план обмена

2. Информационные базы подготавливаются к обмену. Удаление дублей

3. При инициализации обмена, заполняется регистр сведений "Соответствие объектов обмена"

4. Выбирается соответствующий транспорт (прямой доступ, через файл)

5. Выполняется регулярный обмен данными

3.2 Реализация

Рисунок 3.2.1 Схема обмена реализации

Перед созданием плана обмена решим проблему дублирующихся элементов в справочниках и документов для этого в режиме конфигуратор создаем константу «ПрефиксНумерации».

Затем вносим изменения в модули объектов участвующих в обмене в нашем случае это документы и справочники. Эти изменения будут заключаться в том, что теперь при формировании номера документа и кода справочника будет использоваться значение константы «ПрефиксНумерации» для обеспечения уникальности номеров и кодов в каждой из наших баз.

Функцию формирования префикса номера мы вынесем в общий модуль. Добавим общий модуль Обмен. В модуле объекта поместим функцию Функция «ПолучитьПрефиксНомера»(Листинг1). Функция возвращает значение константы и является глобальной.

Теперь доработаем модули объектов обмена, создаем процедуру «ПриУстановкеНовогоКода» (Листинг2). Событие ПриУстановкеНовогоКода возникает в момент, когда выполняется установка нового кода элемента справочника. Вторым параметром вызова обработчика передается префикс, который будет заполнен в данной процедуре и использован системой для генерации кода. В обработчике события мы вызываем функцию общего модуля. Поскольку модуль не глобальный, то обращаемся к ней по имени модуля и имени функции (Обмен.ПолучитьПрефиксНомера). В этой процедуре мы устанавливаем префикс равным значению константы ПрефиксНумерации. Такие обработчики добавляем во все справочники участвующие в обмене.

Теперь перейдем непосредственно к созданию обмена.

В режиме конфигуратор раскроем ветвь общие дерева объектов конфигурации и добавим новый объект конфигурации ПланОбмена с именем Филиалы, представление объекта - Филиал. На закладке Данные создадим реквизит плана обмена Главный, имеющий тип Булево.

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

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

Определим состав объектов участвующих в обмене:

справочники:

- сотрудники,

- физические лица,

- должности организации,

- контрагенты,

- подразделения организаций,

- организации

регламентированные отчеты

Создаем форму узла объекта ПланыОбмена Филиалы и добавляем обработчик события формы «ПриСозданииНаСервере» Этот обработчик понадобится нам для того, чтобы запретить установку реквизита Главный для предопределенного узла, соответствующего данной информационной базе (листинг 3).

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

Для этого на закладке Команды создадим команду «ЗарегистрироватьИзменения»(листинг4). В этом обработчике мы вызываем процедуру «РегистрацияИзмененийНаСервере()»

Процедура «РегистрацияИзмененийНаСервере()» (листинг5). В этой процедуре мы обращаемся к механизму регистрации изменений, вызывая метод менеджера планов обмена - ЗарегистрироватьИзменения().

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

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

Чтобы обеспечить такое поведение кнопки, создадим в модуле формы списка функцию, выполняющуюся на сервере и возвращающую истину, если переданный в функцию узел является предопределенным, функция ПредопределенныйУзел() (листинг6).

Процедура «ПриАктивизацииСтроки()» (листинг7). В этой процедуре доступность кнопки ЗарегистрироватьИзменения определяется в зависимости от значения функции «ПредопределенныйУзел()», в которую передается ссылка на текущий узел (Элемент.ТекущаяСтрока).

Создание процедур обмена

Для инициализации обмена данными мы используем обработку.

Добавим новый объект конфигурации Обработка с именем ОбменДанными. На закладке Формы создадим основную форму обработки. В окне редактора форм на закладке Команды создадим команду формы ВыполнитьОбмен (листинг8).Данная кнопка вызывает процедуру «ОбменСФилиалами()» (листинг9).

Алгоритм работы этой процедуры заключается в следующем: в цикле мы перебираем узлы, которые содержатся в плане обмена Филиалы, и для всех узлов, кроме себя самого, производим сначала чтение сообщений, поступивших из других узлов обмена. Затем мы формируем для них сообщения, предназначенные для передачи и содержащие измененные данные для этого узла. Сами процедуры записи и чтения данных обмена мы разместим в модуле объекта План обмена Филиалы.

Процедура ЗаписатьСообщеинеСИзменениями (листинг10).

Сначала мы сформируем имя файла, который будет содержать данные для обмена, и сообщим пользователю о начале и окончании выгрузки данных в узел. Обмениваться сообщениями мы будем через каталог временных файлов. Имена сообщений стандартизованы и имеют вид МеssаgеКодУзлаОтправителя_КодУзлаПолучателя.xml.

...