Мутабельность при записи документа, через ком соединение #745168

Платформа 8.3 управляемое приложение. При проведении через ком вот такая бяка: {Обработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(7313)}: Ошибка при вызове метода контекста (Записать): Ошибка при выполнении обработчика - 'ОбработкаПроведения': {ОбщийМодуль.УчетНДСБП.Модуль(8699)}: Ошибка при вызове метода контекста (ПолучитьСписокОбособленныхПодразделений): Попытка передачи мутабельного значения результата метода ПолучитьСписокОбособленныхПодразделений . Кто что подскажет?

Что отладчик говорит?  Что передается в ПолучитьСписокОбособленныхПодразделений?

метод описан который возвращает мутабельное значение - что еще требуется пояснить то?

ПолучитьСписокОбособленныхПодразделений в студию

СписокОрганизаций    = ОбщегоНазначенияБПВызовСервераПовтИсп.ПолучитьСписокОбособленныхПодразделений(Реквизиты.Организация); - это строка на которой вылетает Это сама функция

В обоих общих модулях флаг внешнее соединение стоит. Конфа типовая бух корп 3.0.39.67

Реквизиты.Организация случайно не объект?

Реквизиты.Организация это ссылка на какую базу?

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

"Для режима запуска ОбычноеПриложение обмен с сервером невозможен!"

А как заставить комконнектор входить в режиме запуска УправляемоеПриложение?

ком-коннектор вход в режиме внешнего соединения, и спасибо за это Аллаху!

Я бы для начала обрезал руки разработчику конфигурации. Потом разработчику обработки, которая соединяется. И да, вы угадали. По самую голову.

Переведите (-:  Режим запуска для комконнектора никак нельзя изменить? А по делу? Что нужно исправить в конфе и в обработке? Обработка (которая соединяется, это типовая V8Exchan82.epf), насколько я понял, и не была предназначена для соединения с 8.3, поскольку в ее интерфейсе нельзя выбрать версию платформы 8.3., поэтому v83.ComConnector в качестве комконнектора я в коде установил напрямую, и все бы хорошо, если бы доки загружались проведенными, но они загружаются непроведенными, при проведении такая вот ошибка.

смотри 6

ну и что это за решение "Решение было найдено, переделал обработку на запуск из БП."? 1. Что именно переделал? 2. По сути это неважно, что там переделали, поскольку в моем случае бух корп это приемник по любому, запуска из него не будет.

Почему? Какая разница? Еще одно решение обмен через файлы. Например по схеме

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

Ну вот в 6 товарищ хотел но не поборол. Или снимать с поддержки.

это читал?

(почти репост ) В подсистеме Инструменты разработчика (и в ее портативном варианте в сочетании с БСП) реализован кажется наиболее универсальный вариант обхода описанной проблемы. Сама проблема у меня описана тут В общем модуле ирОбщий сделано 2 функции: ЗапистьОбъектЛкс и УдалитьОбъектЛкс, имеющих параметр НаСервере. Эти функции передают почти полное, однако не все, содержимое мутабельного объекта на сервер. Во всех инструментах, выполняющих запись данных, сделан флажок "Запись на сервере" для перенаправления записи объекта на сервер. По сути мутабельностью называют все то, что платформа не умеет сериализовать и десериализовать при вызовах клиент-сервер, однако это еще не значит что сериализовать это невозможно. В случае объектов БД кроме содержимого, имеющего штатную сериализацию, мы имеем еще свойства ОбменДанными типа ПараметрыОбменаДанными и ДополнительныеСвойства типа Структура, но самое главное у объекта имеется модуль, допускающий объявление переменных. Поэтому для полной сериализации такого объекта потребуется сериализовать рекурсивно 1. Данные. Сериализация реализована например методом ЗаписатьXML. 2. Свойство ОбменДанными. Все используемые внутри типы просто сериализуются. 3. Свойство ДополнительныеСвойства. Тут могут быть произвольные значения. Поэтому существует риски зацикливания и прочее. 4. Все переменные модуля объекта. Тут могут быть произвольные значения. Поэтому существует риски зацикливания и прочее. Вот п.4 и есть изначальная причина обзывания объекта данных мутабельным. Потом к нему уже добавился п.3. В моей реализации п.4 не сериализуется, т.к. надежного способа в рантайме перечислить все переменные модуля мне неизвестно. А остальные 3 пункта у меня сериализуются при передаче на сервер и обратно.