• Студия разработки КОРАЛЛ 1С Владивосток

    Обмен между базами 1C 
    или как правильно организовать интеграцию корпоративной информационной системы 

    Читать полностью
25/05/2015

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

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

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


ЗАЧЕМ НЕОБХОДИМА ИНТЕГРАЦИЯ

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

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

 Сравнение функции продуктов bmp’online Sales и  Marketing.

Рисунок 1. Место возникновения задачи интеграции и обмена информцией между подразделениями.


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

1. Подразделения А и В используют единую монолитную корпоративную информационную систему (КИС). Используются единые справочники и документы. По сути задачи интеграции не существует.

НАДОЕЛО ЧИТАТЬ?

Оставь запрос, мы объясним суть статьи по телефону

2. Полная или автоматическая – когда ИС без участия человека синхронизируют справочники и документы с использованием сервисной шины предприятия и подсистемы нормативно справочной информации (НСИ).

3. Автоматизированная – когда справочники синхронизируются автоматически, а документы переносятся с участием сотрудников.

4. Полуавтоматизированная – справочники и документы переносятся с участием сотрудников.

5. Ручная - информация распечатывается на бумагу и заново вносится в другую ИС.

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

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


ИНТЕГРАЦИЯ МОЖЕТ ИЗМЕНИТЬ БИЗНЕС-ПРОЦЕССЫ

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

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

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

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

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

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

Рисунок 2а. Интеграции нет. Обмен информацией между подразделениями идет через уровень руководителей или делегируется подчиненным. В любом случае подразделение «владеет» своей информацией полностью и контролирует ее перемещение.


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

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

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

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


НАЗНАЧЕНИЕ ВЛАДЕЛЬЦЕВ СПРАВОЧНИКОВ

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

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

    Почему так важно иметь единые справочники во всех информационных системах? Между ИС подразделений обычно передают документы, которые отражают факты хозяйственной деятельности, выполняемые в рамках бизнес-процессов. Документы состоят из данных, которые берутся из справочников. Представим себе такую ситуацию (рис. 2а), подразделение А передает документ подразделению Б. В подразделении А документ заполнен с использованием своих справочников, а при получении этого документа в подразделении Б таких справочников нет (есть другие), подразделение Б не может прочитать переданный документ. Наличие одних и тех же справочников на передающей и получающей сторонах является обязательным условием обмена между ИС подразделений.

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

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

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

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

    Правильно ли это? Конечно, нет, но это реально работающий план для интеграции ИС конкурирующих подразделений. Часто руководитель подразделения предпочтет выполнять лишнюю работу по ручному или автоматизированному обмену данных с другим подразделением, чем пытаться до конца решить вопрос по владению справочником с другим подразделением и создать единую базу данных. Только создание слишком большого объема глупой работы заставляет подразделения идти навстречу по вопросу владения справочников.


НУЖНО ЛИ ВЛАДЕТЬ ДОКУМЕНТАМИ

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

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


СТРАТЕГИИ ИЗМЕНЕНИЯ СПРАВОЧНИКОВ

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

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

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

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

    Нормативно-справочная система (НСИ). Этот вариант является логическим продолжением предыдущих двух. То есть обмен настраивается не всех со всеми, а всех с одной выделенной базой НСИ. Желательно, чтобы справочники вносились только в НСИ, а далее распространялись по другим базам. Обмен можно настроить через стандартные планы обмена 1С или с помощью мгновенной синхронизации. Можно использовать специализированное решении 1С-Рарус:Центр управления данными (MDM).

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

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


ПРИМЕР ИНТЕГРАЦИИ НЕСКОЛЬКИХ БАЗ ДАННЫХ

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

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

• Бухгалтерский учет (БУ). В этих базах ведется налоговый учет юридических лиц организации. Используются типовые конфигурации без изменений, которые

• CRM или управление бизнес-процессами. Основная система, автоматизирующая производственную и коммерческую деятельность.

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

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


 Сравнение функции продуктов bmp’online Sales и  Marketing.

Рисунок 3. Пример однонаправленной круговой интеграции.

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

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

    В на рисунке указанной схеме есть еще один момент: из CRM в финансовый учет переносится заявка или счет на оплату покупателя (поставщика), далее из финансового учета этот же документ переносится в БУ и там формируется Акт. Что делать, если этот Акт нужен в CRM? По цепочке передаваемого счета можно восстановить связь между счетом в CRM и БУ, и тогда без проблем передать Акт из БУ в CRM. Акт нужен в CRM и не нужен в финансовом учете. То есть наблюдается некий однонаправленный замкнутый цикл передачи документов между отдельными базами.

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

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


ДОПОЛНИТЕЛЬНОЕ СОГЛАСОВАНИЕ ОБМЕНА

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

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

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


ДРУГИЕ ПРИМЕРЫ ИНТЕГРАЦИИ

    Более сложные варианты синхронизации получаются, когда кроме CRM и базы финансового учета необходима еще и производственная база. В этом случае имеет смысл сделать отдельную базу НСИ для синхронизации справочников, это уменьшит объем работы программистов. Также желательно назначить мастера системы, ответственного за ведение справочников, то есть, например, номенклатуру заводят в CRM, контрагентов в финансовом учете и т.д.

    Как поступать с документами? Здесь логика универсальна, она подходит для этого и всех других случаев. Технология мгновенной синхронизации достаточна затратная по ресурсам, поэтому нужно стремится уходить от нее там, где это позволяет бизнес-логика. Например, на рисунке 4 счета от CRM скорее всего пойдут в базу производства. Из базы производства, затраты на производство пойдут в финансовый учет. Общая картина по сделке будет видна в финансовом учете, а с финансового учета в CRM нужны сведения об оплатах. Налицо односторонние передачи документов, синхронизировать их не надо – это не дает новых качеств системе.


Пример интеграции с применением отдельной базы НСИ

Рисунок 4. Пример интеграции с применением отдельной базы НСИ.

    Другой пример: нужна распределенная база данных, состоящая из N баз, раскиданных по разным городам. Задачу консолидации информации желательно вынести в отдельную базу (на рисунке – консолидация). Здесь важно обратить внимание на проблему обновления распределенных баз. В 1С существует технология распределенных информационных баз (РИБ), которая позволит быстро настроить синхронизацию по плану между всеми распределенными базами и Консолидацией. Технология обеспечивает не только обмен данными, но и обновление конфигураций всех баз.


Пример интеграции с применением отдельной базы НСИ

Рисунок 5. Обмен осуществляется с помощью специальной конфигурации Консолидация.

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


ТЕХНОЛОГИИ ОБМЕНА МЕЖДУ ИНФОРМАЦИОННЫМИ СИСТЕМАМИ НА ПЛАТФОРМЕ 1С

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

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

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

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

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

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

    Интернет (Web service). Это наиболее перспективное направление обмена, где транспортом является веб-служба. Одна информационная база подключается к веб-сервису, веб-сервис подключается ко второй базе и транспортирует сообщение. Для осуществления такого транспорта необходимо иметь установленный веб-сервер (IIS или Apache). Программист может только запускать функции в подключаемой базе, при этом передавать в функцию запрос и получать результат выполнения функции.

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


ВЕБ-СЕРВИСЫ В 1С

    Кратко пройдемся по основным понятиям и принципам работы через Web service в 1С. Web service – это реализация обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети. Значит через Web service можно обратиться с одной программы к другой и при этом выполнять какие-то функции, речь идет не только об 1С.

    Еще пару понятий. SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределенной вычислительной среде. SOAP используется для обмена произвольными сообщениями в формате XML и удалённого вызова процедур (RPC). SOA – «сервис ориентированная архитектура» – означает, что программы для обмена данными друг с другом используют «сервисы».

    Для того чтобы описать Web service нужно воспользоваться языком WSDL (Web Services Description Language, основанный на языке XML. Далее это описание устанавливается в веб-сервер (можно использовать любой). Программа-потребитель обращается к веб-серверу, находит нужный Web service и запрашивает запуск функции, о котором известно из WSDL. Фактически веб-сервер запускает функцию на стороне программы-поставщика, функция обрабатывает запрос и возвращает результат через веб-сервер потребителю. На рисунке 6 видно, что потребителей может быть неограниченное количество и в принципе все они могут запросить поставщика услуг одновременно.


 Применение веб-сервисов для обмена и интеграции между базами 1С.

Рисунок 6. Применение веб-сервисов для обмена и интеграции между базами 1С.

    Что можно сделать в процессе запуска функции на стороне поставщика? Да практически все что угодно: подготовить данные и вернуть их потребителю или наоборот, записать переданные от потребителя данные в базе поставщика; можно выполнить расчет или иную обработку, можно изменить справочник или документ. То есть этот механизм идеально подходит для обмена, но есть один момент, о котором необходимо помнить. Если обмен настроен по расписанию, то можно обойтись одним веб-сервисом, к которому обращаются от потребителя по расписанию. Если нужен мгновенный обмен, когда пользователь зашел в справочник на стороне потребителя или поставщика, и хочет чтобы после изменения поменялась информация на другой стороне, то надо делать два Web service, для вызова с двух сторон. То есть потребитель является одновременно и поставщиком, в зависимости от того кто запускает обмен.

ОСТАЛИСЬ ВОПРОСЫ?

Мы ответим на любой интересующий вас вопрос по интеграции

    Как делается мгновенный обмен. На стороне потребителя и поставщика в карточках справочника или документах прописываются коды соответствующих карточек и документов из другой базы. При нажатии кнопки «сохранить» в карточке или документе из этой базы потребителя запускается функция в базе поставщика (естественно через Web service), в которой передается (в качестве параметров) код карточки и новое значение карточки. Функция изменяет карточку в базе поставщика. Отметим некоторые нюансы:

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

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

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

    В каком виде параметры могут быть переданы в функции? Параметры могут быть переданы в виде списка, то есть при вызове функции передаются строками или числами конкретные значения. Второй вариант — когда в качестве параметра передается XDTO пакет. XDTO — это механизм, разработанный фирмой 1С для обмена данными с другими программными системами посредством XML, позволяющий на уровне языка 1С оперировать не узлами XML, а прикладными понятиями “Сотрудник”, “Счет” и привычными встроенными типами (“ТаблицаЗначений”, “СправочникСсылка” и т.п.).

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

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

• http://infostart.ru/public/203109/

• https://habrahabr.ru/post/136684/

• http://infostart.ru/public/167459/



ключевые слова: обмен данными, интеграция, синхронизация, база данных, конфигурация 1С, 1С Консолидация, веб-вервис, сервис-ориентированная архитектура