Доброго времени суток, уважаемые форумчане!

Прошу вас просветить меня по одному теоретическому вопросу.
Есть две базы 1С 8.3. Есть необходимость наладить оперативное взаимодействие между ними
в реальном времени. Например, при проведении в первой базе документа "ЗаказКлиента" обработчик события проведения
должен открыть вторую базу, создать в ней документ "ЗаказКлиента" - копию проводимого в первой базе и вернуть в первую базу
информацию о том, удалось ли создать во второй базе документ. Если не удалось, то в первой базе должна сгенериться
ошибка проведения заказа, и заказ должен остаться непроведенным.
Я знаю только один способ общения с другой базой 1С 8 - это использование COM-объектов.
Но этот способ ненадежен - из-за каких-нибудь внешних причин (например, автоматических обновления операционной системы на сервере)
COM-объекты вдруг могут перестать работать.

Подскажите, пожалуйста, есть ли другие способы, позволяющие решить эту задачу?

Заранее благодарю.

(0)[есть ли другие способы, позволяющие решить эту задачу?]
безусловно:
планы обмена
УРБД
веб сервисы

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

При проведении по кому лазить - это очень плохая идея. За это очень часто отрывают ППП автору такого решения.

(1) shuhard, мне надо, чтобы именно во время проведения выл отправлен запрос другой базе и получен от неё ответ, и в зависимости от этого документ был проведен или не проведен. Первая база - УТ11.4, вторая база - это УПП 1.3, обычные формы. Её не получится опубликовать на веб-сервере.

(4) "мне надо, чтобы именно во время проведения выл отправлен запрос другой базе и получен от неё ответ"

Тебе отрежут ППП за такое решение, зуб даю.

(4) " вторая база - это УПП 1.3, обычные формы. Её не получится опубликовать на веб-сервере."
И снова обман... Все вокруг врут, как говорил один доктор...

ДенисЧ, а какие еще варианы?

(7) Отказаться от такой дурной идеи. И делать на очередях.

(4) "мне надо, чтобы именно во время проведения выл отправлен запрос другой базе и получен от неё ответ, и в зависимости от этого документ был проведен или не проведен. "

Вам этого не надо.

Вот вам дают же совет, остановитесь.

"Её не получится опубликовать на веб-сервере."

И что же мешает?

(7) ДенисЧ, Вы не могли бы пояснить, что значит "на очередях"?

Вместо КОМа использовать оДату.

(10) Ставить запрос на создание документа в другой базе. Асинхронно проверять его результат. По результату принимать решение.
В транзакции делать какие-то соединения с ненадёжным (да хоть и с надёжным) внешним источником - за такое не только с работы, но и в окно 10го этажа вылететь можно

(3) если COM-объект хранить (в модуле с галочкой "повторное использование")
а не соединяться каждый раз
то будет работать быстро и хорошо :)

(13) Не будет. КОМ в 8.3 сдохнет минут через 5. (В 8.2 дох через 20 минут)

(14) это если его не дергать?

(11)Даже интересно стало, что такое "оДата"?

(16) https://yandex.ru/search/?text=1с%20oData&clid=2233627&lr=14
(15) Я дёргал каждую минуту. Правда, это был не 1с-com, а ADODB, но разницы никакой

(17) Тогда уже лучше чистый веб-сервис, он же полегче и потоньше.
Но один хрен это говнокодинг. При проведении этот коннект периодически будет устраивать ад в базе

А если в документу УТ добавить реквизит ПроведеноВУПП и в плане обмена сделать связь с проведением документа.

(0) Сторонний веб-сервис (с очередью), который будет обменивать данные между базами. Всё по HTTP.

(20) 3achem, это надо будет публиковать обе базы на веб-сервере?

(4) а что там такое во второй базе делается, что это критично для проведения в первой? может правильнее пересмотреть построение системы?

(21) Веб-сервисы появились аж в 8.1, до публикации базы целиком.

(0) а зачем такие извращения?
ну то есть, почему нужно узнать удалось создать документ или нет?
вопрос с префиксами и номерами?

(24) Может, там у него резервирование идёт... Или сраз выпуск/упаковка продукции...

(25) тогда правильнее формировать документ во второй базе.

(26) Так он там и хочет формировать )))
А в первой у него фронт для покупателей...

Всё равно какая-то ерунда в проектировании.

Правильное решение - выкинуть одну базу целиком и весь учет вести в одной базе.
А так да, пусть мучается.
А потом полёт, с 10 этажа

(0) какова цель вот этого: "Если не удалось, то в первой базе должна сгенериться
ошибка проведения заказа, и заказ должен остаться непроведенным"? Почему существует такая зависимость?

(29)Может ещё распределёнка понадобиться. Автор не сказал, для чего вся веселуха?

(0) > COM-объекты вдруг могут перестать работать.
Бывает, например, у 2-й базы платформу обновят... У меня Альфа-Авто с базой партнера УПП по COM лет 7 обмениваются. Правда не каждый день случается. Главное номер документа правильный вернуть из 2-й базы, это только COM может.

(32) "Главное номер документа правильный вернуть из 2-й базы, это только COM может."

Почему именно у COM такие сверх способности? Почему REST не подходит?

Внешние источники данных? Базы же на 1 сервере работают?
А вообще это все бред какой-то

(21) Нет, ничего делать с базами не надо

(0) "при проведении в первой базе документа "ЗаказКлиента" обработчик события проведения
должен открыть вторую базу" - сразу фтопку! Автор этого предложения понятия не имеет, как работает 1с. Шли его в... тундру.

COM старайся не использовать. Лучше веб-сервисы.

Господа, причина здесь в общих чертах такая - на базе УТ11 разработан некий функционал, которым клиент очень хочет воспользоваться. Но он работает на УПП. Съезжать с УПП и переходить на УТ11 он ни в какую, и нам перерабатывать функционал под УПП тоже долго и несерьезно. Поэтому решили так - те сотрудники клиента, которые должны работать с функционалом, будут с ним работать в УТ11, остальные сотрудники останутся на УПП. Но функционал рассчитан на то, что в этой же базе создаются заказы. Но при этом ирнформация об актуальных остатках, логистика и т.д. ведется по-прежнему в УПП. Поэтому и надо, чтобы при создании заказа в УТ11 создавалась его копия в УПП, проводилась, делалось резервирование - и после этого заказ проводился в УТ11.

(37) получить актуальные остатки, логистику и т.д. из УПП и выполнить нужные проверки перед записью заказа в УТ не предлагать?

(37) Допустим.
А теперь объясни, что это за функционал такой, который нельзя перенести на УПП.

(37) разработать функционал ввода заказов как в УТ это "долго и несерьезно"? Конечно серьезней это рассматривать ком-соединение при проведении документа...

(38) OpKc, предлагать. Но такой способ не даст нужной оперативности, если два пользователя в УТ11 в один момент станут проводить заказы на один и тот же товар. Стопануть одного из них должна именно УПП.
(37) Это работа с телефонией (обзвон клиентов, прослушивание звонков, бизнес-процессы обзвона и т.д.) Одна из функций - прямо из отчета по обзвону генерируется заказ клиента. Реализовано все это на управляемых формах под УТ11. Поэтому перенос на УПП - дело долгое

(41) тогда надо делать чтобы из отчета формировался документ в УПП, запускался функционал и после того как получено разрешение формировать заказ в УТ.

(37) Совсем что ли рехнулись? Проводить документ и залезать в другую базу. Переносите нужный функционал в УПП. А то сейчас выяснится что менеджеру нужен 1 документ, в котором он заполняет 2 реквизита.

(35) 3achem, не могли бы Вы вкратце пояснить, как должен быть организован сторонний веб-сервис с очередью?

(41) бред бредовый. что мешает в упп управляемые формы врубить и работать без извращений?

(0) Да, есть метод, он называется примерно так: НРЧТХ - надо рассказать что ты хочешь. Не надо говорить что ты будешь делать, надо цель свою обозначить. В 95% задачах, когда надо что то где то генерить, то это делать вовсе не нужно, и задача решается управленческим решением, а не бредом инженера, который через com 2 базы соединяет.

(44) Да не нужна тебе эта порнуха. Зачем ты хочешь гуиды резервировать?

Вот просто объясни для чего тебе резервировать гуиды? Только не говори что просто хочется.

(0) ну а почему нет ? Com заявлен как один из
Вариантов api. Только засунуть его в перед записью ...где
Транзакции нет и норм

А как ТС узнает документ проведется или нет? перед записью, это начало долго пути, на котором могут быть препятствия

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

Разберись с SQL. Создай триггер и пусть SQL сама там синхронизирует.
Как то так http://catalog.mista.ru/public/235474/

(52) синхронизация тут не нужна, читай тему

(37) наркомания, товарищ.

уж лучше сделайте в УПП аналогичный функционал, чем такую кашу варить

(+54) В УПП нужен только отчет, данные для которого через COM из УТ и таскать.

2(0)(37) тема указана не верно. Нужно переименовать:
"Как вечно доить клиента-лоха?"

Раньше ржали над таксистами в нерезиново: "А дорогу покажешь"
Теперь появились спецы автоматизаторы: "А как сделать научишь/расскажешь?"

(41) "если два пользователя в УТ11 в один момент станут проводить заказы на один и тот же товар. Стопануть одного из них должна именно УПП. " - и в чем проблема?
Первый пользователь жмет кнопку в УТ 11 -> пошло обращение к УПП, там все проверки, с проведением документов, транзакциями.
Второй пользователь жмет кнопку в УТ 11 -> пошло обращение к УПП, там такие же проверки.
Или одновременно в УТ 11 тоже проверяются остатки? Тогда блокировку и в УТ 11 тоже можно наложить. Да, будет подольше, т.к. будет включать все проверки УПП, но куда деваться.

(57) Ещё один... При проведении лезть в другю базу - за это приличные люди отрезают ППП.

(58) +100500

(44) RabbitMQ или любой другой брокер сообщений (хоть самописный на связке pyhton + sqlite). Схема у вас простая База А (передаёт) -> База Б (слушает). Только в схему добавляется брокер База А -> Брокер -> База Б. И никаких com объектов и прочего мусора.

Я только из-за этого топлю за внешних брокеров, чтоб всё без com и желательно без выкладки базы на веб сервис.

(37) Функционал для УПП1.3/УТ10 на УФ встраивается только в путь. Или у вас актуальная БСП используется? Я вот смотрю, как Wizard для УПП сделал свою доработку, там тоже и из БСП куски, обычных форм нет. Все возможно. Конечно, платформа 8.3 в режиме совместимости 8.2.16.

(33) REST в 8.3 появился, не пробовал. Как с помощью REST получить номер для документа другой базы партнера?