Технология проведения миграции данных в крупных проектах

Опубликовал Галина Харитонцева (cinimex) в раздел Обмен - Обмен с другими системами

В статье систематизируется проектный опыт проведения миграции данных в крупных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».

Введение

В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».

При этом основной акцент в статье будет сделан, прежде всего, на технологическую составляющую процесса миграции. Организационная составляющая также затронута, но в меньшей степени.

Термины и определения

Под миграцией данных принято понимать конечную последовательность работ, проект, направленный на разовое массовое перемещение данных из систем-источников (исторические системы) в систему-приёмник. При этом эксплуатация этих данных в системах-источниках прекращается.

Следует отличать миграцию данных от интеграции данных. Интеграция, в отличие от миграции – это постоянная часть архитектуры IT, и ответственна за потоки данных между различными системами и хранилищами данных – и является процессом, а не деятельностью по осуществлению проекта[1].

Схема миграции в общем случае выглядит следующим образом:

Рис. 1

Исторические системы – базы данных компании Заказчика, которые планируется полностью или частично заменить при внедрении новой системы.

Система-приёмник – целевая система, произвольная конфигурация «1С:Предприятие 8».

Исходные данные – данные, выгруженные из исторических систем в произвольный формат xls-файлов. В данном случае формат xlsпредставляется, как один из самых удобных, поскольку возможность выгрузки в xls-файл присутствует во многих учетных системах «предыдущих поколений».

Как современную альтернативу в качестве транспорта возможно рассматривать формат xml-файлов.

Также существуют варианты использования промежуточной базы данных.

Трансформация, конвертация – процесс преобразования исходных данных в данные для загрузки. Трансформация данных происходит в соответствии с шаблонами для загрузки. Результатом трансформации являются данные для загрузки.

Данные для загрузки – данные, предназначенные для загрузки в систему-приёмник. В данной статье, так же как и исходные данные, рассматривается xls-формат.

Шаблоны данных для загрузки – описание таблиц данных для загрузки в целевую систему.

 

Этапы миграции

Рассмотрим поэтапно процесс подготовки и проведения миграции.

К организационным этапам миграции можно отнести следующие пункты:

·         Определение стратегии миграции. На данном этапе Исполнитель и Заказчик договариваются о технологии проведения миграционных работ;

·         Определение состава рабочей группы по миграции. В рабочую группу должны входить специалисты и Исполнителя и Заказчика, знакомые в достаточной степени с работой исторических систем (со стороны Заказчика) и целевой системы (со стороны Исполнителя);

·         Предварительный план миграции. План миграции по ходу проекта будет неоднократно корректироваться;

·         Периоды дат выгрузки данных из исторических систем, объемы данных. Периоды среза данных для миграций, даты тестовых и итоговой миграций. Данную информацию можно отнести к плану миграции;

·         Состав данных, подлежащих миграции. Справочные данные, классификаторы, транзакционные данные, остатки, обороты и пр.;

·         Вопросы проверки качества, корректности и целостности данных в процессе миграции и по итогам;

·         Вопросы отката к предыдущему состоянию в случае сбоев.

Остановимся подробнее на технологических этапах миграции.

Рис. 2

1.     Подготовка шаблонов загрузки данных

Шаблон загрузки данных содержит технические описания таблиц данных для загрузки, алгоритмы и правила загрузки для текущего шаблона.

Каждый шаблон в общем случае предназначен для одной или нескольких связанных таблиц в целевой системе-приёмнике.

В шаблоне указывается:

·         Описание всех полей xls-файла данных для загрузки, включая:

o   Имя поля

o   Признак обязательности заполнения поля

o   Пример заполнения поля

o   Примечание

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

·         Описание заполнения непосредственно полей таблиц целевой системы в случае, если предусматривается что-либо отличное от переноса данных «один в один» из файла данных для загрузки. Актуально для ссылочных полей, например.

 

В процессе работ по данному этапу Исполнитель также должен подготовить загрузчик файлов данных для загрузки. В случае работы с файлами xlsданная задача не представляет особой сложности.

2.     Выявление источников данных

Данный этап может начинаться вместе с предыдущим этапом «1. Подготовка шаблонов загрузки данных».

В рамках данного этапа специалисты Заказчика определяют из каких систем и какие данные могут быть выгружены. Также следует определить какие данные возможно могут понадобиться.

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

Нередки ситуации, когда для обеспечения в дальнейшем целостности информации некоторые данные приходится переносить с печатных источников (оцифровывать) или даже заносить в таблицы со слов ключевых сотрудников Заказчика.

Тем не менее, на данном этапе нужно постараться выявить как можно больше необходимых данных.

 

3.     Выгрузка исходных данных

Процесс выгрузки данных из исторических систем может занять достаточное количество времени, особенно, если систем много, они разные и за них ответственны разные подразделения Заказчика. Необходимо учитывать данный момент при тестовых и итоговой миграциях.

Наиболее удобным вариантом представляется выгрузка в xlsфайлы. Многие старые IT-системы поддерживают такой вариант.

Также могут быть варианты выгрузки в csvформат, dbf, xml форматы и прочие.

Стоит отметить, что по тем или иным причинам (вопросы безопасности, например) Заказчик не всегда может предоставить выгрузки данных в полном объеме на этом этапе! Только структура данных и несколько тестовых позиций. Таким образом, может сложиться такая ситуация, что при тестовых и итоговой загрузках будут обнаруживаться некачественные данные в исходных таблицах, что будет приводить к незапланированным ошибкам.

Для минимизации данной проблемы следует оговорить заранее объемы тестовых выгрузок из исторических систем.

4.     Мэппинг данных

Мэппинг (data mapping) – в общем случае процесс сопоставления данных исторических систем и системы-приемника. То есть, исходных данных и данных для загрузки.

Этап мэппинга - наиболее трудоёмкий этап и может занимать более 50% всех работ по задаче миграции.

На данном этапе в полной мере задействуется вся рабочая группа проекта по миграции.

В процессе мэппинга данных необходимо выделить подэтапы мэппинга таблиц и мэппинга полей.

·         Мэппинг таблиц, или мэппинг шаблонов – сопоставление таблиц исходных данных и шаблонов данных для загрузки. Соответствие может быть как 1:1, так и N:N. В результате данной работы составляется и поддерживается реестр мэппинга таблиц. Данный подэтап необходим для следующего подэтапа мэппинга полей и для отслеживания общего состояния дел по мэппингу.

 

Примерное содержание реестра мэппинга таблиц может быть следующее:

Группа шаблонов 1С

Наименование шаблона 1С

Наименование файла-

источника

Правила формирования файла-источника

Ответственный

Статус

Примечание

НСИ

Шаблон_

Номенклатура

Номенк

латура.xls

• В системе N установить отбор
• Сохранить в txt
• Открыть в xls, колонки - текстовые
• Первая строка - шапка
• Кол-во столбцов - 15
• Сверить кол-во строк в txt и xls
• Наименование листа всегда "Лист1"

Иванов И.И.

в работе

 

 

 

·         Мэппинг полей – сопоставление полей таблиц в рамках уже определенного мэппинга таблиц. Результатом данной работы является реестр мэппинга полей.

 

Примерное содержание реестра мэппинга полей может быть следующее:

№пп

Кл. поле

Обязательный

Имя поля шаблона 1С «Шаблон_Номенклатура»

Описание

Имя поля «Номенклатура.xls»

Алгоритм заполнения

 

 

 

Код

Код элемента справочника

Код

 

 

 

 

Наименование

Наименование элемента справочника

Наименование

 

 

 

Да

Это группа

Содержит одно из значений:
• 1 – для групп
• 0 – для элементов
 

 

Если длина кода=11 символов и последние 4 символа <> "0000", то это элемент - "0", иначе группа - "1".

 

 

 

Полное наименование

Наименование элемента справочника

Наименование

Если ЭтоГруппа =1 , То "", ИначеЕсли ЭтоГруппа=0, то Наименование.

                             

 

В рамках данного этапа также следует провести возможные работы по нормализации данных.

 

5.     Подготовка правил трансформации

В отличие от предыдущих этапов, данный этап – технический и предполагает работу разработчика Исполнителя.

На основании согласованных реестров мэппинга полей специалисты Исполнителя разрабатывают правила трансформации данных.

Для оперативной работы в процессе подготовительных миграционных этапов и дальше, в ходе тестовых и итоговых миграций важно, чтобы существовала удобная среда разработки правил (скриптов) трансформации данных и среда конвертации исходных данных в данные для загрузки.

При этом требования к данной среде включают в себя:

·         Удобство и быстрота разработки правил трансформации;

·         Скорость конвертации данных. Файлы на входе и на выходе могут быть и в сотни тысяч строк!

·         Возможность работать с несколькими входными файлами одновременно;

·         Возможность сохранения правил трансформации в отдельные файлы.

Для своих проектов миграции мы разработали специализированное АРМ разработчика, взяв за основу стандартную обработку «Консоль запросов» 1С.

Обработка «Консоль запросов» была доработана для возможности делать прямые запросы к файлам xls.

Приведем пример объединения двух исходных xls-файлов Сотрудники.xls


Код сотрудника

Фамилия

Имя

Отчество

Дата рождения

2423

Иванов

Иван

Иванович

17.11.1992

1523

Петров

Василий

Александрович

04.02.1991

4363

Сидоров

Кирилл

Николаевич

01.05.1995

6

Денисов

Денис

Денисович

01.01.1990

 

 и Операции.xls со страницами:

Списания

Код сотрудника

Дата

Сумма

2423

01.02.2014

354

1523

02.02.2014

26

4363

03.02.2014

457

6

04.02.2014

100000

2423

05.02.2014

235

1523

06.02.2014

235

4363

07.02.2014

2356

6

08.02.2014

140000

2423

09.02.2014

421

1523

10.02.2014

235

4363

11.02.2014

23523

6

12.02.2014

80000

и Поступления:

Код сотрудника

Дата

Сумма

6

01.05.2004

100

6

02.05.2004

100

6

03.05.2004

100

6

04.05.2004

100

4363

14.02.2016

98

4363

15.02.2016

98

4363

16.02.2016

98

4363

17.02.2016

98

4363

18.02.2016

98

4363

19.02.2016

98

1523

01.06.2014

245245

2423

05.12.1999

1341234

 

 

в один итоговый файл вида:

ФИО

Код сотрудника

Дата рождения

Сумма поступление

Сумма списание

Иванов Иван Иванович

2423

17.11.1992

1341234

1010

Петров Василий Александрович

1523

04.02.1991

245245

496

Денисов Денис Денисович

6

01.01.1990

380000

320000

Сидоров Кирилл Николаевич

4363

01.05.1995

613382

26336

ИТОГО:

 

 

2579861

347842

 

Отметим, что пример является искусственным, специально подобранным для демонстрации всех возможных стадий трансформации источников данных.

Технологическая последовательность операций трансформации здесь выглядит следующим образом:

1.       Запрос в синтаксисе AccessSQLк таблицам MSExcel.

С помощью языка запросов AccessSQL(дающего существенные дополнительные возможности, по сравнению с языком запросов 1С) создается первоначальный запрос, извлекающий данные из файла xls в среду 1С. При этом уже на данном этапе возможны различные проверки и нормализации данных.

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

Рис. 3

2.       Запрос на языке 1С – основной запрос, реализующий алгоритм мэппинга полей. А также: обогащение загружаемых данных данными из базы 1С, перегруппирование, объединение с результатами запросов к другим исходным xls-файлам и пр.

 

Рис. 4

 

3.       Постобработка результата запроса 1С при необходимости. Реализуется с помощью скрипта на языке 1С.

 

Для примера здесь реализуется добавление строки «ИТОГО» по колонкам сумм.

Рис. 5

 

4.       Запись итогового набора данных в xls-файл.

Рис. 6

В общем случае на выходе мы получаем итоговые файлы для загрузки в целевую базу данных 1С.

Также данный инструмент позволяет сохранять правила конвертации данных в отдельный xml файл:

Рис. 7

Кроме того, реализована возможность работать в пакетном режиме, что особенно актуально при большом количестве разнородных мигрирующих данных.

6.     Выгрузка, трансформация и загрузка данных

В ходе предыдущих этапов подготовительная часть работы в целом заканчивается – выявлены все источники данных, сделана выгрузка исходных данных из источников, подготовлены шаблоны загрузки в целевую базу, подготовлен мэппинг данных и, наконец, разработаны скрипты трансформации данных.

Начиная с этого этапа и далее возможна организация череды тестовых и итоговой миграции.

Следует отметить, что перед итоговой миграцией обязательно следует провести несколько тестовых. В ходе тестовых миграций Исполнитель совместно с Заказчиков выявляют:

·         ошибки конвертации, ошибки загрузки данных

·         проводят предварительную оценку качества загружаемых в целевую систему данных

·         по итогам тестовых миграций составляют/актуализируют план итоговой миграции

 

7.     Выверка данных

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

·         Совпадения итоговых сумм по остаткам, по документам;

·         Количественные совпадения, например количество ОС;

·         Корректность заполнения отдельных выборочных сущностей;

Обращаем внимание, что те или иные проверки мигрирующих данных, вопросы нормализации данных необходимо решать на протяжении всех миграционных процессов. Необходимо всегда задаваться вопросом, что нужно сделать на текущем этапе, чтобы избежать ошибок на последующих этапах.

Например:

·         Проверка на дубли по ключевым полям. Можно и нужно проводить еще на исходных данных;

·         Приведение типов полей;

·         Ссылочная целостность;

·         Математические нестыковки. Например, проверка на незаполненные численные поля, на которые запланировано деление при трансформации;

·         В целом, проверки обязательной заполненности полей;

·         Замена некорректных символов. Например, английские символы в кириллических полях («о», «а», «е» и т.п.) Особенно актуально это для ключевых полей!

·         Проверка значений строковых полей на соответствие типов системы-приемника (Ограничения по длине)

После завершения итоговой миграции согласно заранее определенной стратегии миграции и плану миграции принимается решение о дальнейшей эксплуатации исторических систем.

Часто эксплуатация завершается сразу после финальных сверок данных и фиксирования успешности проведенной миграции – пользователи новой системы уже не ведут учет параллельно в двух системах, а полностью переходят в новую систему. При этом доступ к старой системе сохраняется в режиме чтения.

В некоторых случаях может происходить параллельная работа двух систем на время опытной эксплуатации (ОЭ) и даже более этого периода. Вопрос параллельной работы пользователей в двух системах тесно связан с вопросом возможности отката к старой системе, в случае если миграция (или же, в целом, работа новой системы!) будет признана неудовлетворительной.

 

Заключение

В заключении хотелось бы отметить, что когда речь идёт о миграции больших транзакционных систем, к которым относятся и многие конфигурации «1С:Предприятия», переход на новую систему может быть весьма трудоёмким.

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

См. также

Добавить вознаграждение
Комментарии
1. Виталий Попов (Сурикат) 122 17.05.16 22:50 Сейчас в теме
Мне кажется, что для описания общей схемы нужно также добавить синхронизацию данных.
Т.е. когда процесс перехода сильно растянут во времени может получиться ситуация, что часть данных заносятся в исторических источниках, а часть уже в новых. Точнее для средних и крупных систем так обязательно получится. В таком случае необходимо осуществлять синхронизацию данных для обеспечения беспрерывной работы системы.
pisarevEV; dddxddd; ivanov660; monkbest; +4 Ответить 2
2. Евгений Король (king1982) 2 18.05.16 10:02 Сейчас в теме
(1) Именно. На мало-мальски серьезном проекте обмен необходим в обе стороны. Кто будет останавливать работающий бизнес ради какого-то там перехода?
3. Галина Харитонцева (cinimex) 35 18.05.16 12:17 Сейчас в теме
(1)(2)

Коллеги, спасибо за комментарии

Да, в некоторых случаях после внедрения новой системы есть период, когда учет ведут и в старой системе и в новой. В таком случае обеспечивается синхронизация данных. И это, по сути, уже обычная интеграционная работа - регулярный автоматический или полуавтоматический обмен между системами.

Другое дело, что если миграция происходит с целого ряда систем на новую - то обеспечение такой невольной интеграции уже тянет на отдельный проект.
4. Евгений Король (king1982) 2 18.05.16 15:41 Сейчас в теме
(3) cinimex, Если есть ряд систем в начале не синхронизируемых между собой, то переход делается посистемно, сначала одну систему, потом вторую и опять же с синхронизацией. Временно (до окончательного перевода всех процессов) отключаем (или не включаем) в 1С контроль зависимостей одних данных от других.
Да: долго, дорого, муторно, жаба душит, но: дешевле простоя, а тем более риска из организованного хаоса создать неорганизованный бардак, в ходе которого многие активы компаний имеют свойство умножаться на ноль.
pisarevEV; cinimex; +2 Ответить 1
5. Галина Харитонцева (cinimex) 35 18.05.16 16:17 Сейчас в теме
(4) да, согласны - такой вариант самый, пожалуй, надежный и сохраняет нервы крепче

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


По поводу простоя - если брать именно наши проекты, простоя никто из Заказчиков, конечно, не хочет. Да и возможности такой нет. Соответственно, стараемся провести по максимуму тестовых миграций, главных тестовых миграций, сверхглавных тестовых миграций и т.п. Также, стараемся подготовить и автоматизировать процесс так, чтобы финальная миграция ужалась до времени массовой автоматизированной заливки данных по нажатию на одну кнопку, грубо говоря. Поэтому, если всё готово заранее, сама заливка+тест занимают пару-тройку дней и сводится до рутинных нажатий на несколько кнопок.

В целом, вопрос параллельной работы в старых системах, всё же, решается Заказчиком, прежде всего. Если они готовы, IT-отделы старых систем готовы, бизнес готов, это у них стандартная практика - то почему бы и нет. Но нам, как исполнителям потенциально нужно быть готовым к единовременному переносу данных сразу - вот вам новогодние праздники, местные специалисты, дерзайте.
6. Sergei (kauksi) 194 18.05.16 16:20 Сейчас в теме
Не описан любимый процесс миграционщиков - проВэПээРить
7. Галина Харитонцева (cinimex) 35 18.05.16 17:22 Сейчас в теме
(6) имеется ввиду функция ВПР в экселе?

Мы в данном случае эксель используем просто как таблицы некой промежуточной БД.

всю обработку и необходимую аналитику данных в этих таблицах выполняем запросами - там вполне себе полноценный SQL, и insert есть, и нормальное преобразование типов и т.п.

В принципе, можно сразу все эксели переливать в СУБД как есть и работать уже там. Такой ETL будет.... Чем мне не нравится такой вариант - эксель универсален и стоит у всех пользователей и все умеют с ним работать. Это крайне удобно и практично.
8. Трактор Трактор (Трактор) 1109 18.05.16 17:34 Сейчас в теме
Фигня какая-то. Почему xls удобен? Не понятно. Если миграция из 1С в 1С, то удобнее всего конвертация данных, а значит xml. Если миграция из/в другие системы, то смотри, что за системы. Часто удобно бывает сделать промежуточную SQL базу, которая обеспечивает целостность данных.
Мне ни разу не приходилось мигрировать xls файлами. Потому что эксэль считает себя самым умным и иногда искажает данные.
alexsi; pisarevEV; Йожкин Кот; kereo; zqzq; acapulco; myjob1c; утюгчеловек; +8 1 Ответить 4
9. Константин Куликов (Светлый ум) 192 18.05.16 17:49 Сейчас в теме
(8) Трактор, полностью согласен - но в большинстве случаев не хватает квалификации у людей ваять SQl промежуточные базы, да и конвертации как огня боятся - потому и изгаляются выгрузками в файл: XLS, DBF, Txt
10. Галина Харитонцева (cinimex) 35 18.05.16 18:09 Сейчас в теме
(8) xls удобен некой общей универсальностью - и как инструмент, и как транспорт данных

В экселе ведется мэппинг полей - прорабатываются и согласуются алгоритмы сопоставления. Этой работой занимаются специалисты Заказчика от бизнеса + аналитики Исполнителя. В экселе тут же ведутся всякие реестры и отчеты. То есть тут - рабочий инструмент.

Ну, и эксель достаточно удобен как средство хранения информации для обработки. Его можно открыть с любой машины, просмотреть. Специалист Заказчика может сам что-то проверить.

По поводу промежуточных SQL-баз - вариант хороший, не спорю. Такие примеры миграции также у нас в практике есть.

Но, в большой конторе для того, чтобы просто поднять чистую sql-базу может потребоваться писать служебки с кучей согласований, в том числе и служб ИБ.
Далее, остро встанет вопрос по поводу квалификации людей, которым нужно работать с этими данными.
Далее, встаёт вопрос _выгрузить_ из старых систем данные в эту новую sql-базу. Систем может быть десяток, на разных платформах - и MS SQL и Oracle, и те же эксели.
Зачастую, владельцы старых систем никак не заинтересованы в таких работах. Выгрузить 10 файлов эксель "как есть" - это просто. А вот работать для переливки в sql-базу...

С xml - примерно те же проблемы. Софт, квалификация, оперативность работы, доступность для работы
11. Галина Харитонцева (cinimex) 35 18.05.16 18:14 Сейчас в теме
(9) абсолютно верно

ситуация 1 - миграцию делает 1-2 разработчика 1С. Тут можно хоть прямыми запросами из системы А в систему Б делать. Всё ограничивается только уровнем 1С-ников

ситуация 2 - систем два десятка. Только аналитика и мэппинг полей занимают полгода смежной командой Заказчик+Исполнитель - это и бухгалтеры, и экономисты, и прочие. Тестовых миграций и выверок еще на несколько месяцев. Общая длительность работ - больше года.
Понятно, что тут нужно что-то простое, понятное, всем доступное в любой момент. Чтобы Бухгалтер А мог четко и быстро отработать по телефону по файлу с Экономистом Б.
12. Галина Харитонцева (cinimex) 35 18.05.16 18:26 Сейчас в теме
Добавлю, что, конечно, если Заказчик - серьёзное предприятие с бесконечно развитым IT-блоком, то там начинают использоваться уже промышленные ETL-системы

Например, по такой схеме Основные функции ETL-систем

Но, понятно, что бюджеты подобных работ равно как и стоимость соответствующего софта очень нескромные.
13. Сергей Д (dddxddd) 19.05.16 17:40 Сейчас в теме
Суть статьи правильная, на собственном опыте подтвержденная.
Но есть некоторые придирки к тексту. Хочется спросить автора, чем в его трактовке отличается "мэппинг" от "трансформации"?

> На основании согласованных реестров "мэппинга" полей специалисты Исполнителя разрабатывают правила трансформации данных.

ИМХО вы "запутались" в терминах.
Насколько я понимаю, Ваше "мэппинг" это и есть "правила отображения и трансформации" прикладных данных исторической системы в новую. А "специалисты исполнителя", в вашей цитате, реализовывают эти правила трансформации в программные (или иные) "механизмы трансформации".

Например, у нас в Крыму, при переходе из украинского учета в российский учет, бухгалтера выполняли "трансформацию" украинского БУ в российский, но "мэппинг" они не делали... :-))
Не стоит использовать американизмы там, где есть нормальные русские термины.
Makushimo; Трактор; cinimex; +3 Ответить 1
14. Галина Харитонцева (cinimex) 35 19.05.16 17:53 Сейчас в теме
(13) спасибо за комментарий

мэппинг - это такой устоявшийся термин, но корнями не совсем из мира 1С, да..

смотрите ссылку на ETL в (12) или вот, к примеру

то есть это процесс сопоставления полей системы А и системы Б - обычно в виде каких правил, алгоритмов, возможно, кусков кода и т.п. Это аналитическая работа специалиста буквально ручками в экселе или в какой-то специальной программе.

а трансформация, конвертация - это просто процесс автоматизированного преобразования данных как раз по этим правилам
15. Ридван (утюгчеловек) 20.05.16 15:19 Сейчас в теме
Плюсую за расширенную консоль.

Складывается ощущение, что такая схема синхронизации категорически не подходит для достаточно больших компаний, или для компаний, объем данных в исторических системах которых довольно большой.
Я боюсь себе даже представить сколько будет открываться excel с миллионами строк насыщенной колонками таблицы.
Ведь Вы выбрали excel именно потому что в нем удобно будет работать заказчику?
Страшно подумать, во что станет потом заказчику этот excel проверять/сводить/редактировать перед загрузкой в целевую систему.

На мой взгляд сильно проще описать достаточное количество внешних источников данных. И работать с ними в единообразной 1С-ной манере.
Чувствую, что в 97,5% случаев этого будет достаточно.
Исключением будут являться какие-нибудь поросшие мхом источники данных, подключиться к которым просто так нельзя.
16. Галина Харитонцева (cinimex) 35 20.05.16 16:13 Сейчас в теме
(15)
Складывается ощущение, что такая схема синхронизации категорически не подходит для достаточно больших компаний, или для компаний, объем данных в исторических системах которых довольно большой.
Я боюсь себе даже представить сколько будет открываться excel с миллионами строк насыщенной колонками таблицы.


я думаю, да, в этом случае - уже next-level, переход на другой технологический уровень и использование других инструментов. Но общий принцип, в целом, такой же.

В целом, открывать миллионные эксели особой необходимости нет - активная работа с таким файлом ведётся на тестовом примере. Например, 100-1000 строк произвольных строк более-менее отражающих срез данных. Повторюсь, работа именно аналитическая, когда, скажем, бухгалтеры Заказчика сопоставляют поля этих экселей и поля таблиц новой системы- это вот как раз работа по мэппингу данных.

Составлен мэппинг, программист по этому мэппингу написал код трансформации - всё, можно конвертировать исходный файл. И только тут первый раз на сцену выходит миллионный файл.

Ну и потом, нужно смотреть, что за предметная область. Откуда миллион строк в таблицах. Если это проводки - то, возможно, достаточно будет ввода остатков и всё. Ну, а НСИ в таких размерах.. ))
17. Ден Вар (vardo) 37 20.05.16 16:27 Сейчас в теме
Люди любят изобретать велосипеды и не любят изучать стандартные механизмы конвертации
18. Галина Харитонцева (cinimex) 35 20.05.16 16:42 Сейчас в теме
(15)
На мой взгляд сильно проще описать достаточное количество внешних источников данных. И работать с ними в единообразной 1С-ной манере.
Чувствую, что в 97,5% случаев этого будет достаточно.
Исключением будут являться какие-нибудь поросшие мхом источники данных, подключиться к которым просто так нельзя.


если есть возможность, да, конечно, можно поступить и так

но ситуация может складываться так что:

а) просто так никто к другой базе подключиться не даст. Только через служебки, согласования, пробросы портов, разрешения ИБ и прочее. Для каждой базы по отдельности. Плюс, если это рабочая база - то к ней в принципе могут не дать доступ никак. Только к какой-либо тестовой копии, которую чтобы поднять... см. выше

б) даже если доступ получен - мы можем увидеть оригинальные таблицы СУБД, которые, как и в 1С, могут слабо отражать бизнес-смысл. Соответственно, нужна дополнительная приличная аналитика по этим базам... Это время, ресурсы, бюджеты


Иными словами, нужен промежуточный формат такого плана, чтобы без проблем можно было в него выгрузить из старых баз данные (примеры данных) и без больших трудозатрат посадить бухгалтерш и 1С-консультантов разрабатывать алгоритмы переконвертации этих данных.
19. Владимир Пономарев (valafan) 112 21.05.16 22:20 Сейчас в теме
плюс, ещё бы консольку приложить...
20. Виталий Попов (Сурикат) 122 23.05.16 18:18 Сейчас в теме
(8) Трактор,
У меня был опыт миграции xls файлами со СБиСа (точнее csv, суть одна). XLS ничем не лучше и не хуже других форматов. Вопрос насколько специалистам, осуществляющим миграцию, проще работать с тем или иным форматах при переносе. Если, например, у вас уйдет 50 часов на написание правил для выгрузки/загрузки в XML и 10 часов на те же правила, но с использованием csv вы наверняка выберете csv.
21. Игорь Хитров (Новенький_2209) 25.05.16 10:50 Сейчас в теме
(8) Трактор,
Фигня какая-то. Почему xls удобен? Не понятно.

Потому что база-источник может быть построена на таких платформах/технологиях, что специалистам c "той" стороны дешевле, проще, удобнее выгрузить исходные данные в формат "который уже поддерживает наша система". Я участвовал в проекте, в котором максимум что могли дать с "той" стороны, это много-много файлов в формате *.txt. С учетом среднего объема файла в 1 Гб.

Мне ни разу не приходилось мигрировать xls файлами. Потому что эксэль считает себя самым умным и иногда искажает данные.

Как раз таки, если рассматривать только формат xls как источник данных, то вам не обязательно его открывать экселем. Читайте тем средством, которое вам доступно/нравится. Никаких "авто" преобразований в этом случае не будет. Более того, сам формат полей, также можно настроить. Но конечно, стоит на задачу смотреть контекстно. Например, если размер файла с данными начинает превышать гигабайтный размер, в случае с тем же txt, стандартный драйвер чтения такого файла, скорее всего просто завалится. В этом случае, как вариант, файл действительно есть смысл как-то загрузить в какую-то субд. Я в таких случаях использовал MS SQL, делал человеческие вьюшки к ним, и уже через ВИД, цеплялся к ним. В этом случае, никакие продвинутые консоли не нужны, достаточно обычной стандартной итс'овской, или вообще любой. Опять же почему я пришел к понимаю именно такой архитектуры. Смотрите, как правило, данные мигрируют из одной системы в другую. В источнике - там же не табличка, там база. И удобно именно через 1С по быстрому настроить все необходимые для работы связи между таблицами, настроить типы полей, чтобы из 1С это все работало в типах данных 1С и был доступен механизм "по ссылке". Таким образом у вас и интерфейс человеческий к источнику, и запросы со всеми плюшками разименования по ссылке на языке запросов 1С, опять к анализу можно подключить СКД, и отдать этот функционал человеку, "ни 1с'нику". При этом вы как бы в мире 1С, но в качестве источника у вас совершенно сторонняя система.

Надеюсь, дискуссия от моих 5 копеек не испортится :)

slavap; cinimex; +2 Ответить
22. Галина Харитонцева (cinimex) 35 25.05.16 11:44 Сейчас в теме
(21)
И удобно именно через 1С по быстрому настроить все необходимые для работы связи между таблицами, настроить типы полей, чтобы из 1С это все работало в типах данных 1С и был доступен механизм "по ссылке". Таким образом у вас и интерфейс человеческий к источнику, и запросы со всеми плюшками разименования по ссылке на языке запросов 1С, опять к анализу можно подключить СКД, и отдать этот функционал человеку, "ни 1с'нику". При этом вы как бы в мире 1С, но в качестве источника у вас совершенно сторонняя система.


да, абсолютно аналогичная мысль пришла и нам - на стороне принимающей 1С-системы необходимо организовать такое рабочее место, чтобы источники уже были как-либо проинициализированы в "1С-нотацию", с переводом ключевых полей в ссылки и прочее. Технологически это могут быть и через ВИД, и прямые запросы к промежуточной СУБД, прямые запросы к xls и что-то другое.

Такое рабочее место позволяет оооочень быстро и эффективно буквально на лету изменять алгоритмы трансформации данных под новые обстоятельства.
Новенький_2209; +1 Ответить
23. Артем Бардюг (Йожкин Кот) 1024 30.05.16 17:15 Сейчас в теме
Сколько умных слов, задействованных людей и написанных обработок. Все делается при помощи КД 2.0. От заказчика требуется только описание структуры базы.
24. Denis Bazin (Bazin) 6 31.05.16 10:50 Сейчас в теме
Если между 1С 8.X, "На коленке", большие объемы, "Я не люблю КД":
Источник: Запрос -> Таблица значений -> ЗначениеВФайл()
Приемник: ЗначениеИзФайла() -> Таблица значений.
А далее вариации:
1. Грузим "кодом" из таблицы значений
2. (Большой объем): "Кладем" таблицу значений и объект приемник в запрос, сравниваем их, на выходе получаем "Дельту, обновляем элементы объекта.
утюгчеловек; +1 Ответить
25. Rom Shpakoff (Lancelot-2M) 91 14.06.16 00:23 Сейчас в теме
(11) cinimex, видел в живую попытку ребят из Диалог ИТ через экселя провернуть перенос данных из овер 10 баз 7.7 в 1 на 8.х - и не увидел никаких преимуществ технологии.
Все равно лично вкорячил реквизиты синхронизации в нужные справочники, написал отчетов, которые проверяли заполнение этих реквизитов и сравнение справочников в разных базах через COM - потому что данных столько, что если человекам поручить в экселе все проверять - то так и на год подготовительных работ выйти можно))) Считаю предлагаемую технологию ущербной хотя бы в силу большей сложности написания автоматизированных проверок синхронизации данных во множестве "исторических систем" перед выгрузкой во внедряемую.