Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-1279

Consolidate KEN and KEW notification delivery mechanism

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.9.3
    • Component/s: Documentation
    • Labels:
      None
    • Rice Module:
      KEW, KEN
    • Application Requirement:
      Rice

      Description

      Brainstorm and put together an enhancement proposal for the KEN/KEW "flip-flop". Do this in preparation for next week's Rice team f2f so that you and Eric and possibly others can talk a little bit about what this means and where it might fit into the schedule.

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Aaron H., I know we talked about this at the F2F. Are you going to handle putting the Enhancement proposal/design document together for this? If so, let me know if you need help with anything or if you want me to review it.

            Show
            ewestfal Eric Westfall added a comment - Aaron H., I know we talked about this at the F2F. Are you going to handle putting the Enhancement proposal/design document together for this? If so, let me know if you need help with anything or if you want me to review it.
            Hide
            ahamid Aaron Hamid (Inactive) added a comment -

            This is not much of a proposal per se, mostly just a brain storm:

            https://test.kuali.org/confluence/display/KULRICE/Notes+on+ActionList%2CNotification+extraction

            The initial idea was to "flip/flop" KEW to utilize a KEN service API for notification and action list (move KEW action list functionality into KEN) but at the f2f I think we decided instead to move KEN functionality (e.g. message deliverer plugins) into KEW, under the ActionRequest or a "communication broker" service, and expose this as a first class service on the bus which can be used by arbitrary applications.

            I am just starting to look at this again. Any comments/ideas would be appreciated.

            Show
            ahamid Aaron Hamid (Inactive) added a comment - This is not much of a proposal per se, mostly just a brain storm: https://test.kuali.org/confluence/display/KULRICE/Notes+on+ActionList%2CNotification+extraction The initial idea was to "flip/flop" KEW to utilize a KEN service API for notification and action list (move KEW action list functionality into KEN) but at the f2f I think we decided instead to move KEN functionality (e.g. message deliverer plugins) into KEW, under the ActionRequest or a "communication broker" service, and expose this as a first class service on the bus which can be used by arbitrary applications. I am just starting to look at this again. Any comments/ideas would be appreciated.
            Hide
            ewestfal Eric Westfall added a comment -

            Ah, ok. For some reason I was thinking we discussed moving the Action List inton KEN (same end result I think?) At any rate, if you want to discuss this further we can set up a meeting and talk when you are ready to begin looking at it again.

            Show
            ewestfal Eric Westfall added a comment - Ah, ok. For some reason I was thinking we discussed moving the Action List inton KEN (same end result I think?) At any rate, if you want to discuss this further we can set up a meeting and talk when you are ready to begin looking at it again.
            Hide
            ahamid Aaron Hamid (Inactive) added a comment -

            For the record AaronH, AaronG, and Eric discussed this together 2/11/08 and resolved to exploit an existing hook in KEW system to have KEW delegate to a new communications broker module ("KCB") for non-ActionList endpoints. ActionList data/code/UI will remain in KEW for now. KEN will then be modified to route all deliveries through KEW. One significant reason this approach is being taken is that KEN will need to preserve route log and workflow document-related functionality for all end points. Another is that refactoring at any higher level (e.g. ActionRequestService) would entail much more work and shakeup in the system.

            Show
            ahamid Aaron Hamid (Inactive) added a comment - For the record AaronH, AaronG, and Eric discussed this together 2/11/08 and resolved to exploit an existing hook in KEW system to have KEW delegate to a new communications broker module ("KCB") for non-ActionList endpoints. ActionList data/code/UI will remain in KEW for now. KEN will then be modified to route all deliveries through KEW. One significant reason this approach is being taken is that KEN will need to preserve route log and workflow document-related functionality for all end points. Another is that refactoring at any higher level (e.g. ActionRequestService) would entail much more work and shakeup in the system.
            Hide
            ahamid Aaron Hamid (Inactive) added a comment -

            updated title to better reflect the actual task at this point

            Show
            ahamid Aaron Hamid (Inactive) added a comment - updated title to better reflect the actual task at this point
            Hide
            agodert Aaron Godert (Inactive) added a comment -

            Please make sure we have an official technical doc on how this is architected so that we can remember at a later point on down the road.

            Show
            agodert Aaron Godert (Inactive) added a comment - Please make sure we have an official technical doc on how this is architected so that we can remember at a later point on down the road.
            Hide
            ahamid Aaron Hamid (Inactive) added a comment -

            This work has been completed. Modularity issues can be deferred and re-opened as necessary.

            Show
            ahamid Aaron Hamid (Inactive) added a comment - This work has been completed. Modularity issues can be deferred and re-opened as necessary.
            Hide
            delyea David Elyea added a comment -

            Adding to 'Forced Change' list since KEW now depends on the KCB module

            Show
            delyea David Elyea added a comment - Adding to 'Forced Change' list since KEW now depends on the KCB module

              People

              • Assignee:
                ahamid Aaron Hamid (Inactive)
                Reporter:
                agodert Aaron Godert (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 3 days, 2 hours
                  3d 2h
                  Remaining:
                  Remaining Estimate - 3 days, 2 hours
                  3d 2h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified