Python’s popularity for designing and running AI solutions makes it a primary objective to integrate in business logic via jBPM. Part two of jBPM as AI Orchestration Platform series presents jBPM as a platform for orchestrating external AI-centric environments. If you missed it, check out part one of this three-part series.

How jBPM orchestrates Python

jBPM’s Python integration can be implemented in various ways. Our current approach utilizes Jep (Java Embedded Python), a Java extension that allows interaction with Python interpreters. When combined with jBPM’s business process automation (e.g., script task activity), this enables a solid, foundational level of Python orchestration:

Although Jep enables Python integration, it has a usability barrier that may require workarounds during initial implementation. We are describing below some of the most useful workarounds.

Assuming that Eclipse is used as the IDE (more rationale found in Part 1 of this series), let us consider adding the QuickShell extension to our Eclipse setup to enable debugging of Java code with embedded Python, in a Java shell:

The fact that our code runs well using QuickShell does not immediately guarantee its smooth execution in jBPM, but it can definitely make debugging the Java part of our code more efficient (compared to using only jBPM for debugging).

The implementation of multi-threading in various versions of Python, the interfacing options and conventions of Python’s C API, and the compliance (or lack thereof) of various Python modules with those conventions—all of that, crowned by Jep’s own implementation of multi-threading handling—is the next and most important reason for empirical workarounds. These are based on concrete use cases and are implemented by us as solutions addressing specific needs.

Taking the Stroke Prediction solution as an illustration (described in more detail in Part 3 of this series), the following “measure” ensures proper concurrent functioning of the several jBPM processes comprising the solution:

Again, this fix is substantial, but it still does not free us from the necessity of testing our solution end-to-end upon practically every change—and adding other workarounds. As an example of such a use-case-driven workaround, let us consider the following one:

Despite its somewhat basic look and feel (in addition to all the various workarounds to bear in mind), Jep’s strongest advantage is that it enables Python orchestration in jBPM without requiring customization—neither of jBPM for Jep, nor of Jep for jBPM.

With Python integration in place, jBPM orchestrates Python by automating the workflows required by a specific use case. While the automation capabilities of jBPM are impressive, the most practical functionality seems to be the script task activity in a jBPM process. Depending on whether we edit a jBPM process locally in Eclipse or directly on the jBPM server, a script task activity edit implementation will look slightly different, still resulting in identical orchestration behavior in jBPM compared to Python:

Once committed, compiled, and deployed on the jBPM server, our edits go live under their respective processes. Their execution status can be viewed in the jBPM server’s process instance browser:

For more details, check out the code and documentation on the project’s GitHub repository.

For more: C-NLTX/Open-Source

Read Part 1 or Part 3: Orchestrating AI in clinical settings with jBPM