Проект хранилища на MS SQL Server, интеграция с 1С 7.7 и автоматизация разработки в SSDT

[@epee]

Для повышения скорости отката при сбоях, а вернее для отсутствия необходимости в нем, есть вариант с ротацией БД, когда рядом с основной БД создается копия и начинает пополняться без всяких транзакций. Если пополнение прошло успешно, то копия переименовывается в основную либо остается нетронутой, в случае ошибки. (Разумеется, если на сервере достаточно места)

а снепшоты базы для этой цели не думали использовать?
правда у варианта со снепшотом есть минус — в случае неудачного деплоя, вам основную базу надо из снепшота восстанавливать, но если изменений немного — то восстановление из снепшота происходит быстро, создается снепшот очень быстро по сравнению с созданием копии. вариант снепшотов не подходит для если вы деплоитесь на базу которая работает 24\7, но если есть окно обслуживания, то вариант со снепшотом вполне себе рабочий

[@rt001]

Вы обозначили обе причины, по которым мы не используем снимки )))

[@uaggster]

Просто из любопытства вопрос:
А почему было не реализовать средствами 1С (ну, или, скажем так — 1С + что-то) на филиале выгрузку в некую промежуточную структуру, например — xml файл, а на уровне хранилища — загрузку из типового xml файла? Ну хорошо, версионированного файла.
Да, для каждого филиала выгружалку придется писать и поддерживать индивидуально, но вы в любом случае это делали.
И никакого безобразия с монструозными SSIS пакетами с замудрённой логикой на уровне хранилища — нету. Каждый отдельный кусок замечательно тестируется и обкатывается (и загружается) — индивидуально.

[@rt001]

Может, я не понял вопроса… Но кажется причина была описана

Первая проблема заключалась в том, что у 1С77 нет никакого сервера приложений или другого дЕмона, позволяющего взаимодействовать с ней без запуска платформы. Кто работал с 1С77 -знает, что у нее нет полноценного консольного режима. Можно запустить платформу с параметрами и даже что-то выполнить на их основе, но консольных параметров очень мало и цель их была в другом. Но даже с их помощью можно наколхозить целый комбайн. Однако она может непредсказуемо вылететь, может вывести модальное окно и ждать, пока кто-то нажмет ОК и прочие прелести. И, пожалуй, самая большая проблема — скорость работы платформы оставляет желать… Поэтому решение тут только одно — прямые запросы в БД 1С.

Поэтому выгрузка из самой 1С даже не рассматривалась.

(ну, или, скажем так — 1С + что-то)

Если прямые запросы запускать на стороне филиала с помощью чего-то еще, то какая разница, будет этим «что-то» какой-то другой продукт или SSIS?
Монструозность можно было бы уменьшить (не избежать), если использовать те функции, что есть в конфигурации 1С, написанные на языке 1с, позволяющие добраться до документа основание или еще что-то, но это противоречит первому условию
Всё это множество переходов и условий в SSIS появились не из-за прямых запросов, а из-за большого числа сущностей, которые в хранилище нужно слить воедино. Для каждого XML файла пришлось бы делать то же самое — как минимум один компонент на файл, если файлов десятки, то и компонентов десятки, вот они уже и на экран не умещаются. Однако в случае с файлами нужно было бы обеспечить их транспорт, а это еще один сервис. Ну не в шару же их выкладывать.
Плюс логика обработки самих файлов — какой период в них лежит? А есть ли предыдущая версия файла рядом? В какой последовательности их загружать и что делать с соседним файлом в котором такой же или перекрывающий период? Религиозный вопрос — нужно ли хранить где-то историю этих файлов, т.е. уже загруженные/ошибочные/планируемые к загрузке копии…

[@sBroker]

Вот люблю такое, когда человек берет инструменты и совсем немного изоленты и решает задачу — у меня в силу профессиональной деформации всегда первым делом идет мысль «щаща, возьмем .Net или яву и напишем»… Респект вам в этом плане.

[@rt001]

Спасибо)