Добрый вечер!
Ситуация следующая: в конторе где я работаю исторически использовалось 1C (и будет использоваться еще долго...), но параллельно с этим возник еще один тренд — перевод на linux всего что только можно (где не используется 1C) + использование Явы (ибо кросплатформенность+куча всего готового). При этом неизбежно встает вопрос интеграции 1C и самопального софта (кассы, система автоматического форирования доставок и т.д.). С 1Cv7.7 особых проблем не возникало (по крайней мере в плане вытаскивания данных): написал парсер DDS + макропроцессор и вперед — клепать к MSSQL запросы вида:

select $SC_НОМЕНКЛАТУРА.ТОВАР from $SC_НОМЕНКЛАТУРА

Неприятно, но терпимо. Была даже мысля сделать свой фальшивый JDBC драйвер: запрос->JDBC API->DDS->Реальный JDBC.
Но прогресс не стоит на месте и вот на горизонте замаячила восьмерка. DDS днем с огнем не сыщишь. Информация о метаданных храниться в блобе, пожатая непонятно чем (ни стандартный архиваторы, ни ZipInputStream, ни низкоуровневый Inflater не справились, хотя в самой 1C вроде бы используется zlib). Гугление тоже не помагает: на одном форуме упаминается этот самый блоб, а на других в основном советуют смотреть каким-то там трассировщиком реальные SQL запросы — но это можно использовать максимум чтобы посмтреть соответствие вручную (раз, два, три — но ведь НЕ ПОСТОЯННО!!) — никакой автоматизацией процесса здесь и не пахнет.
Связываться через COM особого желания нет:
1. В свое время поигрался с IBM'овским Java2COMBridge (работает но как-то через ж...)
2. Кроме того не факт что 1C и софтина, которой потребуются данные из БД 1C будут работать на одной машине и под одной ОС.
От безысходности появилась бредовая идя (на сколько реализуемая не знаю...):
1. Для сервера восьмерки пишется модуль расширения который висит на сокете, принимает запрос на внутреннем языке запросов 1C (если не получиться модуль расширения — можно вернуться Java2COMBridge).
2. Результат (если он есть) оформляется в виде:
<row>
<column name="col2">AAAA</column>
<column name="col2">BBBB</column>
</row>
и отдается по сокету.
3. На клиентской стороне работает самопальный JDBC драйвер, который посылает запросы, получает ответ и запихивает его в ResultSet (только вместо SQL — запросы на внутреннем языке 1C)

Кто-нибудь занимался подобной интеграцией?
Что можете посоветовать?
Не изобретаю ли велосипед на почве интеграции?

Егорище85А что вы понимаете под интеграцией? Если просто обмен данными, то чем вас не устроил XML? Если вам нужно из собственной программы получить какие-то данные из 1С (например отчеты сформировать), то можете подключиться по COM и работать уже с помощью методов 1С.

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

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

1. Не надо путать COM и DCOM, работать с COM удаленно не получится, не говоря уж том что часть софта будет работать под linux'ом. Единственный вариант поднять сервер на сокете (см. исходный пост) а уж из него дергать 1C через COM (с помощью запросов на внутреннем языке), но это звиздец...
2. Под интеграцией я понимаю возможность рассматривать 1C как еще один источник данных (СО СТАНДАРНТЫМ ИНТЕРФЕЙСОМ!), который можно без проблем встроить в существующую инфраструктуру и многкратно использовать не заморачивась на мелкие технические детали. В 7.7. с этим не было особых проблем (благодаря наличию DDS файла была возможность клепать запросы к MSSQL), а вот с восьмеркой попа... Щас думаю что делать...