Monday, December 05, 2016

New 6.5.0.Final tags for community Docker images

The latest Docker community image tags for 6.5.0.Final are now available on Docker Hub.

More information at the following links:


Share/Bookmark

Friday, November 11, 2016

Red Hat BRMS and BPMS Roadmap Presentation (Nov 22nd, London)

Original Link :  http://www.c2b2.co.uk/red_hat_brms_and_bpms_roadmap_presentation

Featuring Drools, jBPM, OptaPlanner, DashBuilder, UberFire and Errai
For our second JBUG this November we’re delighted to welcome back Red Hat Platform Architect, Mark Proctor who will be part of a panel of speakers presenting roadmap talks on each component technology.
We’re fortunate to have this opportunity for so many project leads to be in one room at the same time, and it’s a fantastic opportunity to come along and ask questions about the future plans for BRMS and BPMS.
The talk will look at how the 7 series is shifting gears, presenting a vision for low-code application development in the cloud - with a much stronger focus on quality and maturity over previous releases.
Key topics will include:
  • The new Rich Client Platform
  • The new BPMN2 Designer
  • New Case Management and Modelling
  • Improved Advanced Decision Tables and new Decision Model Notation
  • Improved Forms and Page building
  • Fully integrated DashBuilder reporting
  • New OptaPlanner features & performance improvements
There will be opportunities for questions and the chance to network with the team over a beer and slice of pizza.
Registration
Attendees must register at the Skills Matter website prior to the meet-up. Please – only register if you intend to come along. Follow this link to register: https://skillsmatter.com/meetups/8489-jboss-november-meetup.
Agenda
18:30 – 18:45     Meet up at Skills Matter with a beer at the bar
18:45 – 19:45     Part One
19:45 – 20:00     Refreshment break
20:00 – 20:30     Part Two
20:30                    Pizza, beer and networking
Speakers
Mark Proctor
Mark is a Red Hat Platform Architect and co-creator of the Drools project - the leading Java Open Source rules system. In 2005 Mark joined JBoss as lead of the Drools project. In 2006, when Red Hat acquired JBoss, Mark’s role evolved into his current position as platform architect for the Red Hat JBoss BRMS (Business Rules Management System) and BPMS (Business Process Management System) platforms - which incorporate the Drools and jBPM projects.
Kris Verlaenen
Kris is the JBoss BPM project lead, and is interested in pretty much everything related to business process management. He is particularly fascinated by healthcare - an area that has already demonstrated the need for flexible business processes.
Geoffrey De Smet
Geoffrey is the founder and project lead of OptaPlanner (http://www.optaplanner.org), the leading open source constraint satisfaction solver in Java. He started coding Java in 1999, regularly participates in academic competitions, and enjoys assisting developers in optimizing challenging planning problems of real-world enterprises. He is also a contributor to a variety of other open source projects.
Mauricio Salatino
Mauricio Salatino is a Drools/jBPM Senior Software Engineer in Red Hat, and author of the jBPM5 and jBPM Developer Guide, and the Drools 6 Developer Guide. His main task right now is to develop the next generation cloud capability for the BRMS and BPMS platforms - which includes the Drools and jBPM technologies.
Max Barkley
Max is a Software Engineer at Red Hat and the Errai project lead. Joining Red Hat as an intern in 2013, he took on his current role after graduating H.B.Sc. Mathematics from the University of Toronto in 2015.

Share/Bookmark

Monday, October 31, 2016

Drools 7 to support DMN (Decision Model and Notation)

The Decision Model and Notation (DMN) specification is a relatively new standard by OMG (Object Management Group) that aims to do for business rules and business decisions what BPMN (it's sibling specification) did for business processes: standardize the notation and execution semantics to enable both its use by business users, and the interchange of models between tools from different vendors.

The Drools team has been actively following the specification and the direction it is taking. The team believes that, in accordance with its long time commitment to open standards, it is now time to support the specification and provide a compliant implementation for the benefit of its users.

The specification defines among other things:


  1. an expression language called FEEL used to express constraints and decisions
  2. a graphical language to model decision requirements
  3. a metamodel and runtime semantics for decision models
  4. an XML-based interchange format for decision models


As part of the investigation, the Drools team implemented a PoC that is now public and available here. The PoC already covers:


  • a complete, compliance level 3, FEEL language implementation.
  • complete support for the XML-based interchange format for marshalling and unmarshalling.
  • A partial implementation of the metamodel and runtime semantics 

We expect to have a complete runtime implementation released with Drools 7.0 (expected for Q1/2017).

On a related note, this is also a great opportunity for community involvement. This being a standard implementation, and relatively isolated from other existing components, it is the perfect chance for any community member that wishes to get involved with Drools and open source development to get his/her hands dirty and help bring this specification to life. Contact me on the Drools mailing list or on IRC if you would like to help.

We will publish over the next few weeks several blogs on this subject, with both general explanations about the specification and with details of our plans and our implementation. Bellow you can find a quick Q&A. Feel free to ask additional questions you might have about this subject on the mailing list.

Happy Drooling!

Questions & Answers


1. What DMN version and what compliance level will Drools support?

Drools is implementing DMN version 1.1 support at compliance level 3.

2. Is DMN support integrated with the Drools platform?

Yes, the DMN implementation leverages the whole Drools platform (including, among other things, the deployment model, infrastructure and tooling). DMN models are a first class citizen in the platform and an additional asset that can be included in kjars. DMN models will be supported in the kie-server and decision services exposed via the usual kie-server interfaces.

3. Is Drools DMN integrated with jBPM BPMN?

At the moment of this announcement, the integration is not implemented yet, but we expect it will be fully functional by the time Drools and jBPM 7.0 release (Q1 2017).

4. Will FEEL be a supported dialect for DRL rules? 

At the moment this is not clear and requires additional research. While FEEL works well as part of the XML-based interchange format, its syntax (that supports spaces and special characters as part of identifiers) is ambiguous and cannot be easily embedded into another language like DRL. We will discuss this topic further in the upcoming months.


Share/Bookmark

Tuesday, October 25, 2016

Drools 6.5.0.Final is available

The latests and greatest Drools 6.5.0.Final release is now available for download.

This is an incremental release on our previous build that focus on a few key improvements to round up the 6.x series.

You can find more details, downloads and documentation here:

Read below some of the highlights of the release.

You can also check the new releases for:
Happy drooling.

What's new?

Core Engine

Configurable ThreadFactory 


Some runtime environments (like for example Google App Engine) don't allow to directly create new Threads. For this reason it is now possible to plug your own ThreadFactory implementation by setting the system property drools.threadFactory with its class name.

Use of any expressions as input for a query 


It is now possible to use as input argument for a query both the field of a fact as in:

query contains(String $s, String $c)
    $s := String( this.contains( $c ) )
end

rule PersonNamesWithA when
    $p : Person()
    contains( $p.name, "a"; )
then
end 

Update with modified properties 

Property reactivity has been introduced to avoid unwanted and useless (re)evaluations and allow the engine to react only to modification of properties actually constrained or bound inside of a given pattern. However this feature is automatically available only for modifications performed inside the consequence of a rule. Conversely a programmatic update is unaware of the object’s properties that have been changed, so it is unable of using this feature.

To overcome this limitation it is now possible to optionally specify in an update statement the names of the properties that have been changed in the modified object as in the following example:

Person me = new Person("me", 40);
FactHandle meHandle = ksession.insert( me );

me.setAge(41);
me.setAddress("California Avenue");
ksession.update( meHandle, me, "age", "address" ); 

Monitoring framework improvements 

A new type of MBean has been introduced in order to provide monitoring of the KieContainers, and the JMX MBeans hierarchical structure have been revisited to reflect the relationship with the related MBeans of the KieBases. The JMX objectnaming has been normalized to reflect the terminology used in the Kie API.A new type of MBean has been introduced in order to provide monitoring for Stateless KieSession, which was not available in previous releases.

Drools Workbench

Guided Rule Editor : Support formulae in composite field constraints 

Composite field constraints now support use of formulae. When adding constraints to a Pattern the "Multiple Field Constraint" selection ("All of (and)" and "Any of (or)") supports use of formulae in addition to expressions.

Authoring - Project Editor - Reimport button 

The "Reimport" button invalidates all cached dependencies, in order to handle scenarios where a specific dependency was updated without having its version modified.
Share/Bookmark

Thursday, September 29, 2016

Google Summer of Code 2016: Drools & Minecraft

Another successful Google Summer of Code program took place this year. We worked together with Samuel Richardson from the USA to get the first integration between the Drools Engine and the popular game engine Minecraft. The scope of the project was to experiment how Drools can be used to declaratively define a game's logic. I initially thought about modelling point & click games such as Escape The Room, Monkey Island, Maniac Mansion, etc but after looking at how to work with Minecraft I've opened the concept to wider game definitions. 
gsoc

We worked with Sam into creating a generic game engine that will take the Rules Definitions and drive the game (the Minecraft Mods) . Sam created a couple of Minecraft MODs that provides a scenario for the game which interacts and delegate to Drools the game's logic.
You can find the work for the Drools Game Engine here: https://github.com/salaboy/drools-game-engine

These two games are using the rules described here:
and here:

We spent a lot of time in trying to get the separation right, so now you can consume the game server itself indepentendly of the UI. This opens up the doors so you can use the engine withoug Minecraft. For that reason we have created also a set of services that exposes the Game Engine via rest in case that you want to interact with it remotely.

You can take a look at the main GameSession interface which is in charge of defining how to create new game sessions and enables the UI to register callbacks so actions can be executed when the logic of the game says so.


Because of this separation you will see that each game has its own test suite where both, the Rules and the GameSession API is tested to make sure that new games can be created and the rules are behaving as expected.

There is a lot of things to improve still, both in the Game Engine and in the MODs, so feel free to get in touch with us if you want to participate on the project. Hopefully we can build enough features to include it in the Drools Project.

Share/Bookmark

Wednesday, August 17, 2016

Red Hat BPMS and BRMS 7.0 Roadmap Document - With a Focus on UI Usability

BPMS and BRMS  6.x put in a lot of foundations, but the UI aspects fell short in a number of areas with regards to maturity and usability.

In the last 4 years Red Hat has made considerable investment into the BPMS and BRMS space. Our engineering numbers have tripled, and so have our QE numbers. We also now have a number of User Experience and Design (UXD0 people, to improve our UI designs and usability.

The result is we hope the 7x series will take our product to a whole new level, with a much stronger focus on maturity and usability, now with the talent and bandwidth to deliver.

We had an internal review where we had to demonstrate how we were going to go about delivering a kick ass product in 7.0. I thought I would share, in this blog, what we produced, which is a roadmap document with a focus on UI Usability. The live version can be found at google docs, here - feel free to leave comments.

Enjoy :)

Mark
BPMS and BRMS Platform Architect.

Other Links:
Drools 7.0 Happenings  (Includes videos)
Page and Form Builder Improvements (Video blog)
Security Management (Detailed blog on 7.0 improvements)
User and Group Management (Default blog on 7.0 improvements)
--------

About This Document

This document presents the 7.0 roadmap with an eye on usability, in terms of where, how and who for. It is an aggressive and optimistic plan for 7.0 and it is fully expected that some items or a percentage of some items will eventually be pushed to 7.1, to ensure we can deliver close to time. Longer term 7.1 and onward items are not discussed or presented in this document, although it does touch on some of the items which would be raised as a result of reading this document - such as the “What’s not being improved” (for 7.0) section.

Wider field feedback remains limited, with a scarcity of specifics. This creates challenges in undertaking a more evidence based approach to planning, which can stand up strongly to scrutiny on all sides. However, engineering and UXD have been working with the field, primarily through Jim Tyrrell and Justin Holmes over the last year on this topic and this document represents the culmination of many discussions over the last year. As such it represents a good heuristic, based on the information and resources available to us at the time.

Understanding Feedback from the  Field

Broadly speaking, we have two types of customers:
  1. Those who want developers to use our product, often times embedded in their apps
  2. Those who want a cross-functional team to use our product

Generally speaking, we do quite well with customer 1, but we have a huge challenge with customer 2. The market has set a pretty clear expectation, on features and quality for targeted audiences, with IBM ODM and Pega’s BPM/Case Management. Almost every customer type 2 either has a significant deployment of these two competitors in place, or the decision maker has done significant work with these products in the past. Moreover, customer 2 is interested in larger, department or organization wide deployments. Customer 1 is usually interested on project level deployments.

Customer 2 is primarily upset with our authoring experience, both in eclipse and in Business Central. It is uncommon that customer 1 or 2 is upset with missing features or functions from our runtime (especially now that 6.3 has been released with a solid execution server and management function), and when she is, our current process to resolve these gaps works well. Therefore, the field feedback in this document (and our current process) is focused on the authoring experience. This isn’t to say other elements of the product are perfect, but simply an acknowledgement that we have limited time and energy and that the authoring experience is the most important barrier to success with customer 2.

The key issues that we have authoring side are fundamental (customer stories available here at request - some are a bit off color). Generally, these issues fall into 3 areas which are further enumerated in “Product Analysis and Planned Changes.”
  1. Lack of support for a team centric workflow - Functional
    1. See Asset Manager (we need to add detail here)
  2. Knowledge Asset Editors
    1. See BPMN2 designer (functional / reliable), decision table editor (usable) and data modeller (usable), forms (usable)
  3. Navigation between functions and layout of those functions in the design perspective
    1. See Design (Authoring perspective)
    2. Deepak - (usable/reliable)
    3. Aimee - Functional

Introduction - The Product Maturity Model and what is Usability

Version 6.x has done well getting BRMS and BPMS to where it is today, with a strong revenue stream. The product maturity model (see image below) is a useful tool for discussing product improvements. It demonstrates that we are low on the model and need to mature and move up if we are to continue to improve sales. Too many aspects of the system, within the UI, may be considered neither functional (F), nor reliable (R), nor usable (U). The purpose of this document is to articulate a plan to address these issues, and in particular highlight the type of users the tool is being designed for and what they’ll be doing with it. The goal for 7.0 is to get as close to the “chasm” described in the model, with an aim to go beyond it as 7.x matures.



When discussing usability it’s very important we understand whether we are talking about lack of features (F), too many or too serious defects (R) or poor UI design (U).

Quite often people report an issue as usability simply because they want to go from A to D, but get stuck at B or C. Either because the functionality is not there to complete the task, or it’s too buggy and they cannot progress. So while good UI design is important, we must balance our efforts across F, R and U to become usable - a focus on UI design only will not help usability, if the underlying product is neither reliable or functional. Commonly this is called Human Centered Design.  By leveraging this common vocabulary, we can foster a more effective and inclusive dialogue with the wider team. So going forward, we are asking our stakeholders to employ the usability model presented here, and in particular the Functional, Reliable, Usable and Convenient terms.

High Level Goal

A minimal viable product for case management is the main goal for 7.0. Case management provides a well defined end-to-end use case for product management, engineering and UXD. This is more than just adding another feature. When a user creates an end-to-end case management solution they will need to use most aspects of our system. Case management also has a clear set of target audiences (personas) for design UI and case worker UI. This allows us to identify both where and how and who for our “fit and finish” efforts are spent to improve things. Ensuring a strong  directed focus on what we do and making it easier to communicate this, with hopefully a more realistic understanding of expectations from others within the organisation.

High Level Plan

When considering the plan as a whole, the initial target user for 7.0, or persona, for the design ui is that of a casual or low skilled developer, who typically favours tooled (low code) environments where possible. See Deepak in Persons:
Where possible and it makes sense, designs will be optimized for the less technical, citizen developers, of Aimee and Cameron Personas. With either optional advanced functionality for Deepak or common denominator designs suitable for all personas. While
Citizen developers are not the primary focus for 7.0, it will become increasingly important and should ideally be targeted for 7.1 onwards, so it’s important as much as practically possible is done for this direction n 7.0.  See “The advent of the citizen developer”.

Throughout this work, where possible and time permitting, designs will be put in place, either as alternative persona support or common denominator persona support for the, 
7.0 will primarily be focusing on all the components and parts that a Business Central user will come into contact with, while building a case management solution. For each of those areas we will try to have a sustained effort, over a long period of time to ensure depth and maturity, with UXD fully involved.

The aim for case management, the targeted components it uses and the Deepak persona is to achieve an acceptable level for functional, reliable and usable. For 7.1 we hope to look more holistically across the system and cross the chasm to become convenient. To become convenient we will need a strong effort in looking at the end-to-end user interaction using the system and trying to streamline all the steps they go through and making it easier and faster for them to achieve the goals they set out to achieve.

Detailed plans here
Detailed resource allocation, here.

Product Changes Done (6.3)

  • The whole business central was updated to PatternFly for v6.3. (See screenshots at end).
  • Execution server UI has been fully redesign with UXD involvement and great field feedback. (See screenshots at end).
    • “I want to congratulate you on the great work on the new kie server management features and UI. It's surprisingly intuitive and does just what it needs to do. Keep up the good work!” (Justin Holmes, Business Automation Practice Lead).
  • The process runtime views have been augmented with the redesigned and newly integrated DashBuilder. They look great and have already had good feedback.  (See screenshots at end).

Product Analysis and Planned Changes

The 7.0 development cycle only started early/mid May, we do not yet have UXD input (wireframes/css/html) for every area. This UXD input will take time and will be produced incrementally across the product, throughout the 7.0 life cycle. What we do have, and is included below, where those efforts will be.
  • Design (Authoring perspective)
    • Problem:
      • The authoring perspective is designed for power users, and fails to work for less technical personas.
      • The project configuration works just like normal editors, which is confusing.
      • The project explorer mixes switching org/repo/project and navigation, which crowds the area. It’s also repository oriented.
      • Versioning, branching are too hard and commits do not squash, creating long unreadable logs for every small save.
    • Solution:
      • See UXD wire diagrams for most of what is described here, although there is still more to do.
      • Create new views for navigating projects, that is content and information oriented and more suitable for the casual coder and moving towards citizen developer. Make things project oriented.
      • Centralise project settings, and improve their reliability and usability.
  • Support for Collaborative Team Based Workflow
    • Problem:
      • Most customers using Business Central want it to support a team, which generally reflects the Deepak, Aimee, Paula and Cameron from our personas.
      • We have no clear workflow for changes to be approved and promoted in the team.
        • The asset manager (versioning and branch management) needs an overhaul. It is extremely confusing to the point of not being functional even for technical users. The current feature does weird branching/merging with git in a single repo, so it’s too technical for Aimee but confusing for Deepak as it doesn’t follow conventions.
        • The screens are way too small to be usable and the actual workflow can be quite confusing
        • The feature hasn’t been QE’d
      • The single git repository model can make integrating Business Central into a CI/CD flow complicated. It’s doable now that we have git hooks, but it is far from convenient. Give our strength in the CI/CD space, this needs to get to convenient.
    • Solution
      • Underlying changes going on for the cloud work (every user gets their own fork) will put in place the backside which will make this easier to progress. Exactly how we will improve the UXD here, to hide and simplify GIT has to be investigated. We have a hiring slot open for someone to focus on this area.
      • Will move to a repository per user. This will support a pull request type workflow in the tool between users.
      • Repo per user will simplify CI/CD
      • To be clear 7.0 will work to improve around the scope of what we have in 6x now, as we have limited time left for 7.0 on this now. With the aim of being minimally viable for deepak. It’s not clear how easy we can make this for aimee too. Likewise wider collaborative workflow, really needs to be considered future work, to avoid expectation problems.
  • BPMN Designer
    • Problem
      • The BPMN designer is the most important area in the product and also the area that gets the most complaints. These complaints are primarily about reliability, Oryx was inherited from an old community project (for time to market) and came with too much technical debt. There are lots of small details, which can detract from the overall experience.
      • Oryx is not testable and regressions happen with almost every fix, making it very hard and costly to stabilise.
    • Solution
      • Work with the Lienzo (a modern canvas library) community to build a new visio like tool, that can support BPMN2, and provide a commercial quality experience.
      • Have a strong focus on enabling testability.
      • Real time drawing of shapes and lines during drag. Including real time alignment and distribution guidelines and snap.
      • Proper orthogonal lines, with multipoint support, and heuristics to provide minimal number of turns for each line.
      • Reduced and more attractive property panels (designed by UXD) for each of the node types, focusing on hiding technical details and (also) targeting less technical users.
      • Change palette from accordion to vertical bar with fly-outs. Support standard and compact palettes.
    • Eclipse
      • To unify authoring experience across web and Eclipse, we are investigating using web-based modelling components inside of Eclipse, without the need for business-central or any other server. However this is a research topic and we are unable to promise anything. We plan to investigate decision tables first, as they are simpler, as they require a single view (and also use lienzo), which may make 7.0. If that goes well, we will look into the designer - but this is not planned for 7.0.
      • Until we have a supported Lienzo based BPMN2 designer for eclipse, we will continue to support and maintain the existing eclipse plug in. The existing items, such as project wizards, will remain and have support.
  • Administration/Settings
    • Problem:
      • Administration and settings are spread out in different locations and are neither consistent nor intuitive. In some cases, such as imports, they have been buggy.
    • Solution:
      • Centralise administrations and settings and ensure they are consistent and intuitive.
      • Ensure all administration and settings are reliable.
      • Work with UXD on improving designs.
        • Designs TBD.
  • Case Management
    • This does not exist yet, but UXD are involved. They have produced visionary documents, which go beyond what we can implement now, and are working with us to produce more incremental and simpler steps that we can achieve for 7.0
  • Decision Tables
    • Problem
      • There are not a lot of complaints about decision tables, other than they could be more attractive. The main issue is they are not functional compared to our competitors.
    • Solution
      • Focus the two Drools UI developers solely on decision tables and moving towards Decision Model and Notation, an OMG standard for decision tables that compliments BPMN2.
    • Must support tabular chaining (part of DMN spec),  design time verification and validation and excel import/export.
    • Work with UXD to improve the aesthetics.
  • Reporting (DashBuilder)
    • Problem
      • Dashbuilder is already a mature and well featured product, with few complaints.  However it came from Polymita and uses a different technology stack, which produces a design miss match - as it’s not PatternFly. Nor can its charts be easily integrated into other pages, which is necessary for process views and case management.
    • Solution
      • An effort has been going on for some time to port Dashbuilder to the same technology as the rest of the platform and adopt Pattern Fly. The results for this can already be seen in the improved jBPM process views for 6.3 and we should have full migration for 7.0
  • Forms
    • Problem
      • This is an inherited Polymita item which was written in a different technology stack and it never integrated well nor is it PatternFly, creating an impedance mismatch.
      • It has some powerful parts to it, but it’s layout capabilities are too limited, where users are restricted to new items in rows only. There is no row spanning, or grid like views.
    • Solution
      • A new effort has been going on for some time now that ports the forms to the same technology stack as the rest of the platform and adopt PatternFly.
      • We are focusing around a bootstrap grid layout system, to ensure we have intuitive and powerful layout capabilities. We have invested in a dynamic-grid system for bootstrap grids, to avoid the issue of having to design your layout first, as it’s hard to change after.
    • Working with UXD to redesign each of the editors for the form components.
  • Data Modeller
    • Problem
      • There are less complaints on this item than others, probably due to it’s more simplistic nature. But UXD have a number requests, to try and improve the overall experience anyway.
    • Solution
      • Support simple business types, optionally and in addition to java types.
    • i.e. number, string, currency, but we won’t lose the ability to use the Java types when required.
    • Layout changes and CSS improvements
    • Longer term we need a visual ERD/UML style modeller, but that will not happen for 7.0
  • Data Services/Management
    • This does not exist yet, but is necessary for case management to work end-to-end. It entails the system allowing data sources to be used, tables to be viewed and their data to be edited. More importantly it allows design time data driven components for forms.

What's Not being improved for 7.0

  • 7.1 will need to have a stronger focus on trying to become more convenient and pleasurable. This will require stronger focus on streamlining how the user uses the tool as a whole, making it easier and faster for them to get things done. Wizards and task oriented flows will be essential here, and general improved interaction design.
  • General
    • Refactoring
  • BRMS
    • Guided Editor
    • Scenario/Simulation
      • We hope to pick this up for 7.1 in 2017.
    • DSLs
  • BPMS
    • Redesign of the navigation
    • Major redesign of process instance list or task list (though adding features to support case management)
      • More focus on building custom case applications that can be tailored specifically to what the customer needs
  • Product Installer
  • It is unclear if the product team will be improving the usability of the installer and patching.
  • Product Portal and Download
    • It is unclear if the product team will be improving how product and patches are found.

Other Notable Roadmap Work

  • Drools
    • Drools is currently focusing on trying to enable multi-core scalability for CEP use cases and also high availability for CEP use cases. There is also ongoing longer term research into pojo-rules and a drl replacement (will most likely be a superset of java).
  • jBPM
    • Horizontal scaling for the cloud is the main focus for jBPM and represents a number of challenges for jBPM, related to how processes running on different services work with each other, as well as how signals and messages are routed and information collected and aggregated.
  • OptaPlanner
    • Horizontal scaling through Partitioned Search is the main focus for OptaPlanner.

Organisational Changes Done and Ongoing

  • The group is now focusing engineers for longer periods of time to specific parts of the product. This will bring about depth and maturity to those areas the engineers work on.
    • 6.x focus was on rapid breadth expansion of features. This gave time to market, which allowed the revenue growth we have, but comes with the pains we have now. The shift to depth will help address this.
  • Migrating to PatternFly
    • Allows engineering and UXD to be more fully engaged. Ensures our product is consistent with all other Red Hat products. Allow Business Central to leverage ongoing research from the PatternFly team.
  • UXD team has increased from 1 person to 2.5. With one person dedicated to providing HTML and CSS to developers.
  • Usability testing of primary workflows and new features with participants representing target Personas for the given workflows/features.
  • The field has become and continues to become more engaged, via the BPM and BRMS Community of Practice initiative, and in particular Justin Holmes and Jim Tyrell’s involvement.
    • They have attended multiple team meetings now, and provide constant feedback and guidance. This has been invaluable.
    • The field engages with UXD in a twice monthly meeting, which lead the effort in developing Personas. These design tools provide a structure to discussions about who our users are and what we need to build in order to make them happy. Today, these personas are all focused on the design/authoring experience, as this is currently the field’s biggest perceived gap in features and we want to focus our effort as much as possible.
    • Jim Tyrrell is proposing to lead a regular field UXD review, to review any changes going on in community, as they happen.  This effort should be scheduled to be done every 3 weeks or so.
    • We also should think about bringing in System Integrator Consulting Partners to help with designing our offering.
    • Engineering releases of the product are being consumed by SA’s and Consultants in order to do exploratory testing before GA.
  • More continuous sustaining effort: organisational and planning changes to support a continuous effort on improving the quality of the platform across the board.  Rather than continuous switching of developer’s focus or postponing bug fixing towards the end of the cycle, there should be a continuous effort to fix known issues (large and small) to improve the overall quality and experience.  Currently set at 20% on average across the team (where some developers are much more focused on sustaining than others).
  • The documentation team have agreed to move to the same tooling (asciidoc) and content source (git repo) as engineering. This should make it easier for them to stay in sync and add value.
    • For 6.x and prior the documentation team had been silo’d before and using a completely different tool chain and document source. They were unable to effectively track community docs, meaning that products docs were lagging behind, as well as lacking content and often wrong. This means the product docs devalued the product, compared to community. We would typically hear field people say they wish they could just show community docs to customers, rather than product docs - this is a situation that cannot be allowed to continue.
  • A subcontractor has been hired to assist with user guide and getting started documentation in a tutorial format, as well as installation and setup - to improve the onboarding experience. This work is currently focused on 6x, but it will be updated to 7.0 towards the end of the project life cycle.
  • QE are now working far more closely with engineering, adding tests upstream into community, ensuring they run earlier and regressions found faster. We have also been working to embed the QE team within engineering, so that there is a greater communication and thus understanding and collaboration between engineering and QE (which did not happen on 6x or earlier).
  • We have greatly improved our PR process. With gatekeepers and an insistence that all code now, backend and frontend is reviewed for tests. 6x has no community provided UI tests, this is no longer the case for 7x.
  • We have also improved our CI/CD situation.

6.3 Improvement Images

Execution Server



Data Modeller (Before and After)



jBPM Runtime Views (Before and After)










Share/Bookmark

Saturday, August 06, 2016

Page and Form builder for Bootstrap responsive grid views - a progress update

Eder has made great progress on the page and form builder,  which are built on top of Bootstrap responsive grid views.

We love the responsive aspects of Bootstrap grid views, but felt existing tools (such as Layoutit) exposed the construction of the grid too much to users. Further changing the structure of a page after it was made and populated is not easy. We wanted something that built the grid automatically and invisibly based on the dragging and positioning of components.

The latest results can be seen in this youtube video (best to watch full screen and select HD):
 https://www.youtube.com/watch?v=LZdU7cCUfrM

We have other videos, from earlier revisions of the tool, that you can also watch, as well as peripheral related tools.
Page Builder
Form Builder
Page/App Deployment
Page Permissions
User and Groups


Share/Bookmark

Friday, July 29, 2016

Security management in jBPM & Drools workbenches


The jBPM 7 release will include an integrated security management solution to allow administrator users to manage the application’s users, groups and permissions using an intuitive and friendly user interface. Once released, users will be able to configure who can access the different resources and features available in the workbench.

In that regards, a first implementation of the user & group management features was announced about 3 months ago (see the announcement here). This is the second article of this series and it describes what are permissions and how they extend the user and group management features in order to deliver a full security management solution. So before going further, let's introduce some concepts:

Basic concepts

Roles vs Groups

Users can be assigned with more than one role and/or group. It is always mandatory to assign at least one role to the user, otherwise he/she won’t be able to login.

Roles are defined at application server level and they are defined as <security-role> entries in the application’s web.xml descriptor. On the other hand, groups are a more flexible concept, since they can be defined at runtime. Both can be used together without any trouble. Groups are recommended as they are a more flexible than roles.

Permissions

A permission is basically something the user can do within the application. Usually, an action related to a specific resource. For instance:

  • View a perspective 
  • Save a project 
  • View a repository 
  • Delete a dashboard 

A permission can be granted or denied and it can be global or resource specific. For instance:

  • Global: “Create new perspectives” 
  • Specific: “View the home perspective” 

As you can see, a permission is a resource + action pair. In the concrete case of a perspective we have: read, update, delete and create as the actions available. That means that there are four possible permissions that could be granted for perspectives. 


Permissions do not necessarily need to be tied to a resource. Sometimes it is also neccessary to protect access to specific features, like for instance "generate a sales report". That means, permissions can be used not only to protect access to resources but also to custom features within the application.

Authorization policy

The set of permissions assigned to every role and/or group is called the authorization (or security) policy. Every application contains a single security policy which is used every time the system checks a permission.

The authorization policy file is initialized from a file called WEB-INF/classes/security-policy.properties under the application’s WAR structure.

NOTE: If no policy is defined then the authorization management features are disabled and the application behaves as if all the resources & features were granted by default. 

Here is an example of a security policy file:

# Role "admin"
role.admin.permission.perspective.read=true
role.admin.permission.perspective.read.Dashboard=false


# Role "user" 
role.user.permission.perspective.read=false 
role.user.permission.perspective.read.Home=true 
role.user.permission.perspective.read.Dashboard=true

Every entry defines a single permission which is assigned to a role/group. On application start up, the policy file is loaded and stored into memory.

Usage

The Security Management perspective is available under the Home section in the workbench's top menu bar.










The next screenshot shows how this new perspective looks:          

               Security Management Perspective             




















Compared to the previous version this new perspective integrates into a single UI the management of roles, groups & users as well as the edition of the permissions assigned to both roles & groups. In concrete:
  • List all the roles, groups and users available 
  • Create & delete users and groups 
  • Edit users, assign roles or groups, and change user properties
  • Edit both roles & groups security settings, which include: 
    • The home perspective a user will be directed to after login 
    • The permissions granted or denied to the different workbench resources and features available 

All of the above together provides a complete users and groups management subsystem as well as a permission configuration UI for protecting access to some of the workbench resources and features.

Role management

By selecting the Roles tab on the left sidebar, the application shows all the application roles:


























Unlike users and groups, roles can not be created nor deleted as they come from the application’s web.xml descriptor.

NOTE: User & group management features were described in detail in this previous article

After clicking on a role in the left sidebar, the role editor is opened on the screen’s right, which is exactly the same editor used for groups. 

Security settings editor

Security Settings 

The above editor is used to set several security settings regarding both roles and groups.



Home perspective

This is the perspective where the user is directed after login. This makes it possible to have different home pages for different users, since users can be assigned to different roles or groups.

Priority

It is used to determine what settings (home perspective, permissions, …​) have precedence for those users with more that one role or group assigned.

Without this setting, it wouldn’t be possible to determine what role/group should take precedence. For instance, an administrative role has higher priority than a non-administrative one. For users with both administrative and non-administrative roles granted, administrative privileges will always win, provided the administrative role’s priority is greater than the other.

Permissions

Currently, the workbench support the following permission categories.

  • Workbench: General workbench permissions, not tied to any specific resource type. 
  • Perspectives: If access to a perspective is denied then it will not be shown in any of application menus. Update, Delete and Create permissions change the behaviour of the perspective management plugin editor. 
  • Organizational Units: Sets who can Create, Update or Delete organizational units from the Organizational Unit section at the Administration perspective. Sets also what organizational units are visible in the Project Explorer at the Project Authoring perspective. 
  • Repositories: Sets who can Create, Update or Delete repositories from the Repositories section at the Administration perspective. Sets also what repositories are visible in the Project Explorer at the Project Authoring perspective. 
  • Projects: In the Project Authoring perspective, sets who can Create, Update, Delete or Build projects from the Project Editor screen as well as what projects are visible in the Project Explorer. 


For perspectives, organizational units, repositories and projects it is possible to define global permissions and add single instance exceptions afterwards. For instance, Read access can be granted to all the perspectives and deny access just to an individual perspective. This is called the grant all deny a few strategy.

The opposite, deny all grant a few strategy is also supported:

NOTE: In the example above, the Update and Delete permissions are disabled as it does not makes sense to define such permissions if the user is not even able to read perspectives.

Security Policy Storage

The security policy is stored under the workbench’s VFS. Most concrete, in a GIT repo called “security”. The ACL table is stored in a file called “security-policy.properties” under the “authz” directory. Next is an example of the entries this file contains:

role.admin.home=HomePerspective 
role.admin.priority=0 
role.admin.permission.perspective.read=true 
role.admin.permission.perspective.create=true 
role.admin.permission.perspective.delete=true 
role.admin.permission.perspective.update=true

Every time the ACL is modified from the security settings UI the changes are stored into the GIT repo. Initially, when the application is deployed for the first time there is no security policy stored in GIT. However, the application might need to set-up a default policy with the different access profiles for each of the application roles. 

In order to support default policies the system allows for declaring a security policy as part of the webapp’s content. This can be done just by placing a security-policy.properties file under the webapp’s resource classpath (the WEB-INF/classes directory inside the WAR archive is a valid one). On app start-up the following steps are executed:

  • Check if an active policy is already stored in GIT 
  • If not, then check if a policy has been defined under the webapp’s classpath 
  • If found, such policy is stored under GIT 

The above is an auto-deploy mechanism which is used in the workbench to set-up its default security policy.

One slight variation of the deployment process is the ability to split the “security-policy.properties” file into small pieces so that it is possible, for example, to define one file per role. The split files must start by the “security-module-” prefix, for instance: “security-module-admin.properties”. The deployment mechanism will read and deploy both the "security-policy.properties" and all the optional “security-module-?.properties” found on the classpath.

Notice, despite using the split approach, the “security-policy.properties” must always be present as it is used as a marker file by the security subsystem in order to locate the other policy files. This split mechanism allows for a better organization of the whole security policy.

Authorization API

Uberfire provides a complete API around permissions. The AuthorizationManager is the main interface for checking if permissions are granted to users.
@Inject
AuthorizationManager authzManager;

Perspective perpsective1;
User user;
...
boolean result = authzManager.authorize(perspective1, user);
Using the fluent API can also be expressed as:

authorizationManager.check(perspective1, user)
    .granted(() -> ...)
    .denied(() -> ...); 
The security check calls always use the permissions defined in the security policy.

For those interested in those APIs, an entire chapter can be found in the Uberfire's documentation.

Summary


The features described above will bring even more flexibility to the workbench. Users and groups can be created right from the workbench, new assets like perspectives or projects can be authored and, finally, specific permissions can be granted or denied for those assets.  
In the future, along the improvement of the authoring capabilities more permission types will be added. The ultimate goal is to deliver a zero/low code, very flexible and customizable tooling which allows to develop, build and deploy business applications in the cloud.



Share/Bookmark

Friday, June 17, 2016

UberFire Forms Builder for jBPM

The new UberFire form builder, that will be part of the jBPM 7.0 distribution, is making great progress. Underneath it is a Bootstrap grid system, but it addresses the issue of other Bootstrap layout builders that require the user to explicit add the grid layout first. Instead it dynamically alters the underlying grid as the user drags and places the components. The same builder code will be used for the latest DashBuilder dashboards too. There are more CSS improvements to come, but you can watch a video below (don't forget to turn on HD and watch it full screen), demonstrating nested form capabilities. Eventually you should be able to build and deploy these types of applications live on OpenShift. Good work Pere and Eder.



Share/Bookmark

Wednesday, June 08, 2016

Tutorial oriented user guides for Drools and jBPM

Community member Nicolas Heron, is creating tutorial oriented user guides for Drools and jBPM (Red Hat BRMS and BPMS). He’s focusing on the backends first, but it will eventually cover all the web tooling too, as well as installation and setup.

All this work is available from bitbucket, using asciidoc and gitbook (free for public projects), so I encourage you all to get involved and help Nicolas out by reviewing and providing feedback.

Click the Table of Contents, to get started
https://www.gitbook.com/book/nheron/droolsonboarding/details

Or just read the pdf:
https://www.gitbook.com/download/pdf/book/nheron/droolsonboarding

He’s just finished the Drools parts, and will moving onto other areas next.

Share/Bookmark