Стоит задача выгружать из 1С изменения по некоторым данным (например изменения номенклатуры, цен, остатков)
Конфигурация не важна (в моем примере ут 10.3, сервер)
Необходим механизм, именно на стороне 1С, позволяющий оперативно выгружать информацию в стороннюю программу.
Варианты:
1.    Как в стандартном обмене с сайтом писать изменения в план обмена. Затем фоновым заданием (в цикле или с периодичностью) считывать изменения и отправлять  - плохой вариант т.к. либо цикл либо та же периодичность задается.
2.    «При изменении» запускать фоновое задание, которое отправит необходимые данные. В тесте при больших нагрузках возникают блокировки и плодятся фоновые задания. Возможен вариант оптимизации, но не нравиться отсутствие контроля запускаемых пользователем фоновых заданий.
3.    «При изменении»  писать в некий регистр сведений, читать из него в фоне и отправлять данные – буду пробовать.

Кто-нибудь сталкивался с похожей задачей на практике? Может есть ещё какие-либо варианты или идеи…

А чем 3 отличается от 1 ?

(0) есть 4 вариант, таскать данные с сиквела через триггеры, самый лицензионно-грязный и самый шустрый

Можно и без изменения конфигурации
http://infostart.ru/public/153884/

автору предлагаю оставить одну (ну, или n) очередь и воспользоваться вариантом (2)

хотя это уже вариант 1

(1) ты мучения Гения нашего не помнишь с его велосипедами с РС и обменами?

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

(7) для real-time это не катит

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

(8) Почему? По сути это близко к реал тайму. А иногда может быть и быстрее, т.к. не нужно запускать дополнительные потоки.

проще всего - обмениваться через текстовый файлик

(1) Третий вариант ещё только попробую.
Отличается тем, что изменения из плана обмена можно выбрать запросиком раз по расписанию регламентного задания, а из регистра можно вытянуть например при добавлении записи.

(10) хотелось бы обойтись без запуска регламента каждую минуту. Сейчас запущен обмен который с очереди таскает в 1С данные когда они есть в фоне. Утром запускается, вечером отрубается. Хотелось бы тоже самое, только в другую сторону и с учетом того, что если вдруг что-то не отправилось, то можно понять что именно не отправилось и потом обработкой или в ручном режиме послать таки.

Можно кстати использовать для обмена MSMQ

v8: Подскажите как связать 1Сv8 и MSMQ

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

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

(14) Ну что-то похожее и используется. Как посылать сообщения не вопрос. Вопрос примерно такой: по какому принципу именно в 1с формировать очередь чтоб послать в очередь MQ )

(0) "3.    «При изменении»  писать в некий регистр сведений, читать из него в фоне и отправлять данные – буду пробовать.

зачем? если уже есть встроенный механизм регистрации изменений для обмена

(16) А при записи нельзя сразу в очередь поставить и оповестить клиента?

(18) При записи на стороне клиента - если проводится большой документ переоценки может относительно долгое время занять процедура. На стороне сервера - получается вариант 2 со своими недостатками.

(16) Или как в 7. Делать очередь на регистрах сведений и использовать вместо критических секций блокировку на записи регистра. Смысл в том, что если поток обработки работает то ничего дополнительно делать не надо, если не запущен то запускаем поток.

(19) Ну так поставил в очередь MSMQ а клиент будет постепенно вытаскивать данные и записывать. Вариант с MSMQ  намного интересней.

(20) Я правильно понял что так получается один поток?

(22) Да. Но можешь использовать и пул потоков и потоко безопасную очередь.

(21) Совершенно верно, но как поставить в очередь MSMQ?
Допустим документ изменения цен проводится. Если при записи или проведении на клиенте то может быть долго. Если на сервере, то это либо один поток, либо неограниченное количество потоков которые возникают по действиям пользователей.
И в таком варианте не отследить что и когда отправил.
Если обработкой ппо плану изменений то по регламенту в цикле как типовой.

(23) Согласен, такой вариант думаю попробовать. но есть определенные опасения за производительность.

(23) Смотря где. При записи лучше использовать по минимуму потоков, так как можно нарваться на блокировки. Там как раз удобен однопоток.
При использовании MSMQ ты поставил в очередь и оповестил клиента. А клиент уж сам будет выбирать из очереди и организовывать.

А что мешает повесить подписку на событие и писать изменения в какую нибудь базу по ADO?

(27)Я вроде уже пробовал так... Пользователь проводит документ 1000 строк, есть подписка на событие "при проведении" в которой отправка сообщений есть.
Пользователь в результате будет ждать пока отработает процедура отправки сообщений, так?

На практике использовал вариант 2.
Подписка на событие + фоновое задание.
Данные уходят в sql базу.

(29) В подписке на событие что-то типа: ФоновыеЗадания.Выполнить("ОбшийМодуль.Блаблабал", МассивПараметров, Ключ, "Синхронизация");

(30) да

(31)А при активной работе пользователей сколько максимум фоновых заданий было? примерно...

(32) не считал, но много
у меня подписка на регистр бухгалтерии
например, вчера запускал групповое проведение параллельно на 2 юрлица, ошибок обмена не было

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

ОжидатьЗавершения тебе поможет

(35) Спс. Попробую. Но ведь тогда очередь из ожидающих фоновых заданий может получиться большая?

(36) здесь остается только максимально оптимизировать время выполнения обмена

с sql.ru :
"Вам нужна хорошая промышленная реализация очереди сообщений.
Это может быть, например, MSMQ, JMS, IBM WebSphere MQ.
Из бесплатных реализаций очередей - Apache ActiveMQ.

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

Если рассматривать конкретные платформы:
WCF, например, позволяет использовать MSMQ в качестве транспорта, есть сторонние адаптеры под WebSphere MQ
J2EE сервера все реализуют JMS"

есть еще Apache Qpid http://qpid.apache.org/

(38)"..Вообщем виде надо выделить какой то сервисный уровень, который будет отправлять сообщения в очередь.." - у меня сейчас только с этим куском загвоздка.
Так обмен с RabbitMQ работает отлично.

(40) А в чем проблема? Сериализвал в XML строку. Отправил в очередь. Через Web сервис оповестил клиента с последним номером сообщения. Клиент уже организует выборку очереди. Если выборка запущена, то ничего не делает, если нет то запускает поток на чтение очереди. При этом раз в минуту можно запускать на чтение очереди если что то пойдет не так. Обрыв связи итд.

(41) "Отправил в очередь" - можно сказать сейчас речь о том где вызывается в 1С процедура отправки в очередь?

Ну отправка в очередь понятно где вызывается там где и произошли изменения. А вот записывашь ты наверное в другую базу из базы где произошли изменения через COM?

(43)Не, вот  Happy Bear верно понял проблему ))
"Ну отправка в очередь понятно где вызывается там где и произошли изменения" - провели документ установки цен, тыща строк. Где вызвать процедуру отправки?

В процедуре при изменении. Сериализация тысячи строк это мизер.

Тебе нужно грамотно выбирать очередь.

Где проще использовать мьютексы семафоры

(45) Сериализовать мне надо в JSON что работает дольше чем ХМЛ, и не просто строку документа, а лефтджоином брать свойства номенклатуры и характеристики из регистра свойств
Поэтому есть некоторые задержки от которых не может страдать  пользователь ожидающий выполнения операций. Поэтому просто при изменении низя это вызывать)

а если в подписке послать во внешнюю систему только ссылку на измененный документ, а она в порядке очереди будет через сервис читать то, что надо (там и все соединения с характеристиками прописать) и писать данные из них в себя, получится проведение тормозить не будет, а будет только очередь из внешних запросов к базе

Ещё, кстати, надо учитывать, что если писать в ПриЗаписи куда-то наружу, то можно получить расхождения с 1цэ из-за отката транзакций.
В этом плане использование планов обменов самое надёжное решение.

(49)Интересный вариант. Но "внешняя система" это просто очередь. И из неё читает cmsсайта, которая никакого доступа в 1С не имеет. Если б целью обмена была бы другая база например, то все ок. Или прослойку какую-то делать нужно...
(50)Планы обмена наверное да, самые надежные. Но есть определенная задача и их использовать тут не очень удобно

(2)    "shuhard: есть 4 вариант, таскать данные с сиквела через триггеры, самый лицензионно-грязный и самый шустрый"

интересно такое кто-нибудь реализовывал?

(52) Делал доп лог на изменение журнала документов в 7.7. с помощи тригеров. Запись лога идет в отдельную базу. Все быстро не заметно. Четыре года отпахало, 20 юзеров любящих обработки c загрузкой  из текстовых файлов.

Рассказывали про реализацию, когда на регистре сведений висел тригер. Если в РС появлялась запись, скриптом запускалась 1с, которая запускала обмен.

Я кстати за план обмена. При обмене очень важно понимать что данные изменились. А так же что данные дошли до сторонней базы.

я за (1) РИБ с отключенной галочкой :)

(52)[интересно такое кто-нибудь реализовывал?]
неоднократно
структура базы 1С на сиквела тупа до безобразия

(55)К сожалению не сталкивался, сложно будет за короткий срок реализовать.
Запрос навесить на триггер в скуле, вытянуть нужные данные, затем как-то через внешние функции всё в json запихать а потом подключить бибилиотеку rabbitmq и послать сообщение. Уверен что прирост скорости будет не хилый и если со всем этим разберусь то будет круто, но сроки...
(53)(54) Через план обмена - это типовой обмен считай. Либо регламентное задание, которое раз в несколько минут запускается, либо, пробовал, фоновое постоянно работает и в цикле читаем изменения и отправляем. Это работало, но как-то не очень красиво ))

Если воспринимать план обмена, как очередь изменений ожидающих передачи в другую программу, то такой путь ниже чем не реалтайм?

1. Читаем и освобождаем очередь изменений (план обмена).
2. Выгружаем изменения.
3. Пункт 1.

И вообще что такое реалтайм, если скорости возникновения изменений их передачи и приема не совпадают?

(48)  Делал выгрузку из 7 в 8 ку через объекты XDTO и прямые запросы. Скрость высокая. Аналогично и  здесь можешь например на C# написать выгрузку через прямой запрос и json. 1000 строк это мизер.

Реалтайм - это xenomai  и реалтайм ядра
Все остальное подвержено квантованию на уровне юзерспейс приоритета и в итоге будут данные пропадать.
https://www.olimex.com/forum/index.php?topic=812.75

(59) запутал еще больше;)))

(60)Нагружай мозги по полной, потом перерывчик и на тебя снизодет озарение

триггеры и еще скорее всего ssis

(48) Может пригодится
http://speshuric.livejournal.com/163665.html

(59) э... чо? 1С и квантовый параллелизм... может в 1С 9.0 такое будет. Настоящего риал-тайма конечно не добиться ) Даже если под QNXом 1с запустить
(63) Спс. На этом можно выиграть время. Сформировать xml и затем с помощью какой-либо внешней библиотеки преобразовать в json. Либо отправлять xml и сериализацию в json делать где-то там на сайте, но это уже если договорюсь

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

(64) Тебе лучше использовать планы обмена с регламентом раз в минуту и ключом, что бы если регламентное задание не закончилось второе следующее не начиналось. Ну и конечно можно ускорить выгрузку используя компилируемые языки. И если лезть в дебри тригеров можно сначала сделать прямой запрос и сериализовать его в джейсон

Если начнешь писать пряме запросы то вот некоторые ссылки
v8: Перевод Запроса 1С в SQL?
v8: Как перевести ГУИД в число и обратно?

вариант 1 с заданием раз в 30 сек (если выполняется предыдущий экземпляр, то новый не запускать). В реальной работе задержка будет незаметна