Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-102

Implement declarative loop support within the Kuali workflow engine

    Details

    • Type: Rice Enhancement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Component/s: KEW
    • Labels:
      None
    • Rice Theme:
      Ease of Implementation
    • Priority Score:
      0
    • Functional Justification :
      Many processes need to perform the same action repeatedly as part of a process definition and most workflow engines and languages have support for this. It's currently a significant gap in KEW even though there are workarounds for it.
    • Technical Justification:
      The backend technical portion of KEW should already be able to support this, so adding the ability for process designers to take advantage of it makes sense.
    • Impact if not Implemented:
      Possible loss of adoption and hindered ability to model workflow processes accurately and efficiently.
    • Priority - KFS:
      No Priority
    • Priority - KC:
      No Priority
    • Priority - KS:
      No Priority
    • Priority - Rice:
      No Priority
    • Effort Estimate:
      Very Low ~ 50 hrs

      Description

      This is really a missing feature that needs to be implemented. It's possible to do this programatically with return to previous action but that is less than ideal. Loops and loop conditions should be able to be implemented declaratively within the process definition language for document types.

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Linking this with an old issue that was entered related to adding this support to KEW.

            Show
            ewestfal Eric Westfall added a comment - Linking this with an old issue that was entered related to adding this support to KEW.
            Hide
            gpro Gary Prohaska (Inactive) added a comment -

            seems important; would be nice to document a couple of sample business use cases to reinforce value of this functionality

            Show
            gpro Gary Prohaska (Inactive) added a comment - seems important; would be nice to document a couple of sample business use cases to reinforce value of this functionality
            Hide
            hsublett Hampton Sublett (Inactive) added a comment -

            Hi Eric, please provide an "Effort" assessment to aid in the voting scheduled for tomorrow. - Thanks

            Show
            hsublett Hampton Sublett (Inactive) added a comment - Hi Eric, please provide an "Effort" assessment to aid in the voting scheduled for tomorrow. - Thanks
            Hide
            ewestfal Eric Westfall added a comment - - edited

            Setting this as "Very Low" effort estimate with the assumption that my understanding that the back-end support is already there and this is mostly an issue in adding declarative support for this into the KEW process definition language.

            Show
            ewestfal Eric Westfall added a comment - - edited Setting this as "Very Low" effort estimate with the assumption that my understanding that the back-end support is already there and this is mostly an issue in adding declarative support for this into the KEW process definition language.
            Hide
            ewestfal Eric Westfall added a comment -

            To affirm the scope for this roadmap item. Based on comments and description on the jira, I think this will include the following:

            1) Allow for looping constructs to be declared in the document type "routePath" XML.
            2) If there is any back-end engine support that needs to be enhanced to support this, then that should be done as well.

            To main thing to consider about is how to support "breaking" the loop condition. KEW already has support built into it to detect potential "runaway" processes, so we have those protections in place. However declarative loops don't buy us much if there is no way to declare the condition upon which the loop is broken. The most logical way to proceed here is to allow for "split" to be defined which can loop back to a previous node. Split nodes can be programmed to determine which branch they should take, so this allows us to leverage any declarative support that might be supported already by splits. Alternatively, we create a container that can include the nodes that should be executed in a loop. That container node can then specify the loop condition and provide a "LoopNode" interface that can be used for the programming of custom looping conditions.

            Show
            ewestfal Eric Westfall added a comment - To affirm the scope for this roadmap item. Based on comments and description on the jira, I think this will include the following: 1) Allow for looping constructs to be declared in the document type "routePath" XML. 2) If there is any back-end engine support that needs to be enhanced to support this, then that should be done as well. To main thing to consider about is how to support "breaking" the loop condition. KEW already has support built into it to detect potential "runaway" processes, so we have those protections in place. However declarative loops don't buy us much if there is no way to declare the condition upon which the loop is broken. The most logical way to proceed here is to allow for "split" to be defined which can loop back to a previous node. Split nodes can be programmed to determine which branch they should take, so this allows us to leverage any declarative support that might be supported already by splits. Alternatively, we create a container that can include the nodes that should be executed in a loop. That container node can then specify the loop condition and provide a "LoopNode" interface that can be used for the programming of custom looping conditions.
            Hide
            sagee Sandra Agee (Inactive) added a comment -

            This scope is confirmed

            Show
            sagee Sandra Agee (Inactive) added a comment - This scope is confirmed

              People

              • Assignee:
                ewestfal Eric Westfall
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: