Здравствуйте.
Вопрос наверное многим покажется простым, но ничего внятного поиск мне не показал
Есть типовой обмен. Допустим УТ->БП. (не суть вожно, вопрос общий).
Для конфигураций на обычных формах у нас был один фал с правилами обмена, загруженный в конфигурацию-источник. Если обмен двусторонний - то во второй конфигурации был свой файл правил обмена.
При выгрузке данных в xml имеем 2 основных тэга (массива данных - не знаю как правильно), это ПравилаОбмена (содержит файл правил обмена из источника) и ДанныеПоОбмену (собственно сами выгружаемые данные). Причем, если я не ошибаюсь, данные уже конвертированы в формат типов данных базы-приемника. Все логично вопросов нет.
Теперь смотрим на правила обмена под управляемый интерфейс, там уже 3 файла
ExchangeRules.xml - файл правил конвертации из базы источника (понятно, вопросов не вызывает)
RegistrationRules.xml - файл правил регистрации (тоже понятно)
CorrespondentExchangeRules.xml - файл правил конвертации из базы корреспондента (!?)
И собственно вопрос: зачем этот файл CorrespondentExchangeRules.xml вообще нужен. Ведь файл обмена уже в себе содержит часть данных, содержащие правила обмена. Где этот файл используется? а если файл ExchangeRules.xml в источнике будет отличаться от CorrespondentExchangeRules.xml...?
Спасибо всем откликнувшимся
Вопрос наверное многим покажется простым, но ничего внятного поиск мне не показал
Есть типовой обмен. Допустим УТ->БП. (не суть вожно, вопрос общий).
Для конфигураций на обычных формах у нас был один фал с правилами обмена, загруженный в конфигурацию-источник. Если обмен двусторонний - то во второй конфигурации был свой файл правил обмена.
При выгрузке данных в xml имеем 2 основных тэга (массива данных - не знаю как правильно), это ПравилаОбмена (содержит файл правил обмена из источника) и ДанныеПоОбмену (собственно сами выгружаемые данные). Причем, если я не ошибаюсь, данные уже конвертированы в формат типов данных базы-приемника. Все логично вопросов нет.
Теперь смотрим на правила обмена под управляемый интерфейс, там уже 3 файла
ExchangeRules.xml - файл правил конвертации из базы источника (понятно, вопросов не вызывает)
RegistrationRules.xml - файл правил регистрации (тоже понятно)
CorrespondentExchangeRules.xml - файл правил конвертации из базы корреспондента (!?)
И собственно вопрос: зачем этот файл CorrespondentExchangeRules.xml вообще нужен. Ведь файл обмена уже в себе содержит часть данных, содержащие правила обмена. Где этот файл используется? а если файл ExchangeRules.xml в источнике будет отличаться от CorrespondentExchangeRules.xml...?
Спасибо всем откликнувшимся
По теме из базы знаний
- [ED2] Обмен УПП 1.3, КА 1.1, УТ 10.3 с EnterpriseData (универсальный формат обмена), обработка
- Правила обмена больше не нужны
- Тонкости и подводные камни работы типового модуля интеграции Битрикс24 и 1С
- Система интерактивных ролей и обработчиков с возможностью интерактивной настройки и не только (платформа 8.3.17+, расширение) для УТ 11 (все), КА 2, ERP 2, Розница 2, УНФ 1.6/3.0, БП 3, ЗУП 3.1, ААА 6
- Я - ЗУПер! Часть 1. Компетенции сотрудников.
Найденные решения
(9) Я решал подобную задачу. Решил путем впендюривания обработки обмена из старой типовой в типовую на УФ и настраивания обмена через COM со стороны старой типовой. Ну, т.е. старая типовая лезет в новую за данными, думая что там все по-старому. Нужно ее не разочаровать :)
Показалось, что так проще всего будет сделать. Успешно работает.
Правда, у меня и задача стояла по односторонней выгрузке из новой в старую.
Из старой в новую будет пожестче... Малой кровью не взлетит, ИМХО.
Показалось, что так проще всего будет сделать. Успешно работает.
Правда, у меня и задача стояла по односторонней выгрузке из новой в старую.
Из старой в новую будет пожестче... Малой кровью не взлетит, ИМХО.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) ЭЭэээ что-то я или не понимаю, или почему...
Из источника выгружаются данные в формате базы приемника По правилам из файла ExchangeRules. Т.е. в файле с данными уже все данные сконвертированы + в файле с данными содержатся правила обмена, т.е. все необходимые алгоритмы уже есть в файле обмена. Так зачем нужен CorrespondentExchangeRules.xml? учитывая то, что этот файл должен быть симметричен ExchangeRules.
Из источника выгружаются данные в формате базы приемника По правилам из файла ExchangeRules. Т.е. в файле с данными уже все данные сконвертированы + в файле с данными содержатся правила обмена, т.е. все необходимые алгоритмы уже есть в файле обмена. Так зачем нужен CorrespondentExchangeRules.xml? учитывая то, что этот файл должен быть симметричен ExchangeRules.
В документации к БСП говорится о том, что макетов может быть несколько, но обязательным является только "ПравилаОбмена".
Т.е. корреспондирующие правила - это уже самодеятельность типовых конфигураций. Когда и как они задействуются - самому интересно, но лень выяснять :)
Т.е. корреспондирующие правила - это уже самодеятельность типовых конфигураций. Когда и как они задействуются - самому интересно, но лень выяснять :)
(6) Типа да. Хотя для меня самого это звучит неубедительно. Ведь как раз при обмене через COM можно взять и там и там. А через файл - правила в файле обмена и так. Получается, что единственный случай когда это может быть критично, это когда при выгрузке данных нужно зачем-то знать, как данные загружаются оттуда сюда. Но зачем это может быть необходимо - ума не приложу. Ведь изначально это изолированные процессы были.
Тут еще дело в том, что работа обмена БСП довольно хитрая и содержит массу недокументированных моментов. Шибко умный он, зараза.
Например, не регистрируются изменения объекта, если нет изменения данных по реквизитам ПКС в правилах обмена. Умеет регистрировать уже выгруженные элементы в регистре, чтобы при повторных выгрузках выгружать только ссылки. Более того - предусмотрено сопоставление элементов из разных баз по разным внутренним айдишникам. И т.п. Может, для каких-то хитрых плюшек оно ему надо... Но для каких, сообразить не могу.
Тут еще дело в том, что работа обмена БСП довольно хитрая и содержит массу недокументированных моментов. Шибко умный он, зараза.
Например, не регистрируются изменения объекта, если нет изменения данных по реквизитам ПКС в правилах обмена. Умеет регистрировать уже выгруженные элементы в регистре, чтобы при повторных выгрузках выгружать только ссылки. Более того - предусмотрено сопоставление элементов из разных баз по разным внутренним айдишникам. И т.п. Может, для каких-то хитрых плюшек оно ему надо... Но для каких, сообразить не могу.
Могу ошибаться, но именно CorrespondentExchangeRules будут использованы при загрузке, а не те правила что записаны в файле обмена.
Может для безопасности так сделано, вдруг файл обмена враги перехватят и поменяют в нем правила.
Может для безопасности так сделано, вдруг файл обмена враги перехватят и поменяют в нем правила.
(8) Точно могу утверждать что при обмене через каталог CorrespondentExchangeRules точно не используется. Специально в источнике добавил новый реквизит и правила загрузил только в источник. CorrespondentExchangeRules оставил типовым. Нормально все загрузилось, с учетом нового реквизита в источнике.
(9) Я решал подобную задачу. Решил путем впендюривания обработки обмена из старой типовой в типовую на УФ и настраивания обмена через COM со стороны старой типовой. Ну, т.е. старая типовая лезет в новую за данными, думая что там все по-старому. Нужно ее не разочаровать :)
Показалось, что так проще всего будет сделать. Успешно работает.
Правда, у меня и задача стояла по односторонней выгрузке из новой в старую.
Из старой в новую будет пожестче... Малой кровью не взлетит, ИМХО.
Показалось, что так проще всего будет сделать. Успешно работает.
Правда, у меня и задача стояла по односторонней выгрузке из новой в старую.
Из старой в новую будет пожестче... Малой кровью не взлетит, ИМХО.
(11) Даааа? как интересно. Надо подумать над этим...
У меня сейчас обмен по кому пока обе базы лежат на одном серваке.
Но нарисовалась проблема в том, что УТ не может работать на 8.3.8. У бухии нужна минимум 8.3.8. Прийдется их разносить на разные сервера и обмен по каталогу. Но идея с впендюриванием старой обработки мне кажется интересной. Спасибо.
У меня сейчас обмен по кому пока обе базы лежат на одном серваке.
Но нарисовалась проблема в том, что УТ не может работать на 8.3.8. У бухии нужна минимум 8.3.8. Прийдется их разносить на разные сервера и обмен по каталогу. Но идея с впендюриванием старой обработки мне кажется интересной. Спасибо.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот