-
Sub-task
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
-
None
-
None
Solution idea outlines
- Engine Level
- Add a new “errorCode” field to ProcessEngineException
- An ExceptionErrorCodeProvider can be implemented and registered in the process engine configuration that provides the error code for the ProcessEngineException based on evaluating the cause and message fields
- The REST API exposes the “errorCode” for error responses
- As a user, when I extend from a ProcessEngineException, I can set a custom “errorCode” in my delegation code
- Cons
- Performance impact: We apply string parsing logic on the engine level whenever an exception is thrown
- We might mitigate this by:
- only doing this in specific command contexts (only those called directly by API); Error codes not available in Job Executor
- for OLE, assign the error code already when throwing it and skipping the provider
- We can provide a flag to disable the error code feature
- We might mitigate this by:
- Performance impact: We apply string parsing logic on the engine level whenever an exception is thrown
- REST API Level
- ExceptionErrorCodeProvider can be implemented
- ExceptionErrorCodeProvider is registered via ServiceLoader
- Cons
- Extensibility via ServiceLoader might seem like a higher obstacle compared to the well-known ProcessEnginePlugin way
- Implement in REST API, configure via process engine configuration
- Cons
- Violation of separation of concerns principle: if the process engine is used standalone, the configuration properties are useless
- Cons
Discussion
- I think the performance impact is neglectable, especially when applying some optimizations.
- For users who really care about this, the error code feature can be disabled.
- Implementing this on the REST API level has performance drawbacks as well; however, only for API that is called via REST API.
- The Engine level approach makes the feature available for users that have implemented a Java retry mechanism.
Decision
Opting for the Engine level approach since it makes the feature available for all users no matter whether they use the Java or REST API. Also, with some optimizations in place, the performance degradation should be minimal.