Шина обмена данными 1с
Обновлено: 06.07.2024
Фирма "1С" объявляет о начале продаж с 13.07.2016 инструментального пакета
"1С:Интеграция 8" (редакция 1.2), реализованного на технологической
платформе"1С:Предприятие 8".
Продукт разработан совместно фирмами "1С" и "ЮнисЛабс Солюшинс".
Инструментальный пакет "1С:Интеграция 8" предназначен для решения задач
интеграции данных и приложений в гетерогенных информационных средах.
Применяется как средство управления обработкой информации при решении
задач:
- интеграции корпоративных учетно-информационных систем;
- построения единых информационных сред и единых систем
нормативно-справочной информации;
- обеспечения интеграции данных;
- создания приложений сервис-ориентированной архитектуры.
эээ ничего не понял. По описанию похоже на консолидацию.
Какая-то вода, кто-нибудь может простыми словами сказать что это и нафига?
(2) наверное спрос будет таким же как и на бизтолк в Росссии
(12) УХ и 1С:Интеграция 8 продукты совершено не связанных классов
Одно событие, один получатель - обмен данными по БСП.
Одно событие, много получателей - шина данных.
Только БСП за цену ИТСа, а шинная поделка на 1С полляма?
я так и не понял, если это нечто вроде КД для обменов, то откуда такой ценник? 480000 за прослойку между базами? да за такие деньги лучше свое написать
Ну свое за такие деньги не напишешь, просто кому это нужно.
(18) не напишешь за пол ляма свой обмен? вполне напишешь, хоть свой, хоть на той же КД. Другое дело, что может это что-то иное нежели обмен
(22) У них в контактах в US версии внезапно адрес появляется:
Address in US
295 Madison Avenue, 12th floor, New York, NY, 10017
Phone
1 646 832 69 17
Такое ощущение, что продукт - типичная липа для отмыва бабла. Наверное под какой-то аукцион подогнали, с потолком до полумиллиона рублей.
(30) Или в рамках импортозамещения. Типа отечественное ПО
И если это теже писатели что внутренний софт в ПФР пишут. там качества ниже чем в типовых от 1С
(30) (31) Боюсь раз на волне импортозамещения 1с пошла в госструктуры, увязнет она во всякого сорта откатинге и распилинге. Бюджет поделят, а потом скажут что это программа плохая .
(34) А ниче, что ты полностью переиначил смысл заявления Грефа своей выдернутой из контекста фразой?
(35) А можешь раскрыть истинный смысл слов Грефа?
Программа «Централизация 2.0» Сбербанка по переводу всех территориальных банков на единую IT-платформу стартовала в 2011 году и была завершена летом 2015 года. В одном из выпусков газеты для сотрудников «Сбербанк-Технологии» «СБТ Vision» главный архитектор IT Сбербанка Андрей Хлызов сообщал, что бюджет программы составляет более $1 млрд (по состоянию на сентябрь 2013 года).
Греф рассказал, что в ближайшее время Сбербанк полностью поменяет свою платформу. «Все процессы должны быть перестроены. Нам нужно вывернуть себя наизнанку, мы абсолютно не готовы к этому. Нам нужна гибкая платформа, не такая огромная, как сегодня. Если мы сейчас меняем какую-то часть своей платформы, нам нужно два-три месяца тестировать. Непонятно, где и что вылезет при этом. Это катастрофа», — сказал Греф.
надо смотреть, как там чего сделано, насколько сильно надо будет кастомизировать при реальных внедрениях. И насколько это легко сделать. Да и нужно ли - может там всё гибко гибко )
А так - вещь необходимая в соответствующих проектах.
Например, мы такое делали и делаем при интеграции 1С с интеграционной шиной Заказчиков.
"Механизм идентификации обеспечивает однозначное определение принадлежности поступающей в ИТП информации к определенному экземпляру процесса обработки
ну вот, вроде и мэппинг есть какой-то и технология ответных квитанций тоже есть
а вообще, если такие продукты выходят под лейблом 1С - это значит, что 1С приходит так или иначе в крупные организации
ибо продукт как раз для интеграции 1С с чем-то типа интеграционных шин
(41) ну, я к тому, что если есть потребность в интеграции 1С и интеграционной шины, то у конторы значит уже есть шина
а вот они стоят очень немало (от IBM, например), их ставят только кровавые ынтерпрайзы себе (есть, правда, типа бесплатные - но это отдельная тема )
то есть, эти ынтерпрайзы начинают внедрять у себя те или иные 1С-решения и встраивать их в свои шины
либо это вообще полноценная шина!
вместо IBM MQ!
думаю, для небольших внедрений, да, можно будет использовать как самостоятельную шину
(43) это полноценная шина , практически бесплатная и для средних темпов свопа должна подойти
Описание по ссылке - какой-то невразумительный поток сознания. У книг иной раз такие аннотации бывают: прочёл аннотацию и пропадет желание покупать саму книгу.
По наитию - похоже на шину данных. Но принципы работы и синхронизации как-то остались за кадром.
Знаю компанию, где сделали доморощенную шину данных для УПП на MS SQL. Ребята подошли к делу скрупулёзно: каждый реквизит каждого приложения на платформе 1С описали, и любая новая интеграция сначала пропускается через матрицу этих реквизитов, после чего становится сразу ясно "чего в супе не хватает". Недостающие реквизиты добавляются в шину данных и их начинают видеть остальные приложения. Соответственно, любой реквизит любого приложения становится доступен в любом ином приложении.
Что-то мне подсказывает, что если бы описание по ссылке было хотя бы на таком уровне, то обсуждение в этой ветке бы более продуктивной, да и клиентов бы тоже прибавилось.
Общие соображения
С развитием стандартов веб-сервисов ("сервисы") появилась идея организации универсального промежуточного ПО основанного на сервисах и являющегося универсальным фундаментом, позволяющим связывать и координировать работу разнообразных приложений и систем в сервис-ориентированной архитектуре.
Таким образом получаем модульную среду, позволяющую объединить самые разные компоненты и системы. Однако не стоит идеализировать ESB, как и в любом другом ПО там могут быть свои собственные ошибки, например, в ранних версиях OpenESB где-то в глубине вылетал NullPointerException при попытке вызвать сервис на Mono и усе, кина не будет.
Схема работы
Основная идея уже всплывала в комменатариях к предыдущей статье: сделать универсальный windows сервис, который будет приземлять вызовы на 1С через COM. Собственно схему работы всей конструкции можно выразить одной строкой:
? <-n SOAP n-> OpenESB <-1 SOAP 1-> OneCService(WCF) <-1 COM n-> 1С
где ? - произвольные внешние системы, в примере их роль играют тесты
OneCService - собственно сервис, разработанный в рамках данного примера
в угловых скобках указаны способы взаимодействия и отношения
Такая схема позволит не вносить серьезных изменений в конфигурацию, а кроме того, получть универсальный механизм, в котором один промежуточный сервис позволяет взаимодействовать с разными базами 1С. В данном пример будет реализовано только взаимодействие с файловыми версиями, для взаимодействия с серверными версиями надо будет просто изменить механизм формирования строки соедиения для V8.Application и добавить дополнительные методы в интерфейс сервиса.
При этом, чтобы обеспечить универсальность, интерфейс сервиса должен содержать методы, позволяющие эффективно осуществлять все наиболее распространенные типы действий. В примере этими действиями будут: выполнения запроса и получения результата, выполнения скрипта на языке 1С и получение результата, а также - вызов произвольного метода с передачей параметров и получением результата. Также необходимо обеспечить возможность передачи сложных типов.
Инструментарий
В качестве инструментов для создания примера понадобятся:
Тонкости с типами
Забегая вперед, рассмотрим один тонкий момент: при любом взаимодействие всегда надо обеспечить передачу данных в формате, понятным обеим сторонам. В 1С большую часть работы в этом плане за нас сделает СериализаторXDTO. Но есть ряд тонкостей:
1. Получение информации о принадлежности данного конкретного значения тому или иному типу.
Казалось бы все просто, все пользовались ТипЗнч(<значение>), но попробуйте выполнить простую строку:
ТипЗнч("ЙЦУКЕН");
ой, а это что такое:
Встроенная функция может быть использована только в выражении. (ТипЗнч)
ТипЗнч<>("ЙЦУКЕН");
при попытке вызвать ее через COM эффект будет не лучше.
Вот почему не получится полностью обойтись без модификации конфигурации, хотя типы можно получить и из результата запроса:
ВЫБРАТЬ 1, "А", Истина, Дата(1,1,1)
в этом случае доработка не требуется.
2. Отсутствие сериализации в XML универсальных коллекций штатными средствами.
А ведь так хочется сделать метод, который бы возвращал/принимал массив чего-то там, и дергать его из внешней системы.
Значит нужно обеспечить как минимум распознавание простых типов и универсальных коллекций (массив в данном примере) и их сериализацию/десериализацю. Со сложными типами проще - с элементом какого-нибудь справочника вполне управятся и штатные средства. При этом надо внести лишь минимальные дополнения в конфигурацию. Информация о типах потребуется в двух основных случаях - при формировании информации о типах колонок в ResultSet'е и при определении того, что значение относится к универсальной коллекции, все остальное будет отправляться в СериализоторXDTO.
При этом в примере реализовано сразу несколько способов определения типов, например, определить тип колонки в результате запроса при наличии образцов типов можно так:
public Type GetColumType ( int _index )
<
object currentType = GetProperty (
Invoke ( GetProperty ( result , "Колонки" ), "Получить" , new object [] ),
"ТипЗначения"
);
try
<
if (( bool ) Invoke ( currentType , "СодержитТип" , new object [] ))
<
return typeof ( double );
>
else if (( bool ) Invoke ( currentType , "СодержитТип" , new object [] ))
<
return typeof ( string );
>
else if (( bool ) Invoke ( currentType , "СодержитТип" , new object [] ))
<
return typeof ( bool );
>
else if (( bool ) Invoke ( currentType , "СодержитТип" , new object [] ))
<
return typeof ( DateTime );
>
else
<
return null;
>
>
finally
<
Release ( currentType );
>
>
В качестве примера использования, рассмотрим метод, возвращающий значение по индексу колонки, преобразованное в нужный формат:
public object GetValueByIndex ( int _index )
<
if ( GetColumType ( _index ) == null)
<
object o = Invoke ( resultSet , "Получить" , new object [] );
o = GetObjectByRef ( o );
return OneCObjectToXML ( o );
>
else
<
return Invoke ( resultSet , "Получить" , new object [] );
>
>
Как видно из кода, все довольно просто: определяется тип, если он примитивный, то значение возвращается как есть, а если нет - вызвается метод сериализующий значение в XML, рассмотрим его:
public XmlElement OneCObjectToXML ( object _o )
<
if ( IsArray ( _o ))
<
XmlDocument doc = new XmlDocument ();
XmlElement arrayElement = doc . CreateElement ( OneCServiceArrayElement );
doc . AppendChild ( arrayElement );
int count = ( int ) Invoke ( _o , "Количество" , new object [] <> );
for ( int i = 0 ; i < count ; i ++)
<
object item = Invoke ( _o , "Получить" , new object [] );
if ( item ! = null)
<
XmlElement itemElement = doc . CreateElement ( OneCServiceArrayElement + "-item" );
arrayElement . AppendChild ( itemElement );
XmlElement itemValueElement = OneCObjectToXML ( GetObjectByRef ( item ));
itemElement . AppendChild ( doc . ImportNode ( itemValueElement , true));
>
>
return doc . DocumentElement ;
>
else
<
object writeXml = Invoke ( connection , "NewObject" , new object [] "ЗаписьXML" > );
try
<
Invoke ( writeXml , "УстановитьСтроку" , new object [] <> );
Invoke ( xdtoSer , "ЗаписатьXML" , new object [] );
//Заполнем буфер текстом xml представления 1с'овского объекта
string xmlString = ( string ) Invoke ( writeXml , "Закрыть" , new object [] <> );
using ( StringReader sr = new StringReader ( xmlString ))
<
XmlDocument doc = new XmlDocument ();
doc . Load ( sr );
return doc . DocumentElement ;
>
>
finally
<
Release ( writeXml );
>
>
>
Как видно из кода, зесь же происходит обработка ситуации, когда надо сериализовать универсальную коллекцию.
Также в примере используется и другие способы определния типов (вплоть до использования "is"), какой из них лучше - вопрос спорный.
Реализация
Ну а теперь, не отвлекаясь, можно рассмотреть собственно сервис. Начнем с интерфейса:
[ ServiceContract ( Name = "onecservice" , Namespace = "http://onecservice" )]
public interface IOneCWebService
<
[ OperationContract ( Name = "ExecuteRequest" )]
ResultSet ExecuteRequest ( string _file , string _usr , string _pwd , string _request );
[ OperationContract ( Name = "ExecuteScript" )]
ResultSet ExecuteScript ( string _file , string _usr , string _pwd , string _script );
[ OperationContract ( Name = "ExecuteMethodWithXDTO" )]
ResultSet ExecuteMethodWithXDTO ( string _file , string _usr , string _pwd , string _methodName , XmlNode [] _parameters );
>
Как видно из кода, данный интерфейс обеспечивает сервису заявленную универсальную функциональность: выполнение запроса, выполнения скрипта, и выполнения метода с параметрами, которые могут быть сложными типами. Также все методы возвращают универсальный результат, расммотрим его:
public class Value : IXmlSerializable
<
private XmlNode anyElement ;
public XmlSchema GetSchema ()
<
return null;
>
public void ReadXml ( XmlReader reader )
<
XmlDocument document = new XmlDocument ();
anyElement = document . ReadNode ( reader );
>
public void WriteXml ( XmlWriter writer )
<
anyElement . WriteTo ( writer );
>
>
[ DataContract ( Namespace = "http://onecservice/types" )]
public class Row
<
private List < XmlNode > values = new List < XmlNode >();
[ DataContract ( Namespace = "http://onecservice/types" )]
public class ResultSet
<
private List < string > columnNames = new List < string >();
private List < string > columnTypes = new List < string >();
private List < Row > rows = new List < Row >();
private string error = "" ;
Рассмотрим также изменения, которые необходимо внести в конфигурацию 1С:
Функция ПринадлежитТипу ( значение , тип ) Экспорт
Возврат тип = ТипЗнч ( значение );
КонецФункции
Функция ВыполнитьСтроку ( стр ) Экспорт
результат = Неопределено;
Выполнить стр ;
Возврат результат ;
КонецФункции
Две базы 1С с соотвествующими изменениями в конфигурации и тестовым справочником приведены в архиве.
Таким образом у нас есть адаптированная конфигурация 1С и сервис, через который к ней можно достучаться откуда угодно. Собственно, результаты полученные на данном шаге уже имеют самостоятельную ценность, так как позволяют, например, выполнить запрос аля ВЫБРАТЬ * Из . откуда угодно, например из веб приложения написанного на RoR'е.
Переходим к созданию так называемого композитного приложения, которое будет развернуто в OpenESB. В данное приложение будет входить один BPEL модуль, в котором будут располагаться несколько BPEL процессов, каждый из которых будет иллюстрировать работу с тем или иным методом сервиса OneCService. Там же будут располагаться wsdl, описывающий интерфейс OneCServic'а, а также wsdl'и описывающие точки входа BPEL процессов и xsd, описывающите типы данных. В композитном приложении будут созданы несколько тестов, которые сводятся к формированию запроса к тому или иному BPEL процессу и проверке на ожидаемый результат. Такая организация позволит разбить приложение на несколько небольших и понятных частей. Рассмотрим примеры этих частей более подробно.
В качестве примера BPEL процесса рассмотрим процесс, выполняющий запрос к 1С и возвращающий его результат, упакованный в ResultSet:
Множество модулей и сервисов, объединенных в одно композитной приложения образуют сборку сервисов:
Теперь рассмотрим более сложный пример в комлпексе - обмен данными между двумя базами 1С. BPEL процесс имеет вид:
Как видим, здесь происходит сначала обращение к первой базе 1С ("ПолучитьСотрудников"), а потом ко второй ("ЗаписатьСотрудников"). Данные передаются в массиве, также здесь выполняется XSL преобразование чтобы извлечь массив из ResultSet'а, полученного в результате обращения к первой базе, для его последующей передачи во вторую базу.
Что можно улучшить
1. Добавить поддержку SQL баз.
2. Попытаться реализовать в поддержку транзакции средствами WCF и их приземление на 1С (не знаю насколько реально).
3. Возможно стоит переработать ResultSet.
4. Сделать возможность приземлять в 1С произвольные типы, объявленные во внешних схемах, добавленных в "Пакеты XDTO".
1C 8.2, Linux и Native API
P. S. Как обычно, жду конструктивной критики и вопросов. А вообще, чем больше копаю, тем больше прихожу к выводу, что "адынэс рулЕз" :)
Интеграция 1С в экосистеме
Требования:
большие объемы данных
оперативная выгрузка с минимальной задержкой
возможность принимать данные в нескольких потоках
Сейчас в 1С популярны способы интеграции:
синхронизация данных XML
ODATA соединение к базе 1С
Каждый из этих способов хорошо подходит для решения определенных задач, но не в нашей ситуации. Коротко опишу почему.
Еще одной причиной неэффективности таких способов является то, что мы не сможем выполнять оперативную выгрузку данных с минимальной задержкой. Эти способы не смогут обеспечить мгновенное получение данных из систем.
Когда данные не только передаются, но и обрабатываются множеством клиентов, которые называются подписчиками (consumers).
Давайте перейдем к практике создания простого приложения на 1С для обмена данными. План создания архитектуры интеграции посредством Kafka будет следующий.
сначала напишем библиотеку DLL для установки соединения
чтобы стать подписчиком (consumers) и слушать топик на наличие новых данных, мы создадим «бессмертное» фоновое задание
для отправки данных в топик (producer) мы сделаем подписку в 1С на запись объектов, для мгновенной отправки
Поднять и настроить сервер Kafka не сложно, в интернете достаточно необходимой информации.
В этой библиотеке основные методы это:
для чтения данных: ConsumerCreate(), Consume(), ConsumeClose()
для отправки данных: ProducerCreate(), SendProducer(), ProducerClose()
Теперь напишем фоновое задание с «бессмертным» циклом для непрерывного чтения данных:
Думаю, в этом коде ничего сложного, мы создаем экземпляр библиотеки DLL в коде 1С и пользуемся его методами.
Так мы обеспечили мгновенную отправку данных с базы А при записи объекта и мгновенное чтение в базе Б.
В итоге мы применение нашей шины в таких проектах, как: MDM (быстрое согласование и контроль данных), DWH (сбор структурированных данных), CRM (быстрое согласование заявок).
При интеграции корпоративных систем возникает задача управления справочными данными. Для решения этой задачи часто используется Master Data Managment(MDM). MDM — это хранилище, которое содержит “эталонные” справочные данные, так называемые “золотые записи”. Справочники в MDM содержат очищенные полные и непротиворечивые данные.
Часто MDM используется как платформа для централизованного ведения справочников. Ввод и валидация справочных данных производится в MDM, а оттуда они реплицируются в IT-системы. Такой подход имеет несколько проблем
- Создать эталонную модель данных, которая подойдет всем системам не так-то просто.
- Справочные данные становятся оторванными от приложений.
- Репликация данных из MDM часто требует серьезной доработки систем. Для систем “из коробки” такая доработка может быть очень дорогой.
Трансформация на интеграционной шине.
Данные о том, как справочники мапируются между системами хранятся в реляционной базе данных, в нашем случае — Oracle. В таблицах будет записано, как из значения справочника в одной системе получить значение в другой системе. То есть какая-то такая структура:
(source_system, source_value, valid_from, valid_to, target_system, target_value)
Данные в справочниках меняются очень редко, а используются очень часто. Чтобы не обращаться каждый раз к базе данных, справочники кэшируются на шине, причем в формате, который шина может сразу использовать.
Для кэширования мы используем Oracle Coherence. Это очень и очень платный продукт. Однако, в данном случае все его мега-функции не используются, поэтому его вполне можно заменить на бесплатное решение (например, hazelcast). Подробнее про coherence можно прочитать здесь. Также лицензия на coherence входит в различные Oracle Suite.
Использования кэша имеет очевидные преимущества:
- данные хранятся в памяти
- данные хранятся в сериализованном виде
- данные могут быть проиндексированы
- синхронизация с базой данных может быть проведена асинхронно
Кэш является распределенным и синхронизация между узлами производится самим Coherence. При добавлении или удалении сервера кластер производит ребалансировку данных между узлами.
Для справочных данных используется схема Distributed Cache Map. Во время старта Oracle Service Bus создается кэш внутри JVM, который держит данные в памяти. На каждом физическом сервере имеется coherence сервер, который хранит справочники (в памяти и на диске) и синхронизируется с базой данных.
При трансформации osb workflow обращается к coherence через Java callout. Можно также обращаться через вызов Enterprise Java Bean.
Читайте также: