Доброго.

Подскажите, как можно реализовать обмен.

Исх.данные:
в Центр.Базу (ЦБ) должны падать документы с переферии (ПБ). Состав документа: Реквизиты + присоединенные файлы (только фото)
Конфа: Управление отгрузкой
Особенности:
1) связь. ПБ несколько. Где то качество связи (интернет) приемлимое, где то ГПРС свистком, есть места где качество связи откровенно убогое.

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

Что сделано:
1. Из выборки обмена выкинуты доки с "ненужным" статусом
2. состав пакета: xml + jpg = zip. 1 файл = 1 документ (тут уже ГПРС вроде как стал справляться, но тоже не всегда, бывает на фтп появляются "битые" архивы с размером 0-100кб)
3. в ПБ регистр: Дата отправки - Дата обработки
4. ЦБ обрабатывает zip, в обмен кидает статус обработки

вроде что то зашевелилось, но
1) в ЦБ стали появляться доки без фото (с xml записываю реквизиты, сохраняю док, к ссылке прикрепляю файлы. есть подозрение что на этом этапе - ошибка прикрепления и файла нет, но док уже записан). опять какую то проверку прикручивать на соответствие файлу обмена и количеству прикрепленных? брр...
2) всеравно иногда проскакивают "битые" архивы для обмена с неадекватным размером
3) обработка всей этой регистрации, обмена итд.... это как БСП переписать )))

Есть у кого улучшательные идеи?

и еще такой вопрос:
Обмен (план обмена, или универсальный xml с конвертацией) - делают 1 файл обмена = вся транзакция. Можно ли как разбить транзакцию на части? Если да - то где, в каком месте БСП или обработки универсалльного обмена

для каждого Док из Транзакция
  СформироватьИОтправитьФайлXML (Док) ...

поставь дроббокс или любое облакое и пусть оно занимается доставкой

(0)посмотри в БСП подсистеме синхронизации данных при обмене через веб сервисы уже реализовано разбитие файла на части. Разбивается по умолчанию по 1 мб, но размер частей настраивается параметрами.

(2) ну идея имеет право на существование. только вот из 10 кусков одного дока 9 дойдет. и потом головняк весь этот мусор очищать.
опять же - если брать стандартный обмен - то файл под 500мб кусками бить....

все таки хотелось бы 1 транзакция = 1 док. да и анализировать так понятнее наверно.

(1) облако не вариант. если только транспорт переложить на какую нибудь filezilla. пусть папку синхронизирует. но опять же тот же самый вопрос с мусором и битыми файлами

(0) 1. В стандартном обмене есть разбивка на несколько частей файла обмена.
2. Мы тоже столкнулись такой проблемой в одном из филиалов, где стоит 4g-модем, но связь 256 кб и то с перебоями. Так вот если осканировали несколько договоров контрагента, то файл обмена получался 50-100 Мб, и обмен вешался, бывало и сутки приходилось жать пока же он все таки пройдет. Решение сделал такое, догворы, как и картинки (у нас их около 200 000 штук сейчас для интернет-магазина) храним не в 1с а отдельно. Конкретно договоры заливаются в облако и идет паралельная синхронизация самой 1с и отдельно договоров, договоры не так важны, поэтому пусть хоть неделю синхронизируются.

(4) Для картинок облако не подошло кстати (из-за их огромного количества файлов), по 2-м причинам.
1. В некоторых Яндекс.диск впадал в ступор, при частых сохранениях например файла "111.jpg" он переставал понимать, какой файл настоящий, тот который только, что записали, или тот который не до синхронизировался и тупо делал файл "111(2).jpg", вначале написали регламентную обработку, которая эти (2) в файлах удаляла, но причина №2 заставила отказаться от облака.
2. Бизлимита у нас там не было, и эти синхронизации за полмесяца весь трафик съедали.

(4) нужны именно доки с фотками. заливать отдельно - потом не найти какая фотка к какому доку. или какой то механизм придумывать что бы прикреплялись в зависимости от имени файла, например.
если просто брать имя файла - то оно у всех доков одинаковое (источник, до хранилища). Фото1, Фото2...
по размеру... сейчас сделано что только jpg в обмен идут. всё что наприкрепляют "ненужного" - видео, сканы итд. обрезается на этапе выгрузки. по jpegaм - ну можно еще размер ужать перед отправкой, привернуть какой нибудь фоновый ресайзер картинок.

безлимит, но эти 4g и 256к (((

(6) Ну мы примерно сделали так. Самая структура как была в справочнике "Хранилище дополнительной информации" так и осталось, только вот хранение переписали не в реквизит 1с, а во внешний файл.
Имя файла = GUID элемента справочника "Хранилище дополнительной информации".

Стандартные 1с механизмы быстро синхронизировались, так как там пакеты меньше 1 Мб. А файла с документами и картинки идут через облако параллельно.

Кстати обмен раньше был 1 раз в сутки и файлы были по 50 Мб иногда и не всегда обмен из-за этого к утру проходил, а вот когда сделали обмен каждые 30 минут, то пакеты маленькие с обменом РИБ проблем почти нет.

(3) почему облака как транспорт не вариант? выложил локально, облако его переместила на другой комп и там локально забрал

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

(8) немного непонял.
облако переместило (ну или не переместило) на ЦБ
на ЦБ я должен как то проверить существование файла (пришло/нет), определить соответствие файл/документ потом прикрепить его к документу? так?

в (7) вроде есть мысль по этому поводу, но в типовой конфе - файл хранится как прикрепленный, плюс, 4 файла (фото1,2,3,4) - реквизиты формы

эмм... а я ведь могу сделать план обмена не на БСП?
в смысле
1. регистрировать изменения только для "нужного" статуса
2. ПрочитатьИзменения () и потом выгружать 1 док = 1 файл. циклом по измененным
3. сверить номер сообщения, снять регистрацию

фото отдельно выгружать

(10) Обмены ты сейчас куда выгружаешь? На фтп? А я предлагаю выкладывать в локальный файл. Далее облако само поделит и переместит на другой компьютер и останется только локальный файл загрузить. Можешь флаг выкладывать который после загрузки будешь удалять. Если файл есть значит приемник еще не загрузил данные. Если файла нет, то все хорошо, выгружаем

(11) а как же справочники и регистры?

(13) сейчас так: состав zip - xml с реквизитами + jpeg-и с фото

когда собираю: распаковываю архив, из xml заполняю реквизиты, записываю, к докссылке прикрепляю картинки, удаляю распакованное

Если картинки будут ходить отдельно - надо как то придумать механизм для прикрепления к доку.
и опять же, картинки - из прикрепленных файлов при открытии формы берутся как реквизиты формы (так в конфе сделано), т.е. на форме сразу открывается часть фото из прикрепленных, по шаблону имени файла - "Фото1.jpg, Фото2.jpg". в прикрепленных - Фото1.jpg, Фото2.jpg, ФотоАнджелиныДжоли.bmp

(11) движения дока не нужны. справочники для реквизитов перенести можно как обычно. или имеется ввиду регистр СоответствияОбъектовИнформационныхБаз ?

(14)  движения дока не нужны. справочники для реквизитов перенести можно как обычно. или имеется ввиду регистр СоответствияОбъектовИнформационныхБаз ?

(10) У нас для одного товара можно любое количество фото прикрепить.
Сохраняем в регистре сведений имена как ГУИД+Приоритет. 2 колонки. Имя файла в папке тож вот так:
0a2ad43c-72fa-11e5-8b90-60a44cb5758e_0.jpg
0a2ad43c-72fa-11e5-8b90-60a44cb5758e_1.jpg

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

(17) В имя файла можно зашить любую инфу, зная в каком месте она стоит.
Например ГУИД это первые 36 символов.
Далее приоритет "_" + 2 символа.
И т.п.

(17) ну прикрепить то можно любые файлы
только вот конфа, при открытии формы дока, ищет в прикрепленных файлы-картинки, с конкретным именем - а именно "фото1, фото2.... И если есть такие - то выводит картинку на форму. если нет - то поле картинки пустое.

Потом СБ открывают док, а там картинок нет, и начинается паника и шум.

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

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

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

(0) Как вариант для рассмотрения.
Делал обмен из очень старой УТ10.2 в новую ERP через web-сервисы. Документы регистрирую в планах обмена, как и положено. Все документы выгружаю по одному. При чём с регистрации снимаю только при ответе от приёмника об успешной загрузке. Если ошибка, то в конце обмена письмо мне на почту со списком всех не выгруженных документов с текстами ошибок.
Конечно, немного времени пришлось потратить на реализацию. Но в итоге получилась очень высокая надёжность обмена и качественная точечная запись данных. Данные вообще не теряются, всё записывается как надо и куда надо.

Конкретно в твоём примере можно сделать такой вариант. Документы отправлять как есть (чтобы сильно не переписывать обмен), а картинки/видео для отправки регистрировать отдельно, и отправлять, например, через http-сервис с подтверждением доставки. Это существенно повысит надёжность.