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

Last week we worked to make further refinements in our core services. Events emitted by our services now include the Activiti Cloud Application Name, Service Type and version. Our new Runtime APIs are now covering Event Listeners and Connectors and we are getting close to start moving these initiatives from the incubator to their own repositories.


@MiguelRuizDevstarted tweaking with Angular in order to build a basic UI to try TaskManagerService out

@igdianovfinishing acceptance tests for GraphQL and subscriptions mechanism

@daisuke-yoshimotois working on making acceptance-tests for Signal Throw Event Cloud Behavior.

@constantin-ciobotarucreating new controllers for Modelling Service to support different backends for storage

@lucianopreaworked on some tickets related to Tasks (#1831#1814)

@pancudaniel7start looking into Activiti7 by checking out the activiti-cloud-examples

@balsarorireviewing PRs and discussions around Service Task Binding behavior in the engine

@ryandawsonukcreated PRs to add application metadata (service name, version, type, parent application) to the events emitted by the runtime bundle and have these consumed by the other components. Included in the PRs changes to the security policies for these services so that service name can be specified in long or short format

@erdemedeirosworked on the new Process Runtime Java APIs. Polished events listeners; added the first iteration for Java connectors (work in progress).

@salaboyworked in splitting the Activiti Cloud Blueprint into separate repositories to leverage cloud deployments and automated pipelines for continuous delivery.


This week we will start reviewing pending PRs from @daisuke-yoshimotoand @igdianov.

Also we will start merging code from the incubator to our infrastructure components to make sure that our Demos and Blueprints use the new services and features. We will also be having more news about our Modelling project soon, so keep an eye on this blog for more news soon.

We keep getting community users messages that wants to try out our new infrastructure and services. We totally recommend to check out our Activiti Cloud Examples Github repository: and our Gitbook’s Quickstart & Overview section:


Get in touch if you want to contribute:

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

Last week we worked hard to move forward Application Services, new Runtime APIs and aligning our services and configurations to map these changes. This week we will push forward to make sure that we start having examples using these new services and APis.

Feel free to join our RFC documents and add comments/feedback.


@igdianovsubmitted Pull Requests related to Notifications and WS integration at the Gateway level for GraphQL endpoints.

@daisuke-yoshimotocreated the first implementation about Signal Throw Event Cloud Behavior that broadcasts signals to all Runtime Bundles by using Spring Cloud Stream. Pull requests:

@constantin-ciobotarudid rebase and resolved conflicts for “delete task” #1812and “delete process instance” #1809related PRs

@ryandawsonukcreated PRs to publish application metadata (which reflects which application a service belongs to) to eureka and to allow the stream names used between runtime bundles and connectors to be overridden. Started work on adding the application metadata to events

@erdemedeirosworked on the new Process Runtime Java APIs. Added first iteration for event listeners. Started thinking about connectors.

@salaboyworked on RFC document for new APIs and some refinements in the Application Service located in our incubator repositories.


We keep getting community users messages that wants to try out our new infrastructure and services. We totally recommend to check out our Activiti Cloud Examples Github repository: and our Gitbook’s Quickstart & Overview section:


Get in touch if you want to contribute:

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

The main goal of this document is to create a proposal for a new set of Process & Task Runtime oriented APIs. This APIs will be provided as separate maven modules from the activiti-engine module, where the interfaces defined in the APIs will be implemented. The main purpose for this new API is to make sure that the path to the cloud approach is smoother, allowing implementations to start by consuming the framework and then move smoothly to a distributed approach. As mentioned by Martin Fowler in his blog post Monolith First, are going through an evolution to better isolation to support scalable and resilient architectures. The API proposed here are consistent with modern development approaches, compact and making sure that the transition to a microservice approach is faster and conceptually more aligned.  

Until now, the Activiti Process Engine was bundled as a single JAR file containing all the services and configurations required for the engine to work. This approach pushes users to adopt all or nothing. Inside this JAR file there are interfaces and implementations which are tightly coupled with the Process Engine internals. This causes maintenance and extension problems of different implementers not understanding where the public API ends and where the internals begin. This also blocks the Activiti team to move forward and refactor the internals into a more modular approach.

It is really important to notice that the old APIs will not be removed, but the new APIs will be always the recommended and maintained approach for backward compatibility.

Process Runtimes are immutable runtimes that knows how to execute a given set of business process definitions (concrete versions). Process Runtimes are created, tested, maintained and evolved with these restrictions in mind. Process Runtimes have a lifecycle, they can be created and destroyed. It is likely for a process runtime to be included in a pipeline for making sure that the Process Runtime will work properly when needed. In other words, we need to make sure that Process Runtimes, after its creation, will work properly based on the acceptance criterion defined.

It is also important to note that Process Runtimes provides you the granularity to be scaled them independently. In contrast with the notion of Process Engine, where you never know the nature of the Processes that you will have in there and hence testing, validating and defining scalability requirements becomes a painful (if not an impossible) task.

In the same way the Task Runtime will provide access to Tasks. Once the Task Runtime is created we can expect the same behavior (and configurations) to apply to every task created by this runtime.

One more important difference between the old notion of Process Engine and Process Runtimes is the data consumption aspect. Process Runtimes are designed to execute Processes. Task Runtimes are designed to execute Tasks. Process & Task runtimes are not designed for efficient querying, data aggregation or retrieval. For that reason the Runtime APIs will be focused on compactness and the execution side. Following the CQRS pattern (Command/Query Responsibility Segregation, the Runtime APIs are focused on the command (execution) side. There will be another set of APIs for efficient querying and data fetching provided outside of the scope of the Runtime APIs. Check the Activiti Cloud Query Service for more insights about these APIs.

Main Constructs (APIs)

While creating the proposal, we have the following architectural diagram in mind. You can consider this as the ultimate objective from an architectural and APIs point of view:


We want to make sure that there are clear limits and separation of concerns between the different components exposed in our APIs and for that reason, even if we cannot fully decouple the internals right now, we want to make sure that our APIs clearly state our intentions and motivations for future iterations.


  • processDefinitons()-> Immutable list
  • processInstances()
    • operations(Create/Suspend/Activate)
  • metadata()
    • signals()
    • users()
    • groups()
    • variables()
  • processInstances() -> get all the process instances that are in this Runtime (quick accessor to bypass the selection of the process definition)
    • Operations
      • Activate
      • Start
      • Delete
      • Suspend
  • Operations(broadcast and batch to all process instances)
    • signal()
    • stats() / info() // The statistics and status of the Runtime
  • configs() -> configurations used to create the Process Runtime
  • destroy()


  • Operations
    • create()
    • complete()
    • claim()
    • release()
    • update()
  • configs() -> configurations used to create the Task Runtime
  • destroy()


  • eventListeners()
  • connectors() - > system to system connectors (old JavaDelegates)
  • dataStore()
  • policies() // security policies for process definitions
  • identity()
    • getGroupsForCandidateUser()



  • health()
  • stats()


  • Events emitted the process runtime
    • ProcessInstanceCreated
    • ProcessInstanceStarted
    • ProcessInstanceCompleted
    • ProcessInstanceSuspended
    • ProcessInstanceActivated
    • ProcessVariableInstanceCreated
    • ProcessVariableInstanceUpdated
    • ProcessVariableInstanceDeleted
  • Events emitted the task runtime
    • TaskCreated
    • TaskAssigned
    • TaskCompleted
    • TaskReleased
    • TaskUpdated
    • TaskSuspended
    • TaskActivated
    • TaskVariableInstanceCreated
    • TaskVariableInstanceUpdated
    • TaskVariableInstanceDeleted

Maven Modules

The separations of concerns between Tasks and Processes at the API level will be kept in separate packages. Providing an activiti-process-runtime-apiand a activiti-task-runtime-api. These packages will represent our Backward Compatibility Layer with clear deprecation and evolution policies.


For Spring Boot users the Spring Boot Starters will provide all the configuration and wiring needed for quickly get a ProcessRuntime and a TaskRuntime up and running.

Developer Scenario

  1. The developer is working in a Java Application with Spring Boot
  2. The developer adds the activiti-all-spring-boot-starterdependency
  3. The developer uses only interfaces in the activiti-process-runtime-api project to interact against Process Runtimes

Maven dependency:






Configuration wise the following types will be autowired (following standard spring practices: aka autoconfigurations) for you while creating the ProcessRuntime instance:

  • EventListener
  • Connector

This autoconfigurations should match the available metadata from our process definitions to make sure that our processes has everything required to run.

Then you should be able to do:


@Autowired private ProcessRuntime processRuntime; 


Now you have a ProcessRuntime available in your application, this ProcessRuntime object will be populated with the available process definitions in the classpath. This means that this ProcessRuntime instance can be heavily tested for that set of process definitions.

With the new processRuntime instance you can access to the available processDefinitions:


List<ProcessDefinition> processDefs = processRuntime .processDefinitions(); 


Notice that there are is no way to change this list of ProcessDefinitions. It is an immutable list.

You can get the configurations used to construct this ProcessRuntime by doing:


ProcessRuntimeConfiguration conf =  processRuntime.configs();


Here you can check which connectors and event listeners are currently registered to your runtime. In particular, getting connectors informations is a key improvement over previous versions:


Map<String, Connectors> connectors = processRuntime.configs().connectors();


This allows Process Runtimes to validate at creation time, that all the Process Definitions loaded can be executed, because all the connectors required are present.

In a Spring context, all connectorsand listenerswill be scanned from the classpath and make available to the Process Runtime at creation time.

To create process instances it should be as simple as selecting the Process Definition and creating new instances with our fluent API:


ProcessInstance processInstance = processRuntime.processDefinitionByKey(“myProcessDefinition”) .start(); 


And then actions:


processInstance.suspend(); ... processInstance.delete(); 


Getting Process Instance should look like:

List<ProcessInstance> instances = processRuntime.processInstances(); [/code]



ProcessInstance instance = processRuntime.processInstanceById(id); 


Task Runtime should follow the same approach as Process Runtime:

@Autowired private TaskRuntime taskRuntime; …

Task task = taskRuntime.createWith()...;




The initial version of these APIs will be restricted to the minimal amount of operations to cover most use cases. Are you using Activiti 5 or 6 APIs? We will appreciate community feedback on what other features not mentioned here are you using in your projects?

Other Considerations and References

Reasons to introduce a new set of APIs:

  • Making sure that we have a clear line between internal code and external APIs that we suggest users to use and rely on for backwards compatibility
  • A reduced technical surface that is nicely crafted and achieving a single purpose.
  • A well defined set of interfaces to avoid all or nothing approach. Improved transitive dependencies control over our microservices and clear separation of concerns
  • Closely aligned with Cloud Native practices for easy transition to distributed architectures
  • Provide more freedom to refactor internals into a more modular and maintainable approach
  • Leverage new reactive frameworks and programing practices

PoC in Incubator (to track the progress)

Feel free to add comments to our live RFC document here:

Last week we worked hard into getting the Activiti Cloud Application Service abstraction layer and our Proposal for a new set of Process & Task Runtime APIs into our Incubator Github Repository: This week we will push forward to get the Application Service up and running into our Kubernetes cluster and a set of examples for the new Process & Task Runtime APIs. We are still refining the RFC document for the Process & Task Runtime APIs, but feel free to jump in our Gitter channel if you want to have a chat about this.


@MiguelRuizDevpolished Service layer between Repository and Controller, crafting more specific methods. Implemented right verbs for requests along with UUID. Changed the RepositoryRestConfigurerAdapter to expose resource Id.

@igdianovWebSockets Subscriptions and GraphQL notification mechanismo integrated with the gateway.

@daisuke-yoshimotoworking on BPMN Signals and Messages

@constantin-ciobotarufinished default diagram when no graphic info present in model” #1808, “delete task” #1812

@lucianopreaworked on creating Ad-Hoc Tasks to Runtime Bundles.

@mteodorifix IllegalArgumentException with illegal-transitive-dependency-check #1866

@ffazzinitrying out new deployment approaches in different namespaces inside Kubernetes.

@ryandawsonukAdded support for variable types to the variable-related REST endpoints on runtime bundles. Updated documentation on security restrictions. Started work on adding application name into services so as to support fully qualified names.

@balsaroriWorking on correcting task events order #1854

@erdemedeirosworked on the new Process Runtime Java APIs. Added support for variables retrieval at process instance and task level.

@salaboyworked on the Application Service RFC and PoC in the incubator. I’ve also worked with @erdemedeirosinto defining the new Process & Task Runtime APIs.


We keep getting community users messages that wants to try out our new infrastructure and services. We totally recommend to check out our Activiti Cloud Examples Github repository: and our Gitbook’s Quickstart & Overview section:

Get in touch if you want to contribute:

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

When you build distributed architectures (with containers involved), applications end up being a set of logically related microservices that you run on top an infrastructure. This infrastructure will allow you to set up isolated environments where you should be able to control resource allocation and security. We believe that inside each of these environments you might want to have a set of these logical applications, which means that you will probably have a lot of containers deployed. Some of these containers will be infrastructural services, such as Data Stores, Message Brokers, Gateways, and some of them will be very domain specific.

The main responsibility of the Activiti Cloud Application Serviceis to provide this high level (Activiti Cloud specific) view of a set of domain specific applications that are running inside an environment. At some level Applications also provide isolation between each other and they usually require different Role Based Access Control, IDM configurations, different message broker configurations, different set of credentials, etc.

The purpose of this document is to serve as a specification for the initial implementation of the Activiti Cloud Application Servicewhich serves as some kind of controller/monitor for the Applications that are deployed inside our Cloud Native environments. This can be used by client applications to consume and interact with each Application Services.


Notice: even if we are targeting Kubernetes we need to make sure that the core service is technology agnostic. This is, as in any service of community project needs to rely on common abstractions, trying to reuse existing ones or collaborating with existing communities to avoid duplication of effort.


The Application Service endpoints should expose the available applications, the application metadata and the application state. The Application Service should not store this information, but rely on delegating as much as possible to the Service Registry, Configuration Service and other services in the infrastructure.

The Application Service is not responsible for deploying/provisioning new applications, but it should expose operations such as the structure and status of the application to understand when applications are already provisioned and ready to receive requests. This means that for at least the initial version of this service most of the operations will be READ only. This service should react to changes in the environment (new service registration/de-registration) to make sure that the Application Service is providing data that is up to date and reflecting the real status of the deployments, this can be achieved by monitoring the Service Registry.

The Application Service should also interact with the Configuration Serviceto understand each application and its infrastructural services configurations and dependencies. For example: if  Runtime Bundle (one of our core building blocks) depends on a Relational Database and a Message Broker, it can look into a Configuration Service(or configMaps) for an entry related to the application service to understand which infrastructural services are required for the application to run. We can be smart and list these requirements before deployment time, so an administrator can make sure that those infrastructural services are ready.

Applications have a relationship with IDM and security, because we are using Keycloak as our SSO and IDM provider, Applications might require to have a different realmconfiguration.

A key important feature that must be considered and analyzed is Applications versioning. Making sure that we can move applications from different environments and that each of these Application will have a lifecycle is important. The intention of this document is to describe these aspects, but not to solve them all.

Interactions / Flow

The following diagram shows the components that will interact to provide the features described above:

Screen Shot 2018-04-11 at 09.08.19



The Application Service has relationships with 4 key components:

  1. Configuration Service (ConfigMaps in K8s and Configuration Service in Spring Cloud)
  2. Service Registry (Eureka outside of K8s and the K8s Service Registry)
  3. Gateway (Spring Cloud Gateway)
  4. Identity Management / SSO (KeyCloak)

In order to provide these high level abstractions (one application composed by a set of services) we need to have an Application Deployment Descriptor, which basically describe the Application expected structure. This Deployment Descriptor describes how the application is composed and implicitly define what is required for the Application to be UP (state).

For this reason, the first step of the interaction is to create this high level Deployment Descriptor.  This high level Deployment Descriptormaps the Activiti Cloud Building Blocks (Runtime Bundles, Cloud Connectors, Query & Audit Services, etc.) to an Applicationstructure.

This Deployment Descriptorwill live inside the Config Server, which has a structure to store Deployment Descriptors in a directory fashion. In other words, the Deployment Descriptor Directorywill have a list of Application Deployment Descriptors available, that can be queried to obtain references to the available Deployment Descriptors for Applications.

This Deployment Descriptorswill be used to match against the Service Registrythe status of each Application.

Each Service provisioned will require to have two pieces of MetaData that will allow the correlation against these Deployment Descriptors:

  • Activiti Cloud Application Name
  • Activiti Cloud Service Type

If these two pieces of information are added to the Service Instance information inside the Service Registry, the Application Service will be able to correlate, validate and monitor the relationship between the services that are currently deployed.

Notice that all services that doesn’t belong to an application, will be grouped together.

The Application Service then, will be in charge of interacting with the Service Registry to answer questions about the amount of deployed applications and their respective state.

The sequence of interactions is as follows:


It is important to notice that there is no state storing as part of the Application Service, all state is created based on the Deployment Descriptors in the Config Service and based on the currently deployed services in the Service Registry.

Data Types

As the first Draft of the service the following Data Types are going to be introduced.

These entities and data types should be agnostic to the underlying implementation. These Data Types represent our view of the world when we think about Activiti Cloud Applications, and we shouldn’t assume any particular implementation or technology stack.

  • ApplicationDeploymentDirectory
    • ApplicationDeploymentEntry[]
  • DeploymentDescriptor
    • applicationName
    • applicationVersion
    • serviceDeploymentDescriptors[]
      • Name
      • Version
      • ServiceType
  • Application[]
    • Application
      • Name
      • Version
      • ProjectRelease
      • Realm (Security Group / IDM bindings)
      • Status
      • Services
        • URL (path??)
        • Configurations[]
          • Resources[]
        • ServiceType
        • Name (Descriptive name)
        • ArtifactName (artifact - maven / docker image)
        • Version
        • Status
  • ServiceType-> Enum:  (Connector, Runtime Bundle, Audit, Query, Domain Service)
  • ProjectRelease(Coming from Modeling Service)
  • Realm(TBD)

Proposed Endpoints

  • GET/v1/deployments/directory-> list of applications that we want to deploy (static)
  • GET/v1/deployments/{deploymentName}-> get deployment descriptor for a given app
  • GET/v1/apps/-> list of APPs names and link to app
  • GET/v1/apps/{appName}/-> get app info
  • GET/v1/apps/{appName}/services
  • GET/v1/apps/{appName}/services/{serviceName}/url
  • GET/v1/apps/{appName}/services/{serviceName}/config

Evolution, Versions Upgrade and Data Migration

If we are considering applications to contain Runtime Bundles, we need to define how these Bundles evolve into future versions and how the version of the application relates to the Runtime Bundles in it. Runtime Bundles were conceived as immutable containers for sets of Runtimes, not necessarily and not only Process Runtimes.   

We need to define some common scenarios of how this is going to work making sure that we cover a wide range of scenarios. Traditionally in BPM platforms there are some different scenarios that you want to cover:

  1. Migration between different versions of the same process definition: this opens the door for a lot of complications like for example: what happens if two process versions are completely different, and migration of in-flight processes is not possible at all? It also introduces the concept of manual migration, where each individual instance needs to be inspected and migrated manually.
  2. Running two different versions of a process definition in parallel, until the old version doesn’t have any more in-flight processes, this is usually a good approach to make sure that things cannot go wrong, but it forces us to think about the routing logic used to create new process instances. *It is interesting thing to notice that this is a more aligned approach with the concept of immutability*.
  3. Sometimes, no matter what you are doing you just want to deploy a new Application version, and forget about the old one, including data. This is quite common on development cycles. Basically you want to throw away your current version of the application and replace it with a new version without really caring about data migration. If you want fast iteration cycles this might be required.

Based on these categories the following strategies are suggested:

  • Maintain: use the same data store and add new versions of process definitions, keeping the old ones in. This will require some enforcement at the time of creating new versions of the existing Runtime Bundle.
  • Migrate: a set of operations will need to be executed when rolling an upgrade, endpoints should be provided for inflight process extraction and injection. This strategy will be very useful for situations when we want to move executions from one environment to another, where the underlying data store is not the same and data need to be moved.  
  • Parallel: You want to run the previous version of the inflight processes in the same Runtime Bundle where those were defined and start running the new version in parallel in a different Runtime Bundle instance. A routing mechanism will be needed and a retire policy might be required to check when to shutdown the old version.
  • Destroy: You want to throw away the old definition and just run the new one. You don’t care about data that was generated by the old version.

Notice that these strategies should be defined at application level, not at Runtime Bundle level, because these strategies will impact other components such as Audit and Query. The consistency needs to be maintained at Application Level.

Each strategy will implement a different flow of actions (pipelines) that should be automated or triggered by a DevOps user. Notice that no reference to any pipeline should be included in this service, but hooks should be available.

(TBD Strategies examples and planning for implementation, suggestions and comments are more than welcome)

Other topics / Risks / Open Questions

We are building the Application Service because we have some Activiti Cloud specific requirements, but the Kubernetes, Spring Cloud and other communities (like JHipster) are looking at these requirements using different angles. As part of the development of this service, we commit to monitor these communities and collaborate with them to make sure that we do not duplicate any functionality, instead we will collaborate and improve what they propose to benefit all from the same set of core libraries and infrastructure.

Notice because of the interaction between the Service Registry and the Configuration Service, for Spring Cloud pure apps, we can bundle the Service Registry and the Configuration Service together as other communities are doing ( Following the same approach we can also bundle the Application Service with these two to avoid extra containers to be deployed.

When we look at K8s, this means that we will need to have a container for the Application Service which will interact with the K8s Service Registry and Config Maps, raising the question if we can bundle this service with the Gateway container.

Some research should be done around the relationship between our ApplicationDeploymentDescriptorsand the real deployment descriptors such as Kubernetes Deployment Descriptors (YAML files) and HELM Charts. It is important to have a trace between the Activiti Cloud view and the real deployment descriptors that are used to provision the services. For this reason, looking into Monocular ( and the relationships between the services explained here is important. It is also important to make sure that we follow similar practices for dealing with versioning and releases as HELM or similar technologies which are already designed to solve these scenarios in a non BPM specific way. 


Github Issues:

Incubator Project:

Original Document in Google Docs open for Comments:

Last week we had some very good progress on our main topics that we want to cover before doing Beta1. Application Service and the new Process Runtime Java APIs are moving forward at very nice pace. There is a lot of work to do around these two areas, so we want to be focused in getting the first iteration out of the door soon. At the same time we keep iterating our core building blocks to make sure that they are consistent.


@MiguelRuizDev changed layout of the Task Manager Incubator Project, from Assembler to Service between Controller and Repository, managing all endpoints from Controller instead of Repository. Implemented architectural changes to tests using Junit and AssertJ.

@igdianovfinishing WebSocket and Gateway integrations for notifications and subscriptions.

@daisuke-yoshimotoworking on the BPMN Signal and Messages types for cloud native deployments.

@constantin-ciobotaruworked to add test for “delete task” #1812, more changes for default diagram when no graphic info present in model” #1808

@lucianopreaworked on standalone tasks and subtasks in Runtime Bundles.

@mteodorivisiting Iasi, Romania and meet remote team there, fixed build issues #1858and #1857

@ffazzinidiscussions and review around application service

@ryandawsonukImproved the security policies on the runtime bundle service by adding filtering by RB name (therefore making it possible to work from a single access control config across multiple services). Created PR to add support for json media type according to alfresco guidelines for audit service.

@erdemedeirosworked on the new Process Runtime Java APIs. Added the basic operations around process definitions and process instances.

@salaboyworked on the Activiti Cloud Application Service PoC to finish the RFC document.

This week we will push harder into the Application Service and APIs definitions and make sure that our Cloud Native Building Blocks are aligned (from a dependencies and APIs point of views).

We keep getting community users messages that wants to try out our new infrastructure and services. We totally recommend to check out our Activiti Cloud Examples Github repository: and our Gitbook’s Quickstart & Overview section:

Get in touch if you want to contribute:

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

Last week I had the pleasure to attend Alfresco Day in New York City. It was a great chance to meet customers and partners creating all sorts of implementations with Activiti. We are quite excited to see their enthusiasm around our new Cloud Native approach in Activiti Cloud. The team is making significant process on the issues triaged for our Beta1 release that should see the light at the end of April.


@MiguelRuizDevEstablishing the “Request of Comments” of task manager pet-project, reading documentation on Spring Data and Spring Rest annotations, tweaking with testing using Junit and AssertJ. Repo:

@igdianovCompleted GraphQL security module. Writing unit and integration tests for GraphQL WebSockets Broker. Getting ready to submit PR with the changes.

@daisuke-yoshimotoworking on streams for BPMN signals. Also, he is working on fixing the bug issue( ACT-4246)

@constantin-ciobotarufixed default diagram when no graphic info present in model (#1808), added 'try activate a cancelled process instance' scenario with error handler support (#1809), worked for acceptance tests for ‘delete task’ functionality (#1812)

@lucianopreaworked on the query-services (PR#35) and runtime-bundle (PR#48) to fix some issue related to the events triggered by engine when a new standalone task is created and add an acceptance test (PR#9) for this scenario. Also did some work on the create a subtask API

@mteodoriUpdate Jackson for vulnerability CVE-2018-7489 #1851and Update to Spring Cloud Finchley M9 #1848

@ffazzinijoined discussions around application service responsibilities

@ryandawsonukadded new admin users to the provided keycloak configuration and defaulted admin access to only the admin role. Created PRs to add support for wildcards on process definitions in security policies and to extend security policies to audit

@erdemedeirosstarted drafting and creating a PoC for the new Process Runtime Java API.

@salaboywork on the RFC for the Activiti Cloud Application Service document plus a PoC on the data model and REST endpoints. We also started drafting our new Process Runtime Java API with @erdemedeiros

This week we will be focused on pushing these efforts forward so keep an eye on the upcoming Request for Comments(RFCs) posts and please provide feedback. These documents are open for all the community members that want to get involved and have an influence on the roadmap of the project.

Get in touch if you want to contribute:

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