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

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)

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

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.

Google Summer of Code 2015: jBPM Mobile (MGTW)

I would like to share with all you guys the success story from the Google Summer of Code 2015 program in collaboration with the jBPM project. This year Rodrigo Garcete from (Ciudad del Este) Paraguay, who this year was in charge of upgrading the jBPM Mobile implementation created using MGWT. This application is a proof of concept showing a fully functional mobile client that can deploy KIE Jars to the execution runtime and then start processes and tasks.
I personally had a great experience interacting with Rodrigo during the program and I do believe that the jBPM community gained a very valuable community member. Here you can find Rodrigo’s fork containing the latest version of the code: https://github.com/rorogarcete/jbpm-console-ng/tree/mobile-integration-mgwt2.0
Keep reading to see what Rodrigo’s experience was and at the end a short video showing the app in action. 

Rodrigo about the GSoC Program

Hi everyone
I am very grateful to the GsoC2015 program, for giving me the opportunity to participate this year, it was my first experience working with an open source community.
Also, I want to thank the JBoss.org community, specifically my mentor Mauricio Salatino (salaboy), for the trust you have placed in me.
The project to which work closely with my mentor salaboy this summer called jBPM Console NG Mobile, as its name implies, the aim of the project was to  adapt the jBPM Console NG application and make it available in the mobile world.
The technology stack that we used consist of MGWT,  UberfireErrai and jBPM.
It is important to mention that the project was already running, but with an old version of MGWT (1.2) and it was also using old services from the jBPM infrastructure.
First thing I did was to migrate all components to use the latest MGWT  version (2.0).
Then I had to modify the API calls to backend services, these changed a lot in version 6.4.0-SNAPSHOT.
The work was not easy .. but it wasnt  impossible, whenever I hit some problems, salaboy help me, explaining, and answering any questions I had, guiding me towards the right path.
After the first evaluation (mid term), all the upgrade was completed and we started looking into adding some new features and improvements. Little by little I was learning the internals of project, everything started to make more sense, and I was getting faster in getting things up and running.
In the final stage, we added new features such as the Deployment screen, the ability to start a process with variables and also completing tasks with simple variables.
From my side, I can say that I learned a lot, the experience was very rewarding, and I would like to encourage  other students in the world to participate in this program. You will learn a lot by working on any open source project.
My  idea is to continue collaborating with the project, keep improving it, adding new features, etc., 
To close this post, I uploaded a video showing the features and improvements that we have had done with salaboy during the program.

Summing up

This was a great year for the program and in my opinion the end results were exactly what the program was designed for:
  • Students getting involved in open source communities
  • Contributing valuable code and research
  • The Student learned real life tools and technologies
Hopefully next year one or more students can participate in the program and contribute to jBPM and Drools!

Extending UberFire with AngularJS for the BPMS Domain

You can now see Alex’s talk, originally created by Kris, showing how to extend UberFire (UF) with AngularJS for the BPMS Domain, using Red Hat BPMS (productized version of jBPM). Everything is built live and in real time.
We are making great progress with our UF documentation, including tutorials. UF forms the core of our extensible UI architecture, it can be used standalone or to extend Drools or jBPM workbenches.
This work was made possible by our polyglot interoperability work for our UF framework, which we show in detail here:
The full UF docs are here, there has been a big update recently, as well as new tutorials. The empty sections will be filled in over next few days:
A recent generated PDF can be found here:

We should be close to a formal launch in a few weeks. The remaining items are:
-GWT 2.8 upgrade
-Move to new L&F theme
-Merge in Tool Windows.
-Move GWTExport to @JsType
-Mege in JS-UI

Uberfire, Drools and jBPM High Level Roadmap Slides and Videos from Red Hat Summit 2015

I did a short, 20 minute, high level presentation on some road map items for Uberfire, Drools and jBPM. I have provided the slides here, and it includes some early POC videos.

You can see the ongoing L&F work in the link below. The design is sleeker and more minimal. It now has a compact mode, that collapses the perspective switcher and sub-perspective menus –  see the “simple perspective”. Click the user name to switch modes. It automatically goes into compact mode when a panel is enlarged. 
user : admin
pass : admin
Mark

Red Hat JBoss BRMS and BPMS Rich Client Framework demonstrating Polyglot Integration with GWT/Errai/UberFire and AngularJS

Last week I published a blog highlighting a presentation I gave showing our rich client platform that has resulted from the work we have done within the BRMS and BPMS platforms, the productised versions of the Drools and jBPM projects. The presentation is all screenshots and videos, you can find the blog and the link to the slideshare here:
“Red Hat JBoss BRMS and BPMS Workbench and Rich Client Technology”

The presentation highlighted the wider scope of our UI efforts; demonstrating what we’ve done within the BRMS and BPMS platform and the flexibility and adaptability provided by our UI technology. It provides a great testimony for the power of GWTErrai and UberFire, the three technologies driving all of this. We can’t wait for the GWT 2.7 upgrade 🙂

As mentioned in the last blog the UberFire website is just a placeholder and there is no release yet. The plan is first to publish our 0.5 release, but that is more for our BRMS and BPMS platforms. We will then move it to GWT 2.7 and work towards a UF 1.0, which will be suitable for wider consumption.  With 1.0 we will add examples and documentation and work on making things more easily understood and consumable for end users. Of course there is nothing to stop the adventurous trying 0.5, the code is robust and already productized within BRMS and BPMS – we are always on irc to help, Freenode #uberfire.

That presentation itself built on the early video’s showing our new Apps framework:
The Drools and jBPM KIE Apps Framework

The above video already demonstrates our polyglot capabilities, building AngularJS components and using them within the UF environments. It also shows of our spiffy new JSFiddle inspired RAD environment.

I’d now like to share with you the work we’ve done on the other side of polyglot development – this time using GWT and UF from within AngularJS. It was important we allow for an AngularJS first approach, that worked with the tool chain that AngularJS people are familiar with. By AngularJS first, I mean that AngularJS is the outer most container. Where as in the above video UF is already running and is the outer container in which individual AngularJS components can be used.

Before I detail the work we’ve done it’s first best to cover the concepts of Screens and Perspectives, our two main components that provide our polyglot interoprability – there are others, but this is enough to understand the videos and examples that come next. A Screen is our simplest component, it is a DIV plus optional life cycle callbacks. A Perspective is also a DIV, but it contains a composition of 1..n Screen with different possible layout managers and persistence of the layout.

Screen

  • CDI discovery, or programmatically registered.
  • DIV on a page.
  • Life cycle callbacks.
    • OnStart, OnClose, OnFocus, OnLostFocus, OnMayClose, OnReveal.
  • Decoupling via Errai Bus.
    • Components do not invoke each other, all communication handled by a bus.
  • Editors extend screens, are associated with resource types and provide the additional life cycles
    • onSave, isDirty.

Perspective

  • CDI discovery, or programmatically registered.
  • Composition of 1..n Screens, but is itself a DIV.
  • Supports pluggable window management of Screens.
    • North, East, South West (NESW).
      • Drag and Drop docking capabilities.
    • Bootstrap Grid Views.
      • Separate design time and runtime.
    • Templates (ErraiUI or AngularJS).
      • Absolute control of Perspective content and layout.
  • Supports persistence of Perspective layout, should the user re-design it.
    • Only applicable to NESW and Bootstrap Grid views.

A picture is worth a thousands words, so here is a screenshot of the Perspective Builder in action. Here it uses the Bootstrap Grid View layout manager. Within each grid cell is a Screen. The Perspective is saved and then available from within the application. If the NESW layout manager was used there is no separate design time, and all dragging is done in-place and persistence happens in the background after each change. Although it’s not shown in the screenshot below we also support  both list (drop list) and tab stacks for Screens.

Now back to what an AngularJS first approach means. 6 different points were identified as necessary to demonstrate that this is possible.

  1. UF Screens and Perspectives should be available seamlessly as AngularJS Directives.
  2. Bower packaging for a pre-compiled UFJS. UFJS is the pre-compile client only version of UF.
  3. UFJS can work standalone, file:// for example. UFJS can optionally work with an UF war backend, allowing persistence of perspectives and other optional places that UFJS might need to save state as well as access to our full range of provided services, like identity management.
  4. Support live refresh during development.
  5. Nested Controllers.
  6. Persistence and routing.
  7. Work with tools such as Yeoman, Grunt and Karma.

Eder has produced a number of examples, that you can run yourself. These demonstrate all of the points have been solved. You can find the code here, along with the README to get you started. We did not provide video’s for point 7, as I believe the video’s for points 1 to 6 show that this would not be a problem.

Eder has also created several short videos running the examples, for each of the use cases, and put them into a YouTube playlist. He has added text and callouts to make it clear what’s going on:
AngularJS + UF PlayList

  1. Overview explaining what each video demonstrates (33s).
  2. AngularJS App + UFJS, client only, distribution using Bower. (2m30s).
    • Install and play with UFJS through Bower
    • Create a Native AngularJS App
    • Integrate this app with UFJS
      • Show UF Screen Directives
      • Show UF Perspective Directives
  3. AngularJS App + UFJS client and UF Server.
    • 1 of 2 (3m58s).
      • Download UF War
      • Install and run on EAP
      • Download and run our Angular demo on Apache
      • Show AngularJS Routes + UF Integration
    • 2 of 2 (4m06s).
      • Use UF to create Dynamic Screens and Perspectives
      • Encapsulate an AngularJS template in a UF Screen
      • Show an AngularJS App (inside a UF screen) nested in a parent controller.
        • Demonstrated multiple levels of controller nesting.
  4. KIE UF Workbench RAD environment with AngularJS component.
  5. Uberfire Editor working seamlessly as an Eclipse editor.

For completeness the original video’s showing the JSFiddle inspired RAD environment, which demonstrates an UF first polyglot environment, have been added to the playlist. See point 4. above

Finally just to show of, and because we can, we added a bonus video demonstrating a UF editor component running seamlessly in Eclipse. This demonstrates the power of our component model – which has been designed to allow our components to work standalone in any environment. We use Errai to intercept all the RPC calls and bridge them to Eclipse. Because the virtual file system our editors use, like other services, is decoupled and abstracted we can adapt it to the Eclipse File io. For the end user the result is a seamless editor, that appears native. This allows the development of components that can work on the web and in Eclipse, or even IntelliJ. We’ll work on making this example public at a later date.

Here are some screenshots taken from the video’s

(click image to enlarge)
(click image to enlarge)
(click image to enlarge)
(click image to enlarge)
(click image to enlarge)
(click image to enlarge)
(click image to enlarge)


(click image to enlarge)

Finally to all those that said it couldn’t be done!!!!

Red Hat JBoss BRMS and BPMS Workbench and Rich Client Technology

Last week I did a blog highlighting the recent R&D we are doing to make our web platform easily extensible and allow the development of a self service apps platform. The blog had two video links showing progress.

Today I gave a presentation that highlighted the wider scope of our UI efforts; demonstrating what we’ve done within the BRMS and BPMS platform and the flexibility and adaptability provided by our UI technology. It provides a great testimony for the power of GWTErrai and UberFire, the three technologies driving all of this. We can’t wait for the GWT 2.7 upgrade 🙂

As mentioned in the last blog the UberFire website is just a placeholder and there is no release yet, we’ll be working on that over xmas, along with documention to make things more easily understandable and consumerable for end users.

The presentation is now live up on Slideshare and I’ve taken time to embed all the video’s within it.
http://www.slideshare.net/MarkProctor/red-hat-jboss-brms-and-bpms-workbench-as-a-platform

The presentation is mostly self explanatory screenshots with headers with videos scattered throughout – many of which are previous video’s you might have seen before. It provides a very good over, using scatter gun approach, of what we have done, what we are doing and where we are going. Two of the videos around the extensible workbench and the technical web ide have audio commentary.

It starts by showing the existing BRMS and BPMS stuff before moving onto the new extensibility efforts. Finally it covers a new demo we’ve done with the workbench reskinned for a more technical audience. It also shows ACE integration for java and xml editing, as well as real time provisioning and running of Spring Pet Clinic application within the workbench.

Kie Uberfire Social Activities

The Uberfire Framework, has a new extension: Kie Uberfire Social Activities. In this initial version this Uberfire extension will provided an extensible architecture to capture, handle, and present (in a timeline style) configurable types of social events.

  • Basic Architecture

An event is any type of “CDI Event” and will be handled by their respective adapter. The adapter is a CDI Managed Bean, which implements SocialAdapter interface. The main responsibility of the adapter is to translate from a CDI event to a Social Event. This social event will be captured and persisted by Kie Uberfire Social Activities in their respectives timelines (basically user and type timeline). 

That is the basic architecture and workflow of this tech:
Basic Architecture
  • Timelines

There is many ways of interact and display a timeline. This session will briefly describe each one of them.


a-) Atom URL

Social Activities provides a custom URL for each event type. This url is accessible by: http://project/social/TYPE_NAME.



The users timeline works on the same way, being accessible by http://project/social-user/USER_NAME .

Another cool stuff is that an adapter can provide his pluggable url-filters. Implementing the method getTimelineFilters from SocialAdapter interface, he can do anything that he want with his timeline. This filters is accessible by a query parameter, i.e. http://project/social/TYPE_NAME?max-results=1 .


B-) Basic Widgets

Social Activities also includes some basic (extendable) widgets. There is two type of timelines widgets: simple and regular widgets.

Simple Widget
Regular Widget
The “>” symbol on ‘Simple Widget’ is a pagination component. You can configure it by an easy API. With an object SocialPaged( 2 ) you creates a pagination with 2 items size. This object helps you to customize your widgets using the methods canIGoBackward() and canIGoForward() to display icons, and  forward() and backward() to set the navigation direction.
The Social Activities component has an initial support for avatar. In case you provide an user e-mail for the API, the gravatar image will be displayed in this widgets.


C-) Drools Query API

Another way to interact with a timeline is throught the Social Timeline Drools Query API. This API executes one or more DRLs in a Timeline in all cached events. It’s a great way to merge different types of timelines.

  • Followers/Following Social Users
A user can follow another social user.  When a user generates a social event, this event is replicated in all timelines of his followers. Social also provides a basic widget to follow another user, show all social users and display a user following list.


It is important to mention that the current implementation lists socials users through  a “small hack”. We search the uberfire default git repository for branch names (each uberfire user has his own branch),  and extract the list of social users.

This hack is needed as we don’t have direct access of the user base (due the container based auth).



  • Persistence Architecture
The persistence architecture of Social Activities is build on two concepts: Local Cache and File Persistence. The local cache is a in memory cache that holds all recent social events. These events are kept only in this cache until the max events threshold is reached. The size of this threshold is configured by a system property org.uberfire.social.threshold (default value 100).

When the threshold is reached, the social persist the current cache into the file system (system.git repository – social branch). Inside this branch there is a social-files directory and this structure:


  • userNames: file that contains all social users name
  • each user has his own file (with his name), that contains a Json with user data.
  • a directory for each social type event .
  • a directory “USER_TIMELINE” that contains specific user timelines



Each directory keeps a file “LAST_FILE_INDEX” that point for the most recent timeline file.




Inside each file, there is a persisted list of Social Events in JSON format:


({“timestamp”:”Jul16,2014,5:04:13PM”,”socialUser”:{“name”:”stress1″,”followersName”:[],”followingName”:[]},”type”:”FOLLOW_USER”,”adicionalInfo”:[“follow stress2”]})
Separating each JSONs there is a HEX and the size in bytes of the JSON. The file is read by social in reverse order.

The METADATA file current hold only the number of social events on that file (used for pagination support).

It is important to mention that this whole structure is transparent to the widgets and pagination. All the file structure and respective cache are MERGED to compose a timeline.
  • Clustering
In case that your application is using Uberfire in a cluster environment, Kie Social Activities also supports distributed persistence. His cluster sync is build on top of UberfireCluster support (Apache Zookeeper and Apache Helix).

Each node broadcast social events to the cluster via a cluster message  SocialClusterMessage.NEW_EVENT containing Social Event data. With this message, all the nodes receive the event and can store it on their own local cache. In that point all nodes caches are consistent.

When a cache from a node reaches the threshold, it lock the filesystem to persist his cache on filesystem. Then the node sends a SOCIAL_FILE_SYSTEM_PERSISTENCE message to the cluster notifying all the nodes that the cache is persisted on filesystem.

If during this persistence process, any node receives a new event, this stale event is merged during this sync.

  • Stress Test and Performance

In my github account, there is an example Stress Test class used to test the performance of this project.  This class isn’t imported to our official repository.

The results of that test, find out that Social Actitivies can write ~1000 events per second in my personal laptop (Mb Pro,  Intel Core i5 2.4 GHZ, 8Gb 1600MHz DDR3, SSD). In a single instance enviroment, it writes 10k events in 7s, writed 100k in 48s, and 500k events in 512s.

  • Demo

A sample project of this feature can be found at my GitHub account or you can just download and install the war of this demo. Please take a note that this repository moved from my account to our official uberfire extensions repository.


  • Roadmap

This is an early version of Kie Uberfire Social Activities. In the nexts versions we plan to provide:

  • A “Notification Center” tool, inspired by OSX notification tool; (far term)
  • Integrate this project with dashbuilder KPI’s;(far term)
  • A purge tool, able to move old events from filesystem to another persistence store; (short term)
  • In this version, we only provide basic widgets. We need to create a way to allow to use customized templates on this widgets.(near term)
  • A dashboard to group multiple social widgets.(near term)


If you want start contributing to Open Source, this is a nice opportunity. Fell free to contact me!

KIE-WB / JBPM CONSOLE NG – CONFIGURATIONS

Hi all, this is a follow up post from my previous entry about how to use the jBPM Console. The main idea of this post is to describe some of the most common configurations that you will required to do to the jBPM Console NG in order to use it in your own company. But before going into technical details we will be covering the differences between the KIE Workbench (KIE-WB) and the jBPM Console NG itself. Both applications require similar configurations and its good to understand when to pick one or the other. We will be covering these topics in the free workshops in London. 

Introduction

If you look at the project source code and documentation, you will notice that there are several projects that are being created to provide a complete set of tools for Drools and jBPM. Because of the modular approach that we have adopted for building the tools, you can basically choose between different distributions depending on your needs. The jBPM Console NG can be considered as a distribution of a set of packaged related with BPM only. The KIE Workbench (KIE-WB) is the full distribution, that contains all the components that we are creating, so inside it you will find all the BPM and Rules modules. If more modules are added to the platform, the KIE-WB will contain them.
Sometime ago Michael Anstis posted an article in blog.athico.com to explain this transition: http://blog.athico.com/2013/06/goodbye-guvnor-hello-drools-workbench.html This blog post was targeted to Guvnor users, so they can understand the transition between Drools 5.5 and Drools 6. So the intention behind the following  section is to explain the same but for jBPM users, trying to unify all the concepts together.

Projects Distributions

The previous mentioned blog explains most of the components that we are creating now, but the following image add some details on the BPM side:
Project Distributions
Project Distributions
Some quick notes about this image:
  • Uberfire and Guvnor are both frameworks, not distributions.
  • We are keeping the name Guvnor for what it was originally intended. Guvnor is a framework to define all the internal project automation and organization. Guvnor is the internal framework that we will use to provide a smart layer to define how projects and all the knowledge assets will be managed and maintained.
  • KIE-WB-Common is not a distribution by itself but it could, because it contains all the shared bits between all the distributions.
  • Drools Workbench only contains authoring tools related with Rules, notice that in the same way as Guvnor it doesn’t provide a runtime for your rules. This could be added in the future but in 6.0 is not.
  • The jBPM Console NG replaced the old jBPM GWT console
  • The difference between names (Drools Workbench and jBPM Console NG) is due the fact that the jBPM Console NG does provide all the runtime mechanisms to actually run your Business Processes and all the assets associated with them.
  • Notice that the jBPM Console NG uses some of the Drools-WB modules and also integrates with the jBPM Designer and the Form Modeller.
  • KIE Workbench contains all the components inside the platform and also add the Remote Services to interact with processes.
  • Notice that the Remote Service in 6.x are only for the BPM side, that means that we can also provide the jBPM Console NG distribution with those services, it is not a priority right now but it can be done if someone thinks that it’s a good idea.
  • You can find all these projects under the droolsjbpm organization in github: http://github.com/droolsjbpm
  • All the configurations and blogs related to the jBPM Console NG also applies for the KIE Workbench
  • The jBPM 6.0 installer will come with KIE Workbench bundled and because of this most of my posts will be showing screenshots of KIE-WB instead of the jBPM Console NG.

Configurations & Deployment

If you take a look at the source code repositories in Github, you will find that the jBPM Console NG, Drools Workbench and Kie Workbench contains a project called *-distribution-wars. These projects are in charge of generating the applications to be distributed for different Servlet Containers and Application Servers. For now we are providing bundles for Tomcat 7, JBoss AS 7, and JBoss EAP 6.1. (If you are a developer, you can also run these applications using the GWT Hosted Mode, which starts up a Jetty server and automatically deploys the application so it can be easily debugged.)
Here we will see how to deploy and configure the application to work in JBoss AS 7. Obviously you don’t need to do so if the jBPM Installer does that for you. But is always good to know what is going on under the hood, just in case that you prefer to manually install the applications.
There are three points to consider when we configure the application for deployment:
  1. Users/Roles/Groups
  2. Domain Specific (Custom) Connectors
  3. JBoss AS 7 Profile
For the sake of simplicity, I’ve borrowed a JBoss AS 7 configured by Maciej and deployed the KIE Workbench latest snapshot, so you can download it and we can review it’s configurations from there. You can download it from here:

Users/Roles/Groups

By default the KIE-Workbench uses the JBoss AS configured users to work. In order to create a new user we need to use the ./add-user.sh script located inside the /bin/ directory. Using this script we will be creating all the users required by our business processes, and for that reason we will be also assigning them groups and roles.
Adding a New User
Adding a New User
As you can see in the previous image, using the ./add-user.sh script you can create a new user for the application (first two options: option B, and empty realm). Note that you need to use different strings for the user name and for the password. For now you can create users with role admin, so it will have access to all the screens of the tool and then you can write the groups where the user belongs. In this case the user salaboy has Role: admin and he belongs to the IT group. There are some restricted words that cannot be used as group names. For now avoid using “analyst”, “admin”, “developer” for group names.

Domain Specific (Custom) Tasks / Connectors

Domain Specific Connectors are the way to integrate your business processes with external services that can be inside or outside your company. These connectors are considered technical assets and because of that needs to be handled by technical users. Most of the time it is recommended to not change/modify the connectors when the application is running, and for that reason these connectors needs to be provided for the application to use in runtime.
Three things are required to use a Custom Connector:
  1. Provide an implementation of the WorkItemHandler interface, which is the one that will be executed in runtime.
  2. Bind the implementation to a Service Task name
  3. Create the WorkItem Descriptor inside the tool
In order to provide these three configuration points you can take a look at the Customer Relationship example in the jbpm-playground repository.
Customer Relationships Example
Customer Relationships Example
The main idea here is to have a separate project that contains the workItems implementations, for example: CreateCustomerWorkItemHandler , you will need to compile this project with maven and install the produced jar file inside the KIE-WB application. In order to do that you just copy the customer-services-workitems-1.0-SNAPSHOT.jar into the WEB-INF/lib directory of the kie-wb.war app. On this example the workItemHandler implementations interacts with a public web service that you can check here , so you will require internet connection in order to try this example.
Notice also that inside the customer-relationship project there are some high level mappings of the Domain Specific Tasks that can be used inside our Customer Relationship Project -> WorkItemDefinitions.wid. This configuration will basically add you Service Tasks inside the Process Designer Palette:
Domain Specific Service Tasks
Domain Specific Service Tasks
The last step is to bind the High Level mapping to their implementation for this environment. You can do that by adding new entries into the WEB-INF/classes/META-INF/CustomWorkItemHandlers.conf  file, for this example we just need to add the following entries:
“CreateCustomer”: new org.jbpm.customer.services.CreateCustomerWorkItemHandler(),
“AddCustomerComment”: new org.jbpm.customer.services.AddCustomerCommentsWorkItemHandler(),
“ManagersReport”: new org.jbpm.customer.services.ManagersReportWorkItemHandler(),

Note about the JBoss AS 7 Profile

In order to run the KIE Workbench you need to run it with full JBoss AS7 profile, so if you are installing it using a fresh JBoss AS7 please don’t forget to point to the full project when you use the ./standalone.sh script:
./standalone.sh –server-config=standalone-full.xml

Download

You can download a pre installed version of KIE-WB where you can clone the jbpm-playground repository which contains the example (Authoring -> Administration and then Clone a Repository using the jbpm-playground url: https://github.com/droolsjbpm/jbpm-playground).
This pre installed version contains the workItemHandlers already installed and configured for the Customer Relationship example, but you can obviously make some changes and upgrade them if it’s needed.
It also has two users created:
User/Password: jbpm/jbpm6 (Groups: IT, HR, Accounting, etc)
User/Password: salaboy/salaboy123 (Groups: IT)
Please feel to try it out and let me know if it works for you.
There are some few seats available for the Drools & jBPM Free Workshop Tomorrow and on Thursday. If you are planning to assist please write me an email to salaboy (at) redhat (dot) com. For more details about it look here.