Комментарии 24
Печально что BPEL, а не BPM.
Помогите мне развеять вашу грусть.
На языке BPEL моделируется только логика взаимодействия решения SBM с внешними web службами других приложений и систем, работающих на той же платформе или совсем других.
BPM — это название подхода управления деятельностью на основе процессов или регламентов. Подробнее на wiki
BPMS — это название класса систем, где моделируется и исполняется приложение, автоматизирующее бизнес-процесс (Business Process Management System). Платформа SBM — относится к этому классу. Сам процесс моделируется в простой нотации workflow. Сразу скажу, что нотация моделирования BPMN не поддерживается. Наша платформа легче, проще, дешевле, чем аналоги с поддержкой BPMN. Моделировать процессы в упрошенной нотации быстрее. Дорабатывать формы UI, структуры хранения данных, отчеты, процедуры и скрипты можно в одной интегрированной среде разработки. Впрочем, нужно самому в этом убедиться…
На языке BPEL моделируется только логика взаимодействия решения SBM с внешними web службами других приложений и систем, работающих на той же платформе или совсем других.
BPM — это название подхода управления деятельностью на основе процессов или регламентов. Подробнее на wiki
BPMS — это название класса систем, где моделируется и исполняется приложение, автоматизирующее бизнес-процесс (Business Process Management System). Платформа SBM — относится к этому классу. Сам процесс моделируется в простой нотации workflow. Сразу скажу, что нотация моделирования BPMN не поддерживается. Наша платформа легче, проще, дешевле, чем аналоги с поддержкой BPMN. Моделировать процессы в упрошенной нотации быстрее. Дорабатывать формы UI, структуры хранения данных, отчеты, процедуры и скрипты можно в одной интегрированной среде разработки. Впрочем, нужно самому в этом убедиться…
А не планируется ли Community версия, чтобы с ваять что нить, а потом если все пойдет по маслу купить допустим Enterprise Версию?
Да и на чем построена система? Дапустим куба сразу пишет на чем она построена https://www.cuba-platform.ru/technologies
Да и на чем построена система? Дапустим куба сразу пишет на чем она построена https://www.cuba-platform.ru/technologies
Для экспериментов есть триальная версия на 30 дней. Также есть облачный хостинг, но в США. Там тоже можно сделать временный аккаунт. Период тестирования можно продлевать. Но совсем бесплатной версии SBM нет.
Community версия есть только у другого продукта — SDA — Deployment Automation, но это совсем другая история.
Технологии?
Web контейнер приложений написан на С++ и работает под Microsoft IIS,
Компоненты: сервер нотификаций, SOAP API, JSON API, BPEL сервис, сервер контроля версий приложений — Tomcat.
СУБД: Microsoft SQL или Oracle. Структуры хранения описаны и открыты.
Своя среда разработки: SBM Composer
Т.е. это конечно проприетарная платформа. Решения с этой платформы врядли можно будет куда-то перенести, хоть и можно выгрузить все в XML. Такой бизнес.
С другой стороны система открыта через API, имеет все обязательные компоненты для долгой и безотказной работы тысяч пользователей, есть система управления версиями приложений с функциями развертывания на различных средах.
Community версия есть только у другого продукта — SDA — Deployment Automation, но это совсем другая история.
Технологии?
Web контейнер приложений написан на С++ и работает под Microsoft IIS,
Компоненты: сервер нотификаций, SOAP API, JSON API, BPEL сервис, сервер контроля версий приложений — Tomcat.
СУБД: Microsoft SQL или Oracle. Структуры хранения описаны и открыты.
Своя среда разработки: SBM Composer
Т.е. это конечно проприетарная платформа. Решения с этой платформы врядли можно будет куда-то перенести, хоть и можно выгрузить все в XML. Такой бизнес.
С другой стороны система открыта через API, имеет все обязательные компоненты для долгой и безотказной работы тысяч пользователей, есть система управления версиями приложений с функциями развертывания на различных средах.
Для более эффективного ПР, вам бы сделать обзор SBM composer, вот тогда программисты точно оценят.
аа!!! ооо!
Скажите, а как посмотреть на вот этот SDA, Communiti edition? на сайте (опять!) ничего такого не нашел. Просто прям беда у них в этом направлении.
Скажите, а как посмотреть на вот этот SDA, Communiti edition? на сайте (опять!) ничего такого не нашел. Просто прям беда у них в этом направлении.
Коммьюнити пользователей продукта пасется здесь — http://communities.serena.com/community/forums/categories/listings/sda-deployment-automation
На сайте serena нужно заполнить форму и получить доступ дистрибутиву. После установки у вас будет лицензия на 5 узлов, но, увы, также ограниченная 30 днями.
Дистрибутив могу выдать и без формы.
На сайте serena нужно заполнить форму и получить доступ дистрибутиву. После установки у вас будет лицензия на 5 узлов, но, увы, также ограниченная 30 днями.
Дистрибутив могу выдать и без формы.
печально, что за пару минут изучения сайта производителя, нет даже намека на цену.
А «start free trial» сразу просит заполнить форму с кучей полей.
А «start free trial» сразу просит заполнить форму с кучей полей.
Видимо, у меня сегодня роль такая «прогонять печали». И вроде погода солнечная в Москве. Может, чувствуется конец лета?!
С ценами все очень просто. Кто-то придумал в США, что цену на сайте показывать не очень правильно — лучше пусть потенциальный клиент поднимет трубку и позвонит ласковым продавцам. Тогда будет возможность поговорить, задать вопросы, и т.д. Для больших и сложных систем или решений это оправдано, на мой взгляд. Опять же лицензирование бывает запутанным. В итоге, Serena не показывает цены у себя и запрещает показывать цены на всех сайтах партнеров.
С ценами все очень просто. Кто-то придумал в США, что цену на сайте показывать не очень правильно — лучше пусть потенциальный клиент поднимет трубку и позвонит ласковым продавцам. Тогда будет возможность поговорить, задать вопросы, и т.д. Для больших и сложных систем или решений это оправдано, на мой взгляд. Опять же лицензирование бывает запутанным. В итоге, Serena не показывает цены у себя и запрещает показывать цены на всех сайтах партнеров.
Я понимаю, что с «ценами всё просто», но, как говорится, «проблемы индейцев шерифа не волнуют». Более того, проблема, как-бы не в США, потому что есть много американских компаний, который показывают цены, в том числе и на «сложные продукты», дают людям аццкие калькуляторы и вот это всё.
Печаль, не потому, что погода в Москве, а потому, что навскидку продукт интересный, но нет. Из-за подходов прошлых веков, просто сразу отказать.
Печаль, не потому, что погода в Москве, а потому, что навскидку продукт интересный, но нет. Из-за подходов прошлых веков, просто сразу отказать.
Вот для сглаживания культурных различий и нужны локальные партнеры, как говорится.
Есть интерес, но нет желания заполнять формы — я могу дать ссылку на ftp или dropbox. Хочется посмотреть, но нет времени на установку — приезжаем и показываем. Недостаточно демонстрации — делаем прототип…
Думайте
Есть интерес, но нет желания заполнять формы — я могу дать ссылку на ftp или dropbox. Хочется посмотреть, но нет времени на установку — приезжаем и показываем. Недостаточно демонстрации — делаем прототип…
Думайте
да, локальные партнеры — это очень хорошая штука :)
Но прежде чем вы дадите ссылку, я в пару слов расскажу о нашей задаче, и что уже попробовали. Вдруг, нам SDA никак не поможет.
Есть у нас продукт, который установлен в куче разных мест, и мы его сопровождаем. Разработка ведется близко к тому, как сейчас принято — на выходе из CI получаются дистрибутивы готовые к установке (обновлению) у клиентов. И вот мы пришли к тому моменту, когда уже практически готовы сделать автоматический деплой.
Самое простое — поставить всем агентов CI, которым будут выдавать job, который всё нужное сделает. Но как-то этот вариант не очень нравится, кажется сложно. Второе, использовать salt stack, к которому мы тоже присматриваемся, но и в этом случае есть некоторое недостатки. Еще в качестве разминки, посмотрели на nomad, который тоже, отлично сделает почти всё, с ним кажется всё будет проще чем с salt'ом, но тоже нет ощущения, что «вот, это оно, это то что нужно».
очевидные требования:
1. клиенты в первую очередь Windows, но есть в планах Linux (CentOS), сервер можно или WIndows или Linux
2. нужна грамотная работа с артефактами. Не везде интернет хороший — уметь докачивать. Подписи, авторизация что-то такое вот.
3. нужна привязка запуска событий к локальному времени. У нас клиенты от Владивостока до Калининграда, и скажем, можно обновлять в интервале от 0:30 до 1:30 по местному времени.
конечно очень хочется «естественных очевидных вещей» — настройки из центра с возможностью что-то сделать локально. И вообще, минимум настроек, кажется процесс должен быть простым:
— при наличии нового артефакта
— дождаться разрешенного времени
— запустить задачу обновления
— если возникли проблемы — откатить в предыдущее состояние.
Но прежде чем вы дадите ссылку, я в пару слов расскажу о нашей задаче, и что уже попробовали. Вдруг, нам SDA никак не поможет.
Есть у нас продукт, который установлен в куче разных мест, и мы его сопровождаем. Разработка ведется близко к тому, как сейчас принято — на выходе из CI получаются дистрибутивы готовые к установке (обновлению) у клиентов. И вот мы пришли к тому моменту, когда уже практически готовы сделать автоматический деплой.
Самое простое — поставить всем агентов CI, которым будут выдавать job, который всё нужное сделает. Но как-то этот вариант не очень нравится, кажется сложно. Второе, использовать salt stack, к которому мы тоже присматриваемся, но и в этом случае есть некоторое недостатки. Еще в качестве разминки, посмотрели на nomad, который тоже, отлично сделает почти всё, с ним кажется всё будет проще чем с salt'ом, но тоже нет ощущения, что «вот, это оно, это то что нужно».
очевидные требования:
1. клиенты в первую очередь Windows, но есть в планах Linux (CentOS), сервер можно или WIndows или Linux
2. нужна грамотная работа с артефактами. Не везде интернет хороший — уметь докачивать. Подписи, авторизация что-то такое вот.
3. нужна привязка запуска событий к локальному времени. У нас клиенты от Владивостока до Калининграда, и скажем, можно обновлять в интервале от 0:30 до 1:30 по местному времени.
конечно очень хочется «естественных очевидных вещей» — настройки из центра с возможностью что-то сделать локально. И вообще, минимум настроек, кажется процесс должен быть простым:
— при наличии нового артефакта
— дождаться разрешенного времени
— запустить задачу обновления
— если возникли проблемы — откатить в предыдущее состояние.
Нужны еще подробности.
В чем заключается ваша технология установки обновления? MSI пакет, файлы меняем, скрипты пускает, базу данных обновляем? Чем сложнее технология, тем потенциально более полезно использовать мощные решения управления развертыванием. CI/CD есть и в GitLab, например.
В чем заключается ваша технология установки обновления? MSI пакет, файлы меняем, скрипты пускает, базу данных обновляем? Чем сложнее технология, тем потенциально более полезно использовать мощные решения управления развертыванием. CI/CD есть и в GitLab, например.
Сейчас это инсталятор .exe, собранный NSIS'ом, на msi так и не перешли. Скрипты внутри простые, вынести куда-то отдельно проблем нет. Для начала можно совсем без скриптов — скачал, остановил службу, заменил бинарник (один), запстил службу, убедился, что запустилась. Если нет — остановил, вернул прошлый бинарник, запустил.
Позвольте, я вольюсь в разговор, попробую ответить на вопросы.
Архитектурно SDA построен на использовании агентов, которые устанавливаются на удаленные сервера. Подключаясь к агенту, центральный сервер получает возможность передавать файлы, запускать скрипты и т.д. Для «общения» используются протоколы JMS и HTTP.
Сами агенты доступны для Windows, Linux и еще ряда осей.
Касаемо работы с артефактами не очень понял насчет подписей и авторизации, о чём речь?
Есть говорить про медленный канал, то, честно, не скажу, есть ли какая-то технология докачки, разбиения по пакетам и т.д.
В одном из вариантов предлагается использовать промежуточный слой (службу) Agent Relay. Архитектура при этом будет выглядеть примерно так:
SDA Server -> Agent Relay -> Несколько Агентов
Профит здесь может быть получен именно когда конечных агентов несколько, т.е. центральный сервер передает все необходимые данные только один раз, а дальше relay их распределяет между агентами.
Запуск деплоя по местному времени — как такого понятия часовых поясов в SDA нет, т.е. при настройке расписания деплоя указывается локальное время. Получается, для решения этой задачи нужно будет настроить для каждого клиента свое расписание, учитывающее его специфику (часовой пояс, допустимый интервал и т.д.).
Сам процесс развертывания на словах выглядит не сложно, можно пробовать :)
Архитектурно SDA построен на использовании агентов, которые устанавливаются на удаленные сервера. Подключаясь к агенту, центральный сервер получает возможность передавать файлы, запускать скрипты и т.д. Для «общения» используются протоколы JMS и HTTP.
Сами агенты доступны для Windows, Linux и еще ряда осей.
Касаемо работы с артефактами не очень понял насчет подписей и авторизации, о чём речь?
Есть говорить про медленный канал, то, честно, не скажу, есть ли какая-то технология докачки, разбиения по пакетам и т.д.
В одном из вариантов предлагается использовать промежуточный слой (службу) Agent Relay. Архитектура при этом будет выглядеть примерно так:
SDA Server -> Agent Relay -> Несколько Агентов
Профит здесь может быть получен именно когда конечных агентов несколько, т.е. центральный сервер передает все необходимые данные только один раз, а дальше relay их распределяет между агентами.
Запуск деплоя по местному времени — как такого понятия часовых поясов в SDA нет, т.е. при настройке расписания деплоя указывается локальное время. Получается, для решения этой задачи нужно будет настроить для каждого клиента свое расписание, учитывающее его специфику (часовой пояс, допустимый интервал и т.д.).
Сам процесс развертывания на словах выглядит не сложно, можно пробовать :)
Подписи — начиная от примитивных md5/sha на бинарник, завершая какими-нибудь другими сертификатами. Нужно ведь как-то убедиться, что полученный «от сервера» бинарник, это именно то, что сервер нам высылает?
Авторизация — например, что бы клиент salt начал работать с сервером, на сервере импортируется ключ клиента.
Авторизация — например, что бы клиент salt начал работать с сервером, на сервере импортируется ключ клиента.
А это мода такая, или неуважение к читателям, когда вставляют в статью, которая будет выведена в колонке в 1000 точек картинку шириной в 1920 точек?
Браузеры как будто бы не умеют нормально масштабировать в 1,92 раза, картинка получается корявой. Поскольку читаю пост в Хроме последней версии — думаю, не я один вижу «лесенки из точек».
Браузеры как будто бы не умеют нормально масштабировать в 1,92 раза, картинка получается корявой. Поскольку читаю пост в Хроме последней версии — думаю, не я один вижу «лесенки из точек».
Немного офтоп, но просто стало интересно, как заглавная картинка (косвенно?) связана с данной темой.
Заранее спасибо за объяснение.
Заранее спасибо за объяснение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Serena выпускает версию 11.1 своей BPM платформы