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

16.09.22

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

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

Скачать файлы

Наименование Файл Версия Размер
Интеграция (Ich will version):
.zip 428,97Kb
7
.zip 428,97Kb 7 Скачать

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 функций для абстрактного справочника "Склады" с авторизацией для функций изменения данных.

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

 
 Обработчики

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

 

 

Произведем публикацию базы на веб-сервере под именем 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 (получить список складов и создать новый).

 
 Обработчики

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

 

 

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

 
 Elastic APM

 

Ich will jeden Herzschlag kontrollieren

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

 

 

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

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

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

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

 
 Обработчики

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

 

 

Gitarrenpart

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

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

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

См. также

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

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

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме. Без существенных изменений типовой конфигурации. Проверено с брендами: Интеграция 1С и GEELY Интеграция 1С и HAVAL Интеграция 1С и KIA Интеграция 1С и FORD Интеграция 1С и LADA ГАРАНТИЯ 100% ВНЕДРЕНИЯ!

36000 руб.

03.08.2020    15729    10    17    

11

Интеграция 1С — Битрикс24. Обмен задачами

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

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

5040 руб.

04.05.2021    17545    6    15    

13

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16357    42    49    

23

[Расширение] БОР-Навигатор.Культура

Зарплата Бюджетный учет WEB-интеграция Обмен с ГосИС Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Расширение конфигурации, включающее в себя объекты, необходимые для подготовки и сдачи отчета "Штатная численность" системы "БОР-Навигатор.Культура" в программе "1С:Зарплата и кадры государственного учреждения", редакция 3.1.

8400 руб.

01.02.2019    25736    9    0    

7

Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС

Обмен с ГосИС WEB-интеграция Платформа 1С v8.3 Управляемые формы 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия государственного учреждения 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Обработка является альтернативой механизму, разработанному фирмой 1С и заполняющему реквизиты контрагента по ИНН или наименованию. Не требуется действующей подписки ИТС. Вызывается как внешняя дополнительная обработка, т.е. используется, непосредственно, из карточки контрагента. Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС (egrul.nalog.ru) для БП 2.0, БП 3.0, БГУ 1.0, БГУ 2.0, УТ 10.3, УТ 11.x, КА 1.1, КА 2.x, УПП 1.x, ERP 2.x, УНФ 1.5, УНФ 1.6, УНФ 3.0, ДО 2.1

2400 руб.

28.04.2016    88576    160    215    

318
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 748 16.09.22 15:46 Сейчас в теме
Ахтунг! Игоря на вас нету...
2. ixijixi 1775 16.09.22 16:25 Сейчас в теме
А давайте его позовем! Или он сам приходит на англицизмы?
Прикрепленные файлы:
Boris_1c; 0x00; frkbvfnjh; a_a_burlakov; +4 Ответить
26. Evil Beaver 8107 18.09.22 20:28 Сейчас в теме
3. amd1986 16.09.22 18:53 Сейчас в теме
Много иностранных слов. Пользы от этого не много.

http запросы не рекомендуется использовать. Лучше https. Get запросы также не стоит.
4. botokash 389 16.09.22 19:00 Сейчас в теме
(3) Настройте https на веб-сервере где публикуете базу, в чем сложность? И почему это GET запросы это плохо?
5. amd1986 16.09.22 19:17 Сейчас в теме
(4) сложности нет. У вас пример с http. И любопытны настройки проверки содержимого запросов с https.
Тем что видны параметры. С точки зрения безопасности лучше использовать post запросы. Да и ограничения по размеру запроса у get запроса есть.
10. nixel 1403 16.09.22 20:24 Сейчас в теме
(5) вы путаете тёплое с мягким. https - это надстройка над http, которая живёт только на уровне веб сервера. На уровне сервера приложений трафик уже расшифрованный.
Выбор get/post/других http-глаголов должен быть обусловлен семантикой и логикой запроса, а "плохостью"
Bazil; Aleskey_K; so-quest; horsgroup; zen_daya; +5 Ответить
15. zen_daya 16.09.22 22:42 Сейчас в теме
(5)
Не соглашусь с вами насчет проблем безопасности GET запросов

Каждый запрос клиента к серверу должен содержать всю информацию, необходимую для выполнения этого запроса, без хранения какого-либо контекста на стороне сервера. Состояние сеанса целиком хранится на стороне клиента.
Надо просто правильно проектировать API
user1831019; +1 Ответить
24. gybson 18.09.22 14:55 Сейчас в теме
(15) Имеется в виду уязвимость URL. В случае с https это не должно быть актуально.
23. gybson 18.09.22 14:53 Сейчас в теме
(5) а DELETE безопасный?

Если есть желание из REST сделать SOAP, то делайте сразу SOAP.
qwerty_3; +1 Ответить
40. amd1986 19.09.22 11:18 Сейчас в теме
(23) SOAP сложнее интегрировать с внешними сервисами.
Aleskey_K; +1 Ответить
6. botokash 389 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 8107 18.09.22 20:29 Сейчас в теме
(13) с какими проблемами можно столкнуться, используя GET вместо POST?
46. amd1986 19.09.22 11:36 Сейчас в теме
(27)
- Проблемы с безопасностью.
- Проблемы с ограничением передаваемых данных.
47. Evil Beaver 8107 19.09.22 11:37 Сейчас в теме
(46) какие проблемы с безопасностью?
51. amd1986 19.09.22 11:55 Сейчас в теме
(47)
В get запросах данные передаются в параметрах запроса
В post запросах данные передаются в теле запроса
7. tormozit 7136 16.09.22 20:13 Сейчас в теме
Заголовки на непонятном думаю большинству читателей языке - не к месту. Думаю стоит их заменить русскими вариантами. Они как бы нужны в первую очередь для ускорения навигации читателя по статье =)
fieryfist; +1 Ответить
8. botokash 389 16.09.22 20:17 Сейчас в теме
(7) Была такая творческая задумка - первый куплет из одноименной песни (его перевод) раскрывает суть "боли" архитектора) Но, как говорится, из песни слов не вырежешь, оставлю как есть. На амальгаме можно посмотреть перевод нормальный.
qwerty_3; +1 Ответить
14. NiGMa 16.09.22 22:20 Сейчас в теме
(7) Сергей, это ж песня. Строчки из песни.
Раммштайн (Rammstein), "Ich will"
37. starik-2005 3033 19.09.22 11:11 Сейчас в теме
(14)
Rammstein
У меня подружка бывшая уважала, мне сам звук нравится, но как это пишется - понятия не имею.

ЗЫ: ИМХО, было бы куда веселее, если бы это все было русскими буквами. Типа: "Ду хаст!" (это все, что я осилил вспомнить). 100% не я один такой.
39. botokash 389 19.09.22 11:17 Сейчас в теме
(37) почему многие в комментариях так активно "цепляются" за подачу? Англицизмы, написано не русскими буквами - это все что беспокоит профессионала в наше время? Есть термины, которые придуманы не нами, есть песни, перевод которых никого не интересует.
qwerty_3; +1 Ответить
41. starik-2005 3033 19.09.22 11:21 Сейчас в теме
(39)
есть песни, перевод которых никого не интересует
Это одна из них?
42. botokash 389 19.09.22 11:26 Сейчас в теме
(41) Тут больше вижу проблему в том, что увидев непонятное для себя людям проще сказать КГ/АМ, а не попытаться разобраться в вопросе. Предлагаю считать этот вопрос закрытым =)
56. starik-2005 3033 19.09.22 13:29 Сейчас в теме
(42)
людям проще сказать КГ/АМ
Людям действительно проще так сказать, даже, предположу, Вам. Так что не провоцируйте людей - будьте к ним благосклонны. Они же пришли с утра на работу и вся их активность часто ограничивается поиском того, над кем бы постебаться. Такова жизнь большинства наших (и не наших - тоже) сограждан, увы и ах...
9. Ndochp 103 16.09.22 20:21 Сейчас в теме
В зипе ЛогированиеREST и ОбработкаВызоваREST?
11. botokash 389 16.09.22 20:25 Сейчас в теме
(9) в зипе cf файл с двумя подсистемами самого инструмента и доработками по примеру из статьи. ЛогированиеREST и ОбработкаВызоваREST это название общих модулей. Так же, в самом начале статьи есть ссылка на репозиторий гитхаб, где базовая конфигурация лежит как проект EDT.
12. Ndochp 103 16.09.22 20:26 Сейчас в теме
16. malikov_pro 1292 17.09.22 16:04 Сейчас в теме
За разработку темы трассировки + и sm.
По содержанию статьи
* "ключевым отличием от него является способ заключения контракта" - не понял какие именно отличия?
* указан что выбран "Elastic APM", но нет описания что вообще возможно собирать в трассировки и почему выбрали именно его. В модуле
ДобавитьВТелоЗапросаМетаданные(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаТранзакцию(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаИнтервалы(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаМетрики(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаОшибки(ТелоЗапроса, КонтекстЗамера);

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

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


Зачем выделять в отдельную переменную?
в СформироватьДанныеКонтекстаЗапроса()

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


Хардкод системы мониторинга
HTTPСоединение = Новый HTTPСоединение("vm-ais-logmonitor.technodom.kz", 8200);


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

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

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

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


Его все равно версионировать, что из БД доп. затраты по сравнению с кодом. И прослеживаемость "Выполнить" отсутствует
19. botokash 389 17.09.22 17:54 Сейчас в теме
(16) ух как много вопросов. На каждый развернуто тут не ответишь, предлагаю перейти в личку, а ещё лучше в телегу.
Если кратко, касательно кода - представлен не готовый продукт, об этом сразу сказано. Там многое стоит ещё доделать, в том числе валидация и упрощение жизни разработчику. Путь на сервер APM да, забыл исправить) А вот про обработчики не понял вопроса.
17. quazare 3586 17.09.22 16:12 Сейчас в теме
18. DemetrKlim 157 17.09.22 16:16 Сейчас в теме
Ну... из всего написанного, я только немецкий текст и понял (спасибо колледжу в земле Саксония.....)
20. malikov_pro 1292 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 3033 19.09.22 10:53 Сейчас в теме
(20)
JSON-RPC
Был тренд в стороне graphQL, хороший механизм для извлечения данных. Я так понимаю, что он является частным случаем реализации.
21. malikov_pro 1292 17.09.22 20:51 Сейчас в теме
(18) Так задайте вопросы с момента когда становится непонятно. Сам при написании статьи упускаю моменты которые для меня понятны, а окружающие с этим не сталкивались.
22. DemetrKlim 157 17.09.22 21:03 Сейчас в теме
(21) Не, я - бестолковый. Занимаюсь кондовым, посконно-домотканным программированием для альтернативно-одаренных заказчиков, случайно приговоренных к работе в бухгалтерии. Я выше арифметики не подымаюсь....
a_a_burlakov; +1 Ответить
32. starik-2005 3033 19.09.22 10:49 Сейчас в теме
(22)
Я выше арифметики не подымаюсь....
Я выше арифметики поднимаюсь только при решении тестовых задач на очередных собеседованиях. Но там вся математика сводится к тому, как интерпретировать формулу. Остальное - это много арифметики, ибо даже красивый значок суммы - это всего лишь сложение элементов массива.
54. DemetrKlim 157 19.09.22 12:55 Сейчас в теме
(32) Тебе смешно, а у меня - комплексы... Как почитаю тексты... осмелюсь сказать, коллег и слюна прокисает от досады. Люди работают с какими-то небожителями, решают какие-то их удивительные и выдающиеся проблемы. А я вспоминаю лица своих заказчиков, у которых основные проблемы описываются на уровне средней группы детсада. Такое ощущение, что я в каком-то интеллектуальном гетто оказался, без права на подъем с глубины.
55. starik-2005 3033 19.09.22 13:27 Сейчас в теме
(54)
без права на подъем с глубины
Воспользуйся социальным лифтом, сам придумай, что это...
25. gybson 18.09.22 15:08 Сейчас в теме
"один из сервисов внутри компании"

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

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

Это кунг-фу с разбором строк, когда на уровне платформы все можно получить разжеванным, оно зачем? У вас модуль обработки вшит в конфигурацию. Вы все-равно не сможете просто так добавить обработку другого запроса.
34. botokash 389 19.09.22 10:56 Сейчас в теме
(25) Условно не соглашусь. Не отрицаю наличие такой ситуации, когда система 1С интегрирована с "устаревшими" продуктами, в период создания которых SOAP действительно являлся стандартом. Но сейчас даже http REST это уже не "модно", все больше grpc и другого низкоуровневого стека используется.
itoptimum; +1 Ответить
28. user1831019 18.09.22 21:55 Сейчас в теме
(2) Да тут в основном немчизмы!
Жаль, что я в школе плохо учил казахский. Сейчас бы в комментариях блеснул казахизмами.
29. DemetrKlim 157 19.09.22 08:00 Сейчас в теме
(28) Я программирование начинал изучать как раз у немцев (промышленные контроллеры только начинали появляться). И вот какое отличие заметил уже тогда (1989 - 1990). Их "учителя" не стараются умничать. Они отчетливо понимают, что их аудитория признает свою изначальную некомпетентность и пришла именно за знаниями и компетенциями, а не на замер.... кто там чем хотел померяться! Если взять несколько самоучителей по программированию отечественных и забугорных авторов, то отчетливо видно, что западенец пишет, как комикс для детей, зачастую - с картинками! Его задача - обучить, дать понимание. Ему не нужно раздувать свое эго, если он реально дожил до самоуважения к себе, как к профессионалу. И берем учебники (методические материалы) наших авторов. На первых же строках автор просто обязан продемонстрировать свое знание высшей математики и истории партии с решениями последних съездов) Текст пресыщен кучей научных терминов, за ссылками на которые надо постоянно нырять "в зад" книжке. Не чтение, а мучение.
Среди коллег, увы, такая родимая генетическая линия тоже присутствует. Надо так написать, чтобы был виден "уровень"))
starik-2005; +1 1 Ответить
31. starik-2005 3033 19.09.22 10:46 Сейчас в теме
(29) Вот соглашусь с Вами, хотя и не стал бы говорить, что наши учебники так уж плохи. Я начал изучать программирование лет в 10-11 по книжке, которую взял у друга. Книжка наша, про бейсик. Потом у приятеля взял книжку "Паскаль в иллюстрациях" - офигенная книжка, в которой все эти "дискретные алгебры" с их графами и двоичными деревьями, хеш-функциями и прочими оптимизациями работы со списками, даны были в виде картинок и очень простых текстов. Но фундаментальное понимание программирования я именно по "нашей" книжке без картинок получил, т.е. сам по себе ответ на вопрос "как это работает". Да, потребовалось выплакать тонну слез, рассчитывать было совершенно не на кого, ибо в 1990-м году вокруг не было компьютеров, а программистов не было даже на большом расстоянии. И я сейчас нисколько не жалею, что мне тогда пришлось пережить эту дыру боли, и очень рад, что я взломал тот текст, а не он меня - сработал принцип образования по Занкову, когда перед учеником ставится такая задача, которую он заведомо не может решить, и через которую единицы продираются. Это действительно работает - на своей шкуре проверил.
30. starik-2005 3033 19.09.22 10:39 Сейчас в теме
Вот такая простая "реализация SOAP" с помощью HTTP-сервисов ))) Осталось только передавать схему данных с информацией о списке сервисов, их параметрах и возвращаемом значении...
35. botokash 389 19.09.22 11:00 Сейчас в теме
(30) это далеко не SOAP. Сейчас тренд в сторону уменьшения размера пакета данных и, соответственно, трафика. Ведь одной из причин появления формата JSON было именно этим обусловлено. Хотя история циклична, команды переходят на protobuff, который по сути низкоуровневый SOAP =)
36. starik-2005 3033 19.09.22 11:06 Сейчас в теме
(35)
Сейчас тренд в сторону уменьшения размера пакета данных
Ну так смысл этого тренда в том, что клиентов очень много стало, а пропускная способность сети за ними не успевает.
А SOAP - он же любой массив данных может передать - хоть жуткий и большой XML, хоть сжатый в 100 раз массив данных в base64. "Протобуф" просто избавляется от дополнительных байт base64 и заголовков полей, но он работает только поверх HTTP2.

А в части моего коммента, то если добавить то, о чем я написал, будет реализация SOAP на JSON. Ну да, пакеты будут чуть меньше, но сложность реализации возрастает. При том для кейсов с 1С размер пакетов - это второстепенная проблема.
38. botokash 389 19.09.22 11:14 Сейчас в теме
(36) я может что-то не правильно понимаю, но SOAP это протокол и согласно ему сообщение имеет определенную структуру, которую никуда не выкинешь. Как бы мы не сжимали тело сообщения, останется обязательная часть, и именно отход от нее обусловлен постепенным отказом от SOAP в высоконагруженных системах. Плюс каждое движение над телом запроса - это дополнительные "такты" как на клиенте так и на сервере.
43. starik-2005 3033 19.09.22 11:26 Сейчас в теме
(38)
останется обязательная часть
Она не такая и большая. И, опять же, в 1С не является узкой частью.
(38)
это дополнительные "такты"
Опять же, в 1С это малосущественно. Я вот, лично, не вспомню и даже навскидку придумать не могу сценарий, где такты и вес сообщения для 1С являются существенными факторами.
И да, для SOAP можно написать так:
Возврат Новый ХранилищеЗначений( Запрос.Выполнить().Выгрузить(), Новый СжатиеДанных(0) );
В HTTP придется все это засовывать в тело ответа, т.е. как минимум создавать новый объект "HTTPОтвет" и засовывать в тело ответа получившиеся данные. И если их не паковать, то размер HTTP-пакета будет больше, чем размер пакета SOAP с пожатым хранилищем значений.
44. botokash 389 19.09.22 11:30 Сейчас в теме
(43) В частном случае системы 1С как 90% всех ИС компании - да. Но все таки в статье моя основная мысль - система 1С как один из сервисов внутри компании. И вот тут становится вопрос анализа всего архитектурного стека разработки компании. И свои выводы я предоставил.
45. starik-2005 3033 19.09.22 11:36 Сейчас в теме
(44) Ну так у каждой системы есть определенные требования к уровню обслуживания: реакция, доступность, нагрузка. 1С - это бэкофис, в лучшем случае еще что-то типа внешнего хранилища НСИ - этакий провайдер мастер-данных, MDM. В кейсе с MDM доступность системы должна быть высокой, но и пакеты там не особо большие ходят. В части бэкофиса, то 1С - это коллектор поступающих от фронта сообщений. И если думать об архитектуре, то в части MDM просто обязан быть механизм кеширования, чтобы за каждым ежеминутно нужным фронт не таскался в 1С - пусть берет из кеша, а 1С пусть кеш обновляет при изменениях. А при транспорте в коллектор нужен приличный брокер сообщений с гарантированной доставкой, а не прямой HTTP-сервис.

Я вот вообще не вижу 1С, как высокодоступного поставщика данных в корпоративной системе - это не ее функция.
49. botokash 389 19.09.22 11:42 Сейчас в теме
(45) Мы говорим о разных вещах. Я о системе 1С как части стека со всеми вытекающими требованиями, а вы о роли системы. Мои доводы о современных требованиях к используемым решениям это про то что по факту окружает нашу 1С систему.
50. starik-2005 3033 19.09.22 11:49 Сейчас в теме
(49)
Мы говорим о разных вещах.
Напротив, мы говорим об одном и том же - об архитектуре. Это слово есть даже в кратком содержании статьи (слово "Архитектор"). Так вот архитектура - это то to be, которое обеспечивает те самые реакцию, доступность и нагрузку. Если нагрузка небольшая, требования к доступности невысокие, а реакция позволяет пользователю сходить и налить кипятка, то нам достаточно 1С и SOAP. Если же требования возрастут, то выигрыш в 10% на HTTP-сервисах не даст ничего, т.к. все упрется сначала в доступность, потом в нагрузку, а потом и в реакцию (ну или наоборот, сначала в реакцию, потом в нагрузку, а за ними и в доступность, ибо Вы решили обновить систему в самый неподходящий момент, ибо предыдущее обновление все к хренам сломало).
53. botokash 389 19.09.22 12:09 Сейчас в теме
(50) Сожалею, но вы меня так и не поняли. Статья - интеграция с точки зрения архитектора. Человек, принимающий решение на основании своих компетенций и поставленных условий решения задачи. А условия не всегда про техническую составляющую, а больше про денежную. В данной ветке дискуссии мне больше нечего добавить =)
57. starik-2005 3033 19.09.22 13:31 Сейчас в теме
(53)
а больше про денежную
Скука.
48. booksfill 19.09.22 11:38 Сейчас в теме
Я не уверен, что паттерн Front Controller такое уж хорошее решение - при всех плюсах получаем серьезные проблемы:

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

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

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

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

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

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

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

4. Как тут уже написали - вместо набора понятных и независимых сущностей, получаем некую загадочную "точку входа", куда по любому чиху лезем, чтобы понять что она умеет. И лезть в документацию, в общем случае, - плохая идея, т.к. совпадение документации с реальной жизнью, такое себе, красивое.
Артано; starik-2005; +2 Ответить
52. botokash 389 19.09.22 12:03 Сейчас в теме
(48) Для меня описанные проблемы выглядят немного "притянутыми за уши":
1. Единая точка входа - это изолированная функциональность подсистемы и отлично поддается тестирования. Если допускается возможность попадания в прод такого рода ошибок в коде - это проблема другого характера. А ошибка разработчика, написавшего обработчик метода сервиса, всегда изолирована через попытку и не может привести к остановке всего сервиса.
2. Цель применения подобного паттерна - разделение ответственности и единообразность. И если мы говорим разработчику не логировать что-то внутри сервиса почему он должен начать это делать? Или почему мы вдруг решим отойти от паттерна и в контроллер тянуть какие-то условия, нарушая тем самым его смысл?
3. Не вижу как пример с типовыми коррелирует с предоставленным подходом? Есть общепринятые рамки создания REST API и не предвидится никаких "вдруг" изменений в механизм его работы.
4. Сошлюсь на ответ в пункте 3. И вопрос к вам от меня - что является "набором понятных и независимых сущностей"?
58. booksfill 19.09.22 15:26 Сейчас в теме
(52)
Если бы я знал "как надо", я бы не комментарии писал,а статьи :)

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


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

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

ПолучитьСписокСкладов - понятно и никак не зависит от "УдалитьСклад".
"УдалитьСклад" - понятный и независимый от метода "ПолучитьСписокСкладов", потому как идентификатор склада я могу получить множеством других способов.
59. malikov_pro 1292 19.09.22 16:30 Сейчас в теме
(33) По ссылке - "GraphQL это синтаксис, который описывает как запрашивать данные", а RPC - " класс технологий, позволяющих программам вызывать функции или процедуры в другом адресном пространстве". Инструменты для разного класса задач. Про RPC упоминаю потому что на практике периодически вижу SOAP с схемой данных в виде одной строки в которую упихивают все подряд (XML), которое нормально заменяется JSON-RPC.
60. starik-2005 3033 19.09.22 16:34 Сейчас в теме
(59)
описывает как запрашивать данные
А что мы делаем при вызове веб-сервисов? В основном или запрашиваем данные, или передаем данные в систему. Остальные кейсы малозначимы. gpaphQL - это просто еще один механизм, позволяющий запросить тот пакет данных, который нужен получателю. Это как oData, фактически, только для извлечения данных.
61. malikov_pro 1292 19.09.22 22:34 Сейчас в теме
(58) "Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет." - если у вас косяк в коде и он не интерпретируется на уровне модуля HTTP сервиса, то даже в ЖР не напишет, не важно его количество.

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

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

Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.
@botokash поэтому писал что хочу делать кодом, чтобы не завязываться на общую структуру данных в спр.
62. botokash 389 20.09.22 05:21 Сейчас в теме
(61)
чтобы не завязываться на общую структуру данных в спр


Думаю понял теперь о чем вы хотели сказать. Я считаю это вопросом в плоскости реализации и не вижу его таким значимым по отношению к поставленной цели, описанной в статье. Я реализовал то что почитал более быстрым, а другой разработчик может сделать как ему больше нравится. Напомню, цель моей статьи была не конечный продукт, а демонстрация практики и подхода к разработке сервисов =)
64. booksfill 21.09.22 11:22 Сейчас в теме
(61)
Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.


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

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

P.S. А вообще, было бы интересно, если кто-нибудь подробно осветил только правильную реализация данного паттерна в 1С, как раз с учетом первичной отказоустойчивости и балансировки нагрузки хотя бы по слушателям.
63. 1CUnlimited 304 20.09.22 13:09 Сейчас в теме
>"использование системы 1С как одного из сервисов внутри компании";
Сразу плюсанул за эту фразу, многие из 1С делают центр, но естественные ограничения платформы как бы намекают
65. malikov_pro 1292 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 и в него собирать наработки.
botokash; +1 Ответить
66. botokash 389 21.09.22 13:32 Сейчас в теме
(65) Спасибо за ссылки, полезная информация.
Оставьте свое сообщение