Чем воспользоваться для распознавания котиков в 1С?

Мой доклад будет в основном о Serverless – как его использовать, если в 1С хочется сделать что-то, чего делать нельзя. Если каких-то возможностей не хватает, и хочется максимально упростить себе жизнь, и при этом не разбираться с Docker самостоятельно.

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

 

Причем тут 1С?

 

 

В 1С можно сделать практически все, кроме:

• действий с оборудованием – эту задачу решают, в основном Native API-компоненты;

• и второе – это какие-то сложные обработки данных, которые связаны с deep-learning, все AI-средства, в том числе и распознавание изображений.

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

Внешние компоненты для этого использовать хорошо, правильно, круто и замечательно.

 

 

А затем вообще все это делать в 1С? Зачем я тут все это дело взялся использовать и еще вас призываю?

Есть такая штука, как Digital Twin Hyperautomation (цифровой двойник организации) – это не про технику, это про бизнес. Глобальный тренд в том, что если у вас в компании есть автоматизация, и вы хотите автоматизировать все, то для каждого процесса, для каждого сотрудника – для всего создается так называемый цифровой двойник.

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

 

 

Зачем все это нужно в 1С?

Я не буду говорить о классических кейсах, когда мы используем внешние компоненты – я буду говорить именно о тяжелых историях, таких как:

• OCR для распознавания первички. Пока что живых кейсов, которые там существенно сократили бы время, наверное, не так много. Но тем не менее, туда все идем.

• Аутентификация по лицу – это самая приятная история и, самое главное, даже не представляете, насколько в современном мире распознавание лиц внедряется легко. Распознать лицо человека сейчас проще, чем проверить наличие печати на документе. Это не шутка, это серьезно. Сам лично проверял – с печатью намного сложнее. Просто потому, что все фреймворки компьютерного зрения лица уже распознают без проблем.

• WMS-системы – в современном мире, если мы внедряем WMS-систему, уже пора строить маршруты по складу с камерой. Это несложно, это реально делается практически по щелчку пальцев, а мы до сих пор иногда думаем, что это некий Rocket science. Это уже давно не Rocket science.

• Учет транспортных средств, распознавание номеров – вообще элементарная задача. Я знаю компании, которые для этого приобретали продукты, стоимостью в миллионы, к счастью рублей. Не надо этого делать – это запросто решается в 1С. Одной 1С-ной обработкой и одной Cloud-функцией за полчаса.

• Не могу не сказать про RPA – взаимодействие с интерфейсом путем кликания по картинкам. Хотя это и плохой тон, но такая практика имеет место быть.

• MES-системы – к сожалению, пока 1С-решения, даже ERP не так плотно входят на MES-рынок. Так или иначе, наблюдать за станком теперь можно не только путем использования его интерфейсов, а просто поставив веб-камеру и обучив сеточку классификации: вот это хорошо, а вот это – плохо.

Дальнейшие кейсы можно придумать самостоятельно. Но общий посыл в том, что AI и 1С – это не о разном, потому что с помощью внешних компонент как раз добавить что-то актуальное очень легко.

 

Online vs Offline

 

 

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

• Наиболее популярный случай – когда какая-то библиотека отсутствует для 1С. GitHub планомерно вошел в нашу жизнь, все знают, что такое NodeJS, .NET Core, Java и т.д. Тот 1С-ник, который владеет только 1С, стал редкостью. Если любой школьник может нагуглить решение простых задач на гитхабе, то почему мы должны для какого-то популярного алгоритма изобретать его аналог внутри 1С? На Инфостарте много крутых правильных решений – например, мы использовали расстояние Левенштейна. Но если вам нужно сравнить две строчки, а на Инфостарте такого решения нет – никто пока что не портировал этот алгоритм внутрь 1С, то «Здравствуй, GitHub» – вы там найдете любой алгоритм в том или ином виде. А дальше настает некая сложность. Либо на NodeJS написать «npm i» и у вас все хорошо, все получилось, либо в 1С переносить очень большие, массивные куски кода, требующие знаний, сил, умения. Мой посыл в том, что писать код повторно не нужно. Если есть готовое решение на любом языке – без разницы на каком, просто берем и используем его – делаем на его основе внешнюю компоненту. Это первый кейс.

• Второй кейс – если нужен доступ к какой-то библиотеке – например, в 1С нет GraphQL, веб-сокетов, доступа к какой-нибудь специфичной СУБД – тем не менее, на гитхабе все это дело присутствует.

• И третий кейс – это торговое оборудование. Сразу скажу, третий кейс – не про мой доклад, C++ в моей жизни иногда появляется, но в последнее время все больше с ужасом и с нежеланием, отторжением. Уже тяжело каждый раз разбираться, где ты не так память выделил, где ты использовал не тот класс и т.д. Соответственно, торговое оборудование – это реальный кейс, для которого внешние компоненты создавались, для которого они хороши, для которого они подходят, где все круто.

 

 

Если у вас магазин, где нужно подключить новую кассу, то Serverless здесь не при чем, для этого NativeApi компоненты – это лучшее, что есть. И ничего из того, о чем я в докладе дальше будут рассказывать, для взаимодействия с ТО придумывать не надо.

Единственное, я надеюсь, что мне в своей жизни не придется этим заниматься, что производитель торгового оборудования все-таки содержит в своем штате программистов на C++. У них других альтернатив нет, потому что у них там COM-интерфейс, и им надо прошивки кодить – там есть люди, которые этим занимаются, они очень крутые и профессиональные, и им в принципе не проблема для своих Си-шных компонент сделать С++ обертку и портировать это в 1С Native API.

 

 

Этот слайд – это сугубо мое IMHO.

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

• Back, front, desktop, mobile – для всего этого можно разрабатывать в 1С. 1С – это очень крутая платформа. Если вы попробуете SPA, вы поймете, что там работать гораздо сложнее – кроме того, что там надо код писать, вам нужно каждую кнопочку отдельно верстать, отдельный компонент делать, отдельно дизайнить. Если у вас не Vue, а Angular, у вас слава Богу есть компоненты Material Design от Google. Но, тем не менее, под мобайл у вас будет свой фреймворк, скорее всего даже и своя команда разработки. Допустим, мобайл вы будете разрабатывать на флаттере. Фронт вы будете писать на Vue или Angular. На бэкенде у вас будет NodeJS – конечно, у вас будет не JavaScript, а уже TypeScript. И там все будет намного сложнее. Потом это все еще должно взаимодействовать – там еще может быть не REST, а какой-нибудь GraphQL. Это очень сложная история. Я верю, что будущее за low-code, будущее за фреймворком, который позволяет что-нибудь объединять и сейчас даже в вебе тренд идет туда. Поэтому нам нужно немного пережить этот кризис, когда ИТ залито деньгами и мы можем кодить фронт на C++, но тема к тому, что RAD (Rapid Applications Development никуда не умерло, она остается. И скоростная разработка, когда вы в одной среде делаете и Back, и Front, и desktop, и mobile – это важная история.

• Далее, конечно, NodeJS – JS сейчас обязателен. Не забываем про WebKit. Это очень приятная штука, и на фронте в 1С что-то делать приходиться все чаще и чаще. Подход хороший. Плюс JS можно использовать для Serverless-решений в кейсе, если они очень небольшие, если вам там не всегда WebKit удобен, если нужно вычислить какую-то функцию, или нужно использовать какую-то криптобиблиотеку – вам не обязательно добавлять на форму браузер в 1С, все это можно сделать где-то на стороне бэкенда. Если у вас сугубо вопрос обработки, но вы сумели освоить только JS, то, конечно, Serverless история полезна.

• И .NET – с точки зрения Enterprise-стека технологий. Сразу скажу, что я не сторонник Java-стека и других, более древних языков. Я считаю, что умирающие технологии должны умирать, а .NET все-таки сейчас активнее всех развивается. Появился .NET Core. И у .NET еще есть определенные плюшки – все-таки 1С это по большей части пока что мир Windows. По крайней мере, клиентский. Хотя, конечно, жизнь меняется. Но тем не менее, разработка по большей части ведется все равно на Windows.

Хотя я и перечислил здесь всего три языка, я не отрицаю всего остального. Я считаю, что, если у вас там есть какое-то желание куда-то развиваться, что-то выучить, я бы рекомендовал для создания комплексных современных крутых продуктов использовать что-то в этом роде. Если в JS не уложились, то расширяйте его .NET. Предлагаю использовать этот стек по восходящей: не укладываемся в 1С – расширяем с помощью JS, не укладываемся в JS+1С – расширяем .NET. Его приходится использовать крайне редко, только для обработки информации.

 

 

Но знание С++, конечно, никогда не повредит. Это база, это самое крутое, что есть. Наверное, наличие в штате разработчика на C++ многие вопросы делает очень простыми и приятными.

 

Все тяготы собственного сервиса и как их преодолеть (про Docker и k8s)

 

 

Что можно сделать, если не хочется Serverless.

Если у вас появился какой-то сервис, который нужно где-то разместить (например, вы написали на JS библиотеку, которая реализует протокол SAML – это последний кейс, который встречали), то его, конечно, можно запустить внутри Webkit. Но зачем внутри WebKit запускать что-то, если это не страничка, которая отображается?

Чтобы запустить какой-то JS-код, его нужно где-то разместить – либо на сервере, либо в Docker.

• При этом запускать что-то на сервере в современном мире – это как-то странно, особенно, если это – одна функция. На сервере мы запускаем только сложные системы, состоящие из кучи компонент (например связку из веб-сервера, 1С-сервера, сервера СУБД – такое никто не запускает в докере).

• Поэтому если вы написали какой-то простенький JS-код, который хочется где-то запустить, его надо запускать в Docker.

Историю про Docker уже много раз показывали. Но с ним есть несколько сложностей:

• Сначала нужно найти, где вы разместите сервер с этим docker-контейнером. Допустим, у вас в организации есть сервер, на котором вы можете запустить этот Docker-контейнер – тогда это, в принципе, не проблема.

• Еще вам нужен DevOps-инженер, который знает синтаксис Dockerfile или YAML-синтаксис Docker Compose, либо вам нужно самим в этом разобраться. Но с этим проблем нет – синтаксис Dockerfile простой, выучить его можно.

• Допустим, вы Dockerfile сформировали, контейнер запустили скачали с Docker-хаба, но контейнер он на то и контейнер, что он имеет полное право упасть. Он не обязан поддерживать свою стабильную работу, обеспечивать какую-то отказоустойчивость. Он нужен вам для разработки и деплоя. Это логично.

• А если вы хотите запустить этот сервис в продакшен, вам нужно обеспечить отказоустойчивость. Особенно, если у вас там работают люди, которые приходят на рабочее место, подставляют лицо перед веб-камерой, и она фиксирует их приход на рабочее месте на удаленке. Соответственно, в этот момент кто-то пришел на работу, лицо перед камерой поставил, когда запустил 1С, а ему сказали – нет, ты на работу не пришел. В этот момент у вас появились проблемы. Конечно, если вы используете контейнеры, то вам нужен оркестратор. 1С же у вас кластеризован, сервер MS SQL, у вас, надеюсь, тоже кластеризован. В качестве оркестратора для Docker-контейнеров выступает Kubernetes. Есть еще варианты. Но этот самый простой – с остальными еще сложнее.

 

 

В любом случае, Kubernetes – это «Добро пожаловать в новый чудный мир».

Здесь уже все работает не так просто:

• у вас уже появляется некий API-сервер;

• у вас появляется отказоустойчивость – у Kubernetes есть Controller Manager;

• есть Scheduler.

Короче, минимум три служебных сервера кроме самих нод, на которых располагаются контейнеры (поды). При этом на каждой ноде должен быть прокси, Kubelet, cAdvisor. И ничего другого желательно, чтобы не присутствовало.

Если у вас нормальная инфраструктура в компании (нормальные инфраструктурщики), то развернуть проект по Kubernetes получится где-то за полтора месяца при условии наличия оборудования и средств финансирования. Таким образом, запуск одной простой функции становится не очень приятной задачей.

А теперь давайте я начну уже говорить о чем-нибудь приятном.

 

 

Kubernetes можно создать в облаке.

И, наверное, даже стоит это делать в облаке, потому что он там уже есть – вам просто частичку выдадут, будете за нее платить 3000 рублей в месяц.

Если вы это делаете для себя, внутри – то конечно, запускаете код в докере, и не надо с этим морочиться. А если вы это делаете для компании, то для компании обычно, наоборот, переменные затраты (OPEX) воспринимаются лучше, чем капитальные (CAPEX).

Грубо говоря, разворачивание собственного Kubernetes вам окупится по этой ставке лет через пятнадцать, наверное.

 

Serverless в Yandex.Cloud

 

 

Serverless в этом отношении гораздо проще – седых волос вы на нем не заработаете. Я писал статью на эту тему.

Его еще иначе называют FaaS (Function as a Service), это название было модно 3-4 года назад.

Serverless – это наиболее простая история сделать что-то, чего делать нельзя.

Заходите в консоль Yandex.Cloud, выбираете Cloud Functions, нажимаете «Создать функцию» – вам сразу появляется выбор среды. На слайде показано, какие среды доступны для Python.

Здесь есть все популярные языки разработки – .NET Core, NodeJS, Java, Go, Bash и т.д.

Я очень посетовал, что там нет OneScript – это прямо упущение. Кстати, с Яндексом может быть получится на эту тему договориться. Все-таки, раз .NET Core у них есть, значит, вопрос добавления OneScript – уже не такая большая проблема.

В сервисе Yandex Managed Service for PostgreSQL есть возможность развернуть спецсборку PostgreSQL для 1С, в Yandex Compute Cloud есть готовые образы сервера приложений 1С с лицензированием. При определенных условиях они туда могут и OneScript добавить. Главное, чтобы это был не «1С:Исполнитель».

 

 

Дальше все просто – у вас открывается редактор для работы с кодом:

• код можно написать вручную;

• можно загрузить из Object Storage, если у вас кода много;

• можно загрузить из zip-архива.

Код на .NET в Yandex.Cloud выглядят даже еще симпатичнее, чем Python – все с подсветкой синтаксиса.

Здесь надо указать точку входа – это функция, которая будет выполнена первой.

К ней там небольшое требование, что она должна возвращать response (значение в формате JSON).

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

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

В Yandex.Cloud можно просто зарегистрироваться и «потыкать». При создании аккаунта на знакомство с сервисами выделяется 4000 рублей, в рамках которых можно пользоваться платформой первые два месяца – вы не израсходуете эту сумму полностью на Cloud Functions.

Из 1С Cloud-функции вызываются элементарно – я надеюсь, что все этот код знают, у меня он уже в шаблон добавлен:

Соединение = Новый HTTPСоединение("functions.yandexcloud.net",,,,,,Новый ЗащищенноеСоединениеOpenSSL());        
    Запрос = Новый HTTPЗапрос("/<тут ИД вашей функции>?integration=raw");
    Запрос.УстановитьТелоИзСтроки("{ ""sentence"": ""мама мыла раму"" }");
    Результат = Соединение.ОтправитьДляОбработки(Запрос);
    СтрокаРезульта = Результат.ПолучитьТелоКакСтроку();

То же самое можно сделать через потоки.

Единственное, что отправлять нужно всегда хотя бы какой-нибудь JSON, иначе у вас Cloud-функция просто не отработает.

Для Python я в HTTP-запрос передаю параметр «integration=raw», чтобы у вас параметры не проверялись отдельно. Если этого не сделать, то движок Яндекса будет пытаться обработать параметры функции, которые вы передаёте. Наверное, для .NET это тоже актуально.

 

 

Здесь показан код Cloud-функции на Python. В принципе, он ничем особо не отличается.

Основное преимущество Yandex.Cloud перед AWS Lambda в том, что мы в 1С мы часто работаем со персональными данными, а эта площадка полностью соответствует 152-ФЗ, плюс задержки по пингу от Yandex.Cloud совсем небольшие – если вы находитесь в Москве, пинг составляет не более 10-20 миллисекунд.

 

Serverless в AWS Lambda

 

 

В Amazon на пинг сразу уйдет 200-300 миллисекунд, плюс 152-ФЗ нам говорит о том, что персональные данные в Amazon передавать нельзя.

При этом AWS Lambda появилась намного раньше – она считается самым продвинутым, самым крутым, самым интересным, что есть. С ним много народа работает. Его тоже стоит рассмотреть.

Тут поддержка языков почти такая же, как у Yandex.Cloud, плюс поддерживается Ruby.

Также поддерживаются предыдущие версии Python – у Yandex.Cloud поддерживаются только самые актуальные.

 

 

Amazon далеко не идеален. Например, редактировать в AWS Lambda код .NET Core уже по умолчанию нельзя.

Для загрузки кода поддерживается Upload из Zip-файла и Upload из Amazon S3 location – точно так же сделано в Yandex.Cloud.

 

 

Для редактирования код на Python уже есть редактор с подсветкой синтаксиса и автодополнением. При создании новой функции, создается демоверсия из шаблона.

У функции есть идентификатор ARN – эту штуку надо запоминать.

 

 

Но если в Yandex.Cloud у вас Cloud Function можно просто сделать публичной, и она заработает, в Amazon вам надо еще API Gateway настроить.

Заходите в вашей консольке в API Gateway, выбираете свою функцию и ее версию. Указываете вид интеграции Lambda и добавляете.

 

 

На выходе получаете обычный URL, с которым вы знаете, что делать – код вызова из 1С примерно такой же, как в Yandex.Cloud.

Просто вызываете по URL и передаете туда JSON, а он вам возвращает другой JSON, который является результатом выполнения функции.

Например, в JSON вы можете упаковать картинку в base64, либо можно по ссылке картинку передать.

Соответственно, в Amazon работает примерно все то же самое.

 

Программное создание Cloud-функций через API

 

 

Serverless еще приятен тем, что эти Cloud-функции вы можете создавать даже автоматически – это уже такой продвинутый кодинг на уровне искусственного интеллекта.

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

Либо вы выстраиваете ваш деплой-процесс, и в нем существует какая-то функция, которая работает вне основной 1С-ной среды. Соответственно, вы ее тоже встраиваете в процесс, обращаетесь к ней через API, добавляете туда параметры – через API можно даже тестировать.

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

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

 

COM еще жив (пока что)

 

 

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

Если у вас Windows, то COM позволяет очень быстро проверять гипотезы.

Если вам надо какой-то код на .NET просто проверить, но не хочется регистрироваться в Yandex.Cloud или в AWS Lambda – открыли Visual Studio, написали там три строчки перед вашим классом, скомпилировали как COM Visible – и, пожалуйста, получили готовый COM-объект, который в 1С нужно просто создать и использовать.

Это делается крайне быстро и очень приятно. Более того, COM еще и отлаживать можно – легким движением руки превращаете в консольное приложение и отлаживайте, что хотите.

COM можно использовать, когда у вас не готовый код – отлаживать код в Serverless-решениях сложнее. Здесь намного проще.

 

.NET ещё живее (кроссплатформенные компоненты на .NET Core и гибридный подход Native API)

 

 

.NET уже не тот, что был – вы его можете использовать и на Linux, и на MacOS.

На .NET можно даже фронт написать – в вебе есть Blazor и WebAssembly.

Есть ML.NET – прекрасная штука для машинного обучения.

В принципе, вы можете это все использовать в виде страшного стремного COM, а потом просто мигрировать проект на .NET Core и скомпилировать решение под Linux. Или взять код и запустить его в Serverless, чтобы не разворачивать это на сервере. Взяли, отладили, посмотрели и задеплоили.

Конечно, .NET правильнее деплоить в Azure, но меня и Yandex.Cloud устраивает.

 

 

Более того, .NET можно использовать через обертку Native API-компонент. Есть замечательный автор, который этим очень долго занимался и написал шаблон Native API компоненты, которая загружает сборки .NET. Порядок использования он описал в статье на Хабре.

Для него в 1С создается объект, и любые классы, которые вы понасоздавали – что в Linux, что в Windows, что в MacOS – вы можете просто взять вот так и заюзать внутри 1С. Причем, на Windows можно отладить, а на Linux уже использовать.

Крутая штука, не требует вообще никаких телодвижений.

Я не знаю, какой путь короче – этот или через Serverless, но и то, и другое – это очень простые решения, которые в своей практике используются. И если вам принципиально не нравятся онлайн-решения (потому что Serverless все-таки будет онлайн), то, пожалуйста, есть гибридный вариант использования .NET.

 

Блеск и нищета Native API

 

 

Пара шпилек в сторону Native API.

 

 

И да, я же вам обещал распознавание котиков. В Amazon и в Yandex.Cloud есть инструменты для распознавания.

Сервис Yandex Vision в Yandex.Cloud можно использовать из Cloud Function.

В Amazon Deep Vision API можно использовать из AWS Lambda.

 

Демонстрация

 

Давайте, я покажу в онлайне, как можно работать в Cloud-функциями в Yandex.Cloud.

 

 

В личном кабинете Yandex.Cloud переходим к Cloud Functions.

 

 

Открывается список Cloud-функций – здесь можно создавать новые.

 

 

Создаю функцию, говорю, что это func3.

 

 

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

 

 

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

• Версия среды исполнения для .NET Core только одна, но для Python можно выбрать несколько.

• Внизу есть возможность задать таймаут и переменные окружения – это значит, что Cloud-функцию можно выполнять в разных средах.

• Класс Handler – самый главный класс, который возвращает обычный response

 

 

Возможности импорта здесь практически минимальны.

 

 

Чтобы этой функцией можно было пользоваться извне, ее нужно сохранить и указать, что она публичная.

Или, если вы делаете непубличную функцию, нужно настраивать API Gateway – он тоже у Yandex.Cloud есть, либо можно встроить аутентификацию.

 

 

Функцию можно протестировать. Для этого нужно задать шаблон данных – HTTP-вызов.

 

 

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

 

 

Запускаете тест, и вот он результат – статус 200 и сообщение «Hello, world!»

Соответственно, верхний JSON вы отправляете – его же можете в Cloud-функции посчитать, а внизу показан JSON, который вам обратно вернется.

 

 

На закладке «Обзор» отображается вся история, что мы тут делали, какая среда выполнения и т.д.

 

 

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

 

 

Все то же самое в Amazon – тоже нажимаете «Creation function».

 

 

Указываете, что Author from scratch. Это значит, что будете создавать функцию с самого начала.

 

 

Выбираем среду исполнения.

.NET Core выбирать не буду, потому что не даст редактировать. Выберу Python 3.8.

Создается функция. Все это можно поюзать бесплатно. В Amazon есть много тестовых вариаций – они еще более лояльные, чем Yandex.Cloud.

Но через Amazon все работает дольше.

 

 

На закладке Code можно задать код функции или что-то загрузить.

 

 

На закладке Test по кнопке Invoke этот код можно протестировать.

 

 

Через поиск открою API Gateway, чтобы его настроить.

 

 

Он у меня уже создан, соответственно, мне нужно туда добавить интеграцию по HTTP API.

 

 

На первом шаге мастера создания интеграции выбираю «Add Integration».

 

 

Вид интеграции выбираю Lambda, выбираю свою функцию и задаю для нее API name.

 

 

Здесь можно сконфигурировать путь Resource path – по аналогии с тем, как мы делаем в 1С.

 

 

Можно настроить имя стейджа и автодеплой.

 

 

Проверяем параметры интеграции и создаем по кнопке Create.

 

 

Теперь у меня API Gateway создался и я могу вызывать эту функцию из 1С по ссылке, которая указана как Invoke URL.

HTTP-вызов, я думаю, все делать умеют – это то, что в 1С уже вряд ли когда-нибудь будет меняться, там сложно придумать что-то для развития.

Общая идея моего доклада – используйте serverless, это наиболее короткий путь. Есть еще COM, который тоже короткий. Но он небезопасный.

 

Вопросы

 

Общая идея понятна – ты можешь быстро написать какой-нибудь скрипт, ничего у себя локально не поднимать, где-то его опубликовать и по-простому REST API делать запросы. Затруднение вызывает то, что вся настройка выполняется интерактивно и нужно не только написать простой скрипт и сделать запрос в виде Cloud-функций, но и настроить Gateway API, авторизацию.

Не обязательно настраивать интерактивно, там есть консольный интерфейс. А настройка API Gateway – это быстрее, чем развернуть docker. И работает стабильнее. Для меня это оказалось самым коротким путем, который позволяет выполнить в 1С что-то левое. Это очень актуально, если вы уже в компании используете либо AWS, либо Azure, либо Yandex.Cloud. Т.е. если у вас Yandex.Cloud уже есть, вы за него что-то платите, тогда у вас уже есть эта консоль – вы просто добавите функцию, и никто эти лишние 100 рублей не заметит. Особенно, если у вас в компании уже принято, что вы не капитальные затраты на сервер просите, а наблюдаете за чеком в облако, отслеживаете, что вы там используете.

Как, по твоему опыту, продать собственнику Cloud? Ведь здесь принципиальная другая схема затрат на это, потому что, когда у тебя разработчик, который пишет внешнюю компоненту, ты как-то платишь ему оклад за поддержку и контролируешь это. А тут в облаке платить деньги за каждый вызов.

Собственники воспринимают затраты на Cloud лучше, чем «Давайте купим сервер и заплатим разработчику». Мир меняется, бизнес меняется, собственники не любят платить много сразу. А когда затраты более-менее размазаны, заказчики их прогнозируют, они понимают, что затраты будут расти с ростом инфраструктуры, что это – некая прогнозируемая история, которую спланировали. «Давайте возьмем нового разработчика» – это намного тяжелее.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на Онлайн-митапе "Расширяем возможности 1С: ВК, веб-технологии, serverless и другое".