środa, 25 stycznia 2017

In one of the recent posts I presented KIE Server Router to allow to scale to more instances of KIE Servers where there is one smart router that can:

find the right servers to deal with requests

aggregate data from various servers

remove burden from clients to know the location of KIE Servers

and more...

With all that it's time to look into using KIE Server Router with workbench to utilize its UI capabilities to work with processes and tasks. Overall idea is to use the router as any other KIE Server so that means:

router will connect to workbench controller

notifies when started

notifies when shutting down

server template is required for the router - if none created before it will self-register itself

all containers deployed behind the router must be in router's server template so all of them can be used in terms of forms, images and data

Though router acts like a KIE Server from workbench point of view it does not allow to perform KIE Server management operations like creating containers or upgrading them etc. These should be still managed in the same way as without router.

Workbench will see the router as regular KIE Server and thus will make the exact same features available for it, like starting processes, working with user tasks etc. So let's imagine following scenario:

KIE servers are running in unmanaged mode with predefined versions of kjars to be deployed, one per KIE Server. These KIE Servers are then connected to router. In turn router is configured to connect to controller once started. In workbench there is a single KIE Server Router server template configured with both kjars (containers) configured and started.

Here you can see how it works

As can be seen in the screen cast, all normal operations are available to the users. Starting processes that are actually executed on different servers (that in real scenario will be on completely different machines) without any hassle. Same goes for retrieving various information like active instances, showing process instance image, work with tasks. All goes via router that decides to what server the request should be forwarded.

Moreover, it aggregates the results for queries e.g. process instance, process definition or tasks so there is no need to go over individual servers to figure out what instances are running and to get the details of them. Even dashboard does work via router, though it still has some issues as it expects to have a single row instead of aggregate of all servers so this is still something to address...

The only limitation at the moment is sorting capabilities of the aggregated results. In general router is capable of doing aggregate sort but the problem here is that the data returned when used through workbench are in raw format and thus router has not information what field is what and thus sorting is in the way that individual servers returned. Though it does support paging in normal fashion.

this is needed when running in memory data base as upon connection of the router to controller, it will push queries to the connected KIE Server to register so workbench queries could work as expected. Since the router is connecting to controller it will the forward these queries to all connected kie servers to register these queries in there. As they are running with in memory db these queries are constantly dropped and thus must be registered again. With real use case these are going to be registered once and won't be really relevant to have the sequence as above.

... use single actor

So if the task is assigned to single actor then when task is created it:

will be assigned directly to that actor - actual owner will be that actor

will be moved to Reserved state

no one else will be able to work on that task anymore - as it is in reserved state

So that seems like a nice approach, but in reality it will constrain users too much because to change the actor you have to change the process definition. And in many cases there is a need for more users to be able to deal with certain tasks instead of just a single person.

... use multiple actors

To solve that you can use approach with multiple actors (as this is supported to specify set of users as comma separated list). So what will happen then?

task will not be assigned to any individual as actual owner as there is no way to tell which one should be selected

task will be available to all actors defined in process definition on that task

task will be moved to Ready state

user to be able to work on task will have to explicitly claim the task

So a bit of improvement but still relies heavily on individuals and manual claim process that can sometimes lead to inefficiency due to delays.

... use groups

naturally to go around the problem with individuals being assigned (as they come and go) better option would be to assign tasks to groups. When task is assigned to group it:

will not be assigned to any individuals as by nature group contains many members

will be available to all actors that belong to defined group(s) - it's resolved on the time of the query as task is assigned to group so changes to the group do not have to be synced with tasks

will be moved to Ready state

user to be able to work on task will have to explicitly claim the task

so this improves situation a bit but still have some issues ... manual claim and potential delays to pick tasks from the group "queue".

... use pluggable task assignment

for this exact purpose, jBPM 7 comes with pluggable task assignment support to let you (or to be precise system) to distribute tasks according to various criteria. The criteria here are what makes the difference, as different business domains will have different ways of assigning tasks. Even different departments within the same organization will differ in that regard.

So what is the task assignment here? In general this is the logic that will be used to find the best suitable candidate to take the task automatically. To carry on with the example, there is a process that is assigned to a singe group - HR.

Task assignment strategy will then be invoked when a task is created and strategy can find the best actual owner for it. If it does such a task:

will be assigned to selected actor

will be moved to Reserved state

no one else will be able to work on this task any more

but if the strategy won't be able to find any suitable candidate (should be rather rare case but still can happen) the task will fallback to default behavior as described above.

Assignment strategy can be based on almost anything that is valuable to the business to make a fact based and efficient decision. That means some strategies can be based on:

potential owners (as in this example)

task data (input variables)

task properties (name, description, project, etc)

time when task was created

external data not related to task itself

So that gives all the options to the users to build their own strategies based on the specific needs. But before going to the implementation (next article) let's look at...

... what comes out of the box

jBPM 7 comes with two assignment strategies out of the box

Potential owner busyness strategy - default

Business rules strategy

Potential owner busyness strategy

this strategy simply makes sure that least loaded actors from potential owner list will be selected. Strategy will work on both types of potential owners - users and groups but to be able to effectively find best match it needs to resolve groups to users. Resolve is done by UserInfo configured in the environment - please make sure you have one properly configured otherwise strategy will not work in most efficient way.

Name of the strategy to be used to activate:

PotentialOwnerBusyness

Business rules strategy

This strategy promotes the use of business rules as a way of selecting actual owners. Strategy does not come with any predefined rules but instead expect to be given the KJAR coordinates of the project to be used to perform assignment. The most important factor here is that any rule can be used and it supports dynamic updates of the rules as well by making use of KIE Scanner that can incrementally update knowledge base upon new version of the KJAR being discovered.

Name of the strategy to be used to activate:

BusinessRule

Configuration parameters supported:

org.jbpm.task.assignment.rules.releaseId

required parameter that points the GAV of the KJAR

org.jbpm.task.assignment.rules.scan

optional - pool interval for the scanner in case it should be enabled - same as KIE Scanner expects it - in milliseconds

org.jbpm.task.assignment.rules.query

optional - drools query to be used to retrieve results - if not given all Assignment objects are taken from working memory and first is selected if not empty

... not only on task creation

task assignment is invoked not only on task creation (though that will be the most common case) but it will also get involved when:

task is released - here the actual owner who releases the task is excluded from the assignment

task nomination

task reassignment (deadlines)

task forwarding

with that it should provide quite capable self assignment behavior when the strategy is tailored for given needs.

... how to use it

Task assignment is disabled by default and can be easily enabled by specifying system property:

-Dorg.jbpm.task.assignment.enabled=true

then selecting strategy is done by another system property:

-Dorg.jbpm.task.assignment.strategy=NAME OF THE STRATEGY

if org.jbpm.task.assignment.strategy is not given PotentialOwnerBusyness strategy is used by default.

To be able to properly resolve group members users need to select user info implementation by system property:

-Dorg.jbpm.ht.userinfo=db

this one will select data base as source of group members and thus will have to be configured additionally. KIE Server comes with example configuration file in

kie-server.war/WEB-INF/classses/jbpm.user.info.properties

where db queries should be specified how to find users of given group.

Optionally you can create userinfo.properties file in the same directory and specify the group to users mapping in following format:

#groups setup

HR=hr@domain.com:en-UK:HR:[maciek,engUser,john]

PM=pm@domain.com:en-UK:PM:[maciek]

this is only for test purposes. For real environment use either data base or ldap based UserInfo implementation.

That concludes the introduction of task assignment strategies that are completely pluggable. Next article will illustrate how to implement custom strategy.

wtorek, 10 stycznia 2017

In previous article I talked about Traditional vs Modern BPM and now I'd like to show what does that mean - a modern BPM in action. For this I used upcoming feature of jBPM 7 that provides case management capabilities that were already introduced in Case management series that can be found here.

So this is another iteration around Order IT hardware case that allows employees to place requests for new IT hardware. There are three roles involved in this case:

owner - the employee who placed the order

manager - direct manager of the employee - the owner

supplier - available suppliers in the system

It's quite simple case definition that looks like this:

As presented above this process does not look much like a regular process - it's case definition so it's completely dynamic process (so called ad hoc). This means new activities can be added to it at any time or different fragments can be triggered as many times as needed.

What is worth notice here is Milestone nodes:

Order placed

Order shipped

Delivered to customer

Hardware spec ready

Manager decision

Milestones are completed based on condition, in this case all conditions evaluate given case instance data - case file. So as soon as data is given the milestone is achieved. Milestones can be triggered manually by signal or can be auto started when the case instance starts.

Here you can watch this application in action

and now we dive into details of how this application was composed...

So application is built with following components:

WildFly Swarm as runtime environment

KIE Server as backend

PatternFly with AngularJS as front end

This application is fully featured and runnable but should be seen as showcase/PoC that aims at showing intension with modern BPM and case applications. No more centralized deployments to serve all but instead have a tailored apps to do the one thing but do it right.

So once you logon you will see the home screen - the purpose of this system - to order new hardware

Here you can see all available suppliers that can deliver IT hardware:

Apple

Lenovo

Dell

Others (for anything that does not match above)

Here the suppliers are considered groups in the BPM world - meaning tasks assigned to selected supplier will match the selection. That will be then assigned to "Prepare hardware spec" task in the case definition.

Once you fill in the form and place an order you'll be given with order receipt

At any given time you can take a look at orders

My orders - those that you (as logged in user) placed

All orders - lists all orders currently opened

From the list you can go into details of particular order to see its status and more

Order details page is build from three parts:

on left hand side you can see the progress of your order - matching all milestones in the case with their status - currently no progress at all :(

central part is for case details

hardware specification document that supplier is expected to deliver

comments section to discuss and comment on the order

My tasks, any tasks that are assigned to you (as logged in user) in scope of this order

right hand side is the people and groups involved in your order - so that can give you a quick link in case you'd like to get in touch

So the first thing to be done here is up to selected supplier - (s)he should provide a document with hardware specification for the placed order

Here is a list of tasks assigned to supplier (as logged in user) that (s)he can take and directly work on by providing hardware specification document

Once document is uploaded, owner of the order can take a look at it via oder details page

Now you can observe some progress on the order - hardware spec was delivered and is available to download in the central section. On the right side you can see the Hardware specification milestone is checked (and green) so it was completed successfully.

Next it's up to manager to look at the order and approve it or reject it

In case manager decided to reject it, the decision and reason will be available in the order details page.

What is important to note here is, since manager rejected the order there is a new option available in the order to request the approval again. This is only available when order was rejected and can be used to change manager's decision. This in turn will create dynamic task for the manager (as it does not exist in the case definition) and thus allow manager to change his/her decision.

Entire progress of the order is always available in the order details page when all order data base be easily found.

Once manager approved the order, the order is again handed over to supplier to place physical order for shipment.
Then on order page you'll find additional action to mark when the order was shipped and later when it was delivered which is usually done by the order owner.

Last but not least is customer satisfaction survey that is assigned to owner for evaluation.

Owner of the order can then provide his/her feedback over the survey that will be kept in order data (case file).

Order is not closed until it's explicitly closed from order details page... usually by the owner when (s)he feels it's completed, otherwise more activities can be still added to the order.

Conclusion

The idea for this article is how you can leverage modern BPM to build quickly business systems that bring value and still take advantage of the BPM just in slightly different way then traditional. This application was build in less than 4 days ... so any reasonable size application to demo capabilities should be doable in less than a week. That's the true power of the modern BPM!

Feel like to try it yourself? Nothing easier then just do it. Just follow instructions and off you go!!!

In this article I'd like to touch a bit BPM in general and how it evolves to mainly ask the question - should I still care about BPM? Hmmm ... let's look into it then...

Proper business context put on top of generic process engine (or case management) is complete game changing activity. Users don't see this as a huge "server" installation but instead see what they usually work with - their domain. By domain I mean naming convention, information entities etc instead of generic BPM terms such as:

process

process instance

process variables

Instead of trying to make business people (from different domains, sometimes completely unrelated) to unify on the terminology and being process engine/bpm oriented, modern BPM solution should aim at making themselves being part of the ecosystem rather then be outsider. This does make a lot of sense when you look at it from end user point of view. In many cases end users would like:

to feel comfortable in the system that supports my daily work

to understand the terminology used in the system - non IT language preferred

to be able to extend its features and capabilities easily

possible to federate with other systems - aggregated UI approach

these are just few points and I am sure many business users could come up with quite a long list in this area.

Nevertheless, what's is the point here? Main one is to not look at BPM as traditional setup anymore but use it to innovate your domain by utilizing the knowledge that is present in each and every coworker in your company. The assets that modern BPM should promote is collectively gathered knowledge of your domain and the way you work to make profit.

I used term 'traditional BPM', what I mean by that is rather big and complex installation of BPM Platforms of any kind. A centralized servers that are meant to do all the heavy lifting for entire company without much of an effort ... at least that what slides say, right? :) Traditional BPM that aimed at solving all problems did not really paid off as it was expected mainly due to complexity it brought. It had few major drawbacks identified throughout number of years:

difficult to learn - usually a big product suites

difficult to maintain - complexity grow with deployments on the platform where upgrades or maintenance activities become harder and harder

difficult to scale - usually because of chosen centralized architecture (which btw was meant to solve the problems with maintainability)

generated components had their limitation - first thing that end users end up with was the UI components were either tightly coupled to the product or not powerful enough

Traditional BPM

Due to those BPM initiatives in organizations were usually expensive and time consuming activities. Moreover, many of them failed to deliver because of the outweighs between expectations/promises and the actual capabilities of the product/solution.

BPM projects often made a promise to bridge the gap between IT and business but in the end (one way or another) IT took control and drifted away of business making the delivered solution not so business focused any more. Some of these were caused by the limitation mentioned above but some were because the chosen architecture was simply not suitable for the needs of the business domain.

I keep saying "business domain" or "business context" and I really mean it - this is the most important aspect of the work when dealing with business (ops ... I did it again) knowledge. The key to the success is the knowledge to be used in IT solution and not vice versa (IT solution altering the way business is done to fit the product/technology).

So if the traditional BPM does not meet its promises, should I still care about BPM at all?

The short answer is yes, though look for alternatives on how to use BPM - as I call it modern BPM. The slightly longer answer is - traditional BPM did have a success stories as well so it does provide a solid ground for next generation of BPM solutions. It did give proper and stable specifications:

BPMN2

DMN

CMMN

to just name the few. So conceptually it is still valid and useful, what is more important is how it is actually realized. The modern BPM is about scoping your solutions to the domain, in other words proper partitioning of your domain will help you solve or overcome some of the issues exposed by traditional BPM.

First and foremost principles of the modern BPM is

avoid centralization

Don't attempt to make huge "farm like" installation that should deal with all your processes within the organization (regardless of its size) - sooner or later it will grow ... Keep it small to the minimum to cover given domain or part of the domain. If your domain is Human Resources think about partitioning it to smaller pieces:

employee catalogue

payroll

absence

contract management

benefits and development plan

etc

with that separation you can easily

evolve in isolation

maintain separately - upgrades, deployments etc

scale individual parts

federate systems to build portal like entry points for end users

use different technology stack/products for individual parts

always put things in business context

keep in mind why things are done the way they are - that's because of business context. If you understand your domain make sure it is captured as knowledge and then used within the IT solutions - this is where BPM practices come in handy. That's the whole point of having BPM in your toolbox - once the business knowledge (business processes, business rules, information entities) is collected it can be directly used for execution.

make tailored UI

Make use of any tools/frameworks/etc you have available to build state of the art tailored UI for the domain. Don't expect generic platforms to generate complete and comprehensive application for you - reason for that it most likely the platform does not know the domain so what it will provide might be limited. Though don't throw away that idea directly, this might be a good start for extending it to fit your needs. All depends on your domain and business context ... I know again :)

Modern BPM

To summarize, modern BPM is about using the tool in more modern way but still the same tool - process/rule engine. Although the tool needs to be capable of doing so - meaning it should be suitable for lightweight deployment architectures. That can easily scale and evolve but still provide value to the business in a matter of days on both months or years of IT projects.

Next article will give an example of such system to show what can be done in less than a week of time... stay tuned!