In The Beginning…
FileNet created Visual WorkFlo. In the years since, the software improved steadily, but the architecture mostly remained. With the release of version 5.0, IBM had rewritten the entire Process code base in Java; yet it remained wrapped in COM and the macro architecture remained mainly unchanged. Then came P8 5.2, and our whole world changed.
Process Engine
Process Engine (PE) as we know it, is both completely gone and yet exactly the same. IBM has struck a tight balance between massive architectural improvements and consistency with the major principles and design of prior versions. Scalability is the key word to describe the improvements.
The Process Engine modules have been repackaged into a web module (peengine.war) that has been added to the ever monstrous FileNetEngine.ear. In practical terms, Process Engine is now deployed to your choice of J2EE container with Content Engine (CE). This allows PE to scale both horizontally and vertically in tandem with CE and for the two to share resources in a more coordinated manner. It also allows for easier implementation of small footprint systems, removing an integration point and performance bottleneck.
Unlock Your Potential with Application Modernization
Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.
On the whole, the PE codebase is very similar, functionally, to what was shipped as PE 5.0. The database structure, as well, will be very familiar. VWTool is still available and very useful. For PE administration, however, Process Task Manager has been obliterated in favor of the same options being made available in the Administration Console for Content Engine web tool (ACCE) as “Workflow Systems”. The Java applet admin tools (Process Configuration Console and Process Administrator) are also made available in ACCE and haven’t changed a bit.
For upgrades, PE will still have its own database, and will be called a “Legacy Workflow System.” This is in contrast to new systems, where each Workflow System is created within an Object Store. In this manner, an Object Store can have a collection of Isolated Regions. This new data management strategy is a departure from the old model, and I haven’t yet encountered a large enough new implementation to speak to the efficacy of this particular change. I’d speculate that we need to modify our strategies and instincts around Workflow System design. I think this change will lead to more systems designed with multiple Isolated Regions, where it would have been uncalled for in the past. I’m not sure what impact this will have—something to explore when we have more data.
Component Integrators
Like the Process Engine, the Component Manager has been swallowed up by the FileNetEngine.ear. In this case, however, the Legacy Component Manager will still be available with Application Engine (AE) or WorkplaceXT and Component Integrators can run seamlessly in either. For Component Integrators to run in the new Component Manager, the required JARs will need to be uploaded to the repository as a Code Module object and linked to the Adapter in Process Configuration Console. The out-of-the-box CEOperations and WSRequest queues use adapters running in the new Component Manager. As of BPF version 4.1.0.9, BPFOperations is still only supported in the Legacy Component Manager.
Migrating custom Component Integrators to the new architecture may require code changes. Legacy support for 3.5 APIs has been dropped. IBM has documented some, but not all, of the changes—thorough testing is critical. Once you get it working, though, the benefits are immense. Where in previous versions highly available Component Managers might try to work on the same Work Object at the same time and see checkout errors, the new model allows the Component Manager threads on each node to communicate and coordinate using the J2EE Server to avoid these issues and share the load. This improved scalability, that like PE scales in parallel to CE, allows for more generally functional and efficient background work processing.
Conclusions
IBM has simplified the BPM architecture in the P8 product and, simultaneously, allowed it to better scale to serve any size implementation. The new architecture and the advent of Content Navigator take us one step closer to a world where AE or WorkplaceXT are no longer required—one of these applications is still mandatory to access Process Designer and Process Simulator. With these great improvements, it is important to remember that these platforms are evolving faster than ever, proceed with caution and don’t go it alone.
