Комментарии 5
При ваших объемах вы точно выстрелите себе в ногу на коллизиях. Я лично встречал создание документа в разных узлах РИБ с одинаковыми УИДами, причем количество узлов было не запредельным, до 100. Базы узлов готовились не созданием начального образа, а копией + перепривязкой + очисткой, скорее всего это было причиной. Прилепили костыль с проверкой места создания при загрузке имеющегося документа (при коллизии создавался клон с другим УИДОм и отправлялся обратно, вместе с удалением "документа-коллизии"). Расследование было интересным и заняло не один день.
Что-то жутко переусложнили решение, ИМХО. Зачем 1С-Шина, зачем вэб-сервис?
У вас была задача на один раз, не нужно было городить весь этот обвес.
Всего 28К элементов, я понимаю когда речь о сотнях тысяч, или миллионах.
Речь шла о разовой выгрузке объёма при подключении одного из филиалов холдинга. Мы решили её как миграцию средствами интеграции: те же механизмы, что потом стали постоянным потоком, просто первый прогон был по историческим данным. Для типизированных данных веб-сервис здесь оптимален: строгий формат, понятые ошибки, предсказуемая нагрузка. Шина при этом работала как ретранслятор и в ряде случаев обогащала данные по пути. В итоге отдельный одноразовый инструмент для миграции не понадобился и при подключение других филиалов, а после загрузки поток просто продолжил работать в штатном режиме.
Крохотный же вроде объем справочников, разбили иерархически, ставки группы и т.д... Зачем в кишки так упарываться?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гонка при создании справочников в 1С: как MD5 от ключа заменил блокировки на миграции 28 тысяч позиций