
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
22.12.2009, 13:15
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Приветствую всех. У меня тут назрела одна задача, хочу попросить помочь принять решение. Итак..Заказчиком была поставлена задача комплексной автоматизации всех бизнес процессов. У заказчика есть большая самописная ИС, хранящая данные в СУБД ORACLE 11g. Самописная ИС охватывает только задачи учета зарплаты и кадров. Для бухгалтерии используется переписанная конфигурация 1С: бюджетка платформы 8.2 клиент-серверная на ORACLE. Встала задача синхронизации и обмена данными между базой 1С и таблицами Oracle самописной ИС. перечислю некоторые способы: 1. Напрямую в Oracle доступ к созданным 1с таблицам. Хотелось бы так сделать, по скорости способ будет быстрейший. Но тут множество проблем с постоянно меняющейся структурой таблиц 1с в СУБД. Да ещё и с авторскими правами 1с. Но по логике, зачем данные посылать куда-то, если все можно сделать внутри Oracle. 2. Обмен через выгруженные xml файлы с созданием плана обмена. проблемы-скорость, актуальность и т.д. 3. Написание обработки в 1с, загружающие данные через adodb или odbc встроенные в 1с. для больших объёмов данных-это неприемлемо. 4. Обмен через COM-соединение или OLE Automation. Каким образом посоветуете сделать интеграцию? может ещё есть способы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.12.2009, 18:41
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
1-й путь невозможен без нарушения лицензионного соглашения 1С ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.12.2009, 19:22
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
ARIST_A1-й путь невозможен без нарушения лицензионного соглашения 1С Здесь странная проблема, ведь лицензионное соглашение противоречит гражданскому кодексу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.12.2009, 19:25
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
а что за лицензионное соглашение такое, что нельзя напрямую к БДтаблицам обращаться? ARIST_A1-й путь невозможен без нарушения лицензионного соглашения 1С ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.12.2009, 23:00
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Алексей2003а что за лицензионное соглашение такое, что нельзя напрямую к БДтаблицам обращаться? ARIST_A1-й путь невозможен без нарушения лицензионного соглашения 1С http://v8.1c.ru/predpriyatie/questions_licence.htm#64 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.12.2009, 07:12
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Vitaly Rastashanskiy, В соглашении в основном речь об изменении и упор на недокументированные средства. С другой стороны "ПолучитьСтруктуруХраненияБазыДанных" вполне документирована, плюс статьи ИТС "Индексы таблиц базы данных", "Размещение данных 1С:Предприятия 8.1", "Размещение данных 1С:Предприятия 8.1. Таблицы и поля". Правда в ИТС явным образом указано, что не следует работать с данными "в обход" платформы. Я бы лично постарался организовать обмен через XML. Да, прямой обмен быстрее - достижимы скорости до дестяков тысяч записей в секунду, при обмене через XML (конечно не при стандартной схеме!) - даже в хорошо оптимизированном варианте имеет смысл рассчитывать лишь на 200-2000 записей в секунду, но вот стоимость поддержки первого варианта.... OLE-COM 1C по производительности сильно хуже, а использование ADO может быть частью варианта с планами обмена. Кстати, почему "adodb или odbc ... для больших объёмов данных-это неприемлемо"? Например есть задача: вычитать регистр сведений по определённым критериям (миллионы записей в таблице, вычитываются 10-200 тыс, размер строки на MS SQL - около 150 байт), перекинуть выбранные записи в таблицу удалённой БД MS SQL (не 1С), удалить переданные записи из регистра 1С. Производительность данной задачи - около 500 записей в секунду. Т.е. 200 тысяч записей перекидывается за 6-7 минут. Непосредственно исполнение команд ADO - около 25% (до 50% - удаление записей из 1С, около 20% - выборка данных). Задача масштабируется по сути линейно - всё работает под 1С 8.0, которая плохо работает с памятью, поэтому выборки более 500-700 тыс. записей могут приводить к аварийным сбоям, но скорость в общем-то не меняется. При этом есть резерв по оптимизации - перетащить всё с клиента на сервер предприятия, перейти на 8.1, перейти на загрузку через BULK INSERT, а не тупые INSERT, и еще некоторые (которые цепляют изменения других подсистем и потому пока не применяются). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.12.2009, 11:08
|
|||
|---|---|---|---|
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Вот мои пару вариантов. 1. Для связи с 1С создать интерфейсные таблички для входящих и исходящих данных (включая поля статуса обработки, дату insert-а и обработки). Средствами 1С настроить периодическую работу с этими таблицами. В Oracle, так понимаю, можно ходить напрямую. В той системе, откуда должны передаваться данные, сделать табличку событий - events(с ключиком события, его названием) и по периодическому опросу этой таблицы начинать обработку, передачу данных. 2. Связываться с 1С через их собственные интерфейсы. Вроде они даже предоставляют механизм веб-сервисов для этого. Мы делали как в п.1. При этом используем в качестве корпоративного стандарта интеграционную платформу IBM WebSphere Business Integration Server. Это "тяжелая" система, интегрирует еще порядка 10 других приложений. В вашем случае все интеграционное решение очень просто реализуется на Apache Camel . Camel обладает возможностью подсоединения к 70-ти различным типам сервисов, включая базы данных, веб-сервисы, те-же файлы и др. А также мощной поддержкой EAI-паттернов. Вот что желательно не делать, когда нужно связать несколько систем: 1. Не связывать БД напрямую друг с другом. Это "сильное" связывание приведет к проблемам при будущих модификациях. 2. По возможности, не использовать файлы вообще. 3. По возможности, не использовать синхронные вызовы, включая COM и OLE. По ходу дела подумайте, а есть ли у вас справочники, которые нужно синхронизировать между системами? Я — ярый противник местечковой интеграции и узкого подхода. Интеграция это всегда нетривиальная задача, которая кажется гораздо проще, чем есть на самом деле. pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2009, 08:00
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Спасибо большое за исчерпывающие ответы, теперь буду детализировать задачу, чтобы ясно представлять, какой объем данных будет двигаться между системами. Возможно можно будет обойтись xml обменом Кстати, почему "adodb или odbc ... для больших объёмов данных-это неприемлемо"? Например есть задача: вычитать регистр сведений по определённым критериям (миллионы записей в таблице, вычитываются 10-200 тыс, размер строки на MS SQL - около 150 байт), перекинуть выбранные записи в таблицу удалённой БД MS SQL (не 1С), удалить переданные записи из регистра 1С. Производительность данной задачи - около 500 записей в секунду. Т.е. 200 тысяч записей перекидывается за 6-7 минут. Непосредственно исполнение команд ADO - около 25% (до 50% - удаление записей из 1С, около 20% - выборка данных). Расскажите пожалуйста в двух словах, каким образом достигается такое чудо оптимизации?используется ли в догрузок xml как вы сказали, хранимые процедуры, вьюшки, или просто обычное connect и reader ADO? pilgr 1. Для связи с 1С создать интерфейсные таблички для входящих и исходящих данных (включая поля статуса обработки, дату insert-а и обработки). Средствами 1С настроить периодическую работу с этими таблицами. В Oracle, так понимаю, можно ходить напрямую. В той системе, откуда должны передаваться данные, сделать табличку событий - events(с ключиком события, его названием) и по периодическому опросу этой таблицы начинать обработку, передачу данных. 2. Связываться с 1С через их собственные интерфейсы. Вроде они даже предоставляют механизм веб-сервисов для этого. Мы делали как в п.1. При этом используем в качестве корпоративного стандарта интеграционную платформу IBM WebSphere Business Integration Server. Это "тяжелая" система, интегрирует еще порядка 10 других приложений. В вашем случае все интеграционное решение очень просто реализуется на Apache Camel . Camel обладает возможностью подсоединения к 70-ти различным типам сервисов, включая базы данных, веб-сервисы, те-же файлы и др. А также мощной поддержкой EAI-паттернов. Как стала задача, сразу открыл книгу "Шаблоны интеграции кис". Действительно, очень хотелось бы сделать всё "по науке" используя EAI-паттерны, я то же сторонник системного подхода. Но не получается пока представить себе как это будет применительно к задаче. Можете рассказать как это будет на каком нибудь маленьком примерчике любого бизнес-процесса, так как у меня нет опыта в таких "глобальных" задачах интеграции. И если использовать промежуточную прослойку в виде фраймворка (огромное спасибо за идею c Apache Camel) как это влияет на скорость? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2009, 11:38
|
|||
|---|---|---|---|
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Попробую прикрепить картинку с примером процесса передачи приходных накладных из ERP в 1С. Это довольно простенький процесс, который успешно эксплуатируется в нашей компании. Как я упоминал, у нас интеграция построена на IBM-овской платформе. Но этот же процесс на Apache Camel можно реализовать в виде вот такого простенького маршрута: Код: plaintext 1. 2. 3. 4. 5. Чтобы маршрут заработал, нужно еще немного дописать определения конечных точек, конфигурации к базе денных, маппинги между результатами селекта и java-объектом, и сам класс для трансформации сообщения из формата ERP в формат 1С. pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2009, 11:40
|
|||
|---|---|---|---|
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Вот собственно картинка процесса с использованием EIP-паттернов. Ничего особенного в ней нету. pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2009, 14:26
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
pilgrВот собственно картинка процесса с использованием EIP-паттернов. Ничего особенного в ней нету. Да, ничего такого. Но сложность в том, что в моем случае доступ к исходному коду ERP Oracle затруднен. то есть эта конечная точка должна проектироваться как шлюз обмена сообщениями. Но дело даже не в этом. Известно что, чтобы приложению связаться с системой обмена сообщениями, нужен некий клиентский API. Как связаться с Apache Camel? Не могу найти конкретного ответа в документации. То есть, принцип такой: некий код в ИС посылает данные в конечную точку, точка посылает сообщение, сообщение принимается "опрашивателем", преобразуется и посылается в другую конечную принимающую точку, где находится до того, как другая ИС не запросит данные. Или я неправильно понял? и конфигурации к базе денных, маппинги между результатами селекта и java-объектом, можно чуть подробнее про эти процедуры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2009, 15:00
|
|||
|---|---|---|---|
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Немного не так. Все гораздо проще. Достаточно лишь иметь доступ к базе данных Oracle и знать структуру таблиц. А Camel сам будет опрашивать таблицы и на основании селекта из базы формировать сообщение, содержащее полноценный Java-объект. За это все отвечает строчка Код: plaintext 1. 2. Видите, здесь прямо указывается интервал между селектами. Потом он сам сделает преобразование сообщения, и отправит его в 1С благодаря коду: Код: plaintext В общем, если у вас есть доступ к одной и второй базе данных, вы знаете структуру данных — остальное дело техники. Доступ к унаследованным базам данных удобно делать через camel-ibatis компонент, он и используется в примере. Посмотрите страничку этого компонента, там немного написано про его конфигурацию и показаны простые примеры. Сам же компонент это всего лишь удобная обертка над фреймворком iBATIS. Поэтому о всех ньюансах конфигурации можно прочитать в документации на iBATIS . В ближайшее время я планирую написать небольшой пример интеграции между парой БД с использованием Camel. Ссылку оставлю в этой ветке. pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2009, 16:44
|
|||
|---|---|---|---|
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Введение в Apache Camel, включая пример создания, разбора и запуска первого проекта — на http://integration-review.com/apache-camel-first-ride . pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.12.2009, 20:40
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Vitaly RastashanskiyРасскажите пожалуйста в двух словах, каким образом достигается такое чудо оптимизации?используется ли в догрузок xml как вы сказали, хранимые процедуры, вьюшки, или просто обычное connect и reader ADO? Ну там всё относительно просто. Есть обработка 1С, которая собственно всё перечисленное делает. Сценарий примерно такой Всё банально. Код примерно такой структуры: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 1. Не использовались возможности массовой загрузки MS SQL (Bulk insert, SQLXMLBulkLoad). Это бы дало реактивное ускорение, но были некоторые ограничения из-за которых в данной задаче они не использованы. 2. Команда ADO - обычный объект ADODB.Command, не возвращающий записи (еще и SET NOCOUNT ON) и не параметризованный, содержащий тупо кучку инсертов. Параметризованные запросы не позволяли передать корректно некоторые типы параметров и жутко тормозили на маршаллинге между COM и 1С. Но при этом сильно тормозят и пакеты с большим количеством инсертов, причем тормозят где-то на клиентской части (то ли их ADO парсит, то ли опять же на передаче). В общем у нас порция 20-100 инсертов оптимальной оказалась. 3. В таблице, куда инсертим индексов мало. 4. В обработке есть режим асинхронного выполнения команды ADO. См параметр adAsyncExecute. Т.е. команду запускаем, пока она колбасится - накидываем новые инсерты, ждём пока предыдущие выполнятся, запускаем новые. При асинхронной обработке отлаживать несколько сложнее. 5. При удалении записей в 1С всё выполнение идёт на сервере приедприятия. При удалении данных (удалении эл-та справочника или удалении набора записей регистра, например) всё равно передаётся выполнение на сервер, и если таких операций много, то нужно обратить внимание, что нет лишних блужданий с клиента на сервер и обратно. Кстати, фоновые задания именно из-за того что выполняются только на сервере выполняют такие задачи достаточно эффективно. 6. При создании больших строк есть проблема того, что в 1С нет аналога StringBuilder. Это лечится нетрадиционным использованием встроенных объектов 1С :) ЗаписьXML умеет строить XML в строку, а не в файл, при этом умеет в эту строку вставлять произвольный текст не имеющий отношения к XML. Короче, ничего сверхъестественного. Цифры даны наиболее типичные (могут гулять в несколько раз). Проценты в коде указывают примерное время выполнения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.01.2010, 12:45
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Для связи баз использовал большинство мыслимых вариантов (1С+Ассеs, 1С + 1С, 1С + Ёксель|Ворд, 1С + МС СКЛ, 1С + что-то на дельфях писанное и прочее). Связи один ко многим базам. Поэтому свои 5 копеек: - Через XML долго, не гибко и разработка не на много быстрая. - На прямую связь быстро, разработка средняя, но очень проблематичные грабли при глобальном изменении. Хоть как разрабатывай, отслеживать надо все конечные базы. Если писать на прямую в таблицы 1С - сочувствую. Там куча обработок, кода, и всякого хлама. Это не просто таблицы - Через прочие файлы (не XML) и разрабатывать долго и работает только, когда однопользовательский поток данных. - Через промежуточный SQL получилась самая оптимальная система и по производительности и по доработке и по масштабируемости. Сам SQL очень надежный (не то, что файлы) и является своего рода призывным пунктом в армии: вроде на прямую быстрее, а на практике наоборот. В общем я хотл сказать автору, что бы рассмотрел вариант с промежуточным хранилищем, если объем данных большой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.02.2010, 12:02
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Enot5467 - Через промежуточный SQL получилась самая оптимальная система и по производительности и по доработке и по масштабируемости. Сам SQL очень надежный (не то, что файлы) и является своего рода призывным пунктом в армии: вроде на прямую быстрее, а на практике наоборот. Что Вы конкретно имеете ввиду под промежуточным SQL? ПО самописное или специализированное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.02.2010, 12:26
|
|||
|---|---|---|---|
|
|||
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Попробовал протестировать самый простой способ:синхронный доступ с помощью ADO. Результаты неудовлетворительные. В силу довольно больших объемов данных, изза специфики предметной области, когда справочники и документы, как ни странно изменяются и довольно часто добавляются. Причем обращения и запросы к бд Oracle, сведены к минимуму, созданы вьюшки, повторяющие структуру данных 1с,созданы несколько хранимых процедур, которые возвращают только измененные записи с какого момента времени, созданы триггеры для заполнения специальной таблицы событий. Так что запрос ADO - простой селект, или запуск хранимой процедуры. Так что видимо, придется все таки использовать промежуточное ПО. Поэтому я хотел уточнить относительно Apache Camel: 1.Возможно ли организовать работу фраймворка с очередями MSMQ, посылку сообщений туда?в силу того,что в 1с довольно развиты средства работы с MSMQ. То есть я знаю, что компонент Apache Camel такой есть,но как на практике.. 2. Какой объем знаний и навыков необходим для разработки и сопровождения Apache Camel. Я, конечно догадываюсь, но хотелось бы систематизировать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.02.2010, 12:28
|
|||
|---|---|---|---|
Интеграция Oracle и 1С:Предприятие 8.2 |
|||
|
#18+
Vitaly RastashanskiyEnot5467 - Через промежуточный SQL получилась самая оптимальная система и по производительности и по доработке и по масштабируемости. Сам SQL очень надежный (не то, что файлы) и является своего рода призывным пунктом в армии: вроде на прямую быстрее, а на практике наоборот. Что Вы конкретно имеете ввиду под промежуточным SQL? ПО самописное или специализированное? Как я понял промежуточный таблицы и пакеты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=28&mobile=1&tid=1522754]: |
0ms |
get settings: |
12ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
220ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 268ms |
| total: | 587ms |

| 0 / 0 |
