План Обмена, получение изменений порциями #593987

Здравствуйте. Помогите советом. Интересует, есть ли возможность обмениваться пакетами Плана обмена ограниченным размером порций, например в 1 пакете отсылается максимум 10 объектов, остальное следующими пакетами. Спасибо!

Да

Смотри процедуры событий ПриОтправки и ПриПолучении Там есть параметр ЭлементДанных. Считай сколько уже отправлено и ограничивай. Только кривая какая то у тебя задумка все равно.

Почему думаешь кривая, просто хочу на этапе внедрения подстраховаться.

где подстраховка то? если с файлом чонить случится в пути - заново пошлёт, ответа о получении не будет же

Попробуй.потом расскажешь:-)

Если обмен на БСП, Количество элементов в транзакции выгрузки данных

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

БСП? Насколько я понял это параметр, пакет все равно будет содержать все измененные элементы.

Спасибо за наводку, пока еще не понял как, буду разбираться.

ну мелкими порциями проще ладить.

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

Всё равно задумка ерундовая, как ни сделаешь всё криво будет.

+ так же, если не удалось импортировать например 99 - ый объект из 100 объектов пакета, то откатывается весь пакет целиком, поэтому если будет уходить по 10 объектов в пакете, то обломается всего 10 объектов из 100. Это снижает критичность ошибки разработчика.

а при обменах не должно быть ошибок разработчика. пример такой ошибки есть? что там можно не так сделать?

НЕ страдайте ерундой, почитайте классиков про обмены. Радченко, к примеру.

+ если у объекта зарегистрированы изменения - значит все проверки уже прошли, загрузка происходит без контроля уже (ОбменДанными = Истина), если прописать всё аналогично типовой - программных ошибок быть не должно впринципе

Аналогично типовой это УнивесальныйОбменДаннымиXML?

В типовом обмене в БП при использовании правил обмена и фонового обмена можно задавать количества объектов в обмене Хотя я не удивлюсь, если все там сделано через одно место, как обычно. Например, есть в настройках ограничения размера пакета. Так 1С если пакет получается больше заданного размера тупо не отправляет "Ответный пакет не был отправлен. Размер исходящего пакета составил: 99 553,14 (КБт) что превышает допустимое ограничение 999 (КБт)". Может и здесь так же будет

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

нет, обычный типовой обмен данными, по плану обмена встроенному... не представляю где вобще там можно накосячить. Обмен какой? между одинаковыми конфами?

про битый файл - , заново пошлёт

нет между 1с и Axapta

дык тут типовые механизмы обмена не канают тогда... двухсторонний обмен? как выгружаете?

ну почему не канают? а вдруг программисты аксапты сделают чудо.

тогда будет лепота) если они под форматы обмена данными 8.1 подстроятся... ответы о загрузке к 1с чтоб ходили и т.д.

но что-то мне подсказывает, что это фантастика ))))

+ 8.1 = 1с :)

хм, поясните, а в чем проблема, если генерить из Аксапты XML ку нужного формата. или 1с генерит особые XML-ки?

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

когда я сапёрам обрисовал своё видение обмена, их глаза медленно приняли форму 5-ти рублевых монет, а язык уже говорил "разработка будет слишком сложной и трудоёмкой".

форматы 1с это структура XML, которые генерит 1С, верно понимаю?

а в чем сложности? сгенерить XML нужной структуры, главное чтобы шапка соответствовала той, которую читает 1с, а внутри все, что хочешь, конечно исходя из того, что даст план обмена в самой 1с-ке

да, в хмл 1с-ных сразу идёт представление объекта 1с, не читает она попорядку атрибуты и тэги хмл, она видит в хмл свою схему и приводит сразу преобразование в объект свой... как то так

ну это если использовать XML-сериализацию, а если без нее укладывать и читать объекты?

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

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

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

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

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

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

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

Хм, в случае когда 1с с 1с номер пакета передается в элементе XML-ки, а номер последнего принятого пакета в другом элементе, что мешает сделать так же из Аксапты, извините, не могу понять.

ммм... напомню, на всякий случай: порядок объектов в файле обмена - не установлен. Если будете "дробить" вывод зарегистрированных изменений на "пакеты" - есть вероятность нарваться на случай, когда "взаимосвязанные" изменения будут переданы в разных пакетах, хаотично  :(

какое хорошее напоминание :-). Я почему то наивно полагал что вывод зарегистрированных изменений на "пакеты" происходит в хронологическом порядке, по мере генерации изменений! Нет?!

Нет.

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

а как же этот порядок выстроить? Кстати а какие типы объектов собираетесь гонять: справочники, документы, регистры?

пока не знаю как выстроить, может и не получится. Гонять буду все 3 вида.     Maxus43, не могу отловить где работают ПриОтправкеДанныхПодчиненному ,  ПриОтправкеДанныхГлавному, ПриОтправкеДанныхУзлаПодчиненному

+ модифицирую объекты, получаю выборку, выгружаю в пакет, не заходит!

Может быть план обмена - не риб?

как выгружаеш?

база должна знать что она главная и у неё есть подчинённые

В плане обмена у тебя должно быть минимум 2 узла.

Галку в БД-источнике поставил, сначала было не РИБ. По учебнику:

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

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

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

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

как сказать узлу, что он главная база? или надо соблюсти правильно создание подчиненной базы? а то я тупо скопипастил план обмена, в другую ЗУП, и отзеркалировал структуру узлов.

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

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

РИБ надо делать ЕМНИП

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

да, нумерацию надо оставить, чтоб коллизий не возникало, без этого никак

спасибо за диалог, Господа!

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

да ладно, можно что-то универсальное написать для этого.

всё вместе одним махом в одном файле - вот и универсальность) загружено всё или ничего

по сути да, но автор ведь хочет извращений :)