Автоматический обмен не работает

Автоматический обмен не работает

Начинающий

Группа: Пользователи
Сообщений: 92
Регистрация: 10.10.2012
Пользователь №: 60 464

Я тоже это читал. Только при закрытии смены кассиром пишет: «При обмене возникли ошибки» (дословно не помню). Так вот при этом в каталоге лежит файл с отметкой о загрузке «@», но перезаписи файла не происходит. Если предварительно файл удаляю, то никаких ошибок не происходит и выгрузка проходит штатно. Проблемы в принципе нет, просто кассиры знают, что им надо тыкнуть ярлычок «Очистка выгрузки» и только после этого закрывать смену.

PS/ Никаких ограничений на запись в каталог нет. Пользователь операционной системы с правами админа (Win XP sp3)

PSS/ Вообще была мысль, что удаление файла отдали на программу, в которую осуществляется загрузка. Так, что особо этому значения не придал

Сообщение отредактировал пит04 — 4.3.2020, 8:26

Тех.поддержка

Группа: Администраторы
Сообщений: 54 687
Регистрация: 25.9.2008
Из: Москва
Пользователь №: 14 717

добавьте в файл выгрузки маски
и будете получать каждый раз уникальный файл

и ничего не придется удалять )

ну, товароучету конечно придется тож об этом рассказать ))

Источник

Ошибка автоматического обмена данными, которой нет при ручном обмене

Серверные Комплексная автоматизация, редакция 1.1 (1.1.30.1) и Бухгалтерия предприятия КОРП, редакция 2.0 (2.0.66.92)

Настроен автообмен через файл с интервалом в час — из КА в БП. Со стороны КА проблем нет: всё уходит, как положено.

После обновления платформы на 8.3.12.1529 автообмен в БП начал периодически (раз в день/два) затыкаться: иногда всё нормально, но в некоторых случаях, судя по истории обмена, ругается типа
«Ошибка записи объекта
ТипОбъекта = Контрагенты
Объект = Наименование контрагента
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Не удалось записать: «Контрагенты»!
ПозицияМодуля = Обработка.ОбменДаннымиXML.МодульОбъекта(3778)
КодСообщения = 26

и в этом случае обмен не проходит, через час КА выгружает новый файл обмена с этими же и новыми данными, БП на него ругается точь в точь такими же словами, и дальше по нарастающей. Размер файла увеличивается, ошибка при его загрузке та же.
Спасает одно. Ручной обмен с теми же настройками, по тем же правилам, под тем же пользователем, с тем же файлом обмена проходит нормально. Тот же самый объект без проблем записывается. После этого автоматические обмены идут нормально какое-то время.
ОбменДанными.Загрузка = Истина и при автоматическом, и при ручном обмене.
При отладке ручного обмена всё ок.
Отлаживать автоматический обмен (фоновый процесс на серверной базе) с учётом того, что сервер, похоже, считает отлаживаемый процесс зависшим и срубает его через какое-то время, та ещё задачка.
Информация «Ошибка записи объекта» мало что даёт.

Есть мысли, куда (или хотя бы как) копать?

Разобрался.
Полученные при обмене объекты при записи пытались зарегистрироваться для обмена с УТ11, и в случае, если их регистрация в плане обмена УТ11 была отключена, то при добавлении узла УТ11 в получатели генерировалось исключение и обмен дальше не шёл.

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

Просто добавил строки (между комментариями):

Источник

Ошибка автоматического обмена данными, которой нет при ручном обмене

Серверные Комплексная автоматизация, редакция 1.1 (1.1.30.1) и Бухгалтерия предприятия КОРП, редакция 2.0 (2.0.66.92)

Настроен автообмен через файл с интервалом в час — из КА в БП. Со стороны КА проблем нет: всё уходит, как положено.

После обновления платформы на 8.3.12.1529 автообмен в БП начал периодически (раз в день/два) затыкаться: иногда всё нормально, но в некоторых случаях, судя по истории обмена, ругается типа
«Ошибка записи объекта
ТипОбъекта = Контрагенты
Объект = Наименование контрагента
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Не удалось записать: «Контрагенты»!
ПозицияМодуля = Обработка.ОбменДаннымиXML.МодульОбъекта(3778)
КодСообщения = 26

и в этом случае обмен не проходит, через час КА выгружает новый файл обмена с этими же и новыми данными, БП на него ругается точь в точь такими же словами, и дальше по нарастающей. Размер файла увеличивается, ошибка при его загрузке та же.
Спасает одно. Ручной обмен с теми же настройками, по тем же правилам, под тем же пользователем, с тем же файлом обмена проходит нормально. Тот же самый объект без проблем записывается. После этого автоматические обмены идут нормально какое-то время.
ОбменДанными.Загрузка = Истина и при автоматическом, и при ручном обмене.
При отладке ручного обмена всё ок.
Отлаживать автоматический обмен (фоновый процесс на серверной базе) с учётом того, что сервер, похоже, считает отлаживаемый процесс зависшим и срубает его через какое-то время, та ещё задачка.
Информация «Ошибка записи объекта» мало что даёт.

Есть мысли, куда (или хотя бы как) копать?

Разобрался.
Полученные при обмене объекты при записи пытались зарегистрироваться для обмена с УТ11, и в случае, если их регистрация в плане обмена УТ11 была отключена, то при добавлении узла УТ11 в получатели генерировалось исключение и обмен дальше не шёл.

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

Просто добавил строки (между комментариями):

Источник

Не получается настроить автоматический обмен между Удаленными подразделениями

Внимание! Данный форум является модерируемым.
Для получения к нему доступа необходимо зарегистрироваться или авторизоваться на сайте.

К ‘организационному вопросу о периодичности обмена’ — совет: прохронометрируйте время выгрузки и загрузки данных в каждую базу, наложите на ось времени — это позволит понять, какую периодичность выбрать. Бывает так, что для выгрузки изменений требуется куда больше 15 минут. Для загрузки впрочем тоже.

По поводу ошибок — новые объекты не добавляли в конфигурацию? При этом Роботу дали доступ к ним, аналогичный типовым объектам?

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

Цитата
Владимир Гаврилов пишет: К ‘организационному вопросу о периодичности обмена’ — совет: прохронометрируйте время выгрузки и загрузки данных в каждую базу, наложите на ось времени — это позволит понять, какую периодичность выбрать. Бывает так, что для выгрузки изменений требуется куда больше 15 минут. Для загрузки впрочем тоже

Ну пока обмен идет 5сек-1,5минут, не больше.

Цитата
Владимир Гаврилов пишет: По поводу ошибок — новые объекты не добавляли в конфигурацию? При этом Роботу дали доступ к ним, аналогичный типовым объектам?

Объекты добавлял, проверю права Робота.

Цитата
Владимир Гаврилов пишет: При обмене фоновым заданием, пользователю, от которого работает сервер, видимо должны быть доступны временные папки, для распаковывания сообщения. Проверьте это

Все 3 базы физически находятся на одном сервере, сервер 1с тоже один, т.е запускаются фоновые задания сейчас из под одной учетки , в 1с учетка на запуск рег. задания = учетка Администратора. Не понятно почему ошибки вылетают только на базе ЦБ

Сейчас просмотрел файл лога обмена.По нему получается, что с одной базой обмен проходит нормально,а со второй- как то кусками информация за сеанс обмена проходит.Ошибка однотипная и через 20 попыток -обмен прекращается (как я понимаю). Кусок Лога обмена с ошибкой (Выделил курсивом) :
2013.03.27 14:37:05|Администратор информационной базы|Обмен.Узел_АМ.Чтение|ok|Объект получен: Реализация автомобилей: Реализация автомобилей АА00000165 от 27.03.2013 14:27:16
2013.03.27 14:37:05|Администратор информационной базы|Обмен.Узел_АМ.Чтение|error|Ошибка чтения сообщения. Попытка № 0 : Ошибка при вызове метода контекста (ПрочитатьИзменения)
(Имя модуля: ОбщийМодуль.пвПривилегированныйМодуль.Модуль, номер строки: 32)
2013.03.27 14:37:06|Администратор информационной базы|Обмен.Узел_АМ.Чтение|ok|Объект получен: Регистр накопления набор записей: Остатки автомобилей: РегистрНакопленияНаборЗаписей.ОстаткиАвтомобилей, (Регистратор = » (213:9c01bcaec518e0ee11e296c38f7ddc16)»)
2013.03.27 14:37:06|Администратор информационной базы|Обмен.Узел_АМ.Чтение|ok|Объект получен: Регистр накопления набор записей: Комплектация автомобилей: РегистрНакопленияНаборЗаписей.КомплектацияАвтомобилей, (Регистратор = » (213:9c01bcaec518e0ee11e296c38f7ddc16)»)
2013.03.27 14:37:06|Администратор информационной базы|Обмен.Узел_АМ.Чтение|ok|Получение объекта отменено: Регистр сведений набор записей: Параметры обмена данными: РегистрСведенийНаборЗаписей.ПараметрыОбменаДанными, (УзелИБ = «Центральная база», НастройкаОбменаДанными = «В лок. сети»): для объекта уже зарегистрированы изменения.

Что же это может быть за ошибка такая «Чтения сообщения» -ведь дальше считывание проходит вроде как?

Сейчас еще одну ошибку выложу.Она возникает,когда после ошибок автоматического обмена пытаешься загрузить вручную (это в окне сообщений пишется) :
00:49:03 29.03 Начало получения файла из локального каталога
00:49:03 29.03 Успешно получен файл сообщения ­9.xml> в каталог
00:49:03 29.03 Функция чтения сообщения получила некорректное имя файла
00:49:03 29.03 Права текущего пользователя обновлены !
00:49:03 29.03 Общее время загрузки: 00:00:00

Если еще раз с удаленки выгрузить (вручную), файл соответсвенно имеет номер . 0000000310, и в ЦБ уже нормально загружается. Кто может объяснить фразу системы обмена:
» Функция чтения сообщения получила некорректное имя файла

Источник

Что делать, когда обмены между разными базами данных портят вам жизнь…

Если при обмене между базами данных наблюдаются следующие симптомы:

• Процедуры обмена занимают неприемлемо много времени.
• Процессы обмена периодически вылетают «по ошибке» и их приходится запускать заново.
• Поиск ошибок обмена превращается в ужасающий квест.

То, скорее всего, вы используете конфигурацию «Конвертация данных». Неважно, какой редакции. Все отличие КД 2.0 от КД 3.0 в удобстве отладки и поиска ошибок (см. выше п. 3).

А если при этом, вам надоело получать сообщения службы поддержки, о новых ошибках, и вы бережете свои нервы, то данная статья написана прямо для вас.

Чуть ниже, я расскажу вам, как навсегда забыть проблемы связанные со словом ‘обмен’.

История проблемы и как пришло осознание того, что нарыв созрел и его пора вскрывать.

Две нетиповых базы данных (условно обзовем их БД1 и БД2):

• В направлении БД1 -> БД2 передаются данные о нормативно справочной информации (НСИ).
  Все справочники создаются только на стороне БД1.
• В направлении БД2 -> БД1 передается информация по кассовым документам. Объем передаваемых данных составляет около 400 000 документов в сутки или, в пиковые периоды, до 150 документов в секунду.
• Объем файла обмена в пределах 0.7 – 2 Гб. Файл обмена транслируется через файловый ресурс.

С какими проблемами сталкивались:

• Общее время обмена, за сутки, составляло порядка 15-20 часов. До 20% времени уходило на формирование и передачу файла обмена (на стороне источника).
• Часть, из этого, уходила на запись файла обмена на дисковое пространство.
• Еще большая часть, уходила на запросы к БД в цикле (таков принцип работы конфигурации «КД»)
• Периодически, приходилось «резать» файл обмена на части, и проталкивать его в КИС руками.
• В КД 2.0 (КД 3.0), пока не загрузился весь файл обмена, обмен не может считаться успешно состоявшимся.
• Поэтому, если при загрузке данных, по 400 тысячам документов, хотя бы с одним документом произошел сбой – весь процесс обмена приходилось запускать заново.
• Поиск ошибок обмена превращался в неблагодарный труд (вспомните добрым словом КД 2.0).

Как решали проблему и что это дало на выходе.

Если кратко, то выполнили следующее:

• Отказались от использования конфигурации КД 2.0, в направлении БД2 – БД1 (трансляция кассовых документов).
• Сбор данных отправки производится одним пакетом запросов к БД. Собранные данные трансформируются в строку JSON.
• В базу-приемник данные передаются посредством HTTP-запроса.
• Запись документов, в базу-приемник, производится без проведения и в несколько потоков.
• Само проведение документов запускает специальный механизм отложенного проведения документов.

Более подробно, все технические аспекты – это тема отдельной публикации (планируется отдельно).

Результаты оптимизации обмена данными:

• Все вышеперечисленное позволило организовать обмен данными фактически в режиме online. Частота обмена данными составляет 10 минут.
• Среднее время транспорта 400 000 документов составляет не более 2ч. 30 минут.
• Возможные ошибки передачи данных не прерывают транспортировку всего потока.
• Простота поиска и локализации ошибок кода конвертации.

Но, это тоже еще не все! Есть еще и вишенка на тортике!

Мы решили не останавливаться на достигнутом и поставили себе целью сократить суточное время обменов до полутора часов! Возможно ли это?!

Мы помним, что в моменты пиковых нагрузок, количество одновременно проводимых документов доходит до 150 шт/сек. При данной интенсивности записей очень большую роль играет повышение параллельности работы системы, а именно – сокращению времени транзакционных блокировок.

В ходе замеров выяснилось, что при проведении кассовых документов, среднее время платформенной транзакции составляет 4.5 секунды на один документ.

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

Вынеся, все данные процедуры, за пределы транзакции, мы добились сокращения времени платформенной транзакции до…… Внимание! – 0.003 сек!

И это еще не все! На момент написания статьи, мы работаем над тем, чтоб при пакетном проведении документов, все данные, необходимые для формирования наборов записей, получались одним пакетом запросов.

Этим самым мы ставим себе целью:

• Разгрузить кластер серверов, снизив количество запросов с 400 000 до 288 запросов в сутки.
• Снизить количество взаимоблокировок базы данных
• И, в конечном итоге, снизим на порядок время проведения пакета документов.

В качестве резюме

Конфигурации «Конвертация данных 2.0» (КД 3.0) – отличные универсальные инструменты. Но, они крайне не готовы к работе с регулярными и большими объемами данных.

Сбор необходимых данных (одним запросом) для последующей online-передачи, может быть решением проблемы.

При пакетном проведении документов:

Получение данных (необходимых для формирования набора записей), производим одним запросом, с последующей передачей в документ-объект.

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

Источник