Простое предложение

[Халфин Тимур Маликович]

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

Как вы смотрите на то, чтобы ПФ предлагал дополнительный сервис за отдельную плату:
выделенный виртуальный сервер с интерпретатором Python и возможностью доступа к данным аккаунта ПФ через внутренний API (с ограничением количества и частоты запросов, конечно. Как внутренних, так и внешних).

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

Я бы заплатил.

[Илья Федоров]

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

Как вы смотрите на то, чтобы ПФ предлагал дополнительный сервис за отдельную плату:
выделенный виртуальный сервер с интерпретатором Python и возможностью доступа к данным аккаунта ПФ через внутренний API (с ограничением количества и частоты запросов, конечно. Как внутренних, так и внешних).

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

Я бы заплатил.

Есть же наработки и решения от Степана Чельцова https://getupd.io/
Я думаю это правильный путь что такие опции делает не сам ПФ, а партнеры.
Я сам чем то похожим хотел заниматься, но есть проблема с ресурсами на все это.

[Халфин Тимур Маликович]

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

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

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

[Халфин Тимур Маликович]

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

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

[Dmitry Goncharenko]

Для нас это достаточно далекая перспектива. Но если заглянуть в будущее, то теоретически план может быть таким:
- Вначале появятся встраиваемые в ПФ приложения - на отдельной вкладке в задаче/проекте и т.п. можно размещать приложение, которое взаимодействует с контентом страницы или со всем ПФ, и что-то делает. Тут место для всяких интеграционных штук, в первую очередь. Например, проверить посылку по трекингу, прошел ли платеж в банке, обменяться данными со сторонней системой и т.п.
При этом сами приложения сторонние и хостятся где-то на стороне.

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

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

[Халфин Тимур Маликович]

Начинающим пользователям достаточно тех средств NoCode, которые вы реализуете - интересно было бы ознакомиться со статистикой использования сценариев/процессов/кнопок в разрезе размеров компании и времени использования ПФ.
По моему опыту, со временем запросы растут и это приводит к появлению огромного количество сценариев.
Начиная с какого-то объема, отладка и сопровождение NoCode становятся довольно затратными (350 сценариев в 100 процессах - нужен целый отдел автоматизации).
Думаю, растут также и затраты на обслуживание этих запросов.
При этом виртуальный сервер с интерпретатором Питон и онлайн редактором/отладчиком - хорошо отработанная технология.

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

вы зря упрямитесь...

[Dmitry Goncharenko]

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

[Халфин Тимур Маликович]

то теоретически план может быть таким:
- Вначале появятся встраиваемые в ПФ приложения - на отдельной вкладке в задаче/проекте и т.п. можно размещать приложение, которое взаимодействует с контентом страницы или со всем ПФ, и что-то делает. Тут место для всяких интеграционных штук, в первую очередь. Например, проверить посылку по трекингу, прошел ли платеж в банке, обменяться данными со сторонней системой и т.п.
При этом сами приложения сторонние и хостятся где-то на стороне.

Мне кажется, вы немного отстали - это в ПланФиксе уже есть, никто не мешает уже сейчас хостить на стороне и реализовывать алгоритмы в рамках API.

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

Поэтому уже сейчас можно предположить такой ответ: "А давайте, сделаем в изолированном пространстве библиотеку - ретранслятор API Python / REST API, при этом для сервера ПФ ничего не изменится в плане нагрузки и безопасности.

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

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

Не надо внешнюю простоту, надо простую концепцию.