We couldn't load the project sidebar. Refresh the page to try again.
If the problem persists, contact your Jira admin.

    • Icon: Sub-task Sub-task
    • Resolution: Unresolved
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • scala-dmn
    • None

      AT

      • In Scala DMN, Script Engines can use process engine context
      • Document breaking changes in migration guide (e.g., when removing interfaces)

      Reasoning

      • When using JUEL in the legacy DMN Engine, context providers registered in the process engine can be used (optionally via Spring & CDI)
        • Context switch in Process Applications is performed
        • Beans can be resolved
        • By default built-in function mappers are available (this is not the case for Spring & CDI)
      • Providing the process engine context with JUEL in the Scala DMN Engine makes migrating from the legacy DMN Engine smooth
      • Since FEEL ist the expression language designed for DMN it makes sense to provide process engine context in FEEL and not only for JUEL
      • With respect to the high adoption of the Spring Boot Starter it makes sense to provide registered beans in FEEL/JUEL

      Status Quo JUEL

      • In process engine config ExpressionManager is initialized in initExpressionManager (Spring and CDI have dedicated expression managers)
        • Functions mappers are registered (e.g., currentUser, now, etc.) => not in Spring & CDI
      • ExpressionManager is wrapped in ProcessEngineElProvider (implements ElProvider)
      • ProcessEngineElProvider is registered in Legacy DMN Engine

      Status Quo Script Engines

      Script engines that can be used in the legacy DMN Engine can be registered in...

        1. the Process Engine via ScriptEngineResolver#addScriptEngineFactory
        2. a Process Application (via SPI & via ScriptEngineResolver#addScriptEngineFactory)
        3. a SPI and be resolved via ScriptEngineManager

      Solution Ideas

      Process Engine context can be used in ...

      1. ... FEEL
      2. ... JUEL (previous behavior)
      3. ... all registered Script Engines

      Scope

      • Minimum: use context either in JUEL or FEEL
        • Adding JUEL support is probably easier
      • Medium: JUEL and FEEL
        • JUEL due to backward compatibility
        • FEEL because it is the default expression language in DMN
      • Maximum: context can be used In all possible expression languages

      See

        This is the controller panel for Smart Panels app

            Loading...

              • Icon: Sub-task Sub-task
              • Resolution: Unresolved
              • Icon: L3 - Default L3 - Default
              • None
              • None
              • scala-dmn
              • None

                AT

                • In Scala DMN, Script Engines can use process engine context
                • Document breaking changes in migration guide (e.g., when removing interfaces)

                Reasoning

                • When using JUEL in the legacy DMN Engine, context providers registered in the process engine can be used (optionally via Spring & CDI)
                  • Context switch in Process Applications is performed
                  • Beans can be resolved
                  • By default built-in function mappers are available (this is not the case for Spring & CDI)
                • Providing the process engine context with JUEL in the Scala DMN Engine makes migrating from the legacy DMN Engine smooth
                • Since FEEL ist the expression language designed for DMN it makes sense to provide process engine context in FEEL and not only for JUEL
                • With respect to the high adoption of the Spring Boot Starter it makes sense to provide registered beans in FEEL/JUEL

                Status Quo JUEL

                • In process engine config ExpressionManager is initialized in initExpressionManager (Spring and CDI have dedicated expression managers)
                  • Functions mappers are registered (e.g., currentUser, now, etc.) => not in Spring & CDI
                • ExpressionManager is wrapped in ProcessEngineElProvider (implements ElProvider)
                • ProcessEngineElProvider is registered in Legacy DMN Engine

                Status Quo Script Engines

                Script engines that can be used in the legacy DMN Engine can be registered in...

                  1. the Process Engine via ScriptEngineResolver#addScriptEngineFactory
                  2. a Process Application (via SPI & via ScriptEngineResolver#addScriptEngineFactory)
                  3. a SPI and be resolved via ScriptEngineManager

                Solution Ideas

                Process Engine context can be used in ...

                1. ... FEEL
                2. ... JUEL (previous behavior)
                3. ... all registered Script Engines

                Scope

                • Minimum: use context either in JUEL or FEEL
                  • Adding JUEL support is probably easier
                • Medium: JUEL and FEEL
                  • JUEL due to backward compatibility
                  • FEEL because it is the default expression language in DMN
                • Maximum: context can be used In all possible expression languages

                See

                  This is the controller panel for Smart Panels app

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

                          Created:
                          Updated:

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

                                Created:
                                Updated: