Вопросы интеграции приложений предприятия активно обсуждаются сегодня компьютерным сообществом. Однако в стороне нередко остается ряд моментов, способствующих рождению преувеличенных надежд, возлагаемых на ряд «модных» средств и технологий интеграции. Не существует информационных систем, которые в одиночку могли бы покрыть потребности современного предприятия. Средние и крупные организации обычно эксплуатируют как минимум десяток многопользовательских систем, а иногда счет идет на сотни и тысячи. В этих системах часто обрабатываются одинаковые данные — начиная со справочников и классификаторов.
Не существует информационных систем, которые в одиночку могли бы покрыть потребности современного предприятия. Средние и крупные организации обычно эксплуатируют как минимум десяток многопользовательских систем, а иногда счет идет на сотни и тысячи. В этих системах часто обрабатываются одинаковые данные — начиная со справочников и классификаторов. Обычны ситуации, когда в рамках одного бизнес-процесса задействованы разные информационные системы. Многие информационные системы изначально ориентированы на получение информации из других приложений и баз данных (например, системы формирования сводной и корпоративной отчетности, системы управления и мониторинга). Поэтому ни одно корпоративное приложение не может рассматриваться как нечто автономное, а всегда является частью большого механизма под названием «информационная система предприятия».
Следствиями отсутствие должного решения проблемы интеграции являются:
- повторный ручной ввод данных (справочники, данные об отгрузках, финансовые транзакции и т.п.);
- многократные и бесконечные «сверки и корректировки» не исключающие ошибок;
- непомерные затраты на формирование сводной отчетности;
- неприемлемые сроки и себестоимость выполнения даже обыденных задач.
Это определяет цели интеграции приложений предприятия.
Цели интеграции
Общие цели интеграции приложений можно сформулировать следующим образом:
- уменьшить стоимость эксплуатации совокупности приложений предприятия;
- увеличить скорость выполнения типичных задач или гарантировать сроки их выполнения;
- поднять качество выполнения задач за счет формализации процессов и минимизации человеческого фактора, как основного источника ошибок.
В качестве целей конкретных интеграционных проектов обычно фигурируют более четкие формулировки. Например: «обеспечить формирование финансовой отчетности предприятия в срок не более одной недели после завершения финансового периода»; «уменьшить время оформления продажи с одного часа до 15 минут»; «уменьшить количество персонала, задействованного для поддержания в актуальном состоянии справочников и классификаторов, с 20 до пяти человек». Но обычно все, в конце концов, сводится к общим целям, которые можно сформулировать в еще более общем виде — уменьшить операционные расходы предприятия или организации. Поэтому интеграционные проекты часто оказываются в выигрышном положении с точки зрения обоснования перед людьми, принимающими решение о финансировании проектов: расчет показателей возврата инвестиций для таких проектов может выглядеть достаточно привлекательным.
Успешная интеграция корпоративных систем позволяет достичь и дополнительных целей — обеспечить автоматизированный контроль прохождения основных бизнес-процессов на предприятии, информационную безопасность при реализации бизнес-процессов и т.
Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Автор, выступая в качестве исполнителя работ, сталкивался с разными вариантами «спонсорства» таких проектов. Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Однако для интеграционных проектов такая заинтересованность жизненно необходима. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т. Согласование и формализация требований разных подразделений становится очень трудной задачей; отсутствие среди «идеологических лидеров» проекта человека, которому подотчетны все задействованные подразделения, обычно означает провал проекта. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния.
Не надо забывать, что основная цель интеграционных проектов — снижение издержек, равно как и предпосылки к проектам лежат в бизнес-области даже если проект относится сугубо к ИТ. К примеру, задача развертывания систем управления и мониторинга возникает, если бизнес озабочен снижением затрат на эксплуатацию ИТ-инфраструктуры. Мало того, интеграционные проекты в какой-то степени являются перекладыванием проблем с бизнес-подразделений на ИТ-службу. Рассмотрим, к примеру, типичную ситуацию, когда формированием отчетов «в стиле Excel» для руководства занимается группа в составе финансового департамента. От ИТ-подразделения при этом требуется лишь поддержание в работоспособном состоянии корпоративных информационных систем. В случае же внедрения системы, автоматически формирующей эту отчетность, за все — в том числе и за ошибки в данных — будет отвечать ИТ-служба. Действительно, по мере увеличения степени интегрированности и взаимосвязанности информационных систем возрастает ответственность, роль и статус ИТ-службы, увеличивается зависимость основных показателей работы всей организации от надежности и эффективности интегрированной информационной системы предприятия.
Программист по неволе24 / 24 / 8Регистрация: 22. 2015Сообщений: 476Записей в блоге: 1
1
Обмен информацией между программами. Как реализуется?29. 2015, 13:33. Показов 3984. Ответов36
Как реализуется обмен информацией между программами?
Грубо говоря. Есть одна программа. Она что-то делает (допустим число в степень возводит). Вот она уже работает, в ней в какую-то переменную записывается результат вычисления и менять код в ней нельзя. Нужно написать программу, которая бы считывала значение этой переменной и использовала бы в своих нуждах. (например на своей форме отображала бы его) Как такое можно реализовать?
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
0
управление сложностью1686 / 1299 / 259Регистрация: 22. 2015Сообщений: 7,545Записей в блоге: 5
29. 2015, 13:36
2
Ничего не понял. Вам нужно что-то типа программы в программе ?
0
1404 / 567 / 127Регистрация: 31. 2011Сообщений: 1,956
29. 2015, 14:10
4
1
Модератор7876 / 5190 / 2156Регистрация: 21. 2014Сообщений: 22,372Записей в блоге: 3
29. 2015, 14:16
5
Сообщение от Alex_From_777
Есть у кого идеи?
Использовать промежуточный файл, в который первая программа пишет данные, а вторая их оттуда читает и использует
1
1404 / 567 / 127Регистрация: 31. 2011Сообщений: 1,956
29. 2015, 14:22
6
1
1404 / 567 / 127Регистрация: 31. 2011Сообщений: 1,956
29. 2015, 14:50
8
1
8379 / 6140 / 615Регистрация: 10. 2010Сообщений: 28,683Записей в блоге: 30
29. 2015, 14:52
9
2
Супер-модератор31884 / 20782 / 8066Регистрация: 22. 2011Сообщений: 36,000Записей в блоге: 7
29. 2015, 15:34
10
Сообщение от Alex_From_777
Вот она уже работает, в ней в какую-то переменную записывается результат вычисления и менять код в ней нельзя
, и какие нафиг пайпы в таком случае?
0
8379 / 6140 / 615Регистрация: 10. 2010Сообщений: 28,683Записей в блоге: 30
29. 2015, 15:39
11
Что мешает в пайп кинуть его переменную «с»?
Но вероятно тут больше подойдет запись в проецируемую память эту переменную, ну и + либо флаг результата или объект события
Супер-модератор31884 / 20782 / 8066Регистрация: 22. 2011Сообщений: 36,000Записей в блоге: 7
29. 2015, 15:55
12
Сообщение от Avazart
Что мешает в пайп кинуть его переменную «с»?
То, что у тебя нет исходников (запрет их изменений равносилен отсутствию). Есть один EXE-шник, который уже откомпилирован, и уже работает. И пишет он результат в переменную. Твои действия для получения значения этой переменной в своей программе?
Я бы вообще поостерегся что-то подсказывать ТС-у. Налицо явная попытка залезть туда, куда лезть нельзя (в систему тестирования, к примеру, чтобы не делать что-то самому, а слизать из тестирующей программы то, чего она ожидает, и получить балл повыше)
1
8379 / 6140 / 615Регистрация: 10. 2010Сообщений: 28,683Записей в блоге: 30
29. 2015, 17:02
13
Сообщение от Alex_From_777
Вот она уже работает, в ней в какую-то переменную записывается результат вычисления и менять код в ней нельзя. Ну хз это можно по разному трактовать. Если есть программа и мы с ней хотим взаимодействовать то очевидно что в этой программе должен быть предусмотрен «протокол» обмена/взаимодействия иначе — только хаки. Сообщение от Alex_From_777
Как реализуется обмен информацией между программами?
Так что слово «обмен» тогда стоит заменить на «кража» со всеми вытекающими
1404 / 567 / 127Регистрация: 31. 2011Сообщений: 1,956
29. 2015, 23:43
14
Сообщение от volvo
То, что у тебя нет исходников
то что она работает не значит, что она не твоя
Сообщение от volvo
слизать из тестирующей программы то, чего она ожидает
для этого и артмани хватитДобавлено через 57 секунд
свою писать не нежно, еще чего заморачиваться
0
управление сложностью1686 / 1299 / 259Регистрация: 22. 2015Сообщений: 7,545Записей в блоге: 5
30. 2015, 12:34
15
Сообщение от volvo
Я бы вообще поостерегся что-то подсказывать ТС-у. Налицо явная попытка залезть туда, куда лезть нельзя (в систему тестирования, к примеру, чтобы не делать что-то самому, а слизать из тестирующей программы то, чего она ожидает, и получить балл повыше)
Полностью согласен, явно не из благих намерений это делается, причем ТС даже не представляет как это работает
0
nick42
30. 2015, 14:18
Не по теме:Есть ещё «презумпция невиновности»; я, например, тоже многое не представляю, как работает, но узнать ХОЧЕТСЯ. А на «применять знания» есть много всякого: и уголовный кодекс, и ФБР, и ФСБ, и совесть, наконец
1404 / 567 / 127Регистрация: 31. 2011Сообщений: 1,956
01. 2015, 11:53
19
Сообщение от Alex_From_777
Стоит уйти покушать, как всё самое интересное заканчивается
А что ты хотел? Еще пофлеймить? Ответ на свой вопрос ты получил
Зачем настраивать обмен данными между 1C и другими системами
Организация обмена данными между 1С несколькими информационными системами является очень важной и «популярной» задачей при организации работы в компании. Очень часто такая необходимость возникает, когда организация имеет распределенную структуру. Ее подразделения могут находиться далеко друг от друга и взаимодействовать только посредством интернета. В каждом таком территориально удаленном подразделении может находиться свой сервер или компьютер, выполняющий роль сервера. На этом сервере находится, например, база данных программы 1С:Предприятие. Для полноценной работы организации между удаленными подразделениями необходимо настроить обмен данными.
Также может быть, что вся организация расположена в пределах одного здания, но учет ведется в различных информационных базах на основе разных программных продуктов 1С. Чаще всего это необходимо для конфиденциальности информации и для разграничения информационных потоков с целью лучшей управляемости на каждом этапе общего бизнес-процесса организации.
Наиболее серьезный вариант это обмен между территориально распределенными системами на основе разных продуктов 1С, но и обмен со сторонними программными решениями (не 1С).
В программных продуктах на платформе 1С реализованы механизмы обмена данными и в этой статье мы расскажем о возможных вариантах обмена между информационными базами 1С, а также об обмене со сторонними программными продуктами.
Какие задачи можно решать при помощи передачи данных в 1С
В зависимости от структуры организации, сложности бизнес-процессов, конфиденциальности информации и многих других факторов обмен данными между информационными системами может решать ряд важных задач:
- организовать регулярное взаимодействие между территориально распределенными подразделениями;
- исключить двойной ввод информации и минимизировать ошибки при повторном вводе информации в разные информационные базы;
- организовать синхронизацию данных без постоянного Интернет-соединения;
- автоматизировать схожие бизнес-процессы в различных подразделениях;
- актуализация нормативно-справочной информации в различных информационных системах.
В зависимости от решаемых задач настройка обмена данными в 1С может превратиться в трудоемкий процесс, решаемый в рамках проекта интеграции 1С. Для качественного выполнения работ по интеграции 1С требуются специальные знания не только программиста 1С , но и консультанта-методолога, который подскажет, как правильно организовать синхронизацию баз данных 1С и сторонних продуктов.
Как выбрать необходимый вариант синхронизации данных
Для настройки и выполнения обмена данных 1С с различными программами необходимо выбрать технологии связи, которые лучше использовать в каждом конкретном случае. Для этого необходимо, в первую очередь, определить какая из программ будет выступать в качестве «источника данных», а какая в роли «приемника данных». Если обе программы и передают и принимают данные, такое бывает очень часто, тогда между ними будет настраиваться двусторонний обмен.
При синхронизации данных между программами необходимо проработать ряд вопросов, которые влияют на выбор формата обмена: определить состав передаваемых данных, правила обмена данными, протоколы обмена, расписание выполнения обмена.
После выбора источника и приемника данных и проработки остальных вопросов синхронизации можно остановиться на следующей классификации обмена между программами:
- обмен данными между абсолютно идентичными конфигурациями баз данных 1С;
- обмен данными между различными конфигурациями баз данных 1С;
- обмен данными между программой 1С и внешней программой.
Обмен данными в 1С
Продукты семейства 1С массово используются российским бизнесом. Практически все задачи учета решаются типовыми конфигурациями. Программы 1С приходится все время интегрировать между собой и с другими системами. Обмен сайта на Битрикс и 1С:Управление Торговлей — один из самых распространенных примеров.
Мы решили составить полный обзор всех методов интеграции продуктов 1С между собой и с другими системами.
Характеристики 1С обмена
Технологий обмена между решениями на базе 1С так много, что нужно разделить на несколько крупных групп:
- информационный обмен может выполняться внутри единой распределенной базы, так и между независимыми конфигурациями;
- встречаются различные каналы обмена: локальный или сетевой каталог, FTP-ресурс, web-сервис, почтовые сообщения, прямое подключение к базе через COM-соединение;
- режим обмена может быть ручной или автоматический по расписанию;
- в интересах учета можно ограничить набор синхронизируемых данных или просто «передавать все»;
- встречаются разные протоколы и форматы обмена данными.
Проще всего настроить обмен между двумя одинаковыми 1С-ками.
Обмен между идентичными конфигурациями
Возможны следующие варианты:
Распределенная информационная база (РИБ)
Приведем примеры задач, которые хорошо решает РИБ:
- Имеется организация с центральным офисом и несколькими удаленными филиалами, связанными между собой медленным каналом связи. Необходимо настроить обмен данными, чтобы в центральном офисе была актуальная информация из баз филиалов;
- Структура базы данных 1С в организации находится в активной фазе доработки. База установлена в нескольких филиалах и в ней параллельно ведется работа. Кроме обмена данными необходимо поддерживать идентичность структуры базы во всех филиалах после обновления;
- Малыми затратами, без дополнительного программирования необходимо настроить обмен данных в типовой 1С между головным офисом и одним-двумя филиалами.
Для выполнения этих задач обмена в «1С:Предприятие» существует механизм распределенных информационных баз (РИБ). Он применяется в территориально распределенных организациях.
Примечательно, что для настройки распределенной базы данных не потребуется никакого дополнительного программирования. Все делается настройками.
Механизм РИБ реализуется при помощи специального механизма «планов обмена».
План обмена — настроенный механизм для передачи информации. Важно, что план обмена — штатный элемент экосистемы 1С, он является частью конфигурации и не создает никаких проблем при обновлениях. При настройке плана обмена указывают объекты и поля, участвующие в обмене.
Например, план обмена «Полный» предназначен для полной синхронизации данных в РИБ. В состав его объектов, участвующих при обмене, входят практически все объекты базы данных. Для настройки обмена между идентичными 1С в плане обмена достаточно установить признак «распределенная информационная база».
Достоинства и недостатки распределенных информационных баз 1С
Преимущества РИБ
Недостатки РИБ
Простота в создании распределенной системы, без необходимости в дополнительном программировании;
Позволяет обмениваться не только данными, но и изменениями в структуре конфигурации базы данных;
Возможность задания условий (фильтров) на прием и передачу элементов данных при обмене;
Изменения в данные можно вносить в любой объект, участвующий в обмене данными;
Имеются способы настройки для разрешения проблемы при одновременном изменении данных в разных объектах распределенной системы. Обмен данными осуществляется между абсолютно идентичными конфигурациями 1С
Структура представлена как древовидная с четким делением каждой пары связанных узлов на «главного» и «подчиненного». Под узлом понимается объект распределенной системы, участвующий в обмене. Изменения конфигурации передаются только от главного узла к подчиненному. При выгрузке данных справочники, документы и прочие объекты блокируются для новых изменений. Поэтому обмен рекомендуется производить маленькими партиями или в нерабочее время.
Другие варианты обмена между одинаковыми конфигурациями
Если механизм РИБ не подходит для синхронизации данных между идентичными конфигурациями, можно использовать другие механизмы, например, универсальный механизм обмена данными или веб-сервисы. Они дают больше возможностей для настройки обмена, но являются более трудоемкими.
Для обмена данными между идентичными конфигурациями существует много внешних обработок. Например, «Выгрузка и загрузка данных XML» является самой известной. Эта обработка позволяет обмениваться любыми данными между одинаковыми конфигурациями.
Разные версии данной обработки могут использоваться в обычном и в управляемом приложениях. Обработки можно найти на диске ИТС, или в шаблонах конфигурации «1С:Конвертация данных». Рекомендуется использовать обработку из «Конвертации данных» версии 2.
Примеры реализации
На приведенной схеме РИБ представлен стандартный обмен между магазинами и кассами в организации розничной торговли. Такой обмен позволяет оперативно обмениваться данными между филиалами используя все преимущества РИБ.
Обмен между различными системами 1С
Варианты передачи данных
Универсальный обмен в 1С
Для синхронизации данных между различными конфигурациями в 1С есть универсальный механизм обмена.
При помощи универсального обмена данными в 1С можно решать множество задач обмена, например:
- В организации учет ведется в разных программах 1С: бухгалтерский и налоговый учет — в 1С:Бухгалтерия предприятия, управленческий — в 1С:Управление торговлей, расчет з/п в 1С:ЗУП. Необходимо организовать обмен данными между этими тремя системами. Ниже есть схема этого примера;
- В организации используется относительно старая, сильно измененная под нужды компании конфигурация Управление торговлей 10.3. Необходимо настроить обмен с конфигурацией последнего релиза (например, БП, КА, УПП).
Этот механизм позволяет создавать распределенные системы, но не требует чтобы они были идентичными. В нем используются уже описанные «планы обмена».
Используемые планы обмена, данные объектов (справочник, документ, регистр сведений и т. ) представляются в формате XML. Универсальный обмен 1С позволяет организовать разовую и регулярную синхронизацию данных.
- Формат обмена — XML-документы. В платформе 1С для обработки XML реализована возможность чтения и записи XML-документов;
- Этот механизм обмена предоставляет большие возможности для настройки структуры передаваемых данных и их состава в различные узлы обмена. Если ни один из имеющихся планов обмена не подходит для обмена, можно создать свой на основе существующего.
Например, необходимо создать односторонний обмен между главной базой и базами филиалов на основе конфигурации УТ 11, причем должен выполниться обмен ограниченными данными, по определенным индивидуальным условиям. РИБ и другие существующие планы обмена для этого не подойдут. В таком случае лучше создать свой план обмена взяв за основу универсальный обмен в формате EnterpriseData. Главным ограничением является то, что универсальный механизм обмена поддерживает только обмен данными. Изменения в конфигурации нельзя передавать между узлами обмена.
Обмен данными по расписанию в 1С
Часто необходимо сделать так, чтобы обмен данными выполнялся регулярно, в автоматическом режиме. Для автоматического обмена в 1С необходимо настроить регламентное задание и указать расписание его выполнения.
Обмен 1С с внешними программами
Помимо обмена между различными конфигурациями 1С, очень часто требуется организовать обмен данными с внешними программами, например обмен 1C с банком или логистической системой, интеграция с интернет-магазином или корпоративным порталом и т.
1С:Предприятие позволяет осуществлять интеграцию с любыми внешними программами на основе различных протоколов передачи данных. С развитием платформы возможности интеграции расширяются.
Рассмотрим несколько наиболее распространенных форматов для интеграции с различными приложениями.
Веб-сервисы в 1С (Web-сервисы)
Пример использования: обмен данными «в режиме реального времени». При изменении данных в одной из систем, участвующих в обмене, запускается обращение к веб-сервису. Формируется пакет с измененными данными, и эти данные передаются в другую систему.
Веб-сервисы широко используются для интеграции различных приложений. В платформу 1С:Предприятие включены широкие возможности для работы с web-сервисами. 1С может выступать как поставщик Веб-сервисов и как потребитель веб-сервисов, опубликованных другим приложением.
Программисты могут создать свой необходимый веб-сервис для решения конкретной задачи.
При использовании веб-сервиса нет потребности в предоставлении внешнему приложению доступа к информационной базе, что очень хорошо с точки зрения обеспечения безопасности данных. Внешнее приложение получает доступ к набору функций 1С, которые сами обрабатывают данные и предоставляют «наружу» конечный результат.
Если 1С передает информацию, в конфигураторе создается новый объект «веб-сервис», и программно описывается его функциональность, например, получение остатков на складах. После того как сервис будет опубликован, стороннее приложение сможет запрашивать и получать информацию о наличии требуемой номенклатуры на складах. Для публикации веб-сервиса на сервере должно быть установлено дополнительное программное обеспечение, веб-сервер. Например, это может быть бесплатный веб-сервер Apache.
Когда 1С получает информацию, в конфигурации создается ссылка, по которой приложение 1С обращается к внешнему веб-сервису, созданному в стороннем приложении. Получив по данной ссылке необходимые данные их обработка выполняется уже внутренними алгоритмами.
Использование HTTP-сервисов
- более простое создание клиентского приложения;
- уменьшенный объем передаваемых данных;
- меньшая потребность в вычислительных мощностях;
- большая нацеленность на работу в мобильных устройствах.
Поддержка REST-интерфейса в 1С
Начиная с платформы 8. 5 появилась возможность автоматически создавать REST-интерфейс для прикладного решения 1С. Благодаря кроссплатформенности и уникальности этого механизма, это наиболее удобное решение вопроса интеграции 1С с внешними системами. Механизм REST может использоваться и при обмене между информационными базами 1С, но для этого существуют более удобные решения.
REST-интерфейс позволяет создавать новые объекты, удалять их, читать и редактировать.
Наиболее часто REST-интерфейс применяется в следующих случаях:
- интеграции с веб-приложениями (интернет-магазины, веб-порталы и т.д.);
- обмена данными с внешним сторонним приложением;
- необходимости расширения возможности приложения 1С сторонними средствами без доработки самой конфигурации.
Для публикации необходим веб-сервер.
Обмен в формате EnterpriseData
Формат обмена данными EnterpriseData разработан фирмой 1С для облегчения интеграции с программами 1С. Этот формат позволяет описать объект базы (справочник, документ и т. ) и содержит информацию об изменении или удалении объекта. На данный момент этот формат поддерживается в следующих продуктах 1С: Управление торговлей 11, Бухгалтерия предприятия 3, Розница 2, ERP 2, ЗУП КОРП 3. Приложения 1С также могут использовать формат EnterpriseData для обмена со сторонними информационными системами.
Обмен в формате EnterpriseData осуществляется посредством обмена XML-файлов. В процессе обмена формируются файлы-запросы и файлы-ответы.
Основным преимуществом формата является то, что он ориентирован на логику 1С, является простым в использовании и не ограничен никакими требования к структуре систем, которые участвуют в обмене.
Применение формата XML в 1С
XML-формат является в некотором роде универсальным форматом и широко используется во всех конфигурациях 1С. 1С:Предприятие поддерживает работу с XML-документами при помощи функций встроенного языка программирования. Благодаря этому XML-формат широко используется в собственных разработках.
Формат широко используется при обмене с удаленными подразделениями и с интернет-сайтами, при загрузке выписок из банков и прайс-листов от поставщиков, при выгрузке данных в отчетные органы и т.
В 1С есть универсальные обработки для выгрузки данных в формате XML.
Преимущество при обмене со сторонними приложениями заключается в том что это широко распространенный формат и поддерживается большинством программных продуктов, независимо от структуры базы данных.
Также в 1С XML-формат используется при сохранении настроек отчетов и печатных форм.
Поддержка JSON в 1С
Начиная с версии 8. 1977 в платформе 1С реализована поддержка формата JSON. В более ранних версия платформы 1С с этим форматом тоже можно было работать, но теперь в 1С появились удобные стандартные средства для работы с JSON. Этот формат широко применяется в веб-приложениях и поддерживается всеми браузерами. По сравнению с XML, текстовый формат обмена JSON является более лаконичным.
Основное применение данного формате в 1С это интеграция с внешними приложениями, особенно с веб-приложениями. Формат JSON можно использовать при обмене файлами между разными приложениями 1С:Предприятие.
Этот формат используется в нашей разработке «Обмен счетами между Битрикс24 и 1С:Бухгалтерия предприятия».
Все описанные выше форматы обмена данными в 1С предназначены для того чтобы подготовить запрашиваемые данные и передать их стороннему приложению. Или запросить необходимые данные у внешнего приложения, получить их и передать для обработки на основании внутренних алгоритмов приложения 1С.
Давайте настроим обмен данными!
Чем больше развиваются информационные системы в бизнесе-пространстве, тем теснее они интегрируются между собой. Платформа 1С активно развивается в данном направлении и имеет ряд удобных механизмов для синхронизации данных, а также поддерживает большое количество технологий и форматов обмена данными. Это позволяет прикладным решениям на платформе 1С активно обмениваться данными между собой и со сторонними приложениями.
Компания ИНТЕРВОЛГА регулярно сталкивается с задачами интеграции 1С с интернет-магазинами и корпоративными порталами, и успешно решает эти задачи.
На нашем сайте есть ряд статей, посвященных обмену между Битрикс и 1С:
- Обмен счетами между Битрикс24 и 1С-Бухгалтерия;
- Как работает обмен товарами 1С УТ и Битрикс24;
- Интеграция Битрикс24 и 1С-Бухгалтерия — Модуль 1С:Синхронизация;
- Интеграция Битрикс24 и 1С – новые возможности и настройка обмена;
- Облачные кассы и 1С — Интеграция, которой не было.
У нашей компании есть большой опыт в интеграционных проектах не только между 1С и сайтами. Вообще все, что касается обмена 1С с чего-либо, нам интересно, в большинстве случаев знакомо, и мы готовы помочь Вам в решении Ваших задач по интеграции 1С.
Вам может быть интересно:
- Переход на новую версию 1С – обновление на УТ 11.4;
- Учет валюты в 1С – внедрение и доработка «1С УНФ».
Взаимодействие интегрированных приложений
Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный обмен сообщениями. В этом списке нет прямого обмена данными между базами данных приложений: этот метод ближе не к интеграции приложений, а к перемещению данных. С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку (например, при загрузке накладных пересчитывать товарные остатки). Прямой обмен данными, который обычно выполняется средствами класса ETL (extract, transfer, load) или самодельными утилитами, обычно такой возможности не предоставляет.
Обмен файлами
Обмен файлами пожалуй, самый распространенный подход к организации взаимодействия. Это связано с относительной простотой реализации, а также существованием стандартных (или «почти» стандартных) форматов обмена. Например, большая часть корпоративных информационных систем позволяет загружать и выгружать файлы, например, в формате CSV (Comma-Separated Values — «поля, разделенные запятыми»). Но у этого подхода есть и недостатки; если необходимо оперировать сложными структурами, то простые форматы обмена уже не пригодны. Возникающие в таких случаях специализированные форматы файлов должны «понимать» взаимодействующие системы, что ведет к жесткой зависимости систем друг от друга. Этот недостаток обычно преодолевают всевозможными утилитами конвертации данных. Кроме того, обычно обмен файлами подразумевает участие человека — кто-то должен выгрузить файл, скопировать его на другой компьютер, загрузить. Однако если интегрируемые методом обмена файлами системы имеют возможность автоматической загрузки/выгрузки (например, по расписанию), то данный подход позволяет построить полностью автоматизированное решение, которое вследствие своей простоты обладает высокой надежностью и пропускной способностью.
Общая база данных
Данный подход концептуально очень прост — несколько информационных систем или приложений используют одну базу данных. Главный его недостаток — связь между интегрированными приложениями настолько тесная, что иногда невозможно заметить границу между ними (обычно так интегрируются продукты одного производителя). Примером такого подхода могут служить большинство ERP-систем, где различные модули системы используют одну базу. Однако слишком тесная связь превращает конгломерат интегрированных приложений в монолит, в «суперсистему», отдельные части которой с трудом поддаются самостоятельной модернизации и замене. С этим борются, используя механизмы серверов баз данных (представления данных, промежуточные таблицы и т. ), но далеко не всегда эффективно.
Удаленный вызов
Основной недостаток удаленного вызова — требование работоспособности всех задействованных приложений в момент взаимодействия. Представьте себе систему ведения справочников, изменения из которой каждую ночь распространяются в десятки корпоративных систем. Вероятность того, что, скажем, в два часа ночи все корпоративные системы находятся в состоянии полной боеготовности, невелика. На этом «погорели» и мы, реализовав с помощью технологий Web-сервисов распространение справочников по корпоративным системам; все пришлось переписать.
Опыт показывает, что подход, основанный на удаленном вызове, приемлем только в тех случаях, когда взаимодействие приложений инициируется пользователем, который сам контролирует результат. Для автоматического взаимодействия без участия человека данный подход практически неприменим. В этом нет ничего удивительного: удаленные вызовы изначально были придуманы не для интеграции разных приложений, а для создания распределенных систем, когда компоненты одной системы могут работать на разных компьютерах.
Асинхронный обмен сообщениями
Это, пожалуй, единственный из перечисленных подходов, который создавался специально для интеграции информационных систем. Идея концептуально проста и напоминает работу электронной почты. Когда приложению А необходимо вызвать какое-то действие в приложении Б, оно формирует соответствующее сообщение с данными и инструкциями и отправляет его посредством системы доставки сообщений. Слово «асинхронный» означает, что приложение А не должно ждать, пока сообщение дойдет до Б, будет обработано, сформирован ответ и т. Сообщение гарантированно доставляется благодаря механизму очередей сообщений, которые снимают с взаимодействующих систем заботу о надежности сети передачи данных, работоспособности взаимодействующих систем в конкретные моменты времени и т.
Недостаток данного подхода — высокая цена. Система гарантированной доставки на основе очередей сообщений обычно сама по себе недешева; единственным известным мне исключением является Microsoft Message Queue (MSMQ), компонент серверных операционных систем семейства Windows. Правда, есть и свободно распространяемые бесплатные (например, ActiveMQ), которые, тем не менее, нужно развернуть, обучить специалистов, поддерживать, написать адаптеры между системой доставки и приложениями и т.
Топология
Существует два подхода к организации маршрутов взаимодействия интегрируемых системы. Первый — прямое взаимодействие интегрированных систем по принципу «каждая с каждой», или «точка-точка». Второй — взаимодействие через центральный узел; подобную звездообразную архитектуру обычно называемую «хаб + спицы». Топология не зависит от физической архитектуры информационной системы, а определяет логические маршруты взаимодействия и передачи данных между интегрированными системами.
Точка-точка
При данном подходе интегрированные системы взаимодействуют напрямую. Преимущества подхода — простота, прозрачность и отсутствие необходимости в дополнительном программном обеспечении. Однако, есть и недостатки. Во-первых, интегрированные приложения должны общаться с использованием одинаковых методов взаимодействия и форматов вызовов/данных. При изменении одного из приложений (если оно повлекло за собой изменение интерфейса взаимодействия данного приложения) приходится модифицировать или как минимум перенастраивать все интегрированные с ним системы. Во-вторых, в информационной системе предприятия появляется слишком много связей, каждую из которых нужно контролировать и поддерживать в работоспособном состоянии.
Если взаимодействующих приложений много, стоимость сопровождения интегрированной таким образом информационной системы предприятия становится неприемлемо высокой. Тем не менее подход «точка-точка» широко используется. Это происходит, как правило, в тех случаях, когда при взаимодействии конкретных приложений необходимо передавать большие объемы данных или обеспечивать нормированное время взаимодействия, а также если эксплуатируемые на предприятии приложения имеют встроенные средства взаимодействия (это часто случается при внедрении нескольких систем от одного поставщика, а также если при разработке заказных программных систем или внедрении новых к ним изначально предъявляется требование по взаимодействию с уже имеющимися системами).
Здесь, однако, таится опасность «ползучей» интеграции, которая делает возможной ситуации, когда при необходимости поменять систему XYZ неожиданно обнаруживается, что сделать этого нельзя, поскольку справочник оргструктуры и сотрудников вашего предприятия, исторически ведущийся в XYZ, каждую ночь реплицируется еще в десяток систем.
Хаб + спицы
Взаимодействие по типу «точка-точка» создает в инфраструктуре предприятия слишком много связей и требует согласования интерфейсов и форматов данных между взаимодействующими приложениями. Эти недостатки призвана решить архитектура взаимодействия, в которой все приложения непосредственно соединены только с центральным узлом, решающим следующие задачи:
- организация маршрутизации взаимодействия между интегрированными приложениями;
- преобразование форматов файлов и данных;
- обеспечение взаимодействия приложений с использованием разных методов и протоколов взаимодействия.
Благодаря введению промежуточного звена, уменьшается число связей между приложениями, устраняются прямые связи, а система интеграции становится более гибкой и дешевой в эксплуатации. Если меняется одно из интегрированных приложений, то — при условии правильно спроектированной системы интеграции — нужно будет модифицировать только одну связь, между данным приложением и хабом.
Недостатком топологии «хаб + спицы» является высокая стоимость приобретения и сложность программного инструментария, играющего роль хаба, а также нехватка специалистов, имеющих опыт применения подобных программных средств.
Выбор средств интеграции
Готовых инструментов интеграции на рынке немало. Так, только корпорация IBM в разделе программного обеспечения интеграции приложений предлагает пару десятков групп продуктов и еще много интеграционных продуктов в других категориях. Сложность выбора состоит в том, что среди представленных средств есть и узко ориентированные (например, IBM Message Broker), и позиционируемые как «универсальные» (скажем, Microsoft BizTalk). Однако выбор того или иного инструментария определяется не тем, что о нем говорит производитель, а конкретным составом «зоопарка» аппаратно-программных решений в организации, которые необходимо заставить работать совместно.
Советы общего плана
Перед выбором программных средств интеграции необходимо четко определить все системы, нуждающиеся в координации или в обмене данными с другими системами; документировать все возможные протоколы взаимодействия, требования по объему данных, расписанию обмена и т. Ключевым моментом также является необходимость участия человека в процессе взаимодействия информационных систем. Часто это диктует выбор решений, не имеющих, на первый взгляд, отношения к интеграции.
Весьма распространенная ошибка — выбрать три-четыре системы из двух десятков, интегрировать их с использованием какого-то инструмента, а при добавлении в «корзинку» еще одной системы обнаружить неприменимость ранее выбранного подхода. Скорее всего, к этому моменту уже будут вложены немалые средства в лицензии на интеграционное программное обеспечение и его изучение, а потому проект в дальнейшем пойдет по пути пришивания заплат, что вполне может убить весь смысл «правильной» интеграции.
Собрав и документировав информацию о будущей картине взаимодействия приложений, необходимо отобрать минимальный набор приложений, дающих все варианты методов взаимодействия, протоколов и т. Возможны разные требования по объему и видам передаваемых данных, по стилям интеграции и так далее — нужно сформировать минимальную по объему репрезентативную выборку, и на ее основе выбирать комплект продуктов для интеграции и запускать пилотный проект.
Совет конкретный
До завершения пилотного проекта нет необходимости приобретать интеграционное программное обеспечение — всегда есть возможность получить временные лицензии и все проверить. При этом партнеры поставщиков таких решений, как правило, решают вопросы проверки оперативнее самих поставщиков, и, самое главное, могут обеспечить техническую поддержку еще до покупки лицензий.
Отдельно про Web-сервисы
Сегодня технология Web-сервисов позиционируется как удобное средство интеграции приложений, поскольку позволяет реализовывать, развертывать, и обеспечить простое межплатформное взаимодействие. К сожалению, наш опыт говорит о практической неприменимости современных технологий Web-сервисов для интеграции приложений как общего подхода. Действительно, пока Web-сервисы оказываются непригодны для обработки больших объемов информации; в них отсутствуют средства поддержки транзакций; взаимодействующие системы должны находиться в работоспособном состоянии на момент взаимодействия.
Непригодность к обработке больших объемов — врожденный недостаток, который связан с XML-природой Web-сервисов. Все данные и параметры вызовов Web-сервисов преобразуются в формат XML, что во много раз увеличивает объем данных со всеми вытекающими из этого последствиями в виде растущей потребности в оперативной памяти и нагрузки на процессоры. К сожалению, речь идет не о гигабайтах передаваемой информации: Web-сервисы «захлебываются», когда за одно взаимодействие между интегрированными системами нужно передавать уже сотню килобайт. (Правда, существует стандарт WS-Attachments, описывающий механизм подсоединения к вызовам Web-сервисов любых данных без перекодирования в XML, однако ведущие поставщики этот стандарт не поддерживают
Далее представьте, что в процессе взаимодействия множества информационных систем необходимо провести согласованные изменения в некоторых из них, то есть выполнить логическую транзакцию, затрагивающую несколько систем. Если для интеграции используются Web-сервисы, то такой возможности нет: в своем «исходном» варианте Web-сервисы не поддерживают заключение в рамки одной транзакции несколько вызовов методов одного или нескольких сервисов. Поставщики интеграционного программного обеспечения в этом случае обычно предлагают использовать так называемые «компенсационные операции» (на каждую операцию предусмотреть отменяющую ее операцию). Скажем, если из трех участвующих в логической транзакции приложений два смогли выполнить какую-то операцию, а одно — нет, то в двух системах нужно выполнить действия отката, отменяющие результат успешно выполненных операций. В теории подход хорош, но, во-первых, никто не гарантирует успех компенсационной операции, а во-вторых, некоторые системы (например, финансовые) не допускают удаления данных, внесенных в базу.
Предварительный стандарт WS-Transactions, призванный решить данную проблему, существует, но отсутствуют его полноценные реализации. Так, корпорация IBM заявила о поддержке этого стандарта в своих интеграционных продуктах, основанных на WebSphere Application Server, но с массой ограничений; самое главное из которых — все взаимодействующие Web-сервисы должны работать под управлением WebSphere Application Server. Аналогичная ситуация и у Microsoft в. Net 3. 0, что выхолащивает смысл Web-сервисов — простоту межплатформного взаимодействия.
Но самое печальное в ситуации с Web-сервисами — не отсутствие реализаций стандартов, сдерживающих их применение для интеграции приложений. Плохо то, что после реализации всех необходимых стандартов Web-сервисы рискуют потерять то, благодаря чему они стали столь популярны, — простоту создания, развертывания, поддержки. Поддержка WS-Transactions, WS-Attachments и других стандартов, расширяющих возможности Web-сервисов, может резко усложнить их создание, отладку и развертывание.
Немного о ESB и SOA
Вернемся теперь на пять лет назад, когда основной платформой интеграции приложений были транспорты на основе очередей сообщений и программное обеспечение промежуточного слоя, ориентированное на обработку сообщений, которое играло роль «хаба» в рассмотренной ранее архитектуре «хаб + спицы».
Подобный инструментарий промежуточного слоя стоил слишком дорого, а специалисты по нему — еще дороже. Когда появился новый метод межплатформного взаимодействия, Web-сервисы, родился и новый подход к организации основы для интеграции — сервисная шина предприятия (Enterprise Service Bus, ESB). Реальным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP. Основанный на ESB подход подавался как более дешевая, простая в реализации альтернатива предыдущей концепции.
Что же получилось в действительности? Появились новые продукты, поддерживающие SOAP, в старые продукты такая поддержка была добавлена, однако они не стали дешевле, а значит, доступнее своих предшественников. Означает ли это конец еще одной красивой сказки? Вовсе нет. Если отбросить пропаганду, то поддержка «хабом» интеграционной системы широкого спектра методов взаимодействия и протоколов облегчает и удешевляет интеграцию. Но не в разы, а на проценты — что уже неплохо с учетом стоимости интеграционных проектов.
Вокруг архитектуры, ориентированной на сервисы (Service-Oriented Architecture, SOA), также очень много маркетинговой шумихи. На мой взгляд, SOA — это не конкретные продукты и даже не технология, а лишь концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. Это означает, что для пользователей ничего не изменится, пока ведущие поставщики программного обеспечения (и прежде всего, производители бизнес-приложений наподобие ERP, CRM, EAM и т. ) не модифицируют свои системы в соответствии с SOA. Только тогда можно получить реальный выигрыш; пока же популярные бизнес-приложения — это замкнутые системы с очень «узким» внешним интерфейсом.
Однако ведущим поставщикам программного обеспечения это не так уж и нужно — хотя бы по той причине, что SOA даст теоретическую возможность клиентам выбирать компоненты от разных поставщиков по принципу «лучший в классе» и объединять их в информационную систему предприятия. При этом производителям, скорее всего, потребуется переписать свои системы. Вместе с тем, в настоящее время поддержка SOA является одним из тех немногих «крючков», которые могут побудить имеющихся клиентов переходить на новые версии бизнес-систем, а также способствовать правильной — с точки зрения поставщика — ориентации новых клиентов. Так или иначе, следующие несколько лет покажут, насколько жизнеспособна концепция SOA.
Решение
Ну раз уж подняли старую тему.
В Windows самый эффективный механизм обмена данными между приложениями — это
разделяемая память (или отображаемые в память файлы, это почти одно и то же), а
также все механизмы, построенные на этой основе (pipes, например). Разделяемая
память поддерживается аппаратно (отображение одной физической страницы на разные
виртуальные адреса), для обмена данными не требуется ни доступ к диску/сети,
ни смена задач, ни переключение в ядро, поэтому скорость максимальная.
У Memory-Mapped Files есть лишь один недостаток — для обмена данными между
сессиями нужно создавать объект MMF в глобальном пространстве имен, а для этого
нужна привилегия SE_CREATE_GLOBAL_NAME, которая, начиная с Windows Vista,
только у администраторов и служб.
У именованных каналов (named pipes) такой проблемы нет, к тому же они поддерживают
обмен данными по сети, работу с безопасностью (например, пайп-сервер может выполнять
запрос в контексте безопасности пайп-клиента), message mode, таймауты и кое-что еще. Правда, написать хорошо работающий пайп-сервер не так просто, как кажется, но такова
цена за его эффективность и функциональность. IpcChannel и NetNamedPipeBinding из WCF
тоже построены на pipes, так что в. NET, вероятно, стоит использовать их.
Еше один вариант — COM/RPC. Скорость здесь будет ниже на порядок, да и для тех, кто не знаком с технологией COM,
написание даже простейшего клиент-сервера может быстро завести в тупик. Но это один из
немногих способов работать с данными в объектном ключе (классы, свойства, методы,
интерфейсы) и вызывать удаленные (в том числе на удаленных машинах) методы так, как
будто они находятся в одном и том же процессе. К тому же COM поддерживается очень
многими средами, это большой плюс. Про компоненты, которые пишутся на C++, а затем
дергаются из JScript или. NET, или используются в Office/1C, рассказывать не буду.
Если ничто из вышеперечисленного использовать нельзя (или не позволяет «религия»),
тогда остаются сокеты. Но это не самое лучшее решение. В двух словах — long path. Даже простейший вызов send, recv или connect на локалхост проходит длинную цепочку
вызовов, от уровня winsock вниз, через провайдеров сети, затем в ядро (AFD), потом в
стек TCP, где для него создаются I/O-запросы, выполняются ожидания, доставка APC и
прочее-прочее. И только пройдя этот «лабиринт» вызовов и часовых механизмов, данные
попадают в ожидающее приложение. Если на компьютере установлен какой-нибудь фаервол и
он настроен на фильтрацию локальных соединений (а такая опция есть у многих из них),
то картина будет еще более запутанной, а путь — еще более длинным.
Что касается WM_COPYDATA, то это вообще последний вариант, когда ничего другого не
остается. Здесь нет гарантии доставки, нет возможности отправить данные в ответ. Для обработки нужна оконная процедура. Сами сообщения летают только в пределах одного
десктопа, а на Windows Vista и выше «режутся» UAC-ом, например если их пытаются слать
от обычного процесса к процессу, запущенному в контексте администратора. А если
разрешить доставку (ChangeWindowMessageFilter), то всякое зловредное приложение
сможет делать то же самое. В общем, это и ненадежно, и неудобно, и несекьюрно.