mazzy andycppКасательно создания своего адаптера - работы будет много
В общем ответ:
1. стандартного адаптера нет
2. свой писать дорого
3. поэтому преимущества от использования связки "BizTalk <-> 1C" очень эфемерны
Приходилось нам "скрещивать" этих "ежа" с "ужом"... правда, обошлось без собственных адаптеров, вполне хватило и стандартных (FS, SOAP).
Активно использовались средства т.н. "универсального обмена данными" из набора внутреннего API 1С 8-рки.
В частности, этот "зверь" может выгружать/загружать пользовательские объекты 1С (элементы справочников, документы, регистры и т.д.) в/из XML-файлы(-ов), в том числе и складывать их по выбору: либо в файловые "шары", либо даже на FTP-узлы (при известной доле "въедливости" разработчика можно даже задействовать COM-компоненты для складывания/считывания в/из MSMQ, но у нас до этого руки так и не дошли).
На строне BizTalk-а работал обычный "мессаджинг", который мониторил "ресив локейшн"-ы на этих файловых "шарах" (или виртуальных каталогах FTP-узлов) и запускал обычные "оркестровки" по распихиванию всего полученного в SQL-ные базы для OLAP-анализа.
Для обратной связи (ERP -> BizTalk -> 1C), т.е. для впаривания "внешних" объектов в 1С (тех же элементов справочников из баз НСИ) использовались веб-службы на стороне 1С-ки, реализованные с помощью т.н. "web-расширения 1С" (стандартный 1С-овский набор .NET "врапперов", реализующий "1С-овский" ADO.NET Data Provider: V8DbConnection, V8DbCommand и все-такое), которые BizTalk дергал через стандартные SOAP-порты.
В принципе, на любом уровне ничего сложного нет, но были и "затыки", например - при описании схем XML-документов, которые приходили от 1С-ки (ейного "универсального обмена данными", бл*) долго пришлось колупаться с "нейм-спейсом" по-умолчанию... (у них, сцуко, любой объект имеет корневой элемент с атрибутом xmlns="", а BizTalk такие "вольности" не может переварить, ему подавай схему документа с явным указанием "нейм-спейса", как-то побороли, уж и не помню как именно).
Вобщем, без собственных адаптеров вполне можно жить, главное - хорошо представлять себе возможности обеих сторон и, безусловно, задачи, которые они должны решать...

mazzy...
Вы выгружали в OLAP только 1Совские данные?
...

В разные периоды времени - по-разному... у нас 1С-кой заменяли(-или?) Legacy System, поэтому в разные периоды времени доля данных из LS/1C распределялась типа так: 90%/10% -> 70%/30% -> 50%/50% -> 20%/80% -> ... (когда стало ~ 5%/95% - я просто ушел), теперь, наверное, "они" имеют 0%/100%.
mazzy...
А что делали с guid'ами?
...

Да ничего не делали, guid'ы - они и в Африке guid'ы, пусть их даже 1С-ка генерит "не по правилам", нам это не мешало.
mazzy...
Была ли необходимость смержить 1Совские и данные из других систем? По какому ключу предлагаете это делать?
...

Судя по ответу на первую цитату - необходимость была, но предлагать я тут ничего не берусь, т.к. не представляю себе задач, которые вы "имеете ввиду", задавая этот вопрос...
Если говорить про наш случай, то в OLAP-базе ключи на все размерности у нас были "собственные" (те же guid'ы), равно как и структура (иерархия) размерностей, удобная для анализа на уровнях топ-менеджеров, данные из 1С-ки (или любой другой OLPT базы) "мапились" на эти ключи в явном виде, т.е. что не было "замаплено" заранее - попадало в ветку "не определено" и специальный человек "резолвил" это с некоторой периодичностью...
При трансляции НСИ в базы 1С по подразделениям, она сначала вводилась в "самую главную" 1С в центральном офисе, а оттуда уже с "неправильным 1-С-овским guid'ом" попадала в базы 1С подразделений... ("универсальный обмен данными" позволяет всовывать объекты с уже готовым 1С-овским guid'ом).
Сам я не большой специалист по 1С, но ребята, которые на этом специализируются, говорили мне когда-то, что вполне возможно впихнуть в ИБ 1С и настоящий "правильный" guid, сгенеренный стандартными средствами Винды... Я лично не пробовал... (за что купил, за то и продаю), хотя, чтобы попробовать надо написать всего-лишь 3-4 строчки кода на 1С-L: выгрузить к-л объект в XML, подменить в нем ссылку (Ref="xxxx-yyyy-.....") на "правильный" guid и сохранить новый объект в ИБ на базе этого XML. Сложность такой "проверки" в том, что даже если 1С-ка и сохранит такой объект с "левым" для нее guid'ом, то еще не факт, что это пройдет безболезненно для дальнейших манипуляций с этим объектом в ходе жизненного цикла системы/приложения... (поэтому до таких "глобальных" проверок руки обычно тоже не доходят).

DolterПо поводу "правильности" гуидов:...
в итоге получаем гуид, сформированный по правилам 1С (для v8.x)
Не-е-е-е, сдается мне, что все не так просто "у нее внутре", чтобы можно было тупо, переставив байтики местами, получить из "обычного" guid'а "1С-овский"...
Насколько мой "пытливый ум" успел заметить, 1С-ка для каждого типа своих объектов (в зависимости от состава объектов в "конфигурации") генерит на определенных местах ("секциях") "своего" guid'а вполне определенные значения, которые сквозняком одинаковые для всех объектов данного типа (по крайней мере для документов я наблюдал это лично), т.е., не привязываясь к метаданным конкретной "конфигурации", в общем виде нельзя сгенерить "правильный" 1С-овский guid для объекта, который вы хотите вкрячить "извне" 1С-ки...

mazzy зашел на огонек"мапились"
... и специальный человек "резолвил" это с некоторой периодичностью...
А... Блин, неспортивно как-то... Но тоже выход
Гы-гы, мы когда на "Платформе-2005" услышали как "украинские пивовары" пользуются "маппингом" тоже сначала подумали - "неспортивно"...
Зато потом, когда все было реализовано, опыт ("сын ошибок трудных") показал, что это - единственный офигительнейший способ развязать руки разработчикам OLAP в деле удовлетворения всевозможных "прихотей" топ-менеджмента (то им так хочется разделить "кусок пирога", то эдак... то одну иерархию по продукту, то другую... то "укрупняют" региональное деление филиалов, то "разукрупняют"... и т.д., доходило даже до того, что у разных топ-ов было разное "видение" структуры иерархии клиентов и ни один не хотел уступать другому).
Реплицировать всю эту "аналитику" на OLTP приложения, чтобы факты "на местах" изначально привязывались к ней - полный и бесперспективный геморрой... (проходили уже).
А тут - собрал все факты по ключевым размерностям (период, продукт, клиент, филиал, дальше даже фантазия не простиралась), "замапил" их на 25-30 иерархий, которые каждый "топ" сам себе выдумал - и наслаждайся "крутостью" OLAP-технологий...
Ну да, есть некоторая потеря времени на поддержку "маппингов", но (опять же - из опыта) - по сравнению с геморроем согласования ключей из разных систем и репликации аналитик по источникам OLTP данных это просто "цветочки"...