Всем привет. есть вопрос.
Раньше заказы падали в 1с через почту, 1С читал почтовый ящик и забирал письма с заказами.
Сейчас сделали загрузку заказов с сайта через WEBСервис, в который задания отправляет RABBITMQ.
Вопрос Насколько это изящный способ обмена, при условии что заказы должны падать без остановок?
Есть ли хорошие альтернативы данному методу?

(0) у нас обмен 1с с Битриксом через JSON, довольно удобная современная штука

(1) стандартный от битрикса?

я так понимаю сеанс 1с крутится, а если упал ?

(2) нет не битрисовский, (3) данной проблемы нету,если падение вовремя обмена или ошибка то придет соответствующий ответ или не ответ

(4) а как следить за "не ответ"?

(0) В момент создания заказа на сайте дергаем 1С через сервис, в параметрах передает данные заказа в виде JSON. Если 1С на связи и заказ в ней создался нормально, то на этом дело закончено.
Если 1С отвалилась или что-то пошло не так, то данные заказа записываются в файл и сохраняются  в некий каталог на сайте (по одному файлу на один заказ). Когда 1С поднимается, то регламентом лезет в этот каталог через FTP, скачивает файлики и загружает заказы. Это аварийный вариант.
По такой схеме  несколько наших клиентов работают уже несколько лет (один уже 4 года) без сбоев.

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

(6) Через кролика можно единый отказоустойчивый алгоритм создать

(8) Я не против!

(0) "Хорошей альтернативой" может быть передача информации не на ВЕБ сервис 1С, а по FTP. Транспорт тот же. Технология проверена десятилетиями. Библиотек готовый миллионы. Сайт вообще может не знать работает ли 1С. Если нужно - используются файл-флаги или отправляется запрос на сайт на повторную передачу.

+ (10) И да. FTP штатно более "многопоточен", чем 1С.

(10) И как же 1С узнает, что у нее там что-то новое появилось?

(12) Просканирует каталог входящих. Ровно так же как и по электронке. Только работа с файлами несколько попроще и понадежней, чем с POP или IMAP.

+ (13) Странно, что такого рода вопросы вообще возникают.

(14) Странно, что до сих пор возникают предложения организовывать обмен путем периодического сканирования каталога входящих. Я уже поднимал этот вопрос  ранее и приводил более чем подходящий пример. Этот как если ты каждые 5 минут бегаешь в сортир, чтобы проверить, не хочется ли тебе пописять. В нормальном организме для этого существует "событие" вместо "периодического регламента".

(6) приму к сведению. спс.

обмен через "папочки" устаревшая технология, очень много народу через JSON, прошёл ответ что все ок поставили признак успешной загрузки, нет продолжаем выгружать до "посинения" мы даже файлы таким образом отправляем преобразовав в Base64.
Если вопросы с безопасностью можно не на прямую, а через сервис очереди организовать

(15)
"Я уже поднимал этот вопрос  ранее и приводил более чем подходящий пример."
Да... Я помню терки за сеансовую безопасность в 1С. Только сейчас анонсирована поддержка пула соединений, удержание соединений... На тот момент ничего этого в 1С небыло. А вы и понятия не имели зачем оно нужно.

То же самое и с "событиями". Пока в 1С не появится чего-либо похожего на стэк/очередь событий - оно годится только для ларька с малонагруженным обменом. Для реальной работы оно еще очень не готово.

(17)
1. JSON - это формат представления данных. А не технология обмена.
2. "Сервис очереди" - вот именно этого и нет. Организовать на 1С пока не получится. Нужен дополнительный костыль.

(19) ну это понятно имею ввиду HTTP сервис в 1с в формате JSON

(18) Да-да, у нас же тут у каждого поголовно по 10 заказов в секунду надо загружать, веб-сервисы не справятся. А раз так, то надо организовать регламентное сканирование каталога 10 раз в секунду.
Удачи, чо.

+ (21) Кстати, с загрузкой 10 заказов в секунду 1С справится аж только так. При правильном кодировании, конечно же.

+(22) На веб-сервисах, имеется в виду.

(20)
1. "HTTP сервис в 1с" - кранты сеансовой безопасности. Любой неавторизованный сервис может слать любые запросы и они будут обработаны. Можно конечно учетные данные передавать в запросе и тогда сделать их (учетные данные) доступными любому встречному поперечному.
2. Накладные расходы на создание сеанса 1С могут быть очень большими. А он (сеанс) будет создаваться при каждом новом запросе. ЦЫ : https://wonderland.v8.1c.ru/blog/povyshenie-proizvoditelnosti-veb-servisov/

(22) "с загрузкой 10 заказов в секунду 1С справится аж только так." Это когда модуль внешнего соединения АБСОЛЮТНО пустой и параметры сеанса либо не используются либо заполняются простыми значениями при простейших условиях.

(24) поэтому я и написал по поводу вопросов безопстности в (17) использовать прокладку в виде сервиса очереди дабы закрыть плямой путь из вне в 1с

+ (25)
"Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие <b>ШАБЛОННЫЕ</b> операции, и обладающие <b>УНИФИЦИРОВАННЫМИ</b> привилегиями."
ЦЫ : https://wonderland.v8.1c.ru/blog/povyshenie-proizvoditelnosti-veb-servisov/

Вот тогда на тестовой площадке у них получилось вот что :
"Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с."

Как только вам понадобится более сложная логика, чем 1 запрос от неавторизованного сервиса никаких 10 заказов в секунду вы не получите.

Все перечисленное относится к 8.3.9.1818 и выше. Для более ранних релизов и того не получить.

(26) Ну все правильно. Нужна очередь запросов. И желательно с сеансовой авторизацией.
В варианте с FTP - сам FTP и есть очередь. Авторизацию можно задать любой существующей на сегодняшний момент сложности. Кроме того вы можете быть абсолютно уверены в том, что никакие сторонние запросы в 1С не попадут.
Есть минуса - обмен с сайтом в асинхронном режиме. По умолчанию. И ничего с этим в варианте с FTP не сделать.

(28) Ну, если не очень хочется FTP, то можно промежуточную SQL-базу - получится тоже самое, что и FTP, только проще.
Конечно, также будет лазанье каждый раз для проверки - а есть ли там чего-то нам, но будет меньше проблем со скоростью выполнения.

(24) "А он (сеанс) будет создаваться при каждом новом запросе" - да ну )

(25) А кто заставляет писать код так, чтобы модуль внешнего соединения был непустой, а параметры сеанса заполнялись "сложными значениями при сложных условиях"?

(30) "Недостаточная производительность веб-сервисов объяснялась тем, что <b>КАЖДЫЙ</b> вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса." ЦЫ : https://wonderland.v8.1c.ru/blog/povyshenie-proizvoditelnosti-veb-servisov/

Странно, что работая с ВЕБ-сервисами, Вы не заметили эту особенность.

(32) А про пул соединений там написать забыли?

(32) Пропиарюсь еще разок, раз случай подвернулся. http://v-can.ru/demo/site/itil/
Включайте фиддлер и смотрите, за сколько миллисекунд запросы к 1С выполняются. База 1С:ITIL с 54-мя параметрами сеанса, релиз платформы 8.3.8.2088.