В крупных компаниях все бизнес-процессы не помещаются в одной учетной системе. Вводить информацию в несколько учетных систем ‒ долго и трудоемко, поэтому нужно иметь возможность переносить ее из одной системы в другую.
Это не самый простой процесс. Так что же такое обмен данными, как и где он используется? Давайте разбираться.
Обмен данными ‒ это перенос данных между функциональными блоками в соответствии с набором правил, управляющих передачей данных и координацией обмена.
Какие средства обмена есть непосредственно в системе 1С?
Для начала введем некую классификацию данного процесса в системе 1С:
- Обмен данными между абсолютно идентичными конфигурациями баз данных 1С.
- Обмен данными между различными конфигурациями баз данных 1С.
- Обмен данными между программой 1С и внешней программой.
В обмене всегда присутствует источник: то место откуда мы берем данные, и приемник: то место куда их кладем. Но различных способов отправки данных между ними существует несколько. Есть 2 основных способа: напрямую и через файл.
Каналы и способы обмена данными между техническими средствами систем безопасности
Обмен через файл
При таком способе источник выгружает данные в файл, а приемник потом их забирает. Но источник может напрямую подключаться к приемнику и положить туда необходимые данные, либо приемник может зайти к источнику и забрать все что нужно.
Прямой обмен
К прямым можно отнести обмен с помощью com объекта и веб сервисов.
COM (англ. Component Object Model — модель компонентного объекта; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов объекта, каждый из которых может использоваться во многих программах одновременно.
Web-сервис – это сетевая технология, обеспечивающая межпрограммное взаимодействие (между различными приложениями) на основе веб-стандартов. Web-сервисы дают возможность обратиться с одного приложения к другому и при этом выполнять определенные функции.
Это не все возможные варианты обмена, но самые распространенные. О других будет рассказано ниже.
Метод есть, средства для обмена есть. Осталось только отправить данные. Однако, встают следующие вопросы:
- какие данные;
- начиная с какой даты;
- как передать только измененные данные?
И ответить на все эти вопросы нам помогает объект системы 1С: «План обмена».
План обмена — штатный элемент экосистемы 1С, он является частью конфигурации и не создает никаких проблем при обновлениях. При настройке плана обмена указываются объекты и поля, участвующие в обмене, то есть настраивается состав обмена. Так же, указываем с какого момента начинаем обмен. Чтобы не передавать постоянно одни и те же данные за период, реализован механизм регистрации изменений. То есть, объекты (справочники, документы, регистры сведений и т.д.), которые включены в состав обмена, при изменениях регистрируются в плане обмена и при следующем запуске обмена именно эти изменения и будут переданы приемнику.
Демонстрация обмена данными между программами по сети
В плане обмена можно выделить три главных составляющих:
- Узел обмена.
- Состав обмена.
- Механизм распределенной информационной базы.
Узел обмена — это те источники, с которыми мы ведем обмен. Состав обмена — это те данные, которыми мы обмениваемся. Что касается механизма распределенной информационной базы, рассмотрим его немного подробнее.
Информационный обмен может выполняться как между независимыми конфигурациями, так и внутри единой распределенной базы. Для выполнения задач обмена в 1С:Предприятие существует механизм распределенных информационных баз (РИБ). Он применяется в территориально распределенных организациях. В РИБ всегда есть главный узел и второстепенные.
Все базы должны быть полностью идентичны по структуре. Обновление производится только для корневого узла, затем эти обновления через обмен поступают в подчиненные узлы. В корневой узел сливается вся информация из подчиненных. В состав обмена входят все доступные для обмена объекты системы 1С.
Пожалуйста, обратите, внимание!
Между какими базами можно построить обмен? Между ВСЕМИ. Но есть НО. Должно выполняться хотя бы одно из этих условий:
- База должна быть доступна.
- База должна иметь доступ к каталогу обмена.
- База должна иметь доступ к почте.
Почему должно быть выполнено хотя бы одно из этих условий? Все просто, обмен ‒ это всегда взаимодействие двух баз между собой. Если одна из них не будет доступна, мы никак не сможем забрать или отправить данные при прямом обмене. Представим, что у вас две базы, между которыми нужно настроить обмен. Одна находится где-то в облаке, вторая у вас на сервере.
Тогда к первой есть доступ практически из любого места, при наличии интерфейса. Ведь расположение базы в облаке уже говорит о доступности этой базы из любого места при наличии ссылки на нее (как для любого сайта).
Со второй базой несколько сложнее, так как база расположена на определенном сервере, и чтобы попасть в эту базу, сначала нужно зайти на этот сервер, используя специальные программы (например rdp и т.п). Как же можно настроить обмен в данном случае? В данном случае мы можем настроить обмен именно со стороны базы, расположенной на сервере. Именно она будет стучаться к доступной базе в облаке: забирать ее данные и относить свои.
Если у нас обмен между двумя базами на разных серверах, не имеющих доступа друг к другу, то тут уже с прямым обменом сложнее. В этом случае нужно одну базу сделать доступной. Например, опубликовать ее и дать доступ извне. В таком случае она будет доступна аналогично облачной (но при этом физически все так же будет находится на вашем сервере), и доступ к ней будет по ссылке.
Знаете ли вы что?
Если же такой возможности нет, следует прибегнуть к обмену через файлы. Вот тут мы переходим ко второму условию. Каталог обмена должен быть доступен для баз, которые обмениваются. То есть, должен быть некий каталог, доступ к которому есть у сервера, на котором расположены наши базы, чтобы, создав файл с данными, одна могла перенести его в этот каталог, а вторая зайти и забрать этот файл.
Если нет возможности обеспечить такую доступность, можно осуществить обмен через почту. То есть, база-источник должна зайти на почту и отправить данные на указанную почту, база-приемник должна зайти на почту и прочесть это письмо. Этот метод требует доступа к почте с указанием параметров подключения к ней.
В результате, если не будет выполнено хотя бы одно из этих условий, настроить обмен просто невозможно.
Настройка обмена
Как же построить обмен?
-
Настроить типовой обмен. Фирма 1С поставляет свои решения уже со встроенными обменами. Состав обмена зависит от типа поставляемой конфигурации. Так, в 1С Бухгалтерии есть типовой обмен, например, с 1С УТ и 1С ЗУП.
В чем плюс такого обмена? Фирма 1С позаботилась о нас и реализовала его в стандартных конфигурациях, вам лишь нужно зайти и настроить подключение между базами. Однако, так как это преднастроенный обмен и довольно статичный, очень часто бывает, что данного функционала недостаточно. Например, нужно обмениваться какими-то типами документов, которые не включены в состав обмена. В таком случае нужно дорабатывать существующий обмен, что не всегда легко и просто.
В чем плюс данного подхода? Да, он универсален тем, что выгрузить вы можете любые данные за определенный период и даже загрузить их, если базы похожи по структуре. Но возникнет куча вопросов и проблем, если базы отличаются друг от друга. Почему?
Данные выгружаются в определенном виде в файл xml, но, предположим что в базе-источнике есть справочник Контрагенты, а в приемнике он называется, например, Клиенты. Данная обработка не поймет, что по сути это одно и то же и ее также нужно будет дорабатывать и изменять. Кроме того, данная обработка не привязана к плану обмена, поэтому не отслеживает изменения и не может выгружать только изменения, а лишь все данные за период.
С какими системами может обмениваться система 1С?
Помимо обмена между различными конфигурациями 1С, очень часто требуется организовать обмен данными с внешними программами, например обмен 1C с банком или логистической системой, интеграция с интернет-магазином или корпоративным порталом и т.д.
Некоторые интеграции уже включены в стандартные конфигурации, например обмен с клиент банком. Но на практике большинство обменов довольно индивидуальны, что требует разработку их с нуля или доработку под конкретную задачу.
1С:Предприятие позволяет осуществлять интеграцию с любыми внешними программами на основе различных протоколов передачи данных. С развитием платформы возможности интеграции расширяются.
Выводы
Да, обмен не самое приятное действие, но без него никуда. Практически каждый обмен индивидуален. Поэтому, существующие/преднастроенные правила обмена не всегда удовлетворяют бизнес-потребности. Что приводит к постоянной доработке этих правил и созданию новых.
Создание обмена ‒ довольно тонкое и трудоемкое дело, ведь машине надо дать понять: какие данные нужно забрать из источника, в каком виде и как создать эти данные у себя в приемнике, чтобы не было дублирующих записей и чтобы они были отражены в учете по всем правилам. При этом важно не упустить связи объектов между собой.
Только представьте, что необходимо объяснить системе все те действия, которые делали вы, вводя справочники, документы и т.п. Нередко ошибки обмена не сразу бывают очевидны и проявляются лишь спустя месяц: при формировании какого-то отчета можно увидеть, что что-то было загружено некорректно. Но самая большая проблема состоит в том, что ошибки обмена влекут за собой ошибки в итоговых данных. И при их обнаружении вам придется устранять не только сами ошибки обмена, но и последствия такого обмена, что является невероятно трудоемкой работой.
У нас большой опыт в этом деле, причем в нестандартных обменах, таких как обмен между 1С Бухгалтерия 8.3 и 1С 7.7. Его сложность в том, что необходимо настроить выгрузку из одной платформы и загрузку в другую платформу, и с этой задачей обмены 1С уже не справляются. Осложняется настройка такого обмена еще и тем, что конфигурация 7.7 позволяет совершать пользователям различные действия, фактически, без серьезных ограничений, а 8.3 значительно ограничивает их действия. Для того, чтобы в такой ситуации учет в 1С БУ 8.3 был сформирован правильно, приходилось не только выдумывать дополнительные правила обмена, но и изучать логику работы 1С 7.7 с документами, чтобы все перенести в 1С БУ 8.3. Кстати, вид обмена в данном случае использовался через файлы, так как платформа 7.7 довольно устаревшая и не имеет возможностей современных технологий, таких как веб сервис, например.
Есть различные варианты обменов между разными базами 1С, но на практике для решения определенных бизнес задач приходится вносить значительные изменения/настраивать правила обмена. В итоге, во многих проектах внедрения различных конфигураций 1С обмен является первоначальным этапом и от его качественной реализации в значительной степени зависит исход всего проекта. При этом, корректно рассчитать трудозатраты по созданию обмена практически невозможно. Обмен ‒ как черный ящик: никогда не знаешь какие сложности возникнут.
Именно из-за всех этих сложностей мы решили создать гибкий алгоритм обмена через настройки.
Такой алгоритм мы реализовали в Галочке. Для обмена мы используем веб сервисы. Данный способ обмена быстрее, чем обмен через файлы или com объекты. Однако, и последние способы доступны в Галочке, так как различные ситуации требуют различных способов решения. И мы смогли учесть вариативность, используя настройки при загрузке данных.
Источник: galochka.ru
1.3. Обмен данными между программами
1. Для того чтобы данные, выделенные одной программой, были доступны из другой, первая должна объявить их в директиве PUBLIC в начале программы, а вторая — в директиве EXTRN, указав их тип. В таком случае вторая программа будет работать с данными, расположенными в «чужом» логическом сегменте данных.
2. Возможна передача данных из одной программы в другую через стек.
Допустим, что подпрограмме требуются данные основной программы. Вызывающая программа может передать их через стек. При этом каждая команда PUSH записывает в стек одно слово (два байта) из памяти или регистра. Процедура может прочитать из стека записанные основной программой данные и выполнить с ними необходимые действия.
Чтобы понять процесс обмена данными через стек, надо учесть особенности адресации стека. Указатель стека регистр SP изменяет свое состояние при выполнении команд PUSH (запись) и POP (чтение). Причем, содержимое регистра SP уменьшается на 2 при выполнении команды PUSH и увеличивается на 2 при выполнении команды POP. Таким образом, регистр SP обычно указывает на вершину стека (совместно с регистром стека SS).
Для чтения из стека и записи в стек в произвольном месте сегмента следует применять регистр BP, который связан по умолчанию при адресации с регистром SS.
3. Кроме перечисленных способов обмена данными между программами возможна передача через регистры общего назначения.
2. Общие рекомендации по выполнению лабораторной работы
Процедура создания выполняемого модуля включает следующие этапы:
1. Создание исходного файла с расширением .ASM. Следует загрузить программную оболочку Far Manager и использовать встроенный редактор (Shift+F4)
2. Получение объектной программы и файла листинга с помощью макроассемблера TASM. Макроассемблер вызывается с помощью командной строки следующего формата:
TASM/ZI имяс, имят, имял ,
где имяс — имя исходного файла с расширением ASM;
имят — имя выходного файла с расширением OBJ;
имял — имя файла листинга программы с расширением LST.
Рекомендуется все файлы называть одним именем. Различаться они будут по расширению имени файла, которое назначается макроассемблером. Для этого следует указать в командной строке:
TASM/ZI имяс.
3. Получение выполняемой программы и файла карты программы.
Программы в объектном формате могут быть объединены в единый загрузочный модуль с помощью компоновщика TLINK. Компоновщик запускается в работу следующей командной строкой:
TLINK/V имят1 имят2, имяк, имя
где имят1, имят2 — имена компонуемых файлов с расширением OBJ;
имяк — имя файла исполняемой программы с расширением EXE;
имя — имя файла карты исполняемой программы с расширением MAP.
Имена имяк, имя можно не указывать в командной строке: они будут назначены по умолчанию с именем первого компонуемого файла и будут отличаться расширением . Например, если в командную строку записать
TLINK/V имят1 имят2,, то будет создан исполняемый файл с именем имят1.exe и файл карты памяти имят1.map
4. Отладка исполняемой программы.
Для отладки программы и изучения взаимодействия скомпонованных программ в одном модуле используется программа-отладчик TD. Отладчик можно загрузить в рабочую область оперативной памяти командой TD. Затем в отладчике загружается программа, подлежащая отладке.
Можно использовать также и командную строку:
Лабораторная работа содержит четыре этапа, которые выполняются в изложенной ниже последовательности. В процессе выполнения работы следует подготовить ответы на поставленные вопросы.
Источник: studfile.net
IPC: основы межпроцессного взаимодействия
Любая операционная система была бы весьма ущербна, если бы замыкала выполняющееся приложение в собственном темном мирке без окон и дверей, без какой-либо возможности сообщить другим программам какую-либо информацию. Если посмотреть внимательно, можно заметить, что далеко не все приложения являются самодостаточными. Очень многим, если не большей части, требуется информация от других приложений, либо они должны эту информацию сообщать. Именно поэтому в операционную систему встраивается множество механизмов, которые обеспечивают т.н. Interproccess Communication (IPC) — то есть межпроцессное взаимодействие.
В историческом плане сначала появилась необходимость в общении процессов, выполняющихся на одном компьютере. В дальнейшем с бурным развитием сетевых технологий все острее стала чувствоваться потребность в средствах для взаимодействия процессов, выполняющихся на разных компьютерах в сети. Особенно трудна такая задача, если это компьютеры на базе разных платформ и/или с разными операционными системами.
Рассмотрим подробнее несколько ключевых примеров, демонстрирующих важность IPC. Вам, возможно это покажется неправдоподобным, но зачатки IPC существовали еще в MS-DOS — и это несмотря на то, что MS-DOS при всем желании трудно назвать многозадачной средой. В самом деле, когда вы в командной строке вводили подобную инструкцию :
C:>DIR|MORE
происходило следующее: выполнялась команда DIR и ее вывод записывался во временный текстовый файл. После этого содержимое файла подавалось на вход команды MORE. В результате вы получали листинг каталогов, который в случае большого количества каталогов не уезжал мгновенно за экран, а мог скроллироваться с помощью клавиши Enter. Конечно же это очень примитивный IPC, но его наличие показывает, что уже тогда такой механизм был востребован и в какой-то мере реализован.
Примеры использования IPC охватывают гораздо большее количество программ и приложений, чем вы скорее всего думаете. Когда вы выходите в интернет, ваш браузер — одна программа (процесс) — взаимодействует с web-сервером — другой программой (процессом). Эти программы выполняются на разных компьютерах; браузер на вашем, сервер — где-то еще. И вас не волнует, какая ОС установлена на сервере и какая там платформа.
Или, например, вы работаете с удаленной базой данных. Ваше клиентское приложение — это один процесс, на сервере базы данных запущен другой процесс. Процесс на сервере выполняет запросы к БД, поступающие от вашего процесса.
| ПРИМЕЧАНИЕ Вообще, для сетевых форм IPC (но не обязательно только для них) очень часто используется концепция «клиент-сервер». Как вы понимаете, «клиент» — это приложение, которому требуются данные, «сервер» — приложение, предоставляющее данные. |
А если брать только взаимодействие программ, выполняющихся на одном компьютере, самым банальным примером будет следующий: текст из вашего текcтового редактора передается в электронную таблицу или программу для верстки. Да-да, наш старый знакомый буфер обмена — это тоже один из механизмов IPC!
И еще можно было бы привести очень много примеров.
Средств, обеспечивающих взаимодействие между процессами, создано достаточно много. Огромное их количество реализовано в Windows 9x, еще больше — в Windows NT/2000. Теперь нужно приличное количество времени, чтобы хотя бы познакомиться со всеми! Замечу, что нет, и наверное в принципе не может быть универсального способа обмена данными, который годился бы на все случаи жизни — все равно в некоторых случаях использование другого способа будет предпочтительнее. Но я надеюсь, что после прочтения этой статьи вы сможете достаточно уверенно ориентироваться в мире IPC и обоснованно выбирать тот или иной метод.
Тот факт, что механизмы IPC работают на уровне операционной системы, положительно сказывается на скорости и надежности программ и программных комплексов, построенных с их использованием. Эффективность приложений соответственно возрастает.
Вообще, правильнее было бы называть эти механизмы «Interthread Communication» — межпотоковое взаимодействие. Если вы помните, выполняются именно потоки, они же и обмениваются данными. Однако, смысл для отдельных механизмов взаимодействия появляется только в том случае, если эти потоки принадлежат разным процессам.
Ведь потоки, выполняющиеся в рамках одного процесса, вовсе не нуждаются в дополнительных средствах для общения между собой. Так как они разделяют одно адресное пространство, обмен данными могут обеспечить обычные переменные. Таким образом, IPC становится необходим в том случае, если поток одного процесса должен передать данные потоку другого процесса.
Теперь давайте рассмотрим основные виды IPC и случаи, в которых они используются.
Буфер обмена (clipboard)
Это одна из самых примитивных и хорошо известных форм IPC. Он появился еще в самых ранних версиях Windows. Основная его задача — обеспечивать обмен данными между программами по желанию и под контролем пользователя. Впрочем, вы наверняка сами неплохо знаете, как используется буфер обмена. 😉 Не рекомендуется использовать его для внутренних нужд приложения, и не стоит помещать туда то, что не предназначено для прямого просмотра пользователем.
Сообщение WM_COPYDATA
Стандартное сообщение для передачи участка памяти другому процессу. Работает однонаправленно, принимающий процесс должен расценивать полученные данные как read only. Посылать это сообщение необходимо только с помощью SendMessage, которая (напомню) в отличие от PostMessage ждет завершения операции. Таким образом, посылающий поток «подвисает» на время передачи данных.
Вы сами должны решить, насколько это приемлемо для вас. Это не имеет значения для небольших кусков данных, но для больших объемов данных или для real-time приложений этот способ вряд ли подходит.
Разделяемая память (shared memory)
Этот способ взаимодействия реализуется не совсем напрямую, а через технологию File Mapping — отображения файлов на оперативную память. Вкраце, этот механизм позволяет осуществлять доступ к файлу таким образом, как будто это обыкновенный массив, хранящийся в памяти (не загружая файл в память явно). «Побочным эффектом» этой технологии является возможность работать с таким отображенным файлом сразу нескольким процессам. Таким образом, можно создать объект file mapping, но не ассоциировать его с каким-то конкретным файлом. Получаемая область памяти как раз и будет общей между процессами. Работая с этой памятью, потоки обязательно должны согласовывать свои действия с помощью объектов синхронизации.
Библиотеки динамической компоновки (DLL)
Библиотеки динамической компоновки также имеют способность обеспечивать обмен данными между процессами. Когда в рамках DLL объявляется переменная, ее можно сделать разделяемой (shared). Все процессы, обращающиеся к библиотеке, для таких переменных будут использовать одно и то же место в физической памяти. (Здесь также важно не забыть о синхронизации.)
Протокол динамического обмена данными (Dynamic Data Exchange, DDE)
Этот протокол выполняет все основные функции для обмена данными между приложениями. Он очень широко использовался до тех пор, пока для этих целей не стали применять OLE (впоследствии ActiveX). На данный момент DDE используется достаточно редко, в основном для обратной совместимости.
Больше всего этот протокол подходит для задач, не требующих продолжительного взаимодействия с пользователем. Пользователю в некоторых случаях нужно только установить соединение между программами, а обмен данными происходит без его участия. Замечу, что все это в равной степени относится и к технологии OLE/ActiveX.
OLE/ActiveX
Это действительно универсальная технология, и одно из многих ее применений — межпроцессный обмен данными. Хотя cтоит думаю отметить, что OLE как раз для этой цели и создавалась (на смену DDE), и только потом была расширена настолько, что пришлось поменять название ;-). Специально для обмена данными существует интерфейс IDataObject. А для обмена данными по сети используется DCOM, которую под некоторым углом можно рассматривать как объединение ActiveX и RPC.
Каналы (pipes)
Каналы — это очень мощная технология обмена данными. Наверное, именно поэтому в полной мере они поддерживаются только в Windows NT/2000. В общем случае канал можно представить в виде трубы, соединяющей два процесса. Что попадает в трубу на одном конце, мгновенно появляется на другом. Чаще всего каналы используются для передачи непрерывного потока данных.
Каналы делятся на анонимные (anonymous pipes) и именованные (named pipes). Анонимные каналы используются достаточно редко, они просто передают поток вывода одного процесса на поток ввода другого. Именованные каналы передают произвольные данные и могут работать через сеть. (Именованные каналы поддерживаются только в WinNT/2000.)
Сокеты (sockets)
Это очень важная технология, т.к. именно она отвечает за обмен данными в Интернет. Сокеты также часто используются в крупных ЛВС. Взаимодействие происходит через т.н. разъемы-«сокеты», которые представляют собой абстракцию конечных точек коммуникационной линии, соединяющей два приложения. С этими объектами программа и должна работать, например, ждать соединения, посылать данные и т.д. В Windows входит достаточно мощный API для работы с сокетами.
Почтовые слоты (mailslots)
Почтовые слоты — это механизм однонаправленного IPC. Если приложению известно имя слота, оно может помещать туда сообщения, а приложение-хозяин этого слота (приемник) может их оттуда извлекать и соответствующим образом обрабатывать. Основное преимущество этого способа — возможность передавать сообщения по локальной сети сразу нескольким компьютерам за одну операцию. Для этого приложения-приемники создают почтовые слоты с одним и тем же именем. Когда в дальнейшем какое-либо приложение помещает сообщение в этот слот, приложения-приемники получают его одновременно.
Объекты синхронизации
Как ни странно, объекты синхронизации тоже можно отнести к механизмам IPC. Конечно, объем передаваемых данных в данном случае очень невелик 😉 Но именно эти объекты следует использовать, если одному процессу нужно передать другому что-то вроде «я закончил работу» или «я начинаю работать с общей памятью».
Microsoft Message Queue (MSMQ)
Этот протокол действительно оправдывает свое название — он обеспечивает посылку сообщений между приложениями с помощью очереди сообщений. Основное его отличие от стандартной очереди сообщений Windows в том, что он может работать с удаленными процессами и даже с процессами, которые на данный момент недоступны (например, не запущены). Доставка сообщения по адресу гарантируется. Оно ставится в специальную очередь сообщений и находится там до тех пор, пока не появляется возможность его доставить.
Удаленный вызов процедур (Remote Procedure Call, RPC)
Строго говоря, это не совсем технология IPC, а скорее способ значительно расширить возможности других механизмов IPC. С помощью этой технологии общение через сеть становится совешенно прозрачным как для сервера, так и для клиента. Им обоим начинает казаться, что их «собеседник» расположен локально по отношению к ним .
Резюме
Конечно, я перечислил далеко не все способы обмена данными. Если бы это было так, то это было бы не так интересно 😉 За рамками данной статьи остались такие вещи, как глобальная таблица атомов, хуки и некоторые другие технологии, которые с некоторой натяжкой можно признать механизмами IPC. Но главное, как я считаю, сделано: теперь вы знаете, что это за непонятные аббревиатуры и как из всего многообразия методов IPC выбрать наиболее подходящий.
Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.
Источник: www.rsdn.org