Интеграция (Ich will version)

16.09.22

Интеграция - WEB-интеграция

+54 –

Поговорим про интеграцию с точки зрения архитектора.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
Интеграция (Ich will version): .zip 428,97Kb 9	9	Скачать (1 SM)	Купить за 1 850 руб.

Intro

Для начала, обозначу рассматриваемые вопросы данной статьи:

использование системы 1С как одного из сервисов внутри компании;
реализации Contract First подхода при написании http-сервисов;
tracing запросов - что это такое и для чего нужно 1С разработчику.

Так же, будет продемонстрировано использование "самописной" конфигурации, реализующей пример решения рассматриваемых вопросов. Данная конфигурация не является готовым продуктов и распространяется как есть. Скачать можно на GitHub. Используемая платформа 8.3.18.

Ich will

Что бы понять требования к одному из сервисов внутри компании, давайте составим общий "портрет" любого из сервисов внутри компании и совместим с возможностями прикладного решения на платформе 1С.

Очевидным будет признать - большинство популярных фреймворков разработки сервисов ориентированы на архитектурный стиль REST API. А самым используемым форматом обмена данными является JSON. Платформа 1С позволяет нам как создавать собственные http-сервисы, так и имеет средства работы с JSON. Фиксируем: REST API и JSON.

Далее, определим как мы будем документировать созданный сервис для себя и предоставлять описание сервиса другим разработчикам. Это должно быть универсально и всем понятно. Таким стандартом де-факто является спецификация OpenAPI, актуальной версии 3.0.2. Сама спецификация представляет из себя либо JSON либо YAML файл. Создать абстрактный JSON файл платформа 1С позволяет, а следовательно вопрос создания спецификации лежит только в плоскости ее наполнения. Для работы со спецификациями наиболее распространен набор инструментов Swagger, включающий в себя пользовательский интерфейс Swagger-UI для визуализации OpenAPI. Swagger-UI можно встроить как отдельный ресурс http-сервиса. Запоминаем: OpenAPI и Swagger-UI.

Спецификация сервиса должна быть сопуствующим артефактом работающей системы, но вот подходов к его появлению несколько: Contract First и Code First. Первый подход говорит нам - сначала разработай спецификацию (заключи контракт) и уже по ней пиши код, но и пока не изменится спецификация изменения в коде не должны нарушать заключенный контракт. А вот второй подход ровно противоположный - пиши код и спецификации будет сгенерирована на его основании, т.е. изменение кода ведет к обновлению спецификации. Кодогенерацию спецификации поддерживает большинство фреймворков, поэтому Code First подход довольно распространен. Для платформы 1С подход Code First реализовать возможно только на уровне вендора, но вот для прикладных решений такой возможности совсем нет. Нам остается Contract First.

И самым важным, по моему мнению, требованием будет возможность наблюдать работу сервисов - частота вызова, среднее время отклика, наличие ошибок и многое другое. Теория "Наблюдаемости" (Observability) систем нам подсказывает очевидный выход - Tracing запросов. Для его реализации есть универсальные Jaeger или Elastic APM. Я хочу Elastic APM.

Ich will dass ihr mir vertraut

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

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

Созданный http-сервис с настройками:

Как мы видим, для сервиса достаточно единой точки входа:

ОбработкаВызоваREST.ОбработатьЗапрос(Запрос);

Подготовка задачи

Что бы наглядно провести демонстрацию создания REST API поставим простую задачу - реализация CRUD функций для абстрактного справочника "Склады" с авторизацией для функций изменения данных.

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

Обработчики


Функция ПолучитьСклады(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Массив;
	ЗаголовкиОтвета = Неопределено;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции
Функция СоздатьСклад(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Структура;
	ЗаголовкиОтвета = Неопределено;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции
Функция ПолучитьСклад(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Структура;
	ЗаголовкиОтвета = Неопределено;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции
Функция ИзменитьСклад(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Структура;
	ЗаголовкиОтвета = Неопределено;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции
Функция УдалитьСклад(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = "ок";
	ЗаголовкиОтвета = Неопределено;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции

Созданный справочник и перечисление:

Произведем публикацию базы на веб-сервере под именем test.

Настройка сервиса

Кратко пробежимся по основным настройкам нового сервиса.

Шаг первый - регистрация самого сервиса.

Шаг второй - определим наши ресурсы. Исходя из поставленной задачи, у нас должны быть:

/warehouses - общий с методами GET (полный список складов) и POST (создание нового склада)
/warehouses/{id} - адрессный с методами GET (получить конкретный склад), PUT (модифицировать существующий) и DELETE (пометить на удаление)

Данные ресурсы разместим в группе logistic. Параметр URL "id" потребует краткого описания.

Ресурсы

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

Модели данных

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

Методы ресурсов

Заключительный шаг - активировать произведенные настройки для обработки вызовов. Используем соответствующую команду "Сохранить настройки". Теперь мы можем перейти по ссылке http://localhost/test/hs/internal/v1/docs и увидеть сгенерированную спецификацию. Данный пример наглядно показывает подход Contract First в рамках системы 1С.

Ich will dass ihr mir glaubt

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

Нарушение спецификации со стороны клиента приводит к коду ответа 422, согласно стандарта RFC. Нарушение спецификации со стороны сервера (ошибка программиста) будет приводить к ответу 500. Так же, данный код ответа будет формироваться при любом исключении, возникающим при вызове функции-обработчика. Поэтому любые описанные в нашей спецификации API методы ресурсов будут содержать данные варианты ответа по умолчанию.

Проверим функцию контроля спецификации со стороны клиента на примере метода создания склада. Пропустим в теле запроса свойство "type" и получим соответствующую ошибку от сервера. Самое главное, сама функция-обработчик метода не была вызвана, а клиент получил человекочитаемое описание ошибки.

Ich will eure Blicke spüren

Для рассмотрения трейсинга запросов нам потребуется установленные Elasticsearch и Kibana версии 7.17, а так же APM server соответствующей версии. Будем считать что они все работают на localhost. Подробное описание принципа работы, развертывания и настройки данного окружения опущено, так как не является темой данной статьи.

Доработаем код модуля "ИнтеграцияСклад", сделав работоспособными методы ресурса /warehouses (получить список складов и создать новый).

Обработчики

Функция ПолучитьСклады(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Массив;
	ЗаголовкиОтвета = Неопределено;
	
	Запрос = Новый Запрос;
	Запрос.Текст = 
		"ВЫБРАТЬ
		|	Склады.Код КАК Код,
		|	Склады.Наименование КАК Наименование,
		|	Склады.ВидСклада КАК ВидСклада
		|ИЗ
		|	Справочник.Склады КАК Склады
		|ГДЕ
		|	Склады.ПометкаУдаления = ЛОЖЬ";
	
	РезультатЗапроса = Запрос.Выполнить();
	
	ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
	
	Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
		
		СтруктураДанных = Новый Структура("Код, Наименование, ВидСклада");
		
		ЗаполнитьЗначенияСвойств(СтруктураДанных, ВыборкаДетальныеЗаписи);
		
		СодержаниеОтвета.Добавить(СтруктураДанных);
		
	КонецЦикла;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции

Функция СоздатьСклад(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Структура("Код, Наименование, ВидСклада");
	ЗаголовкиОтвета = Неопределено;
	
	ДанныеСклада = КонтекстЗапроса.ТелоЗапроса;
	
	НовыйСклад = Справочники.Склады.СоздатьЭлемент();
	
	ЗаполнитьЗначенияСвойств(НовыйСклад, ДанныеСклада);
	
	НовыйСклад.Записать();
	
	ЗаполнитьЗначенияСвойств(СодержаниеОтвета, НовыйСклад);
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции

Сделаем несколько запросов к сервису. При правильно настроенном окружении мы увидим примерно следующую картину в Elastic APM:

Инструмент мониторинга увидел нашу систему 1С как сервис. Кроме общего дашборда имеется статистика вызовов по каждому методу вызываемых ресурсов и зарегистрированные ошибки кода 1С.

Elastic APM

Ich will jeden Herzschlag kontrollieren

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

Результат "из коробки" нашей конфигурации показывает запрос как одно целое. Что бы добавить span внутри запроса сервиса используем встроенные методы подсистемы.

ЛогированиеREST.ИнициализироватьИнтервалОбращенияКБД(КонтекстЗамера, Наименование, Запрос);

ЛогированиеREST.ЗавершитьИнтервал(КонтекстЗамера);

Запросом к БД является не только выборка через объект "Запрос", но и работа в объектной модели - чтение и запись объекта. Проведем небольшую иньекцию в наш код.

Обработчики

Функция ПолучитьСклады(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Массив;
	ЗаголовкиОтвета = Неопределено;
	
	Запрос = Новый Запрос;
	Запрос.Текст = 
		"ВЫБРАТЬ
		|	Склады.Код КАК Код,
		|	Склады.Наименование КАК Наименование,
		|	Склады.ВидСклада КАК ВидСклада
		|ИЗ
		|	Справочник.Склады КАК Склады
		|ГДЕ
		|	Склады.ПометкаУдаления = ЛОЖЬ";
	
	ЛогированиеREST.ИнициализироватьИнтервалОбращенияКБД(КонтекстЗамера, "ВЫБРАТЬ Справочник.Склады", Запрос.Текст);
	
	РезультатЗапроса = Запрос.Выполнить();
	
	ЛогированиеREST.ЗавершитьИнтервал(КонтекстЗамера);
	
	ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
	
	Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
		
		СтруктураДанных = Новый Структура("Код, Наименование, ВидСклада");
		
		ЗаполнитьЗначенияСвойств(СтруктураДанных, ВыборкаДетальныеЗаписи);
		
		СодержаниеОтвета.Добавить(СтруктураДанных);
		
	КонецЦикла;
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции

Функция СоздатьСклад(КонтекстЗапроса, КонтекстЗамера) Экспорт
	
	ТипОтвета = Перечисления.ТипыОтветовREST.Успешно;
	СодержаниеОтвета = Новый Структура("Код, Наименование, ВидСклада");
	ЗаголовкиОтвета = Неопределено;
	
	ДанныеСклада = КонтекстЗапроса.ТелоЗапроса;
	
	НовыйСклад = Справочники.Склады.СоздатьЭлемент();
	
	ЗаполнитьЗначенияСвойств(НовыйСклад, ДанныеСклада);
	
	ЛогированиеREST.ИнициализироватьИнтервалОбращенияКБД(КонтекстЗамера, "Записать склад", "НовыйСклад.Записать()");
	
	НовыйСклад.Записать();
	
	ЛогированиеREST.ЗавершитьИнтервал(КонтекстЗамера);
	
	ЗаполнитьЗначенияСвойств(СодержаниеОтвета, НовыйСклад);
	
	Возврат ОбработкаВызоваREST.СформироватьРезультатОбработчика(ТипОтвета, СодержаниеОтвета, ЗаголовкиОтвета);
	
КонецФункции

Повторим несколько запросов к сервису и посмотрим результат.

Gitarrenpart

Подведем краткий итог:

систему 1С можно и нужно использовать как один из сервисов внутри компании;
подход Contract First реализуем и и повышает качество написания http-сервисов;
tracing запросов должен стать базовым инструментом разработчика 1С.

Буду рад обратной связи и спасибо за потраченное время!

+54 –

См. также

Интеграция системы Datamart завода Москвич и Альфа-Авто, редакции 5 и 6

WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Обмен данными Datamart завода Москвич и автодилера на Альфа-Авто, ред.5 и 6

240000 руб.

01.08.2023 2573 2 0

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Системный администратор Программист Пользователь Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме.

36000 руб.

03.08.2020 17802 19 22

Интеграция 1С с OpenCart 2.x, 3x — модуль обмена данными

WEB-интеграция Оптовая торговля Розничная торговля Программист Управляемые формы 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Модуль интеграции 1С с OpenCart 2.x, 3x позволяет обмениваться данными между OpenCart (самая популярная бесплатная cms для интернет-магазинов) и 1С:Предприятие 8.

6800 руб.

17.11.2015 120273 379 139

224

Функционал задач в Битрикс24 у Вас в 1С

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс 24. Разработка имеет двухстороннюю синхронизацию 1С и Bitrix24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (платформа начиная с 8.3.23). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021 19886 13 17

Сервисы 1СПАРК Риски и 1С:Контрагент для «старых» конфигураций

WEB-интеграция Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Бухгалтерия государственного учреждения Россия Платные (руб)

Доступ к сервисам 1СПАРК Риски и 1С:Контрагент в «старых», но широко используемых конфигурациях.

6000 руб.

30.01.2019 25039 47 5

SALE! 15%

Все службы доставки в Вашей 1С! Без изменения конфигурации! 1С:УТ, 1С:ERP, 1С:КА, 1С:УНФ

WEB-интеграция Рабочее место Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

40+ служб доставки для 1С в одном модуле! Внешняя обработка, которая НЕ изменяет Вашу конфигурацию! Подписная модель на 1 год.

~~16800~~ 14280 руб.

22.03.2017 38766 18 49

Модуль для обмена "1С:Предприятие 8. УАТ. ПРОФ" с FortMonitor

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021 14436 42 8

Конструктор API для обмена базы 1С 8.3 с другими системами по протоколу http в формате JSON

WEB-интеграция Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Расширение значительно упрощает написание API на 1С. Веб программисты получают простой и понятный доступ к 1С. Описание API создаётся автоматически и представляется в виде удобном как для человека, так и для программной обработки.

24000 руб.

27.09.2024 1208 1 0

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. SerVer1C 815 16.09.22 15:46 Сейчас в теме

Ахтунг! Игоря на вас нету...

2. ixijixi 1913 16.09.22 16:25 Сейчас в теме

А давайте его позовем! Или он сам приходит на англицизмы?

Прикрепленные файлы:

26. Evil Beaver 8244 18.09.22 20:28 Сейчас в теме

(2) Это германизмы

3. amd1986 16.09.22 18:53 Сейчас в теме

Много иностранных слов. Пользы от этого не много.

http запросы не рекомендуется использовать. Лучше https. Get запросы также не стоит.

4. botokash 395 16.09.22 19:00 Сейчас в теме

(3) Настройте https на веб-сервере где публикуете базу, в чем сложность? И почему это GET запросы это плохо?

5. amd1986 16.09.22 19:17 Сейчас в теме

(4) сложности нет. У вас пример с http. И любопытны настройки проверки содержимого запросов с https.
Тем что видны параметры. С точки зрения безопасности лучше использовать post запросы. Да и ограничения по размеру запроса у get запроса есть.

10. nixel 1434 16.09.22 20:24 Сейчас в теме

(5) вы путаете тёплое с мягким. https - это надстройка над http, которая живёт только на уровне веб сервера. На уровне сервера приложений трафик уже расшифрованный.
Выбор get/post/других http-глаголов должен быть обусловлен семантикой и логикой запроса, а "плохостью"

15. zen_daya 16.09.22 22:42 Сейчас в теме

(5)
Не соглашусь с вами насчет проблем безопасности GET запросов

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

24. gybson 18.09.22 14:55 Сейчас в теме

(15) Имеется в виду уязвимость URL. В случае с https это не должно быть актуально.

23. gybson 18.09.22 14:53 Сейчас в теме

(5) а DELETE безопасный?

Если есть желание из REST сделать SOAP, то делайте сразу SOAP.

40. amd1986 19.09.22 11:18 Сейчас в теме

(23) SOAP сложнее интегрировать с внешними сервисами.

6. botokash 395 16.09.22 19:35 Сейчас в теме

(5) На то это и пример, не понимаю претензии. Платформа 1С не отвечает за протокол, а разработчику 1С вообще без разницы что стоит перед/на веб-сервере. Об этом должны заботиться сетевики, безопасники, админы.
Про GET - можете ссылкой о чем речь? Делать запрос на получение ресурса в REST API методом POST - звучит странно.

13. amd1986 16.09.22 20:33 Сейчас в теме

(6)
(6)

Делать запрос на получение ресурса в REST API методом POST - звучит странно.

Потому что не сталкивались с проблемами.

27. Evil Beaver 8244 18.09.22 20:29 Сейчас в теме

(13) с какими проблемами можно столкнуться, используя GET вместо POST?

46. amd1986 19.09.22 11:36 Сейчас в теме

(27)
- Проблемы с безопасностью.
- Проблемы с ограничением передаваемых данных.

47. Evil Beaver 8244 19.09.22 11:37 Сейчас в теме

(46) какие проблемы с безопасностью?

51. amd1986 19.09.22 11:55 Сейчас в теме

(47)
В get запросах данные передаются в параметрах запроса
В post запросах данные передаются в теле запроса

7. tormozit 7231 16.09.22 20:13 Сейчас в теме

Заголовки на непонятном думаю большинству читателей языке - не к месту. Думаю стоит их заменить русскими вариантами. Они как бы нужны в первую очередь для ускорения навигации читателя по статье =)

8. botokash 395 16.09.22 20:17 Сейчас в теме

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

14. NiGMa 16.09.22 22:20 Сейчас в теме

(7) Сергей, это ж песня. Строчки из песни.
Раммштайн (Rammstein), "Ich will"

37. starik-2005 3088 19.09.22 11:11 Сейчас в теме

(14)

Rammstein

У меня подружка бывшая уважала, мне сам звук нравится, но как это пишется - понятия не имею.

ЗЫ: ИМХО, было бы куда веселее, если бы это все было русскими буквами. Типа: "Ду хаст!" (это все, что я осилил вспомнить). 100% не я один такой.

39. botokash 395 19.09.22 11:17 Сейчас в теме

(37) почему многие в комментариях так активно "цепляются" за подачу? Англицизмы, написано не русскими буквами - это все что беспокоит профессионала в наше время? Есть термины, которые придуманы не нами, есть песни, перевод которых никого не интересует.

41. starik-2005 3088 19.09.22 11:21 Сейчас в теме

(39)

есть песни, перевод которых никого не интересует

Это одна из них?

42. botokash 395 19.09.22 11:26 Сейчас в теме

(41) Тут больше вижу проблему в том, что увидев непонятное для себя людям проще сказать КГ/АМ, а не попытаться разобраться в вопросе. Предлагаю считать этот вопрос закрытым =)

56. starik-2005 3088 19.09.22 13:29 Сейчас в теме

(42)

людям проще сказать КГ/АМ

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

9. Ndochp 103 16.09.22 20:21 Сейчас в теме

В зипе ЛогированиеREST и ОбработкаВызоваREST?

11. botokash 395 16.09.22 20:25 Сейчас в теме

(9) в зипе cf файл с двумя подсистемами самого инструмента и доработками по примеру из статьи. ЛогированиеREST и ОбработкаВызоваREST это название общих модулей. Так же, в самом начале статьи есть ссылка на репозиторий гитхаб, где базовая конфигурация лежит как проект EDT.

12. Ndochp 103 16.09.22 20:26 Сейчас в теме

(11) Спасибо, пропустил.

16. malikov_pro 1324 17.09.22 16:04 Сейчас в теме

За разработку темы трассировки + и sm.
По содержанию статьи
* "ключевым отличием от него является способ заключения контракта" - не понял какие именно отличия?
* указан что выбран "Elastic APM", но нет описания что вообще возможно собирать в трассировки и почему выбрали именно его. В модуле

ДобавитьВТелоЗапросаМетаданные(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаТранзакцию(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаИнтервалы(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаМетрики(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаОшибки(ТелоЗапроса, КонтекстЗамера);

Сам разбирал структуру сообщения sentry, много чего интересного накопал, блок с производительностью там тоже есть.
* для многих развернуть сервис мониторинга неподъемная задача, нужна как минимум ссылка на документацию по установке.
* По каким аспектам пересекается с анализом производительности БСП?
* Возможно ли переложить эти наработки на мониторинг работы внутренних функций, в формах например?

По коду
* зачем комментарий?

// ОписаниеСервиса
ОписаниеСервиса = УправлениеRESTПовтИсп.ПолучитьОписаниеСервиса(КонтекстЗапроса.КлючСервиса);

Зачем выделять в отдельную переменную?

в СформироватьДанныеКонтекстаЗапроса()

ИмяПубликации = ПолучитьИмяПубликации(ДанныеИсходногоЗапроса);
Результат.ИмяПубликации = ИмяПубликации;

Хардкод системы мониторинга

HTTPСоединение = Новый HTTPСоединение("vm-ais-logmonitor.technodom.kz", 8200);

Отправка сделана синхронно, и если сервер мониторинга недоступен, то колом встает основной сервис. Возможно коллеги предложат решения с + и -.

По реализации
У Валерия Крынина уровень абстракции сложен для восприятия (мне по крайней мере), у вас представлена более простая модель HTTP сервиса с одной точкой входа, думаю подходы будут интересны сообществу, например вариант маршрутизации без regexp
* в ПроверитьКонтекстЗапросаПоСпецификации не увидел блока валидации тела запроса по JSON Schema наработки уже есть.

На сколько сложно вынести описание обработчиков в код?

// Вызов обработчика
РезультатОбработчика = Неопределено;
Команда = "РезультатОбработчика = " + КонтекстЗапроса.ОписаниеМетода.Обработчик + "(КонтекстЗапроса, КонтекстЗамера);";

Попытка
	Выполнить(Команда);

Его все равно версионировать, что из БД доп. затраты по сравнению с кодом. И прослеживаемость "Выполнить" отсутствует

19. botokash 395 17.09.22 17:54 Сейчас в теме

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

17. quazare 3802 17.09.22 16:12 Сейчас в теме

хорошо. спасибо!

18. DemetrKlim 180 17.09.22 16:16 Сейчас в теме

Ну... из всего написанного, я только немецкий текст и понял (спасибо колледжу в земле Саксония.....)

20. malikov_pro 1324 17.09.22 20:48 Сейчас в теме

(19) А вот про обработчики не понял вопроса. - сейчас реализовано в виде записей с справочниках, мне привычнее в виде кода, возможно просто непривычно. При наличии "библиотеки" HTTP сервиса под нее можно сделать трансформацию кода в/из swagger.

"На каждый развернуто тут не ответишь" - задал в том числе чтобы коллеги обратили внимание на эти вопросы.
Моя версия была опубликована в 19 году, Валерий в 20 году добавил свое, после началась "движуха" по swagger, в этом году вроде еще "пролетала" реализация. Движение есть, вероятность сделать серверную часть на уровне Коннектор1С присутствует. Нужен тот кто соберет базово github проект, дальше могу подхватить, практика EDT+git полезна, пример https://github.com/plastinin/diagramobject/issues

Рядом тема с JSON-RPC, как легковесная замена SOAP, больше ограничений по сравнению с REST, но и реализация думаю проще будет.

33. starik-2005 3088 19.09.22 10:53 Сейчас в теме

(20)

JSON-RPC

Был тренд в стороне graphQL, хороший механизм для извлечения данных. Я так понимаю, что он является частным случаем реализации.

21. malikov_pro 1324 17.09.22 20:51 Сейчас в теме

(18) Так задайте вопросы с момента когда становится непонятно. Сам при написании статьи упускаю моменты которые для меня понятны, а окружающие с этим не сталкивались.

22. DemetrKlim 180 17.09.22 21:03 Сейчас в теме

(21) Не, я - бестолковый. Занимаюсь кондовым, посконно-домотканным программированием для альтернативно-одаренных заказчиков, случайно приговоренных к работе в бухгалтерии. Я выше арифметики не подымаюсь....

32. starik-2005 3088 19.09.22 10:49 Сейчас в теме

(22)

Я выше арифметики не подымаюсь....

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

54. DemetrKlim 180 19.09.22 12:55 Сейчас в теме

(32) Тебе смешно, а у меня - комплексы... Как почитаю тексты... осмелюсь сказать, коллег и слюна прокисает от досады. Люди работают с какими-то небожителями, решают какие-то их удивительные и выдающиеся проблемы. А я вспоминаю лица своих заказчиков, у которых основные проблемы описываются на уровне средней группы детсада. Такое ощущение, что я в каком-то интеллектуальном гетто оказался, без права на подъем с глубины.

55. starik-2005 3088 19.09.22 13:27 Сейчас в теме

(54)

без права на подъем с глубины

Воспользуйся социальным лифтом, сам придумай, что это...

25. gybson 18.09.22 15:08 Сейчас в теме

"один из сервисов внутри компании"

Внутри компании лучше SOAP. Там и с типизацией получше, с валидацией и структура данных документирована.

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

Это кунг-фу с разбором строк, когда на уровне платформы все можно получить разжеванным, оно зачем? У вас модуль обработки вшит в конфигурацию. Вы все-равно не сможете просто так добавить обработку другого запроса.

34. botokash 395 19.09.22 10:56 Сейчас в теме

(25) Условно не соглашусь. Не отрицаю наличие такой ситуации, когда система 1С интегрирована с "устаревшими" продуктами, в период создания которых SOAP действительно являлся стандартом. Но сейчас даже http REST это уже не "модно", все больше grpc и другого низкоуровневого стека используется.

28. user1831019 18.09.22 21:55 Сейчас в теме

(2) Да тут в основном немчизмы!
Жаль, что я в школе плохо учил казахский. Сейчас бы в комментариях блеснул казахизмами.

29. DemetrKlim 180 19.09.22 08:00 Сейчас в теме

(28) Я программирование начинал изучать как раз у немцев (промышленные контроллеры только начинали появляться). И вот какое отличие заметил уже тогда (1989 - 1990). Их "учителя" не стараются умничать. Они отчетливо понимают, что их аудитория признает свою изначальную некомпетентность и пришла именно за знаниями и компетенциями, а не на замер.... кто там чем хотел померяться! Если взять несколько самоучителей по программированию отечественных и забугорных авторов, то отчетливо видно, что западенец пишет, как комикс для детей, зачастую - с картинками! Его задача - обучить, дать понимание. Ему не нужно раздувать свое эго, если он реально дожил до самоуважения к себе, как к профессионалу. И берем учебники (методические материалы) наших авторов. На первых же строках автор просто обязан продемонстрировать свое знание высшей математики и истории партии с решениями последних съездов) Текст пресыщен кучей научных терминов, за ссылками на которые надо постоянно нырять "в зад" книжке. Не чтение, а мучение.
Среди коллег, увы, такая родимая генетическая линия тоже присутствует. Надо так написать, чтобы был виден "уровень"))

31. starik-2005 3088 19.09.22 10:46 Сейчас в теме

(29) Вот соглашусь с Вами, хотя и не стал бы говорить, что наши учебники так уж плохи. Я начал изучать программирование лет в 10-11 по книжке, которую взял у друга. Книжка наша, про бейсик. Потом у приятеля взял книжку "Паскаль в иллюстрациях" - офигенная книжка, в которой все эти "дискретные алгебры" с их графами и двоичными деревьями, хеш-функциями и прочими оптимизациями работы со списками, даны были в виде картинок и очень простых текстов. Но фундаментальное понимание программирования я именно по "нашей" книжке без картинок получил, т.е. сам по себе ответ на вопрос "как это работает". Да, потребовалось выплакать тонну слез, рассчитывать было совершенно не на кого, ибо в 1990-м году вокруг не было компьютеров, а программистов не было даже на большом расстоянии. И я сейчас нисколько не жалею, что мне тогда пришлось пережить эту дыру боли, и очень рад, что я взломал тот текст, а не он меня - сработал принцип образования по Занкову, когда перед учеником ставится такая задача, которую он заведомо не может решить, и через которую единицы продираются. Это действительно работает - на своей шкуре проверил.

30. starik-2005 3088 19.09.22 10:39 Сейчас в теме

Вот такая простая "реализация SOAP" с помощью HTTP-сервисов ))) Осталось только передавать схему данных с информацией о списке сервисов, их параметрах и возвращаемом значении...

35. botokash 395 19.09.22 11:00 Сейчас в теме

(30) это далеко не SOAP. Сейчас тренд в сторону уменьшения размера пакета данных и, соответственно, трафика. Ведь одной из причин появления формата JSON было именно этим обусловлено. Хотя история циклична, команды переходят на protobuff, который по сути низкоуровневый SOAP =)

36. starik-2005 3088 19.09.22 11:06 Сейчас в теме

(35)

Сейчас тренд в сторону уменьшения размера пакета данных

Ну так смысл этого тренда в том, что клиентов очень много стало, а пропускная способность сети за ними не успевает.
А SOAP - он же любой массив данных может передать - хоть жуткий и большой XML, хоть сжатый в 100 раз массив данных в base64. "Протобуф" просто избавляется от дополнительных байт base64 и заголовков полей, но он работает только поверх HTTP2.

А в части моего коммента, то если добавить то, о чем я написал, будет реализация SOAP на JSON. Ну да, пакеты будут чуть меньше, но сложность реализации возрастает. При том для кейсов с 1С размер пакетов - это второстепенная проблема.

38. botokash 395 19.09.22 11:14 Сейчас в теме

(36) я может что-то не правильно понимаю, но SOAP это протокол и согласно ему сообщение имеет определенную структуру, которую никуда не выкинешь. Как бы мы не сжимали тело сообщения, останется обязательная часть, и именно отход от нее обусловлен постепенным отказом от SOAP в высоконагруженных системах. Плюс каждое движение над телом запроса - это дополнительные "такты" как на клиенте так и на сервере.

43. starik-2005 3088 19.09.22 11:26 Сейчас в теме

(38)

останется обязательная часть

Она не такая и большая. И, опять же, в 1С не является узкой частью.
(38)

это дополнительные "такты"

Опять же, в 1С это малосущественно. Я вот, лично, не вспомню и даже навскидку придумать не могу сценарий, где такты и вес сообщения для 1С являются существенными факторами.
И да, для SOAP можно написать так:

Возврат Новый ХранилищеЗначений( Запрос.Выполнить().Выгрузить(), Новый СжатиеДанных(0) );

В HTTP придется все это засовывать в тело ответа, т.е. как минимум создавать новый объект "HTTPОтвет" и засовывать в тело ответа получившиеся данные. И если их не паковать, то размер HTTP-пакета будет больше, чем размер пакета SOAP с пожатым хранилищем значений.

44. botokash 395 19.09.22 11:30 Сейчас в теме

(43) В частном случае системы 1С как 90% всех ИС компании - да. Но все таки в статье моя основная мысль - система 1С как один из сервисов внутри компании. И вот тут становится вопрос анализа всего архитектурного стека разработки компании. И свои выводы я предоставил.

45. starik-2005 3088 19.09.22 11:36 Сейчас в теме

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

Я вот вообще не вижу 1С, как высокодоступного поставщика данных в корпоративной системе - это не ее функция.

49. botokash 395 19.09.22 11:42 Сейчас в теме

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

50. starik-2005 3088 19.09.22 11:49 Сейчас в теме

(49)

Мы говорим о разных вещах.

Напротив, мы говорим об одном и том же - об архитектуре. Это слово есть даже в кратком содержании статьи (слово "Архитектор"). Так вот архитектура - это то to be, которое обеспечивает те самые реакцию, доступность и нагрузку. Если нагрузка небольшая, требования к доступности невысокие, а реакция позволяет пользователю сходить и налить кипятка, то нам достаточно 1С и SOAP. Если же требования возрастут, то выигрыш в 10% на HTTP-сервисах не даст ничего, т.к. все упрется сначала в доступность, потом в нагрузку, а потом и в реакцию (ну или наоборот, сначала в реакцию, потом в нагрузку, а за ними и в доступность, ибо Вы решили обновить систему в самый неподходящий момент, ибо предыдущее обновление все к хренам сломало).

53. botokash 395 19.09.22 12:09 Сейчас в теме

(50) Сожалею, но вы меня так и не поняли. Статья - интеграция с точки зрения архитектора. Человек, принимающий решение на основании своих компетенций и поставленных условий решения задачи. А условия не всегда про техническую составляющую, а больше про денежную. В данной ветке дискуссии мне больше нечего добавить =)

57. starik-2005 3088 19.09.22 13:31 Сейчас в теме

(53)

а больше про денежную

Скука.

48. booksfill 19.09.22 11:38 Сейчас в теме

Я не уверен, что паттерн Front Controller такое уж хорошее решение - при всех плюсах получаем серьезные проблемы:

1. Единую точку отказа - любая ошибка в самом методе (а иногда и в вызываемых из него) приведет к остановке всех сервисов.
Либо к тому, что они будут работать не так, как ожидалось (это в огород "попытка исключение", или заплатке типа Если ИСТИНА Или ...).

Не забываем, что "в подарок" еще получаем единую точку атаки.

Это все равно как отказ автопилота полностью заблокирует возможность ручного управления самолетом.

Мне кажется, что реализация такого паттерна без обязательной реализации системы "аварийного" канала - плохое решение.

2. Искусственная связь разных сущностей с "навязанным" общим решением.
Например, считаем, что все действия надо логировать, потом передумываем, точка входа начинает проверят некие условия и вместо удобства выполняет никому не нужные действия. Плюс еще на этапе архитектуры приходится закладывать соответствующие возможности, усложняя ее.

А все потому, что логика разных сущностей меняется независимо от остальных и с разной скоростью.

3. Потенциал стать бутылочным горлышком. Это хорошо видно на примере типовых конфигураций 1С, когда движения делаются путем вызова стандартных методов, которые зачастую выполняют 90% не нужной работы, в угоду универсальности и в ущерб понятности и быстродействию.

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

52. botokash 395 19.09.22 12:03 Сейчас в теме

(48) Для меня описанные проблемы выглядят немного "притянутыми за уши":
1. Единая точка входа - это изолированная функциональность подсистемы и отлично поддается тестирования. Если допускается возможность попадания в прод такого рода ошибок в коде - это проблема другого характера. А ошибка разработчика, написавшего обработчик метода сервиса, всегда изолирована через попытку и не может привести к остановке всего сервиса.
2. Цель применения подобного паттерна - разделение ответственности и единообразность. И если мы говорим разработчику не логировать что-то внутри сервиса почему он должен начать это делать? Или почему мы вдруг решим отойти от паттерна и в контроллер тянуть какие-то условия, нарушая тем самым его смысл?
3. Не вижу как пример с типовыми коррелирует с предоставленным подходом? Есть общепринятые рамки создания REST API и не предвидится никаких "вдруг" изменений в механизм его работы.
4. Сошлюсь на ответ в пункте 3. И вопрос к вам от меня - что является "набором понятных и независимых сущностей"?

58. booksfill 19.09.22 15:26 Сейчас в теме

(52)
Если бы я знал "как надо", я бы не комментарии писал,а статьи :)

Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет.
При этом "вес\значимость" того, что этот метод делает может быть различным для разных, вызываемых им методов.
И ошибка эта вовсе необязана выглядеть как "все пропало", она может провиться, например, чт овремя отклика станет слишком велико.

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

"набором понятных и независимых сущностей"

ПолучитьСписокСкладов - понятно и никак не зависит от "УдалитьСклад".
"УдалитьСклад" - понятный и независимый от метода "ПолучитьСписокСкладов", потому как идентификатор склада я могу получить множеством других способов.

59. malikov_pro 1324 19.09.22 16:30 Сейчас в теме

(33) По ссылке - "GraphQL это синтаксис, который описывает как запрашивать данные", а RPC - " класс технологий, позволяющих программам вызывать функции или процедуры в другом адресном пространстве". Инструменты для разного класса задач. Про RPC упоминаю потому что на практике периодически вижу SOAP с схемой данных в виде одной строки в которую упихивают все подряд (XML), которое нормально заменяется JSON-RPC.

60. starik-2005 3088 19.09.22 16:34 Сейчас в теме

(59)

описывает как запрашивать данные

А что мы делаем при вызове веб-сервисов? В основном или запрашиваем данные, или передаем данные в систему. Остальные кейсы малозначимы. gpaphQL - это просто еще один механизм, позволяющий запросить тот пакет данных, который нужен получателю. Это как oData, фактически, только для извлечения данных.

61. malikov_pro 1324 19.09.22 22:34 Сейчас в теме

(58) "Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет." - если у вас косяк в коде и он не интерпретируется на уровне модуля HTTP сервиса, то даже в ЖР не напишет, не важно его количество.

Либо маршрутизация делается на уровне платформы, но она не умеет в regexp, и за ней "допроверять" в коде, либо используем роутер реализованный кодом. Проблемы при маршрутизации на уровне платформы начнутся когда начнете добавлять Listeners (слушатели), типовых форматов ответов, валидации передаваемых данных, доп аутентификации итд, вам придется в каждую функцию обработчик их прописывать, пробовал, неудобно.

"Если я не путаю, то в качестве примера часто приводят браузеры, но если один из них перестанет работать, всегда можно вызвать другой." - сначала надо написать чтобы было удобно поддерживать и окружающим была понятна структура. Для примера посмотрите HTTP сервис для Mango в УНФ/РарусCRM, при адаптации их переписал на более прозрачную схему.

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

62. botokash 395 20.09.22 05:21 Сейчас в теме

(61)

чтобы не завязываться на общую структуру данных в спр

Думаю понял теперь о чем вы хотели сказать. Я считаю это вопросом в плоскости реализации и не вижу его таким значимым по отношению к поставленной цели, описанной в статье. Я реализовал то что почитал более быстрым, а другой разработчик может сделать как ему больше нравится. Напомню, цель моей статьи была не конечный продукт, а демонстрация практики и подхода к разработке сервисов =)

64. booksfill 21.09.22 11:22 Сейчас в теме

(61)

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

Вот, собственно я это и имел в виду, но, написал коряво. Тогда уже получаем достаточную надежность.
Просто насторожило введение Front Controller без оговорки об опасности реализации его в лоб, ну, или я был не внимателен.

А если надо больше, то это уже можно реализовать на уровне перенаправления средствами Apache + кластеризация и т.п., далее много умных слов, не имеющих никакого отношения к статье. :)

P.S. А вообще, было бы интересно, если кто-нибудь подробно осветил только правильную реализация данного паттерна в 1С, как раз с учетом первичной отказоустойчивости и балансировки нагрузки хотя бы по слушателям.

63. 1CUnlimited 320 20.09.22 13:09 Сейчас в теме

>"использование системы 1С как одного из сервисов внутри компании";
Сразу плюсанул за эту фразу, многие из 1С делают центр, но естественные ограничения платформы как бы намекают

65. malikov_pro 1324 21.09.22 11:55 Сейчас в теме

(64) "то это уже можно реализовать на уровне перенаправления средствами Apache" - https://infostart.ru/1c/articles/1258813/
"балансировки нагрузки хотя бы по слушателям." - вывод аутентификации на уровень кода, создание нескольких публикаций для одного HTTP сервиса, балансировка на уровне NGINX https://serveradmin.ru/nginx-v-kachestve-balansirovshhika-nagruzki/

нужно разбираться что за сервис, какого типа нагрузка, какое количество запросов, если есть состояние сеанса, то рядом нужно redis например прикручивать. Если "справочники", то выношу в промежуточный сервис на PostgREST, статью по этому поводу писал.

Будет свободное время - попробую организовать проект на GitHub и в него собирать наработки.