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

Welcome to a new edition of Last Week (22/8/17 - 29/8/17) @ Activiti 7 / Dev Logs. Last week we made a huge effort to stabilize our builds and repositories configurations (activiti-build). A new repository was added to make sure that we control the project's dependencies and 3rd party dependencies in a single place. Another important milestone was our JS client example, which can be found here that demonstrate how a simple Angular app can interact with our secure services going through the gateway service.

 

 

@daisuke-yoshimoto he improved sending event data to Audit Service for performance issue and transaction consistency. Next, he is adding MongoDB support to Audit Service.

@erdemedeiros made small improvements and added integration tests for query service; Add basic filtering for audit service; Updated Postman examples.

@ryandawsonuk removed dbdriver dependency from runtime bundle and added spring boot config to load external jars and properties file to runtime bundle at docker build stage. Configured keycloak IDM and gateway for CORS and added basic javascript client to connect to services via gateway.

@salaboy Added a new repository containing our BOMs (Bill of Materials / Dependencies) which is called: activiti-build. This repository contains a set of POM files which describes the projects (Activiti and Activiti Cloud) dependencies separated from 3rd Party ones. After this huge refactoring, started working on a simple Kubernetes deployment descriptor. A blog post will follow about how to set up Activiti Cloud in a kubernetes cluster.


This week will be all about Kubernetes and how to simplify our application publishing/deploying mechanisms without re-inventing the wheel. Because it is a holiday season you will see less activity in the Gitter channel, but I will be around answering questions and working as usual (no holidays for me :).

rallegre

DMN Decision Tables 101

Posted by rallegre Employee Aug 23, 2017

What is DMN?

Decision Model and Notation (DMN) is an industry standard managed by the Object Management Group (OMG) for modeling and executing decisions that are determined by business rules.

What is the role of DMN?

Based on the DMN specification, “the primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes, and finally, to the business people who will manage and monitor those decisions. DMN creates a standardized bridge for the gap between the business decision design and decision implementation. DMN notation is designed to be usable alongside the standard BPMN business process notation. Another goal is to ensure that decision models are interchangeable across organizations via an XML representation.”

What is a DMN decision table?

A DMN decision table is a tabular representation of the decision logic. You can think of a decision table as a spreadsheet that allows you to define a row for each business rule.

Decision tables in Alfresco Process Services & Activiti 6

Here is a simple DMN decision table to determine the price of a single public transportation ticket (right column) depending on the type of passenger (left column).

 

DMN decision table in APS

The left column in light blue refers to possible input data. In this example, there is only one input column (Type of passenger) but you can have as many columns as different type of inputs you have (i.e. type of passenger, area, time of the day…). The cells under the input column header (called input entries) refer to the possible conditions regarding the input.  MVEL is the expression language we support for conditions. For each possible input entry, we define corresponding output entry in the output column cell next to it. The right column in light green refers to possible output data. Each row defines a possible input value and the corresponding output value. In the example here, if the passenger is a child under age 4 then the transportation ticket is free.

XML view

If you download the simple decision table presented here as a DMN file, the decision table is represented by a decisionTable element inside a decision XML element.

<definitions xmlns="http://www.omg.org/spec/DMN/20151130" id="definition_1017" name="Price calculator" namespace="http://www.activiti.org/dmn">
  <decision id="Pricecalculator" name="Price calculator">
    <description>Rules to calculate price</description>
    <decisionTable id="decisionTable_1017" hitPolicy="FIRST">
    <!-- ... -->
    </decisionTable>
  </decision>
</definitions>

Hit policy

In DMN, the hit policy specifies how many rules can be satisfied and what the results of the evaluation of a decision table consist of. The hit policy is set in the hitPolicy attribute on the decisionTable XML element. In the top left corner of the Decision Table Editor, you can select from 2 hit policies: first (single pass) and any (single pass). Both hit policies will always return a maximum of one satisfied rule although multiple rules can be satisfied. When first (single pass) is selected, the execution of the table will stop and return the output of the first satisfied rule. When any (single pass) is selected, all valid rules are executed. However, all satisfied rules must generate the same output. The execution returns only the output of one of the satisfied rules.

Let’s play with a sample app

To help you get started with DMN decision tables, we designed a sample app using Alfresco Process Services (powered by Activiti). We also built the same example using Activiti 6. The use case is an employee annual bonus with the decision logic to evaluate the bonus being defined in a decision task referencing a DMN decision table.

Import & publish the app

Import the Annual bonus.zip app into Alfresco Process Services from the menu App Designer > Apps > Import App. If you are using Activiti 6, please import this app. When done importing, publish and deploy the app on the dashboard.

Run the sample app

Click on the Annual bonus app and start the process.

 

 

In this form used to start the process and thus referenced on the start event, the user is submitting his yearly achievements details. The submitted information is going to be used as input data entries for the decision task calculate annual bonus. Once the process has been started, the user can check the results of the executed DMN decision table by selecting the executed decision tables.

 

 

The decision table displayed is showing the execution path highlighted in light blue. Based on the input values submitted by the user, the first row is the one that satisfied all the conditions displayed in each cell of the 3 input columns. Since the hit policy is set to First, it was the only row executed to return the result.

 

 

The user can also see the name and values of the input entries and output result.

 

 

Let’s now submit an empty form and check the resulting execution and bonus result.

This time the conditions that didn’t match are highlighted in red.

Because we didn’t check the box for the completed obligations, the first 4 rows were not executed since the condition of the first column was never satisfied. The fifth row was executed since an empty expression was considered as a matching condition.

 

Sign in to the admin console

From the administration console (activiti-admin.war), administrators have access to the process instance details including the variables and the executed decision tables via the action Show Decision Audit.

For debugging purposes for example, administrators can modify the values of the variables on a running instance. To keep the instance running on our example, we added a timer after the decision table with a 5min duration period.

Summary

DMN decision tables provide a natural and visual way to specify decision logic. This simple example is showing you how to use them within a process app for automated-decision making. Typical use cases include calculating discounts, credit ratings, who to assign tasks to, what service level (SLA) to use, and so on.

 

Here are other resources that you might find useful:

 

Hope you found this example useful. Feel free to share your comments!

Last week, the whole team spent a lot of time making sure that the code and projects are well organized under a whole new set of repositories. You can find all the new repositories under the github.com/Activiti organization. A blog post will follow next explaining the changes and additions to our projects. I recommend to our community members to check the Activiti/activiti-cloud-examples repositories, where you can find a Docker based example of starting the whole infrastructure plus your domain specific runtime bundles (Spring Boot Process Enabled applications).

 

@daisuke-yoshimoto he is trying to improve sending event data to Audit Service for performance issue and transaction consistency.Next, he is adding MongoDB support to Audit Service.

@gmalanga still working on the elastic repository, for replacing the existing Spring-Data JPA repository for the query service with Elasticsearch.  

@abdotalaat working on getting a simple local identity service to support simple scenarios where SSO is not required.

@fcorti continued to work on the activiti example. This time integrating the 'activiti-cloud-keycloak' container for authentication, ‘activiti-cloud-registry’’ implementing the registry using Spring Eureka and 'activiti-cloud-starter' to define a real microservice architecture for the departments (in the example). Next week is planned to complete the iteration.

@erdemedeiros merged first iteration of query module into the master branch; created related starter in the activiti-cloud-starters repository. Currently adding more integration tests to the query starter.

@ryandawsonuk modified some of the key services to separate out a starter and an implementation based on the starter with the implementations now published to dockerhub and the main cloud example able to use the published images

@salaboy mostly worked on creating the builds in our internal servers to make sure that we can publish docker images to docker hub and reviewed multiple times the example that we are building in activiti-cloud-examples.

This week

This week is all about refining our process to produce and publish docker images to Docker Hub and creating End User examples against our new services. We will be also looking at creating a initial version of our Kubernetes services descriptors.

Notice: as part of our work to keep the project healthy we are closing all the issues in Github that are inactive. We take reported issues very seriously and for that reason we want to make sure that all open issues are being worked on. If you are involved in one of these closed issues and you still think that there is some work to be done there, please get in touch, re-open the issue and write a comment. All new opened issues will be worked on and have a person assigned to it that will report back progress. 
Join us in Gitter if you know or want to learn about Activiti, Spring Cloud, Docker and Kubernetes.

 

Original Blog Post: Activiti 7: Last week Dev Logs #7 – Salaboy (Open Source Knowledge) 

salaboy

Activiti & Activiti Cloud

Posted by salaboy Employee Aug 22, 2017

After a week of moving things around, we are reaching a point where we can share the new structure of our projects and repositories. The changes introduced highlight the different nature of each of these projects and how are they going to be used and consumed. The changes are now considered stable and unless we find very good reason for a new re-organization, these repositories will be considered as part of the Activiti 7 project main efforts.

 

Conceptually, you will find that there are 3 main layers:


Screen Shot 2017-08-16 at 15.24.05

The Core layer will always contain Java Frameworks, in this case, the Activiti/Activiti repository will host the Process Engine that you can embed in your own applications as any other java dependency. While this is enough for some cases, it requires you to build a significant layer of integration and make some complicated decisions about your runtime. I’ve seen such implementations fall into two main categories:

  • The engine embedded in the application: this approach has major drawbacks regarding footprint of your application, memory consumption and adding too much responsibility.
  • The engine embedded in a service layer: this approach is better, but it pushes you to define this service layer. Some companies use this layer to make sure that they don’t depend on a process engine, but this is costly and takes a lot of time to get it right

The same applies to the Query and Audit modules, which are now hosted in the same repository, but we might want to move those away in a future refactoring.

The next new layer that we are providing in Activiti is the Service Layer. As mentioned before, we want to avoid you having to implement this Service wrapper on top of the Engine. For that reason, we have created a modern REST HAL API and Message-Based Endpoints that can be easily extended and adapted to your needs. These Services are designed and implemented in isolation to make sure that they follow the single responsibility approach. We now provide the following services:

  • Process Engine
  • Audit Service
  • Query Service

This list will be expanded in the future with more services, and we will make sure that our services doesn’t overlap functionality that is already provided by the infrastructure or other popular components that you might be already using. A typical example for avoiding overlap, in this case, is the new SSO/IDM component that we are using. We are not providing any homegrown SSO/IDM mechanism as most of the BPM engines out there do. Instead, we are delegating that responsibility to a component that has been designed for providing that integration layer with SSO and IDM specific implementations.

Finally, our last layer is the Infrastructure layer. Our new infrastructure layer allows us to provide a simple way to bootstrap all these services in a cloud-oriented way. We recognized that most of our users aim to run these services on existing infrastructure and for us, it is important to make their lives easier. This infrastructure layer is based on Spring Boot, Spring Cloud,  Docker and Kubernetes, relying on and reusing all the services that they provide so our services can scale independently.  Once again, by aligning our services to these technologies we wanted to make sure that we don’t overlap with the features that they provide. We want our users to feel that when they adopt Activiti, they don’t need to change their infrastructure or the way that they do things in their other services.

The Repositories

Under the Activiti organization in Github we have created several repositories to represent these layers. These repositories are linked in our CI servers and arrows in the following diagram means downstream dependency.  Every time that we make a change in the core engine all the services will need to be built and test again.

Notice also, that all the repositories that depends on *-starters are going to generate and publish Docker Images to Docker Hub, meaning that you will be able to consume all these infrastructure without the need of compiling a single Java class.

Our activity-cloud-examples repository will provide examples that show how to bootstrap the whole infrastructure in your dev environments and existing cloud infrastructures.

One more important thing to understand is that we recognise that each implementation will probably want to replace one or more of these components, so you can end up using the example implementation as reference to implement your own components. If you think that one of your components might benefit the whole community then please get in touch- we can help each other with the design and implementation.

Here are some of the links to our new repositories, Docker Hub and our Travis-CI builds:

Core and Core services repository

https://github.com/Activiti/Activiti

Docker Hub Activiti organization

https://hub.docker.com/u/activiti/dashboard/

Activiti Cloud related repositories

https://github.com/Activiti/activiti-cloud-starters

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

https://github.com/Activiti/activiti-cloud-query

https://github.com/Activiti/activiti-cloud-audit

https://github.com/Activiti/activiti-cloud-registry

https://github.com/Activiti/activiti-cloud-gateway

https://github.com/Activiti/activiti-cloud-sso-idm

Activiti Cloud Examples

https://github.com/Activiti/activiti-cloud-examples

Travis CI public builds

https://travis-ci.org/Activiti/

New Approach / New Scenarios

You might have notice that we now have more services, more things to manage, possible different types of storage. Clearly the way of using the Process Engine is changing. This new approach will open the door to new scenarios, scenarios where we don’t work against a single clustered process engine.  Scenarios where we want different components to emit events that will be aggregated by other components such as the Query and Audit service. Each of these different scenarios might have different requirements such as the use of NoSQL data stores to support graph based data or json documents for search and indexing. This new approach will also allows us to scale different parts of our infrastructure separately and responsively.

Because of that all our services are dockerized and will require an orchestration layer to wire them together. The next section provides a quick intro to these docker images and how to get all the infrastructure up and running by following the activiti-cloud-examples.

A (docker) image worth more than 1000 words

We have now 6 (docker) images published on docker hub and you can get them all up and running in just a couple of minutes. The following diagram shows set of services started when you follow the README file in the activiti-cloud-examples repository:

activiti-cloud-infrastructure.png

Notice that Cloud Connectors are not there yet. The client application represent your other microservices that might share the same infrastructure as Activiti. And Databases related to each services are omitted for simplicity, but the Runtime Bundle docker-compose is starting a PostgreSQL DB. 

Also notice that the communication between these components is likely to happen in an asynchronous way, and for that reason we are also starting RabbitMQ as our message broker. Because we are relying on Spring Cloud Streams, the provider (binder) can be replaced with by some other providers such as Kafka and Active MQ. 

From a client/developer side, you only need docker to get all up and running in a couple of minutes. No java or maven is required to build your domain specific runtime bundles.

You can use the (chrome plugin) postman collection to test the services endpoints.

We will be working hard to make sure that we provide tools to package and version runtime bundles to make sure the the whole process of building and deploying these images is smooth and fast.

More blog posts about Runtime Bundles are coming, which is a central concept in the new infrastructure.  

If you are interested, have questions, comments or if you want to participate in all these changes please get in touch. You can join us everyday in our Gitter channel, where we have open discussions about how each of these components are implemented.

Stay tuned!

 

Original Blog post: https://salaboy.com/2017/08/22/activiti-activiti-cloud/

Big changes are coming into the Activiti 7 project. Last week (7/8/17 - 13/8/17) we started making some big organizational changes in how we structure our projects and our repositories. We have created 3 new repositories: activiti-examples, activiti-compatibility and activiti-spring-boot-starters. Due the amount of changes we are trying to minimize the negative impact that we have in our builds and in people working on different branches. All these changes are necessary and we hope to stabilize the build by the end of next week.

 

@daisuke-yoshimoto added new REST API for handling task variables. Next, he is adding MongoDB support to Audit Service.

@gmalanga is working on using ElasticSearch to provide an alternative implementation of the Query Service.

@abdotalaat created  a new spring JPA project that expose data (users-IdentityInfo-groups-membership) using Rest Endpoints. The previously created user/group/membership migrator from activiti 6 to keycloak was moved here.

@fcorti developed iteration n.3 of the Emergency Call Center project as an example of microservices based solution. This time the project is composed by an Activiti process (with some Java delegates) and three external REST services running as three independent Spring Boot applications. 

@erdemedeiros worked on query module improvements; added support to variable related events. Now the Query Service module is quite close to be merged on the master branch.

@ryandawsonuk integrated zuul and eureka into the docker setup, moved the main docker example app to using postgres, reduced the size of the docker images and refactored the audit service to split out a starter dependency.

@salaboy was working on refactoring the API modules inside the new Activiti Services modules. Now we have the activiti-services-api module that contains all the contracts (interfaces) that can be shared with other external modules. I also added an initial version of the @ActitiviRuntimeBundle annotation that will serve as main entry point to configure your process enabled Spring Boot applications.

This week in Activiti 7

This week we will finish the repository changes and we will stabilize all the builds. We are getting closer to start our journey with kubernetes and for that reason we will spend some more time in making sure that our docker images are correctly built and published to docker hub. As usual you can track our progress and check our outstanding issues and planning here: https://github.com/Activiti/Activiti/projects/1. Feel free to get in touch if you see something in our boards that you might want to contribute to the project. We are looking forward to mentor people interested in joining the project as community members.

Join us in Gitter if you know or want to learn about Activiti, Spring Cloud, Docker and Kubernetes.

Hi everyone, welcome to the Activity 7 Dev Logs #1 (3/07/17-9/07/17).

Last week we published the initial short term roadmap for Activiti 7 and we started executing according that plan. We got a lot of great feedback and some external community contributors are already working with us. This is a short update about what we did last week.

 

@daisuke-yoshimoto our community contributor from Japan is helping us with cleaning up the parent pom dependencies and tests that are failing when the Locale is set to Japanese. He is also having discussions with @ryandawsonuk about IDM and is that going to work in the future. You can track Daisuke work here: https://github.com/daisuke-yoshimoto

@fcorti and @cijujoseph are working on creating our flagship example process that we will use to demonstrate all the new changes in the project infrastructure .

@balsarori helped us with clean up of the old Form classes contained inside the process engine.

@erdemedeiros is working on the new REST HAL APIs and Data Types, this is an initial PoC to make sure that we can interact with the process engine via REST making sure that we have clear definitions (in JSON format)  of the data types accepted and returned by these endpoints. You can track Elias' work here: https://github.com/erdemedeiros

@ryandawsonuk is working on integrating keycloak as our default IDM and SSO provider and removing the IDM module from inside the process engine. This is valuable contribution to the keycloak project as well that it didn't supported spring boot 2 just yet, so Ryan provided the PR to the spring boot keycloak adapter.  You can track Ryan's work here: https://github.com/ryandawsonuk

@salaboy (myself) I'm working in making sure that the process engine emits events using well defined data types via messages using Spring Cloud Stream. These messages should use the same JSON data types and payloads that Elias is defining, so I'm currently working in a PoC to demonstrate this event emitters and endpoints in action. You can track my work here: https://github.com/Activiti/Activiti/tree/history-refactoring

Consider that all the code references are work in progress so they will evolve accordingly once the basics are done. We aim to improve coverage and code with every commit/merge to master branch.

This Week in Activiti 7

This week  we are moving the activiti-rest and activiti-common-rest modules to the activity-compatibility repository, so we can focus only on the core engine inside the Activiti repository.

We will aim to have a first draft of all Data Types, Commands and Endpoints for the new HAL APIs and message based communications, so we can share and ask for feedback to the community. We will also try to have a working example with Keycloak to demonstrate all the advantages of having a fully fledge SSO and pluggable IDM for our infrastructure.

NOTE: if you want to send a contribution to 6.x version of the engine please  send PRs to the 6.x branch. We are going to a clean up process in Github, so if you have an open PR, branch or issue please get in touch. We will not discard any issue but we need to make sure that all the PRs, branches and issues are still relevant.

Feel free to join us in the official Gitter channel of the project and join the discussions.

Hi everyone, welcome to a new edition of the Activiti 7 Dev Logs #2 (10/07/17-16/07/17).

We keep crunching code based on our short term roadmap for Activiti 7. We started to see some light at the end of the tunnel, and there will be more blog posts about the new HAL API draft and the IDM integration with Keycloak later this week. This is a short update about what we did last week.

 

 

@daisuke-yoshimoto was adding the new REST API that generates JSON/XML/SVG for Process Definitions and SVGs for Process Instances. We are trying to provide a process diagram in a more flexible format (SVG) than a PNG/JPEG image. We wanted to analyze the complexity of providing SVG generation in the backend in contrast with client side generation, which should be possible as well. You can track his work here.

@gmalanga (our brand new community contributor) started working on providing a new endpoint for getting meta information about Process Definitions such as required roles and users, User Tasks, Services Tasks, delegates/connectors required, etc. This will helps us to understand more about our runtime bundles for smart deployments in the future.

@abdotalaat (a new community member as well) was working in a PR related to code quality, removing dead code and making sure that our tests improve their quality. You can check his work here.

@erdemedeiros: was adding new entry points to the REST HAL API, moving legacy REST API to activiti-compatibility repository and now he moved to work with the initial PoC of the new History/Audit module. With Salaboy we are working in this branch. 

@ryandawsonuk was adding a sample Keycloak integration for the new REST API for authentication and capturing users for actions such as recording process initiators. The integration is almost done and now we need to figure out the structure of the different modules and how these modules will integrate into end users applications. You can follow the work and the discussion here.

@Salaboy:  I was working on the REST APIs refinements and overall project clean ups and structures. We are getting quite close to get our initial HAL APIs initial draft, and we will be sharing more about this soon. I finished my first take on the History/Audit and Query modules and now Elias is taking that over for pair reviewing and improvements. Some of my work is already in master for the API and there were some more cleanups being reviewed here. 

As a side note we are now using GitHub Projects to track our and community contributions so feel free to get in touch if you find something there that you want to work on:

https://github.com/Activiti/Activiti/projects/1

As usual feel free to join us in our Gitter channel for further discussions and collaborations:

https://gitter.im/Activiti/Activiti7?utm_source=share-link&utm_medium=link&utm_campaign=share-link

Stay tuned!

Hi everyone, here another Dev Log from the Activiti 7.x (17/7/17 - 23/7/17) team. We are making a lot of progress on creating the new services decoupled and independent. We are reaching a point where we can start writing examples that demonstrate clear advantages in comparison with the traditional (monolith) approach.

As usual, you can track the progress via the GitHub project:  https://github.com/Activiti/Activiti/projects/1

 

Here is the list of people contributing to the project on daily basis and the work that they performed last week:

@daisuke-yoshimoto was adding new ProcessDiagramGenerator for new REST API that generates SVG for Process Definitions and for Process Instances. In contrast with the previous version that only generated PNG/JPG which are difficult to manipulate.

@gmalanga was working on a metadata set of endpoints for process definitions. This will enable us to check against different components to see if all the requirements to run our deployed process definitions are met by the runtime environment. One simple check might be to check if the users and groups required by our processes are defined in our IDM provider.

@abdotalaat was working in a PR related to code quality, removing dead code and updating the PR after some changes in master.

@fcorti was working on a simple but concrete example process, defining an Emergency Call Center coordinating the requests together with different Organizations (Fire Department, Police, Hospitals, etc.). The process definition will run in Activiti 6, but it will be ready to be deployed in a microservices architecture in the future Activiti 7. The project is in the development phase and you can find the design at this link. Feedback and help are more than welcome.

@erdemedeiros mainly worked on the initial PoC of the new History/Audit module: make the REST API read-only; improve the result presentation. He’ll carry on that next week.

@ryandawsonuk verified the Keycloak integration with some tests in the sample project and mocking for identity in the spring boot starter project. I also set up the Keycloak integration to use a docker container that loads sample configuration from a json file. I then moved on to doing PoCs to assess options for the new Query Service.

@salaboy was working on adding the initial version of the activiti-services. These modules will contain the core logic to expose our brand new HAL APis and Message Based Endpoints. These modules are in draft stage and will evolve quickly if you are interested in more details about these services get in touch.

This Week on Activiti 7

This week we will be working towards polishing all these services and making sure that we have examples to demonstrate how they all work in coordination. We will also publish a couple of RFC (Request For Comments) blog posts about the new HAL APIs, Data Types and Message Based Endpoints. You will also see some changes in how the artifacts are versioned so we can release an Early Access version (EA) every month. 

We are also encouraging the community to join us in the community workshops that we are going to organize once every two weeks to work on the project. If you are in the London area, get in touch, join the Gitter channel and ask us for more details. 

This is a great chance to get involved and shape the future of the Activiti project.

We are closing our 4th week (24/7/17 – 30/7/17) of work on the new Activiti 7.x project and we are moving fast to make sure that we provide a set of robust services that are ready to be integrated into your existing micro services architecture. We have chosen a technology stack that relies on standard Spring mechanisms for integrations and topics such as: IDM, security, messaging and SSO.

This new month that is starting tomorrow will be all about introducing two new services called Audit Service & Query Service. These services are completely independent of any process engine instance and will be in charge of aggregating information for different users (applications) to consume. These new services will allow us to remove the responsibility from the process engine to keep track of auditing and to deal with complex queries for different types of clients.

 

 

Here is what we were up to this last week:

@daisuke-yoshimoto added new ProcessDiagramGenerator for new REST API that generates SVG for Process Definitions and for Process Instances. Next, he is creating new REST API that provides xml/json of Process Definitions.

@gmalanga was fixing some issues related to the endpoint for metadata process definition, then moved to integrate elasticsearch as repository for the query service. Still progressing with the elasticsearch integration.

@abdotalaat was working in a PR related to code quality, removing dead code and making sure that our tests improve their quality.

@fcorti The first version of the Emergency Call Center process example has been completed at https://github.com/Activiti/activiti-examples/tree/master/emergency-call-center. This version of the process runs on Activiti 6 but in the next releases more support to a pure microservice architecture will be added.

@erdemedeiros worked on Audit module. The existent code was adapted based on the last changes from the master branch. Currently adding more integration tests for this module.

@ryandawsonuk worked on the new activiti-services-query component, which will provide a way to query aggregated data consumed via an event stream. A structure has been put in place so that the default repository can be replaced with an alternative (e.g. elastic). Various approaches for providing a query DSL were evaluated and QueryDslPredicate was chosen.

@salaboy was working on improving the Command Based Endpoints for interacting with the process engine as well as adding versioning to the Rest APIs controllers. With @erdemedeiros and @ryandawsonuk started looking at the release process for maven central and some estimations on when a first version might be uploaded there. Pull requests are piling up so I spend some time reviewing and collaborating with @daisuke-yoshimoto and @gmalanga.

We are evaluating the possibility of making another community workshop the 21st August in Central London (Near Oxford Circus Tube Station). You are all invited to come and join us while we work that day. This is a great way of getting introduced to the work that we are doing and to join the community. If you have troubles convincing your boss about how that is valuable you can get in touch and we can help you with that as well. :)

I will publish soon a newly updated roadmap blog post based on the work that we did for Milestone #0.

Last week (31/7/17 - 6/8/17) on the Activiti 7 project we spend a lot of time working on clean ups and infrastructure as well as refining and adding new Activiti Services (Gateway and Registry). We are enabling all our services to work with Docker so they can be scaled independently. We hope to start publishing these Docker images soon for those eager to try them.

 

@igdianov started researching tracing with Zipkin and reviewing our CQRS implementation.

@daisuke-yoshimoto added new REST API that provides JSON/XML/SVG for Process Definitions and Process Instances.Next, he is creating new REST API for handling task variables.

@gmalanga was working on the ElasticSearch implementaiton of the query module.

@abdotalaat was working on a migration application for User, Groups and Memberships from Activiti 5.x/6.x to Keycloak json configuration.

Francesco Corti this week worked on the second iteration of the Emergency Call Center Activti example. The enhancement this time is that a real micro services architecture has been developed using a Spring HATEOAS project to run three different services in three different Apache Tomcat instances. You can check the project here for further details.

@erdemedeiros (Elias Ricken de Medeiros worked on audit module: improve tests coverage; launch docker used for tests directly from Maven. The initial implementation is now merged into the master branch. Moving to query module.

@ryandawsonuk (Ryan Dawsonset up the build to create docker images of core Activiti services and put together a start script to run the build and start containers from the images using a docker-compose.

@salaboy worked on finishing the initial version of the command based endpoints as well as how to test these interactions. I’ve also moved the spring boot starter sample app to a new repository under Activiti/activiti-examples/. We are refining our services to make sure that they all play nice together, as part of this month roadmap we have included two new services, the Gateway and the Registry that will enable us to scale and communicate our services in a unified way.

 

This week plan

This week we need to review our SSO security integration with Keycloak now that our services are behind a Gateway, we need to make sure that the Gateway itself is secure and each service behind the Gateway can consume the signed tokens. We also need to finish the initial Docker configuration of the following services: Gateway, Registry, Runtime Bundles (Process Engine), Audit Service, Query Service, Rabbit MQ and all the  DataSources so we can start building examples.

Stay tuned!

See you all in Gitter