Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-14083 Expose engine exceptions to implement retry behavior
  3. CAM-14681

Evaluate location of implementation: Engine vs. REST API level

    XMLWordPrintable

Details

    • Sub-task
    • Resolution: Fixed
    • L3 - Default
    • None
    • None
    • None
    • None

    Description

      Solution idea outlines

      1. 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
      2. 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
      3. 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

      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.

      mgm-controller-panel

        This is the controller panel for Smart Panels app

        Attachments

          Activity

            People

              tassilo.weidner Tassilo Weidner
              tassilo.weidner Tassilo Weidner
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Salesforce