Коллеги подскажите пожалуйста как лучше сделать. Начальство поставило задачу выгружать онлайн документы из одной базы 1с в другую идентичной конфигурации через http сервисы. Я делал несколько раз обмен через http и json но это были обмены с внешними системами. 1с просто отдавала нужные данные в формате json. Попробовал выгрузить (загрузить) документы 1с через json. Возник вопрос как быть с реквизитами. Каждый раз при записи реквизита документа дергать http сервис базы приемника и передавать в базу приемник реквизиты источника? Например чтобы записать документ "Заказ клиента" через json надо чтобы в базе приемника были заполнены склад, контрагент и т.д.

Планы обмена, регистрация изменений...

(0) В источнике определяешь ключ синхронизации для склад, контрагент и т.д. - по коду, по наименованию, а уникальному идентификатору и т.п.
В json из источника в приемник передаешь ключ, в приемнике по ключу ищешь и заполняешь реквизиты

(2) "в приемнике по ключу ищешь и заполняешь реквизиты" Это понятно. У меня вопрос как в приемник передать реквизиты.

У тебя будет ы json что то типа:
{
ТипДокумента: "ЗаказКлиента",
КонтрагентКод: "00-0000001",
КонтрагентНаименование: "Пупкин",
СкладКод: "00-0000002",
СкладНаименование: "Пупкин"
}

В приемнике
ЗаказКлиента.Склад = СправочникСкладыПолучить("00-0000002", "Пупкин");
....

функция СправочникСкладыПолучить(СкладКод)
    
    Результат = Справочники.Склады.НайтиПоКоду(СкладКод);
    Если Результат.Пустая() Тогда
        Результат = Справочники.Склады.СоздатьЭлемент();
        Результат.Код = СкладКод;
        Результат.Наименование = СкладНаименование;
        Результат.Записать();
    КонецЕсли;
    
    Возврат Результат.Ссылка;
    
Конецункции

(4) Спасибо. Получается надо формировать json документа со всеми подчиненными реквизитами до примитивных типов так?

Ога

Здесь думай, не думай, а вариантов всего два
1 - регистрация изменений, тащить все что изменилось, получать ответ и снимать с регистрации
2 - тащить все, что входит в документ
Второе медленнее, но гораздо проще.

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

А почему http сервис нельзя использовать просто как транспорт xml файла?

В простейшем случае, одностороннего обмена:

Вот у тебя есть http-метод ПолучитьИзменения(КодУзлаОбмена, НомерПоследненогоПринятогоСообщения)

В этом методе
1. Удаляешь регистрацию изменений по НомерПоследненогоПринятогоСообщения
2. Формируешь xml-файл обмена, возвращаешь его в качестве ответа.

А справочники склады, контрагенты
1) ты либо включаешь в план обмена (тогда при изменении контрагента он отправится и без документов)
2) или при формировании сообщения включаешь в него все "реквизиты" встречающиеся в документах: контрагенты, склады и т.п.

(10)на мой субъективный взгляд формат JSON гораздо проще, понятнее, удобнее, чем XML.

нужно поделить на 2 шага выгрузку
1 делается запрос какие из объектов присутствуют в приемнике (те самые контрагенты склады и прочая)
2 производится выгрузка. те которые уже есть передаются по УИД, те которых нет передаются полностью для создания в приемнике.

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

(12) в таком случае замените в моих сообщениях xml на JSON и ничего не изменится.

На мой взгляд, JSON просто более человекочитаемый.

(15)Понятно, что от формата файла обмена идеология обмена практически не меняется. Это никто не оспаривает. Просто Вы сами спросили автора, а почему не XML
(13)При одностороннем обмене "те, которые есть" возможно надо переписать, так как они могли измениться в базе источнике. Тогда одного УИД недостаточно и надо либо сравнивать объекты, либо хотя бы один раз передавать в приемник каждый объект с потрохами

Ну и не забывай ответить на такой вопрос: А выполняются ли твои обмены? И как ты собираешься это мониторить.

В моем примере из (10) нужен нулевой шаг:
Если НомерОтправленного=НомерПринятого Тогда
ОбменВыполняется(Истина);
Иначе
ОбменВыполняется(Ложь);
КонецЕсли;

Я мониторинг обменов к zabbix прикрутил, но это большая тема не много не по топику.

(7) Вариантов всегда больше. Я к примеру с документами не тащу справочники, только их GUIDы и если в приемнике нет элемента я просто создаю новый с нужным гуидом, но не заполненный. А вечером (раз в сутки) отдельно тупо выгружаю все справочники и обновляю только те которые найдены в приемнике.

(16)ну пусть больше. Хотя описанный Вами вариант это не самостоятельный, новый вариант, а последовательное выполнение двух базовых. А зачем в приемнике незаполненный вновь созданный элемент?

(19) А почему бы и нет?
Зато это сильно уменьшает время выгрузки и загрузки и освобождает от необходимости регистрации так как это 7-ка, и там с регистрацией чуть сложнее чем в 8-ке.

Ну и в конец концов. Я лично с этим не работал, знаком поверхностно, но ведь есть Подсистема БСП ОбменДанными. Там как раз трансфер уже реализван через web сервисы и в справочниках даты последнего удачного обмена нарисованы...

Погугли как настроить обмен данными между БУХ и ЗУП. У тебя будет аналогично, только нужно будет правила обмена на конвертации данных 2.0 написать. Учитывая что базы идентичны, будет не сложно. И будет по методике 1С, что классно для человека который тебя со временем заменит.

(0) если базы идентичные, большой разницы нет json xml
если в приемнике нет данных которые содержат реквизиты, твоего передаваемого объекта, придется их тоже отправлять из источника. Обычно "улетает" не один объект, а некий набор связанных с ним

(3) сразу все данные.