Skip navigation
All Places > Alfresco Process Services & Activiti (BPM) > Blog

Last week it was all about the GA release. We worked hard to improve our coverage and acceptance test to make sure that we reduce the potential issues after releasing. You can find more about the GA release here, and you can keep track of the Service Release 1 (SR1) that will follow if critical issues are found. We improved our getting started guidesand simplify the deployment steps to make sure that you can get all the services up and running with a single HELM command.

Moving forward we started planning the 7.1 Release Train so feel free to get in touch via Gitter/Twitter/Email if you are interested in being part of those planning sessions.

@CTI777Worked on following issues: #2465, #1862, #2272 (Missing audit event api's for signals)

@igdianov
Completed PRs:

@almerico  Made pr to JenkinsX, pipelines configurations.

@miguelruizdevworked on the coverage of LIKE operator in Query, identified redundancy of description field in process at the cloud level and fixed edge case of standalone tasks variable retrieval in Query (2514)

@ryandawsonukworked on the GA release.

@erdemedeirosfinished work on connector variable mapping (https://github.com/Activiti/Activiti/issues/2213) for both non-cloud and cloud implementations. Provided examples for it.

@constantin-ciobotaruFixed process variable mapping json format (2483), added process id in process extension json file (2497), updated aps to work with activiti modeling 7.0.0.GA, worked for fixing swagger in case of jackson mixin in api models (2456)

@salaboyworked with @ryandawsonukand @erdemedeirosto polish the last issues around 7.0.0.GA and we did the release.

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

I am happy to announce that Activiti Cloud 7.0.0.GAhas been released! After a hard year of work we are closing this first iteration providing building blocks to create Business Automation applications in a Cloud Native approach.

Activiti Cloud 7.0.0.GA is providing a Business Automation layer for Kubernetes, building on top of Spring Boot (2.x), Spring Cloud Greenwich (RELEASE) and Docker containers.

We are quite excited to see how the community pick up these components to build all sorts of business applications. We are very keen to help community members to get started and see which Open Source project integrations make sense for the future.

You can consume all the Activiti Cloud artifacts from Maven Central:

 

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.activiti.cloud.dependencies</groupId>
<artifactId>activiti-cloud-dependencies</artifactId>
<version>7.0.0.GA</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>

 

In this GA release you will find the following Spring Boot Starters to create your own domain specific services using our Cloud Native Building Blocks:

  • Runtime Bundle Spring Boot Starter (internal release 7.0.128)
    • Contains Activiti Core 7.0.0.GA (internal release 7.0.127)
  • Cloud Connectors Spring Boot Starter (internal release 7.0.74)
  • Query Service Spring Boot Starter (internal release 7.0.106)
  • Audit Service Spring Boot Starter (internal release 7.0.81)
  • Modeling Backend Spring Boot Starter (internal release 7.0.99)
  • Application ServiceSpring Boot Starter  - Beta (internal release 7.0.64)
  • Notification Service Spring Boot Starter - Beta (internal release 7.0.16)
    • GraphQL endpoint and Subscriptions

All these Spring Boot Starters are based on Spring Boot 2.1.2 and Spring Cloud Greenwich RELEASE and all the artifacts are compiled to work with JDK11.

 

As part of this release we are also providing the first iteration of our new Activiti Modeler Application, where you can model your business processes and export them in Projects.

 

You can also deploy our Example HELM charts in your favourite cloud providers or On-Premise Kubernetes installation by following our Getting Started Guide:

https://activiti.gitbook.io/activiti-7-developers-guide/getting-started/getting-started-activiti-cloud

Or follow our 5 steps deployment:

  1. helm install stable/nginx-ingress --version 1.1.2
  2. kubectl get services (Look for the Ingress Service EXTERNAL IP, it might take a minute)
  3. helm repo add activiti-cloud-charts http://activiti.github.io/activiti-cloud-charts
  4. helm repo update
  5. helm install —name awesome  activiti-cloud-charts/activiti-cloud-full-example —set global.gateway.domain=<ingress external ip>.nip.io —namespace=salaboy

We are also providing some Jenkins Xquickstarts that you can use to leverage CI/CD from day one, we believe that as part of our Cloud Native transformation, CI/CD becomes a fundamental practice for our day to day operations.

https://github.com/Activiti?utf8=%E2%9C%93&q=quickstart

A blog post is coming to demonstrate how to leverage these quickstart if you are using Jenkins X.

Moving forward, a new roadmap blog post is being create to share what the focus will be for Activiti Cloud 7.1.x release train.

 

If you are interested in the future of the project you can take a look at our presentation at DevCon:

 

The future of Activiti Cloud @ DevCon 2019 

Last week we work hard on improving acceptance tests coverage and rest endpoint refiningments. As you can see there was a quite active week all over the place. We got great contributions from @daisuke-yoshimotorefining warning and runtime behaviour for our services. Our pipelines are improving every week and we are fine tuning our services to boot up even faster. This week is going to be all about wrapping the first GA release, there is still a lot of work to do, but we are confident that we can release the first cut of the Activiti Cloud Cloud Native approach. We are confident that we can use this release as base layer to keep improving and adding functionalities.

 

@daisuke-yoshimotoworked on adding warning if process has the async=true property

@CTI777Worked on following API issues mostly in runtime bundle and query service: #2390, #2439, #1953, #2381, #1954, #2464

@Cristian Florescuworked on update instance variables (https://github.com/Activiti/Activiti/issues/2445): done; worked on acc tests for updating instance variables (https://github.com/Activiti/Activiti/issues/2465): wip

@almerico 

Working on reliability of pipelines  #2430,#2454,#2472,#247,#2327,#2269,#2446

@igdianov
Completed PRs:

WIP:

@miguelruizdevworked on the addition of admin endpoints across our services to delete standalone tasks.

@ryandawsonukupgraded app versions of spring cloud, boot and spring cloud kubernetes. Worked through the projects resolving the problems. Merged various PRs in activiti-cloud-charts and tested the resulting charts on different clusters.

@erdemedeirosworked on connector variable mapping (https://github.com/Activiti/Activiti/issues/2213): almost done for activiti core; some work still remaining for runtime bundle.

@constantin-ciobotaruAdded connector model types, connectors validation, testing modeler app FE + BE

@salaboyworked on defining Variables Mapping backend work and tagged interfaces for Deprecation and Internal usage. Also reviewed around 40+ PRs.

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

Last week we had an amazing time in Alfresco DevCon 2019in Edinburgh. We had a lot of face to face discussions about what is going to be priority right after the GA release. We have identified some areas that we need to improve and some services that we need to expand to provide a better experience. We also touch on integrations with other Open Source projects such as JHipster, Istio and KNative. Some RFC blog post are coming right after we wrap up the GA release.

 

@daisuke-yoshimotois working on Integrate Modeling Service's backend and frontend into one Docker container.

@CTI777Worked on following issues: #2417 Add RB admin get task by id endpoint, #2420 Add acceptance tests to new admin REST endpoints, #2396 Add tests for datetime fields for filters, #2439 Add filter for standalone tasks

@almericoWorked on helm charts and Docker image optimizations.

@igdianovworking on quickstart for activiti cloud applications with JX

@miguelruizdevworked on creating  conformance tests for variables in processes and tasks.

@ryandawsonukgot the trending topics UI working against ttc-chart, created PR to add notifications to the backend in ttc-chart,presented at DevCon.

@erdemedeirospresented and attended DevCon. Reviewed and merged pull requests related to new admin REST endpoints.

@salaboyhad fun at DevCon while reviewing PRs :)

 

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

salaboy

Activiti Cloud @ DevCon 2019

Posted by salaboy Employee Feb 1, 2019

We had an amazing time here in Edinburgh, Scotland with the Alfresco community. We (Elias de Medeiros and myself) presented what we are planning to do in 2019 and we announced live in the stage Activiti Cloud RC1. Ryan Dawson presented a quick tour around the main features in Activiti Cloud and the path to the Cloud from Activiti Core. It really felt great to come full circle, after presenting our ideas of Activiti Cloud a year ago in Lisbon, we proved that we are going in the right direction and that we can deliver a major version in a year time. We have learnt a lot on this journey and 2019 will be all about solidifying these learnings in actual code/services being released every month.

Slides

The future of Activiti Cloud OSS (Elias De Medeiros/Salaboy)

 

https://www.slideshare.net/salaboy/the-future-of-activiti-cloud-devcon-2019

 

 

As part of the presentation I've introduced a new (draft) Activiti Cloud Applications Operator with a set of (Kubernetes) Custom Resource Definition that you can find here: https://github.com/salaboy/activiti-cloud-apps-operator

A whirlwind tour of Activiti 7 (Ryan Dawson)

 

Whirlwind tour of Activiti 7 by Ryan Dawson 

 

Hackathon GraphQL notifications

During the hackathon the awesome work of Ryan Dawson and Igor Dianov to integrate GraphQL into our Trending Topics Campaigns example. The following video show how our Trending Topics Campaign Example is now also using graphQL subscriptions to be notified about Runtime Bundle events. You can see in the GraphIQL UI a subscription looking for all the PROCESS_COMPLETED events, which are pushed from the service side.

We will be working hard on our GA release so please feel free to get in touch with feedback in Gitter and test our latest RC1 release.

Last week we worked hard on getting RC1 out of the door with support for JDK 11 and a new Notification Service providing GraphQL queries and subscriptions. You can see the release notes here. We are quickly moving to a GA release so we are polishing our APIs, Docker Images and HELM charts to provide a good experience for our first GA release.

 

@daisuke-yoshimotoworked for the issue about history table configuration.

@mteodori#2406Allow using https in acceptance tests

@CTI777Worked on following issues: #2371 Add admin complete task endpoint #2372 Add-admin update task endpoint #2373 Add admin delete task endpoint #2336 Activiti Cloud Notifications GraphQL Service and Microservice Example #2393 Start Process inconsistency of parameter name in request response for process name

@almericoWorked on Java11 issues and pipelines updates.

@igdianovworked on graphQL HELM charts and the RC1 release

@miguelruizdevworked on the addition of sequence number and message idfor events in Audit service

@ryandawsonukdid first version of presentation for devcon before focusing on porting TTC to java11, getting the pipelines passing and running the release of RC1.

@erdemedeirosworked with @CTI777to release new admin REST endpoints. Worked with @salaboyon DevCon presentation for the next week.

@salaboyworked on RC1 and DevCon presentation, did a PoC on a custom Activiti Cloud Kubernetes Operator

 

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

salaboy

Activiti Cloud RC1 released!

Posted by salaboy Employee Jan 30, 2019

I am really happy to announce that Activiti Core and Activiti Cloud RC1 are now released and ready to be used by all our community members.

 

In this release we included pretty big changes and refinements. We are now running with JDK 11 and we included the next iteration for our GraphQL based notification service. We did refine a lot of APIs in our Runtime Bundle and Query services to support more scenarios. We are going to go fast to GA and we will concentrate on refine and test the core features. We encourage community members to test the released artifacts and report back any issues that you might find to here.


You can find the full list of issues and features included in RC1 here

 

Main Features and fixed issues:

  • Activiti Core & Activiti Cloud moved to JDK 11
  • Activiti Cloud: GraphQL notification service implementation
  • Activiti Core & Activiti Cloud: default JSON serialization for process variables
  • Activiti Core new Connector Functional Interface added
  • Activiti Cloud acceptance tests splitted into separate clusters
  • Activiti Cloud new Admin APIs in Runtime Bundle and Query
  • New conformance tests for BPMN scenarios
  • Improved HELM Charts configurations

You can find the published RC1 artifacts in Maven Centraland the tagged Docker Images in Docker Hub.

You can now update your BOM dependencies to:

<dependencyManagement>   
  <dependencies>
    <dependency>
      <groupId>org.activiti.dependencies</groupId>        
      <artifactId>activiti-dependencies</artifactId>        
      <version>7.0.0.RC1</version>       
      <scope>import</scope>       
      <type>pom</type>     
    </dependency>   
  </dependencies> 
</dependencyManagement>


Also our HELM charts activiti-cloud-full-example version 0.7.0were upgraded to use RC1 Docker Images.

If you find any issues with RC1 please create an issue here. Or get in touch via Gitter.

 

We will be aiming for a GA Release by mid February track progress here.

 

This is a great time to get involved to help us with the testing process, integrating with your favourite Open Source projects and learning about the technology stack that we are using to build these amazing tools.

Last week we work hard to upgrade all our builds, pipelines and repository to use JDK 11. This is a major change that requires the use of JDK 11 in all the consumers of the libraries. We also included tests and new APIs conformance tests and we started with the preparations for DevCon. Part of the team was involved in a Kubernetes training by @learnk8s which was awesome and totally recommended. We are aiming to release RC1 by the end of the week.

 

@daisuke-yoshimotoworked for Handling expressions for json variables. Next he is working on Integrate Modeling Service's backend and frontend into one Docker container.

@constantin-ciobotaruworked for [Acceptane Tests] Add scenarios for process extensions in modelingand Add extraVolumes and extraVolumeMounts to service helm charts

@CTI777Worked on following issues:
Writing tests in acceptance tests and scenarios.
#2369 Add admin delete process endpoint
#170 Root task query implemented in a proper REST way

@almericoJdk 11 support

@igdianovWorked on troubleshooting Jdk 11 example pipelines with @almerico Worked on investigating and troubleshooting HTTPS support for Activiti Cloud Helm chart. Worked on Notifications Service Helm charts to add support for HTTPS, Sticky sessions, and Jdk11

@miguelruizdevworked on the PRs addressing this issue

@ryandawsonukWorked on moving configurations from examples to spring boot startersbefore attending training

@erdemedeiroschecked missing issues to cover admin rest endpoints before attending Kubernetes training.

@salaboyreview Pull Requests and help on the JDK 11 migration. Worked on DevCon slides for my “Future of Activiti Cloud OSS” presentation with @erdemedeiros

 

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

DevConis getting closer and we are working hard on making sure that we get Activiti Cloud RC1 out of the door. We are focusing on Priority 1 issues that will impact the APIs and configurations of our building blocks. We will also increase the conformance testing on our distributed environments which will lead to the first GA release (we are aiming for the 15th of Feb). I know that I said this before, but this is a perfect time for you to get involved with the project and get in touch if you want to discuss your use cases or integrations with other Cloud Native tools.  

@daisuke-yoshimoto is working on the issue #2324about integrating Modeling Service's backend and frontend into one Docker container. Especially he focuses on replacing the authentication part (keycloak).

@constantin-ciobotaruRename applications in modeling to projects (2177)

@CTI777Worked on following issues:
#2330 Add and Delete Candidate Users Groups should emit events
#2322Task formKey property not propagated to Query when updated
#1901 Create subtask endpoint has the wrong path
#1964 RuntimeBundle TaskVariableController setVariables taskId param now
#1745 fix hal collection rel name
#2355 Update Task Name in the same way as we update priority

@almericoWorking on support for OpenJDK 11 #2076

@igdianovWorked on support for OpenJDK 11 #2076 and worked on Notifications GraphQL acceptance tests

@miguelruizdevworked on the addition of the completion task fields Duration and Completed Date.

@ryandawsonukautomated the deployment of the trending topics backend services in a pipeline that also runs the trending topics acceptance tests. Also automated the deployment of a security policies setup together with running their acceptance tests. With updatebot version propagation these will enable us to know when a change breaks either example.

@erdemedeirosworked with @CTI777 to fix collection relation name for HAL responses across query, audit and runtime bundle (https://github.com/Activiti/Activiti/issues/1745)

@salaboyworked on conformance tests for Call Activity BPMN element and reviewed pull requests. Also I started preparing for DevCon.

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

Last week, after a week of festive holidays, we worked hard in closing as many issues that we could to get Beta5 out of the door. New conformance sets were added to Activiti/Activiti and serves as the basis for our Acceptance and Conformance tests for our distributed services. We are now running automated tests against our chart releases and we are happy to see the velocity of the entire cycle increasing week by week. Now for RC1the GraphQL modules are almost ready to be included and we will be reviewing and merging @igdianovPull requests soon.

 

@daisuke-yoshimotois working on the issue #2324about integrating Modeling Service's backend and frontend into one Docker container.

@CTI777Worked on following issues: #1893, #2318,#2244Commits in:

@almericoAutomate Docker Image & Helm Charts release #2312,#2325,#2327

@igdianovWorked on Notifications GraphQL Service PRs:

@miguelruizdevworked on the acceptance test coverage of the editable fields of tasks and the process definition retrieval from query.

@ryandawsonukworked on getting the acceptance tests in the pipeline passing and ensuring all the versions were set read for 7.0.0.Beta5 release.

@erdemedeiros- holidays -

@salaboyworked on Beta5 release and added the new set 3 and set 4 conformance tests. I did some initial tests on JHipster UAA integration and we hope to include that in RC1.  

 

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request

I am happy to announce that Activiti Core and Activiti Cloud Beta5 has been released. 

You can find the released artifacts in Maven CentralDocker Hub and in our GitHub repository for HELM Charts

The focus of the Beta5 release was to add more Conformance and Acceptance tests. We are now working with fully automated Kubernetes Aware Pipelines in Jenkins X that runs our distributed acceptance tests after every change to guarantee consistency across all the services. The API coverage it's getting better and exposing new features is becoming easier.

The full CI/CD approach is allowing us to go faster and the overall release time has been shortened to around 3 hours. We are still testing internally our new automated HELM Charts, but we hope to be able to publish them soon for community consumption.

The fastest way to get started with Activiti Cloud is to use our HELM charts that allow you to deploy all the services to a Kubernetes Cluster by following some simple steps. You can use any tooling that you already use to deploy HELM charts to Kubernetes or you can try Jenkins X. You can take a look at our Getting Started guides:

You can find the full release notes here.

If you are interested in getting started with Activiti Core you can check our examples repository which highlight how the new Runtimes API is used in the context of Spring Boot 2 applications:

If you are interested in getting involved get in touch via Gitter

We are closing an amazing 2018 for Activiti. We’re moving the Activiti project forward to the cloud with Activiti Cloud, we moved from design, proof of concept to implementation and stabilisation of the first set of Cloud Native Building blocks. Being an Open Source project we believe that this is a journey worth sharing. This blog post will share some of the key milestones that we accomplished during this year. You can find a more detailed blog post about our journey to Beta phase here.

 

It all began with a simple idea

Back in mid 2017 we started playing around with a very simple idea:

 

“Let’s create a set of Business Automation building blocks using a modern Cloud Native stack.”

 

We wanted to make sure that we avoid hitting the same traps of the past. Our goal was to provide a Digital Process Automation platform for the cloud and not just another “Microservices Orchestration” service.

 

Here are some failures from the past that we wanted to avoid:

    • Monolith architecture: which pushed implementers to adopt all or nothing
    • Fragmented Deployments: providing support for a wide range of Java Servlet Containers & Application Servers has its challenges and in the end you often need experts to get things done. We need to standardize and leverage new technologies to deal with deployments, upgrades and migrations.
    • Overlap with Infrastructure: with the rise of cloud providers, we wanted to make sure that the platform provides value and it doesn’t overlap with services and features already provided by the platform (i.e. service registry, distributed timers, distributed job executor, email service, etc). We wanted to make sure that we work in a “integrate instead of build” approach. A good example of that approach is the integration of Keycloak for IDM.
    • Non standard mechanisms for extensions: frameworks relied on a single JVM to provide extensions, this always caused problems while trying to integrate the platform with third party libraries (single classpath, single JVM), maintenance headaches and extremely complicated clustering setups. The perfect example for this issue is that every time that you wanted to add a new Java class with a Java Delegate for a service task you needed to shut down the server and start it again. That is because it runs on a single JVM with a single classpath that needs to be rebuilt every time you want to add a new class.
    • Vendor Lock-in Due to implementation details: relaying on the JVM for Java based process automation platforms mean complete vendor lock-in due technicalities leaking into the process/business models. When you want to move your BPMN processes to another vendor you will depend on specific library versions, which locks you into the implementation of those processes.
    • Non-Friendly Developer/DevOps tools: nowadays tools are built with concepts of CI/CD and GitOps from the ground up. Integrating process automation platforms with these practices has been always challenging due these tools were not built with those concepts in mind. Now with Activiti Cloud, we version every component independently.
    • Not ready for the Cloud: the cloud (cloud providers) didn’t existed back then, so it is natural to expect that most of the tools were not ready to even run efficiently in a cloud infrastructure.

 

 

Early 2018 (Jan) we had our first Proof of Concept where we built the initial implementations of our building blocks called: Runtime Bundle, Cloud Connectors, Query Service, Audit Service and Applications Service.

We began the year validating this approach and making sure that we got as much feedback as we could to make the right choices for the first version of Activiti Cloud.

 

We knew right from the beginning that we needed to validate not only our approach to Cloud Native, we needed to validate the whole technology stack, tools and practices used to build Cloud Native applications. The only way validate what we were doing was to share our Journey and speak with as many people as possible in order to understand what the maturity level was for each of the different tools we were using.  

 

The Journey is the destination

When we started carefully analyzing each of the fundamental ideas and core Services for Activiti Cloud there were key technologies and tools (containers, orchestration and CI/CD), that if we adopted, would significantly influence the architecture of our cloud native building blocks (Runtime Bundle, Cloud Connectors, Query Service, Audit Service and Applications Service).

First Milestone: Containers

Our first milestone was around two technologies that represent a big change in how you think about your solutions: Spring Boot & Docker

  • Spring Boot promotes the creation of self-contained applications/services which can be executed without thinking about deployment. A single, self-contained unit that can be distributed and executed, tested and monitored. Spring Boot also introduces the concept of “Starters” which are extensions to a Spring Boot Application. These extensions add functionality to your existing Spring Boot Application. Widely used extensions can be found in start.spring.io . With Activiti Cloud we aim to provide the main functionalities provided by Process Automation platforms as Spring Boot Starters, that you can attach to your existing Spring Boot ecosystems or run in isolation.
  • Docker pushed us to think even more about isolated units that can run using a single process approach. The benefit that approach is safety, testability, and reproducibility. Docker Containers are immutable and this matches with the Spring Boot approach but it clashes with traditional process automation frameworks and Servers, which allowed users to deploy (at runtime) new process definitions. This was a clear indication that things will need to change.

 

Once you mature the idea on how containers work and waste a lot of time discussing why it is a terrible idea to containerize your old-fashion web application, your thoughts jump towards thinking about container orchestration and Cloud Native Architectural patterns.

Which takes us to the second milestone: Spring Cloud & Kubernetes.

 

Second Milestone: All in on Kubernetes

Moving from single to multiple services creates the demand for container orchestration. Historic Process Automation platforms forced legacy tools on implementers—all or nothing. When modernized properly, both Docker and Kubernetes help a lot in this regard. Now our Cloud Native building blocks will transparently work with your distributed applications.  With Activiti Cloud we wanted to go one step further than “just fit in”, we want to provide a context-aware set of building blocks that can leverage the infrastructure where they are running. This means that it knows that it can use Kubernetes native services and integrate against those. Examples are Service Registry and ConfigMaps (for now and Jobs and timers in the future). We see this as critical to empower developers and devops teams to use modern and agile tools to move fast in the cloud.

 

We quickly realized that Docker is not enough, Kubernetes pushes you to really think about Cloud Native patterns and ways of working that we couldn’t neglect when designing Activiti Cloud.  At that point, around March 2018 we made the decision to focus only on real Kubernetes deployments, leaving aside tools like Docker Compose and even Minikube, solutions that were good for quick demos, but introduce a lot of noise. It is important to notice here, that all the building blocks provided by Activiti Cloud can be run with Docker Compose and in Minikube, but the team is focused on real life Kubernetes deployments.

 

Now, if you are a Java Developer and want to develop Cloud Native applications, you will notice that Spring Boot is not enough. You need to step back and look at how your Microservices will interact with each other and components like: Gateway, Message Broker, Configuration Server, Service Registry, etc. become essential to building robust and reliable distributed applications. This is where Spring Cloud steps in to fill this gap. When you look at Spring Cloud and Kubernetes, the patterns that they promote are quite similar and there is a huge match in terms of how both recommend to build distributed applications. It took us some time, but finally, we realized that the power of Spring Cloud relies on the abstractions (interfaces) provided that promotes these patterns. The next big logical step was to contribute to the Spring Cloud Kubernetes framework, which basically provides implementations of these abstractions using Kubernetes Native Services.

 

We strongly believe that Spring Cloud Kubernetes gives us the contextual awareness that our services require in order to best leverage the provided infrastructure. For this reason, we are committed to contributing back with lessons learned, examples, documentation and new features that will enhance the capabilities that a Java Developer creating Spring Boot Applications will need when running their applications in Kubernetes.

 

Until here, everything was running smoothly, but the day to day Developer Experience was really bad and slow. We had introduced Docker (Dockerfile and docker build) and Kubernetes (Deployment Descriptors/Manifests, a.k.a. yaml hell) on top of our Java Applications, and we started suffering the pain of maintaining all these extra steps in our pipelines. This pain takes us to the next Milestone: CI/CD.

Third Milestone: CI/CD from beginning to end

 

The Cloud Native approach promotes multiple isolated units—a good thing. Yet, this introduces complexity: a number of containers to release, manage, configure, monitor, etc. Delivering on agility is almost impossible without an effective and comprehensive CI/CD practice.

 

Developers and DevOps will need to be comfortable creating, testing and releasing containers. Yet, Cloud building blocks and microservices deployment pipelines are sophisticated and complex. Some of the common topics that you will need to sort out when moving to a cloud native approach are:

  1. A single logical Application now lives in multiple repositories, where each one will generate a set of artifacts that needs to be managed, released and deployed to multiple environments
  2. You now depend on a complex infrastructure where multiple tools needs to be coordinated together to automate as much manual work as possible
  3. You need to define and maintain different environments to test and validate that your distributed applications are working as expected before promoting changes to production
  4. You need to have the right monitoring tools to understand what is going on in your distributed application

 

For a big percentage of organizations, which are just starting their DevOps journey, all these points are a big leap forward and people tend to be scared about changing the way they work.

 

With this backdrop, Jenkins X comes into play. Jenkins X provides a very forward looking, Kubernetes first way of doing CI/CD, which translates straight away over to providing the same consistent way of doing CI/CD in a multi-cloud environment. The technology choices and the approach of Jenkins X matched 100% with our practices and adapting our projects to work in the Jenkins X way was minimal.

As developers, we need to be always looking for tools that:

  1. Simplify our day to day life
  2. Promotes best practices from the community and encourage agility

Jenkins X was designed to provide both and it takes a lot of the burden of creating and releasing Docker Images, HELM charts and promotes the use of GitOps practices to be able to quickly reproduce your environments (where you run your containers) in no time by storing all the configuration in Git repositories.

 

After several months of heavy work on automation, we can say that now we are building all Java Libraries, Docker Images and HELM charts using automated pipelines that create a release for every Pull Request. You can now browse all our repositories (40+ repos, including example ones) and you will see automated releases created after every merge to the master branch.

 

This is just the beginning

We consider that Activiti Cloud represent the first set of Kubernetes-aware building blocks. There is a lot of work ahead to provide all the functionality that is expected from a Business Automation platform, but we believe that on top our basic build blocks (Runtime Bundle, Cloud Connectors, Query Service, Audit Service, Notification Service and Applications Service) we can build a very robust and modular solution, that you can adapt to whatever your business needs.

 

There are some important consequences that now appear evident to us, but we recognise that are not so easy to spot unless you go through a similar journey:

  • Due the fact that now that Process Runtime will know about the infrastructure and it will try to use as many services as possible, the Process Runtime complexity is reduced. The Process Runtime should move towards more simple libraries with less responsibilities. In other words, by removing overlap between what we knew as Process Engine with the infrastructural services, the Process Runtime will deal with less concern and it will keep the focus on just running BPMN process models
  • It makes a lot of sense to have a separated Task Runtime from the Process Runtime, due multiple Process Runtime will want to reuse the Task Runtime. This once again will promote single responsibility and simplicity for the Process Runtime.
  • Everything is built API first and both REST and Message Driven APIs should be provided. These APIs now should be tested against different scenarios and the testing should now include conformance checks, that guarantees coherence across the entire distributed system.
    • In a world of mobile clients and user focused experiences we need to go one step further and provide full reactive APIs. We are quite close to include our GraphQL endpoints for data aggregation and subscriptions thanks to @igdianov community contributions!
  • In the same way Spring Cloud provides interfaces, Activiti Cloud provides interfaces and separate implementations using different technologies. We recognise that a single implementation will not fulfil every possible use case, for that reason we encourage our community to provide different implementations of the Activiti Cloud components using their favourite technologies. An example of this can be easily explained with the Audit Service, which provides an implementation using a relational database to store audit events. For some use cases that will be more than enough, but if you are already using NoSQL databases, a MongoDB implementation (for example) makes a lot of sense to store, index and report on these events (Thanks to @daisuke_yoshimoto, who provided this implementation as a community contribution).
  • If containers are immutable, we can leverage tools like Istio to do blue/green deployments and to control traffic between Runtime Bundle versions.
  • Due the similarity in infrastructure between Activiti Cloud Connectors and Functions as a Service (such has AWS Lambdas) we believe that the Knative Project represents the way to go for our Kubernetes approach. By using Knative we can simplify even further our Process Runtime and leverage the infrastructure even more in a cost efficient way.
  • Understanding the boundaries of each Activiti Service and the Services provided by the infrastructure framework becomes really important to understand how the overall design will work and how the pieces fit together. We are 100% committed not to duplicate/overlap with the infrastructure frameworks that we are using, this includes: Kubernetes, Knative Project, Istio, Spring Cloud and Spring Cloud Kubernetes. An example of this commitment might be the usage of Istio for Circuit Breaking instead of Ribbon + Hystrix provided by Spring Cloud. The moment that we see an overlap we contribute back with improvements, in this case to Spring Cloud Kubernetes, to be aware of the infrastructure (in this case that Istio is present). Understanding where the right abstractions are (where the interfaces should live) it is extremely important to avoid overlapping and allow us to make sure that we keep the focus of Activiti Cloud on digital process automation instead of solving infrastructural or tooling gaps.
  • Thanks to tools and frameworks like GraalVM, Spring Cloud Kubernetes and  JHipster, the Java Community is quickly catching up and understanding its way to the Cloud, we expect this trend to continue improving our day to day developer experience. For this reason the Activiti Cloud team is really committed to adopt, collaborate and integrate with these frameworks and tools.

 

We are aiming to release Activiti Release Candidate 1 (RC1) by the end of January and share more about what is coming next year at that point.

The Community is where you learn

We do everything in the Open and we encourage people to join us. If you are interested in building Cloud Native Applications, Activiti gives you an open way to learn about the tools that we are using and how they will work in a real Kubernetes Cluster.

 

This year (2018) was quite intense on presentations intent on sharing our Journey to Cloud Native Applications. We recognised that before even using Activiti Cloud people need to understand the advantages and the way of working with Cloud Native tools.

 

For that reason we participated in the following events:

 

We are now going full circle, and we will be presenting the first Release Candidate of Activiti Cloud at Alfresco DevCon 2019 in Edinburgh. We have learnt a lot by sharing and this will continue in 2019.

 

If you are interested in Activiti, feel free to get in touch via Gitter, we are really open to participate in Java User Groups and share our lessons learned around the technologies that we are using, the design approach of Activiti Cloud, our journey to CI/CD using Jenkins X. You can also follow our getting started guides if you want to get your hands dirty with all the technology mentioned in this blog post:

 

Happy 2019 &  Stay tuned!

Last week we released Activiti Cloud Beta4 and moved straight away to the Beta5 planning. We are aiming to release Beta5 during the first week of January and currently we have 35 open issues: https://github.com/Activiti/Activiti/issues?q=is%3Aopen+is%3Aissue+milestone%3ABeta5

 

There has been also huge progress on automating our Docker Images and HELM charts generation for our example projects. This means that now you can find the examples being released and tested as part of our Java libraries lifecycle. There are a lot of improvements and refinements to cover, but the basics are already in place. You can find now our Docker Images being tagged with fixed versions at release time of the example repositories.

 

@daisuke-yoshimoto is working on improving autodeployment strategy issue. https://github.com/Activiti/Activiti/issues/2138 

 

@constantin-ciobotaru Add more acceptance tests for the exporting applications.

 

@CTI777
worked on providing method for subprocess and changes for Audit EventConverters.
Commits in:

 

 

@almerico

 

Worked on new examples pipeline. PR’s:

 

 

Issues:

 

 

@igdianov Worked on the following PRs and Issues:

 

 

@miguelruizdev worked on testing Beta 4 release and conformance tests scenarios refactoring

 

@ryandawsonuk Updated ttc chart to use latest gateway version following upgrade to be boot 2.1. Ported a patch from PR to acceptance scenarios to fix step matching in security policy tests. Managed the release to maven central from bamboo. Updated quick starts and charts and added Beta4 entry to gitbook. Provided a way to extend keycloak realm at deploy time.

 

@erdemedeiros worked on Beta 4 release. Reviewed pending pull requests. Reviewed pending tasks for admin APIs.

 

@salaboy worked on testing Beta4 and updating dependencies after release. I fixed #2275 which demonstrated the power of our CI/CD approach for our community members, fixing a bug from report time to release time in less than 3hs.

 

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

 

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request ;)

I am happy to announce that Activiti Core and Activiti Cloud Beta4 has been released!

 

You can find the released artifacts in Maven Central, Docker Hub and in our GitHub repository for HELM Charts.

The focus of the Beta4 release was to improve data consistency between the different services and maturity of the new APIs. We improved the way of handling data inside the Query Service (now it also contains Process Definitions and Variables are kept in different scopes for improved performance on query) which lead us to improved coverage on different scenarios. We are looking forward to leverage these changes with the GraphQL extensions that are still experimental, but we are planning to add soon into our release process. As mentioned before, the APIs are getting better and better and as part of our commitment to support a wide range of cloud deployments we included the first iteration of our Conformance Tests and Cloud Conformance Tests suites.

These test suites are designed to enable implementors to extend the basic sets to cover their use cases. We believe that this is a “must”if you are planning to leverage a CI/CD approach.

 

Also a big part of this release was the upgrade to Spring Boot 2.1 and Spring Cloud Greenwich.M3 which we want to keep in sync with our release train. 

 

The fastest way to get started with Activiti Cloud is to use our HELM charts that allow you to deploy all the services to a Kubernetes Cluster by following some simple steps. You can use any tooling that you already use to deploy HELM charts to Kubernetes or you can try Jenkins X. You can take a look at our Getting Started guides:

You can find the full release notes here.

If you are interested in getting started with Activiti Core you can check our examples repository which highlight how the new Runtimes API is used in the context of Spring Boot 2 applications:

If you are interested in getting involved get in touch via Gitter

Last week we worked hard to close Beta4, which will be released later today. The full team is focused on making the release process smooth so we can include more fixes and features in every milestone. In Beta4 we managed to close 41 issues and you can check our next milestones here: https://github.com/activiti/activiti/issues?q=is%3Aopen+is%3Aissue+milestone%3ABeta4

@CTI777worked on finalizing update process event and task/process variablesCommits in:

@almericoWorking on JX pipelines Issues #2224 and DIND maven install #2201 PR’s:

@daisuke-yoshimotoworked on the issue #2075. PR’s:

https://github.com/Activiti/Activiti/pull/2229

https://github.com/Activiti/activiti-cloud-runtime-bundle-service/pull/171

@igdianovworked on the following PRs and Issues

@constantin-ciobotaruworked in modeling for:

  • send to model repository both modelToBeUpdated and newModel during update
  • add full json process metadata when export applications
  • export the content only (without metadata) for json based models

@miguelruizdevworked on acceptance test coverage and bug fix on task updated and process updated events

@ryandawsonukCreated a cluster for running example-level projects, updated the developer guide to explain how to make changes across repositories in the current structure, updated modeler repos to use masteras well as ttc repos, committed a chart for the trending topics example, ran a test release.

@erdemedeirosReviewed and merged pending pull requests. Fixed set process instance name on query-service (https://github.com/Activiti/Activiti/issues/1952). Fixed missing info on cloud events (https://github.com/Activiti/Activiti/issues/2248). Fixed audit handler for process updated and Process Suspended events.

@salaboyworked on refining services for Beta4 release, improving acceptance tests and we merged the initial version of our new APIs conformance tests ( https://github.com/Activiti/Activiti/tree/develop/activiti-spring-conformance-tests) that will help us to test our cloud modules.

Get in touch if you want to contribute: https://gitter.im/Activiti/Activiti7

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request