In an older role I helped work on a proof-of-concept (POC) for IBM Process Federation Sever (PFS). At the time this was a really new offering from IBM in the BPM space. PFS is a WebSphere Liberty Profile and Elasticsearch-based source for BPM Task data.

IBM BPM already provided a way to federate instance and task data between two different BPM systems running the same version: essentially you register the systems with each other and one API call for instance or task data can pull the data from both systems.

PFS introduced a way to provide this same functionality to systems not on the same version. So think about running an IBM BPM v8.0 platform but you want to upgrade to v8.6. You could do that in place and put your platform at risk and require a lot of testing; or you could stand-up a v8.6 system and migrate apps one at a time to the new platform. But what if you don’t want your users to have to switch back and forth between the different Process Portals? This is where PFS comes into play: create a central source for task data that can be accessed by Process Portal (or any other work mgmt UX using PFS REST APIs which look just like the Federated BPM REST APIs) and that source can serve both the v8.0 data and the v8.5 data. Yay – win win!

PFS was not a performance solve, per IBM. It was just a way to consolidate task data in one location; the fact that they chose Liberty and ElasticSearch is totally up to them…both are relatively lightweight, so I’m sure that had something to do with it. I’m pretty sure Liberty is on the horizon for the BPMN engine so maybe it was their own little POC of BPM in Liberty.

Either way, when a BPM Task is created a bunch of stuff happens in BPM and the database, but most obviously a row is added to the LSW_TASK table. When someone logs into the Responsive Process Portal, a legacy* REST API call is made against BPM and that ends up hitting this LSW_TASK table (and a bunch of other tables) to determine if the user should see that task and be able to claim it and action on it. (*) By legacy I mean the existing IBM BPM REST API that has been with the product since Lombardi Teamworks 7.5.1.

A lot of other DB activity hits LSW_TASK, like when a task is created and actioned-on and claimed and even some instance-related events can hit LSW_TASK. The bottom line is that pretty much all IBM BPM developers and administrators realize that database latency should be as low as possible; the tech sales pitch was always “put BPM and its database right beside each other.”

Contrary to IBM’s standpoint, we started the PFS POC looking for a task source that displayed better performance then hitting the regular BPM REST API. In the POC environment the database resources were all centrally managed at the enterprise level. And though our DB and schema were in the same data center as our application servers, we still saw some latency between BPM and the DB. Attribute it to whatever you want…we were running Oracle 12c on Exadata as a two (2) node cluster. Do all the research you want – that’s a fast setup. But also recognize that we were one app in an incredibly large landscape of DB consumers. And most schemas were partitioned off with default settings and such. But as the BPM team, we weren’t DBAs and we relied on the DBA teams to manage that for us, which was totally fine.

So we thought “hey, a noSQL file-based BPM task repository with an existing API – yay speed!”

I’m not going tinto the details of our POC but in the end I learned a lot about how PFS works.

1. First you have to build new tables in the BPM database for PFS information
2. Second you have to configure BPM to use those new tables. How you might wonder?
   1. You essentially setup a trigger that says anytime BPM creates a task or does anything human-task related add a row to one of the PFS tables
3. PFS is configured to regularly ping those BPM-schema PFS tables over JDBC to look for changes in the data – essentially PFS is looking for new tasks or changes to existing tasks
4. Then PFS queries into the detailed LSW tables to collect the full task and business data
5. PFS indexes that data into its Elasticsearch cache and updates the BPM-schema PFS table to flag the row as already read
6. And this happens over and over as tasks are created and updated

NOTE: PFS does not have its own SQL database except for one to hold Saved Searches, which are defined over a REST API operation and can be used to search the task index in Elasticsearch

If you paid attention to that extremely simplified walk-through, you’d notice how many times I mention DB calls…so maybe you see? In an environment where we already had DB latency, why would we want more activity on the DB just to outsource the task data?

The POC still continues and there is a chance the new DEF might end up playing a role in the solution. But either way – just like IBM said, we didn’t find PFS to be a performance solve.