| Цитата |
|---|
| Иван Токарев написал: HTTP-сервис. База доступна. Из УТ в Б24 все изменения прилетают. При синхронизации вручную обмен в обе стороны работает как надо |
|
Разработчикам |
Коннектор 6.0.
Коннектор 6.0.
|
Добрый день!
А когда всё же новый коннектор для УНФ будет? А то как обделённые с основной программой, по логике, для CRM) |
|
|
|
|
|
|||
|
|
|
|
|||
|
|
|
Причём изменения не передаются ни по компаниям, ни по товарам. Ошибок в истории взаимодействия нет. В журнале регистрации УТ ошибок по «Соединению с HTTP-сервисом» нет. Не могут ли на это влиять версии релизов платформы и конфигурации:
|
|||||
|
|
|
Проверьте POST на /hs/sync_bitrix1ctotal/push в access-log веб-сервера в момент изменения компании. После выбора «Через http-сервисы» заново выгрузите настройки подключения на портал, не только подписки. Также исключите вторую базу с тем же ID коннектора — она может забирать события. pushPost может подавлять ошибки и возвращать success, поэтому пустой журнал регистрации успешную обработку не подтверждает |
|||||||
|
|
|
|
Роман, пытаемся реализовать сценарий, который предполагает такой обмен:
|
|
|
|
|
Одновременная связь того же элемента СП со вторым самостоятельным документом 1С штатным конструктором не поддерживается: в модуле один тип СП соответствует одному виду объекта 1С. Поэтому полный сценарий потребует доработки. Рекомендуемый вариант — оставить Заказ поставщику основным объектом синхронизации, а при записи документа Д определять связанный элемент СП через сохранённую связь с Заказом поставщику и обновлять поля этого элемента через crm.item.update. Таким образом, задача технически решаема: первая связь — настройками, вторая — точечной доработкой обработчика записи документа Д и передачи его данных в уже существующий элемент СП. |
|||
|
|
|
|
Спасибо за совет, Роман! 🤝
|
|
|
|
|
Но у обеих подключенных баз разные ID подключения. |
|||||||||||||||
|
|
|
|
Доброго времени суток!
Примерно месяц назад появилась проблема следующего характера: 1С УНФ при синхронизации с коробочным Битрикс24 просто вылетает. Никаких ошибок не показывается, в журнале обмена тоже тишина. Что смог выяснить: если удалить идентификаторы дел, то все работает. Но как только там они начинают появляться, то 1С также начинает вылетать. Еще заметил такую странность (предварительно удалив все идентификаторы дел): 1. Существующий счет изменяю в 1С и создается индетификатор дела с ID 1000 2. Запускаю обмен и создается идентификатор дела с ID 999 GUID у них показывается общий, а ID объекта тоже отличается. Все настройки коннектора перекопал, уже не знаю что делать. Надеюсь на вашу помощь 
print_r() - ты лучший!
|
|
|
|
|
Сравните полные URL обеих баз. В проблемной базе заново опубликуйте HTTP‑сервисы и проверьте, что GET /hs/sync_bitrix1ctotal/push возвращает success. Подписки и настройки пока повторно трогать не нужно. |
|||||||||||||||||
|
|
|
|
|||
|
|
|
Уже обновили. В чистом расширении без настроек, всё равно без ошибки не обошлось. Но, так понимаю, ничего серьезного. Просто направляю на всякий случай. Ошибка при вызове метода контекста (Выполнить) {ОбщийМодуль.ОбщегоНазначения.Модуль(10758)}:РезультатЗапроса = Запрос.Выполнить().Выбрать(); {ОбщийМодуль.ОбщегоНазначения.Модуль(5962)}:Возврат ДанныеИзБезопасногоХранилища(Владельцы, Ключи, ОбщиеДанные, ОбластьДанных); {ОбщийМодуль.ОбщегоНазначения.Модуль(6013)}:ДанныеВладельца = ПрочитатьДанныеВладельцевИзБезопасногоХранилища(Владельцы, Ключи, ОбщиеДанные, ОбластьДанных); {ОбщийМодуль.РаспознаваниеДокументов.Модуль(366)}:ИдентификаторПодсистемы(), {ОбщийМодуль.РаспознаваниеДокументов.Модуль(224)}:ПараметрыАвторизации = ТекущиеПараметрыАвторизации(); {ОбщийМодуль.РаспознаваниеДокументовЗамерыВремениСлужебный.Модуль(10)}:Если Не РаспознаваниеДокументов.ПодключеноКСервисуРаспознавания(ПытатьсяПодключитьсяПриПроверке) Тогда {ОбщийМодуль.РаспознаваниеДокументовЗамерыВремениСлужебныйВызовСервера.Модуль(5)}:Если Не РаспознаваниеДокументовЗамерыВремениСлужебный.ДоступнаОтправкаЗамеровВремени() Тогда {ОбщийМодуль.РаспознаваниеДокументовГлобальный.Модуль(7)}:РаспознаваниеДокументовЗамерыВремениСлужебныйВызовСервера.ОтправитьЗамерыВремени(); [ОшибкаВоВремяВыполненияВстроенногоЯзыка] по причине: Ошибка выполнения запроса по причине: Работа с таблицей невозможна. Структура таблицы несовместима с текущими расширениями конфигурации. |
|||||
|
|
|
|
Добрый день! Столкнулись с периодической проблемой в работе комплексного коннектора Битрикс24 с 1С:Управление торговлей 11. Буду очень признателен разработчикам или участникам форума за помощь в диагностике и поиске решения. Описание проблемы Интеграция работает через Push&Pull (Long Polling). Соединение запускается в отдельном сеансе 1С и может нормально функционировать продолжительное время — иногда несколько дней. Однако периодически возникает ошибка: Конфликт блокировок при выполнении транзакции После этого длительное соединение прерывается, в 1С появляется окно ошибки с предложением сформировать отчёт. Сам процесс 1С при этом остаётся запущенным, но для продолжения обмена приходится закрывать ошибку и повторно запускать соединение с Битрикс24. Проблема повторяется на разных версиях коннектора и платформы. Наша конфигурация
Точное место возникновения ошибки В последних отчётах зафиксирована следующая последовательность: Б24_К_ЛонгПуллингКлиентСервер.Модуль(128): Б24_К_ОбщегоНазначенияВызовСервера.ДобавитьВЛог(...) Б24_К_ОбщегоНазначенияВызовСервера.Модуль(1277): НовыйЭлемент.Записать(); Конфликт блокировок при выполнении транзакцииНасколько я могу судить по стеку, исключение возникает при записи сообщения в собственный журнал коннектора — через ДобавитьВЛог(). При этом сама запись в журнал, судя по всему, не является основной операцией обмена, однако ошибка её выполнения приводит к прерыванию Long Polling. Аналогичные конфликты возникали и ранее, в октябре, на более старых версиях. Что уже проверяли
В чём хотелось бы разобраться Буду благодарен, если подскажете:
При необходимости могу предоставить ZIP-отчёты платформы по каждому из случаев ошибки, технологические журналы, полные стеки исключений и дополнительные сведения о конфигурации. Проблема для нас достаточно существенная, поскольку после прерывания Long Polling обмен останавливается до повторного запуска соединения. Очень хотелось бы устранить первопричину Заранее большое спасибо за помощь и за развитие коннектора! |
|
|
|
|
|
Забыл написать, природа ошибки не периодичная, она точно связана с пользователями которые через тонкие клиенты приходят в ту же базу файловую на которой запущено соединение с Битрикс24. Ошибка на сервере происходит сразу как приходят люди на работу утром. При этом в тонких клиентах они у себя конечно ничего не видят плохого работают как работали, но интеграция отваливается на сервере.
|
|
|
|
|
|
|||
|
|
|
По коду подтверждается: запись информационного сообщения в Б24_К_Логирование выполняется без обработки исключения, а в Long Polling вызов ДобавитьВЛог() находится до блока Попытка. Поэтому обычный конфликт блокировки при записи лога завершает соединение. Поправим это, сделаем ограниченные повторы записи, а при неудаче — запись в журнал регистрации 1С и продолжение работы. Одновременная работа пользователей и IIS с файловой базой действительно может вызывать блокировку. Но текущий стек показывает только «жертву», а не владельца блокировки. Для его поиска соберите ТЖ с событиями EXCP, EXCPCNTX, TLOCK, TTIMEOUT, TDEADLOCK за несколько минут до ошибки, включая процессы IIS и пользовательских сеансов. Временно попробуйте отключить хранение истории взаимодействий и полностью перезапустить Long Polling, поскольку настройки читаются при запуске соединения. |
|||
|
|
|
Большое спасибо за подробный ответ и подтверждение причины проблемы! Настройку хранения истории взаимодействий мы уже отключали ранее, ещё в октябре, и после этого полностью перезапускали соединение Long Polling. К сожалению, конфликты блокировок продолжились, в том числе 11, 12 и 13 ноября. Технологический журнал у нас уже включён. Сейчас регистрируются EXCP, TLOCK, TTIMEOUT и TDEADLOCK, с сохранением файлов за 20 суток. Дополнительно включим EXCPCNTX и подготовим журналы по процессам 1С и IIS за несколько минут до возникновения ошибки. Очень радует, что удалось определить место возникновения исключения и что планируется исправление с повторными попытками записи и продолжением работы Long Polling. Будем благодарны, если подскажете, в какой ближайшей версии коннектора ориентировочно планируется это исправление. Спасибо за помощь! |
|||||
|
|
|
|
Добрый день, подскажите пож-та, когда исправите баг с неправильной передачей габаритов и веса из Б24 в 1C УНФ фреш? Вы как бы писали что уже исправили, но по прежнему ничего не работает. Складывается впечатление что вы либо не понимаете в чем проблема, хотя подробно её описал выше в теме, либо тут пишите что сделали, а на самом деле даже начинали работать над решением.
Подскажите какая сейчас проблема с передачей между этими двумя решениями в плане передачи веса и габаритов? (Интересно, занимались вы этим вопросом или нет) Люди за свои же деньги получают гору проблем и полное безразличие со стороны разработчиков. |
||||
|
|
|
|||
