changeway2023 opened a new issue, #3987:
URL: https://github.com/apache/incubator-kie-kogito-runtimes/issues/3987
### Describe the bug
When using a Serverless Workflow with a custom KogitoWorkItemHandler, the
Kogito engine fails to find the handler at runtime. It throws a
WorkItemHandlerNotFoundException because it searches for a handler with the
generic name "Service Task" instead of the name specified in the
functionRef.refName of the workflow definition.
### Expected behavior
The Kogito engine should successfully find and execute the
UpdateViewStateWorkItemHandler by looking up the handler using the name
provided in functionRef.refName ("sys.updateViewState").
### Actual behavior
The process fails with a WorkItemHandlerNotFoundException. Debugging shows
that the engine is trying to find a handler named "Service Task".
The root cause was traced to WorkItemNodeInstance.java in the
createWorkItem() method. The WorkItem name is being set from work.getName():
Java
// In WorkItemNodeInstance.java
workItem.setName(work.getName());
During the execution of a Serverless Workflow, work.getName() incorrectly
returns the default value "Service Task" instead of the expected refName
"sys.updateViewState". This causes the WorkItemManager to fail when looking up
the correct handler.
### How to Reproduce?
1. Create a custom KogitoWorkItemHandler:
Implement the KogitoWorkItemHandler interface. The getName() method should
return a unique identifier, for example, "sys.updateViewState".
Java
public class UpdateViewStateWorkItemHandler implements KogitoWorkItemHandler
{
@Override
public void executeWorkItem(KogitoWorkItem workItem,
KogitoWorkItemManager manager) {
// Business logic here
manager.completeWorkItem(workItem.getStringId(), null);
}
@Override
public void abortWorkItem(KogitoWorkItem workItem, KogitoWorkItemManager
manager) {
// Abort logic here
}
@Override
public String getName() {
return "sys.updateViewState"; // The registered name for the handler
}
}
2. Define a Serverless Workflow:
In a Serverless Workflow JSON file (e.g., three-step-approval.json), define
a function and reference it in a state's actions using functionRef. Ensure the
refName matches the name returned by the handler's getName() method.
Function Definition:
JSON
"functions": [
{
"name": "sys.updateViewState",
"type": "custom",
"operation": "service:sys.updateViewState"
}
]
State Action:
JSON
"actions": [{
"functionRef": {
"refName": "sys.updateViewState"
}
}]
3. Run the process:
Trigger the execution of the Serverless Workflow.
### Output of `uname -a` or `ver`
Darwin 10.0.0.3 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:25 PDT
2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6020 arm64
### Output of `java -version`
openjdk version "21.0.5" 2024-10-15 OpenJDK Runtime Environment Homebrew
(build 21.0.5) OpenJDK 64-Bit Server VM Homebrew (build 21.0.5, mixed mode,
sharing)
### GraalVM version (if different from Java)
_No response_
### Kogito version or git rev (or at least Quarkus version if you are using
Kogito via Quarkus platform BOM)
<dependency> <groupId>org.kie.kogito</groupId>
<artifactId>kogito-bom</artifactId>
<version>2.44.0.Alpha</version> <type>pom</type>
<scope>import</scope> </dependency>
### Build tool (ie. output of `mvnw --version` or `gradlew --version`)
Apache Maven 3.9.10 (5f519b97e944483d878815739f519b2eade0a91d) Java version:
21.0.5, vendor: Homebrew, runtime:
/opt/homebrew/Cellar/openjdk@21/21.0.5/libexec/openjdk.jdk/Contents/Home OS
name: "mac os x", version: "15.5", arch: "aarch64", family: "mac"
### Additional information
Proposed Solution / Analysis
The issue appears to be a mapping problem between the Serverless Workflow
specification and the underlying jBPM engine's model. The functionRef.refName
from the SWF definition is correctly assigned to the WorkItemNode's name, but
not to the associated Work object's name.
A viable solution is to modify the line in WorkItemNodeInstance.java to get
the name from the WorkItemNode instead of the Work object. This ensures the
correct name is used to look up the handler.
Suggested Fix:
Change this line in WorkItemNodeInstance.java:
Java
workItem.setName(work.getName());
to:
Java
workItem.setName(getWorkItemNode().getName());
This change correctly retrieves the name defined in the Serverless
Workflow's functions array and resolves the issue. This seems to be a necessary
fix rather than a workaround, as there appears to be no external configuration
to control this behavior.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
