Вопрос к уважаемому Serginio1

Предыстория:
Есть 12-летняя система контроля запуска посетителей на мероприятия. Написанная на 77. Неудобна лишь тем, что сканирование с помощью ручных сканеров через терминальные сессии.

Есть моб. приложение на Android. Которое умеет распознавать штрих-коды и отправлять их значения GET-запросами на онлайн-сервер системы учета билетов (не 1С). Документация по приложению есть, тут проблем нет.

Так как на многих площадках в момент запуска людей хромает Интернет по разным причинам, там используется система на 1С 77 (оффлайн), по локальной сети.

Хочется связать моб. приложение с оффлайн 1С 77, удобнее телефоном сканить, без этих ручных сканеров с терминалами.
Но, в 7-ке нет http-сервера.

И тут выбор:
1. Можно поискать специалиста, который сваяет серверное оффлайн-приложение на чем-нибудь, кроме 1С.
2. Можно и с 1С8. Но для целей сканирования оффлайн - слишком громоздко. Да и переносить готовое и уже отлаженное в 8-ку пока не хочется.
3. Или же попросить форум помочь понять - иду ли в верном направлении и можно ли в семерке:
- отследить через NetObjectToIDispatch45 поток GET-запросов, которые должны выполняться последовательно (Нужно получить в 1С запросы на URL вида http://192.168.0.1/ScanTicket.aspx?barcode=1234567890, которые отправляет Android-приложение с около 10 устройств)
- отправить ответ приложению (текст вида "Билет действителен")
Может есть какой-то пример кода в 1С для NetObjectToIDispatch45?

С .net и с пониманием принципа работы из статей Serginio1 у меня все плохо.

Нарыл на просторах код для ElisyNetBridge, с надеждой, что поможет с наскока для NetObjectToIDispatch45, но знаний нет, ковырял-ковырял, на этапе buffer = encode.GetBytes(responseString) - получаю  Поле агрегатного объекта не обнаружено (GetBytes)
пробовал encode = net.ТипКакОбъект("System.Text.Encoding"), но там ошибка NetObjetToIDispatch45: Не удалось привести тип объекта "System.String" к типу "System.Type".

Общий код такой:

Процедура Тест()
    
    net=СоздатьОбъект("NetObjectToIDispatch45");
    net.УстЭтоСемерка();
    
    Попытка    
        listener = net.СоздатьОбъект("System.Net.HttpListener");
        listener.Prefixes.Add("http://*:8080/");
        listener.Start();
        
        Сообщить("Прослушивание...");
        //Метод GetContext блокирует пока ждет запрос.
        
        cont = listener.GetContext();
        request = cont.Request;
        Сообщить("1. "+request.RawUrl); //тут получаю url успешно
        // Получить объект ответа
        response = cont.Response;
        Сообщить("2. "+response.StatusCode); //тут получаю 200 успешно
        // Создать ответ - HTML-строку
        responseString = "Ответ от HttpListener";
        encode = net.ПолучитьТип("System.Text.Encoding");
        buffer = encode.GetBytes(responseString);
        
        // Получить поток ответа и записать ответ в него.
        response.ContentLength64 = buffer.Length;
        output = response.OutputStream;
        output.Write(buffer,0,buffer.Length);
        
        // Необходимо закрыть выходной поток.
        output.Close();
        listener.Stop();
        Сообщить("Успешно.");
    Исключение
        Сообщить(ОписаниеОшибки());
        listener.Stop();
        net = "";
    КонецПопытки;
    listener  = "";
    net = "";
КонецПроцедуры // Тест


Веб компонента для 7.7 не ?

(1) Спасибо, ушел искать/изучать. Не знал, что такое есть

(0) Не совсем ясна схема которую вы хотите. Если хотите получать запросы непосредственно с андроид приложений - это несколько затруднительно с архитектурной точки зрения (http-сервер в 77 - очень плохая идея). По хорошему нужен сервис (локальный), который бы опрашивала 1С (отдельный сеанс-робот по внешнему событию).

(3) Да, именно это нужно - получение непосредственно с андроид приложений.

Предполагаемая схема такова:
1. Ноутбук с установленной семеркой, IIS
2. до 10 людей с телефонами с android приложением, с которых идут http-запросы на этот ноут.
3. 1С их должна словить, обработать и отправить с минимальной задержкой ответ на этот запрос обратно "в риалтайме". А приложение получает ответ из 1С как ответ на свой GET-запрос.
Сервис может быть и ок, но вот я затрудняюсь сказать что лучше (быстродействие и т.д.) и прощупываю варианты. Причем, если в 7-ке я смогу чего-то написать, то доп. компоненту уже не осилю самостоятельно.

Garykom - он там на Го ваял такую прокладку
посмотри полистай у меня в группе складских/тсд/адресных приблуд https://infostart.ru/community/groups/22/publications/
- листай там, там всякого есть...

(4) если извращенно: поставь 8-ку, на ней подыми сервис, который будет общаться/воротами для запросов снаружи.
8-ка будет по COM дергать 77. ну и в 8-ке главное чтобы не потерялись запросы

есть v7server.dll в интернете. это com служба запускающая пул из 1с77
+ сайт из 1й странички:
If Request.QueryString.Count=0 Then
   Response.Write "(!)Что вы хотели узнать?"
Else
   Dim str_in
   Dim str_out
   str_in=Request.QueryString("w")
   set v7=CreateObject("v7Server.Connection")
   v7.ParametrWEB = str_in
   str_out = v7.EvalExpr("ProcessWEB()")
   If Response.IsClientConnected Then
      Response.ContentType = "text/xml; charset=windows-1251"
      Response.Write str_out
   End If
End If

Если есть онлайн-сервер системы учета билетов, в который идёт информация при сканировании этих билетов, то что вообще делает 77 в этой связке? Система контроля запуска на мероприятия? В чём заключается этот контроль? А что тогда делает онлайн-сервер учета билетов? ИМХО надо более развёрнуто рассказать про то, что уже есть и то, чего хотелось бы получить в итоге.

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

(1) поглядел, не, там все как-то не то, что нужно.
(5) Спасибо, гляну
(6) да, вариант, просто у Serginio1 получил уже в 1С сам http-запрос со сканера. Одна загвоздка - отправить ответ обратно (там явно я по синтаксису неверно что-то пишу). И все, вопрос решен. Но если не получится, то да, вариант с прокладкой останется.
(7) Спасибо, погляжу

(8) Онлайн-сервер работает в случае адекватного Интернета на площадке. И при наличии не более 5000 посетителей (когда мелкие проблемы с Интернетом не задерживают запуск посетителей).
Самописная конфа 77 используется, когда нет возможности организовать нормальный Интернет.
Например, вышки моб операторов начинают сбоить после того, как в одну точку приходит более 5000 человек (стадион, парк, поле или какой-нибудь Дворец Спорта). Были ситуации, когда нехорошие люди ставили глушилки связи. Или на площадке бетонные перекрытия/подвальное помещение и проблемы с 3G/4G. Или просто физически на входных группах нет оборудования для выхода в сеть. Поэтому в таких случаях на массовых мероприятиях прокладывается локальная сеть для сканирования билетов. Без выхода в Интернет.
Сама оффлайн система контроля, которая на 77 - это БД, в которую заранее до начала мероприятия подгружаются данные по всем действительным билетам (Уникальный штрих-код/цена/когда покупался/где и т.д., к которой подключается человек-контролер со сканером ШК. Когда человек приходит на концерт с билетом - идет сканирование ШК на билете и проверка на наличие в БД/не проходил ли он ранее/выходил ли из площадки/дополнительная инфо (кто покупал, когда и т.д.). Чтобы, например, по одному билету вошел один человек, а не несколько, или если что-то произошло (драка/теракт/в обморок упал) или пришел на концерт, а потом заявление в MasterCard на возврат денег по причине неоказанной услуги.
Онлайн - все то же самое, только БД билетов на удаленном сервере.
То есть, фактически за час-полтора-два надо быстро и без тормозов проверить 5/10/60К человек. А большинство ж еще приходят без пятнадцати минут начало.
Поэтому онлайн-мониторинг в этом случае не подходит. Нужно обойтись без Интернета.

ИМХО лучше локальный веб-сервис сделать с локальной БД, безо всяких 1С. То есть - андроид-девайсы быстро сканируют ШК, получая (размещая) данные в БД. Конечно это затратнее по времени, но правильнее.

(11) тут надо актуальность поддерживать локальных БД, иначе через 2 разных входа с копиями билета одновременно зайдут.

(10) Да, это вариант, который да, вполне хороший и правильный - если не взлетит с 77.

(11) Локальная БД всегда одна. Если площадка с хорошим Интернетом - то онлайн (оффлайн тогда не используется вообще, нет смысла). Если с плохим - то заранее всегда готовится только оффлайн база, и посетителей запускают только через нее. Требований каких-то больших к железу и необходимости разделения локально БД нет, так как и сейчас 10К людей спокойно заходят через 10 входов за час с использованием одной БД 77 на нетбуке 10-летней давности с XP. По серверной части все работает. Одно неудобство сейчас - табуретки на входах еще с 10-ю нетбуками с воткнутыми сканерами на каждом входе, которые же надо еще и к розеткам (провода, оборудование, куча лишнего времени на установку, люди спотыкаются, некрасиво).
Так же есть давнее оффлайн-приложение на .net, которое как раз работает с этими же android-приложениями по http, но в нем ни отчетности красивой, ни настроек полезных (вида "пересадка, поменяйте билет" или "Сектор 1 с фанатами" идет только в эти две двери, сантехник - в эту дверь, все остальные - вот туда, или звук из HL2 проиграть при повторной 10-й попытке пройти с фальшивкой "Гражданство отозвано, статус - злостный нарушитель" и т.д.) - а в 77 уже эти и другие штуки сделаны.
Можно, конечно, и дотнетчика нанять и подлатать, чтобы "как в 1С", но это ТЗ писать, тестировать, а если накосячил, то и не выявить и не исправить мной :)

RabbitMQ в архитектуру просится, ИМХО.
А требование стабильного инета уже лет 10 как просто реализуемо - просто люди не пойдут туда, где нет 3G.

(13) просится, если бы это была бы установленная на стадионе система контроля, где людей больше 30К. Но обычно очереди в сканировании более 5 сканов одновременно не бывает, да и обрабатываются эти ситуации. Нет сильной нагрузки, поэтому RabbitMQ мне кажется, тут излишний
Интернет - не соглашусь. Зависит от площадки, и на практике часто получается, что обещают 4G, а пришло 1000 человек и уже далеко не 4G. Попробуй как-то на концерте, стоя в толпе написать кому-то в вайбер, например.

(4)  По 3 пункту не совсем понятно, как 77 будет "ловить" http-реквесты которые приходят на ноут с IIS? Ещё и "обратно" отправлять ответы? Тут только IIS:
1) принимает запрос от клиента
2) дёргает 1С (тут варианты как реализовать)
3) получает ответ от 1С
4) отправляет ответ клиенту.

ну тут же ку3чка всяких умных программтистов. написали бы уже давно сервер-прокладку простейший.

(16) Ну вот же, в соседней ветке e-rogov сделал сам того не подозревая, кажется, именно то, что нужно ТС и не знает как продать. Правда там есть вопросы с параллельной обработкой запросов, с очередями, размерами буферов и т.п. Плюсом там избыточный функционал.
Лично я бы сработал по старинке - силами вебсервера делал бы всё во внешней к 1С базе. Инструментов навалом.

+(17) а если сильно надо дёргать 1С - на крайний случай, была же ВК файлового поллинга.

+(18) в качестве рабочего бреда - можно даже слать окну 1С WM_SYSCOMMAND тем же vbs и ловить формексом )))

Мне больше нравятся вэб сокеты
https://infostart.ru/1c/articles/434771/
Хотя можно пришпондорить и gRPC
https://devblogs.microsoft.com/dotnet/grpc-in-dotnet-6/

Ну или можно взять обмен по TCP/IP
https://infostart.ru/public/525806/
Легко можно переписать на том же Xamarin

https://infostart.ru/1c/articles/551698/

А проще и дешевле взять уже готовое решение типа
https://www.cleverence.ru/software/licenses/UP2-RTL15B-1C77/#spec