4 Problems You'll Face When You Upgrade From jBPM 5 to 6
These solutions will save you a headache when you upgrade from jBPM 5 to 6
You’ve started to upgrade from jBPM 5 to 6.
And soon, your company will have better tools to manage their complex processes.
...all because of your foresight.
Ok, fine. You have to upgrade before support ends for version 5.
But still! You’re almost finished. You just need to test jBPM 6 with your existing processes.
Easy, right? Wrong.
Big Update, Big Headaches
Due to major changes in jBPM v6, the upgrade from v5 can be quite a headache. But not for you. You’ll know the solutions to get around those problems.
Here are 4 problems you'll face when you upgrade.
4 Problems You’ll Face When You Upgrade
PROBLEM #1: “No session for context”
When: You try to claim a task created in v5
Why: The ContextMappingInfo table is empty.
When you use the PER_PROCESS_INSTANCE strategy in v6, it expects an entry in the ContextMappingInfo table to map that process instance to a session. But in jBPM 5, the only strategy is Singleton. In this strategy, all processes use the same session and there is no mapping entry.
Solution: Change to PER_REQUEST
- Open your kie-deployment-descriptor.xml file
- Find the runtime-strategy block
- Change whatever is inside that block to PER_REQUEST
Why this works: PER_REQUEST creates a new session for every request instead of tying it to a process. Old and new processes will use a new session
- Only use this method if you don’t have rules or facts stored in your previous sessions.
- PER_REQUEST does not allow you to store facts or timers across different requests.
- Unfortunately, other methods require you to create fake data in the ContextMappingInfo & SessionInfo tables. Yikes!
PROBLEM #2: “Cannot find RuntimeManager for task”
When: You try to claim a task created in v5
Why: The deploymentId is missing in AuditTaskImpl & Task tables. In the services API, the deploymentId is used to create a RuntimeManager. But...this API wasn't introduced until v6.
Solution: Add the deployment Id
1: Find the deployment ID of your kjar. It’s the maven GAV separated by colons
- Ex. org.codelikethewind:simple-process-kjar:1.0.0-SNAPSHOT
- If you have multiple kjars, make sure this deployment ID maps to the process of your task
2: Update the AudtiTaskImpl and Task tables with the deployment Id
- Something like this
UPDATE AUDITTASKIMPL set DEPLOYMENTID='org.codelikethewind:simple-process-kjar:1.0.0-SNAPSHOT' where DEPLOYMENTID IS NULL;
UPDATE TASK set DEPLOYMENTID='org.codelikethewind:simple-process-kjar:1.0.0-SNAPSHOT' where DEPLOYMENTID IS NULL;3: Try it again!
PROBLEM #3: “... cannot be cast to HumanTaskNode”
When: You try to run a process created in v5
Why: Processes created in jBPM 5 are incompatible with version 6
In v6, the process to assign nodes an id at runtime has changed. Processes created in jBPM 5 are incompatible with this new strategy
Solution: Use the v5 id strategy
In your server properties, add this flag to your server config
jbpm.v5.id.strategy=trueNote: All your new v6 processes will be created with the old v5 id strategy. This compatibility flag will be deprecated in v7.
PROBLEM #4: Table sequences are incorrect
Why: Entities no longer use the default HIBERNATE_SEQUNCE
In jBPM6, a few major tables are now using their own sequence. When a new task is created, it will incorrectly start from 1. This creates obvious sequence clashing issues.
Solution: Reset the sequences for jBPM tables
1: Download this script.
- It’s a stored procedure that will reset your sequence to the highest id in your table
- You will need to change the table names to match your jBPM tables
2: Make a backup of your tables ;)
3: Run the script!
Helpful Links
I hope this helps your migration efforts. See you again for v7!
Happy Coding,
-T.O
