L3 Support
  1. L3 Support
  2. LS-930

Perf Optimisation — Avoid unnecessary Flowable DB variable retrieval during order cancellation

    Details

    • Type: Bug Bug
    • Status: Ready for QA Ready for QA (View Workflow)
    • Priority: Normal Normal
    • Resolution: Unresolved
    • Component/s: None
    • Labels:
      None Labels
    • Customer:
      Mobinets
    • Complexity:
      Medium
    • REQUESTER:
      INTERNAL

      Description

      While cancelling an order, the FN service retrieves the Flowable process variables "oldServiceType" and "oldSubscriberIps" from the Flowable DB using the passed variable "fWOID".

      Currently, these variables are fetched for all operation types of the order (8 types: Activation, Termination, etc.),
      even though they are only required in specific cases:

      oldSubscriberIps → required only for operation "IP Management"

      oldServiceType → required only for operations:

      -"Shifting Installation"

      • "Add Service"

      During testing on the cloud version, a performance issue was identified:

      -Fetching both variables from the Flowable DB can take more than 10 seconds

      -The cost is incurred even when the variables are not needed

      Root Cause:

      -Unconditional retrieval of Flowable variables for all operation types, causing unnecessary DB calls and latency.

      Proposed Solution:

      -Refactor the variable retrieval logic to:

      -Avoid reading variables for all operation types

      -Fetch variables only when required, based on the operation type:

      -Retrieve oldSubscriberIps only for "IP Management"

      -Retrieve oldServiceType only for "Shifting Installation" and "Add Service"

      -Read only the single required variable instead of both

      Expected Benefit:

      -Reduce unnecessary Flowable DB calls

      -Improve order cancellation performance

      -Eliminate the ~10s delay observed in the cloud environment

        Activity

        Ayed Bada made changes -
        Field Original Value New Value
        Gantt Options Milestone (set to milestone: having a due date but zero effort)
        Planned Start 2026-02-13 24:00 (milestone: set planned start date to due date)
        Planned End 2026-02-13 24:00 (milestone: set planned end date to due date)
        Ayed Bada made changes -
        Assignee Khaled Khalil [ kkhalil ] Ayed Bada [ abada ]
        Ayed Bada made changes -
        Status Open Bug [ 10108 ] Dev Scheduled [ 10014 ]
        Ayed Bada made changes -
        Status Dev Scheduled [ 10014 ] Implementation in progress [ 10016 ]
        Ayed Bada made changes -
        Status Implementation in progress [ 10016 ] To Be Released [ 10400 ]
        Ayed Bada made changes -
        Description While cancelling an order, the FN service retrieves the Flowable process variables "oldServiceType" and "oldSubscriberIps" from the Flowable DB using the passed variable "fWOID".

        Currently, these variables are fetched for all operation types of the order (8 types: Activation, Termination, etc.), even though they are only required in specific cases:

        oldSubscriberIps → required only for operation "IP Management"

        oldServiceType → required only for operations:

        "Shifting Installation"

        "Add Service"

        During testing on the cloud version, a performance issue was identified:

        Fetching both variables from the Flowable DB can take more than 10 seconds

        The cost is incurred even when the variables are not needed

        Root Cause:

        Unconditional retrieval of Flowable variables for all operation types, causing unnecessary DB calls and latency.

        Proposed Solution:

        Refactor the variable retrieval logic to:

        Avoid reading variables for all operation types

        Fetch variables only when required, based on the operation type:

        Retrieve oldSubscriberIps only for "IP Management"

        Retrieve oldServiceType only for "Shifting Installation" and "Add Service"

        Read only the single required variable instead of both

        Expected Benefit:

        Reduce unnecessary Flowable DB calls

        Improve order cancellation performance

        Eliminate the ~10s delay observed in the cloud environment
        While cancelling an order, the FN service retrieves the Flowable process variables "oldServiceType" and "oldSubscriberIps" from the Flowable DB using the passed variable "fWOID".

        Currently, these variables are fetched for all operation types of the order (8 types: Activation, Termination, etc.),
        even though they are only required in specific cases:

        oldSubscriberIps → required only for operation "IP Management"

        oldServiceType → required only for operations:

           -"Shifting Installation"

          - "Add Service"

        During testing on the cloud version, a performance issue was identified:

          -Fetching both variables from the Flowable DB can take more than 10 seconds

          -The cost is incurred even when the variables are not needed

        Root Cause:

          -Unconditional retrieval of Flowable variables for all operation types, causing unnecessary DB calls and latency.

        Proposed Solution:

          -Refactor the variable retrieval logic to:

          -Avoid reading variables for all operation types

          -Fetch variables only when required, based on the operation type:

          -Retrieve oldSubscriberIps only for "IP Management"

          -Retrieve oldServiceType only for "Shifting Installation" and "Add Service"

          -Read only the single required variable instead of both

        Expected Benefit:

          -Reduce unnecessary Flowable DB calls

          -Improve order cancellation performance

           -Eliminate the ~10s delay observed in the cloud environment
        Khaled Khalil made changes -
        Status To Be Released [ 10400 ] Ready for QA [ 10023 ]
        Ayed Bada made changes -
        Attachment Cancel_resources.bpmn20.xml [ 128212 ]
        Ayed Bada made changes -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 7 hours [ 25200 ]
        Worklog Id 291607 [ 291607 ]
        Ayed Bada made changes -
        Baseline Start 2026-02-13 24:00 (set baseline based of initial work logging)
        Baseline End 2026-02-13 24:00 (set baseline based of initial work logging)
        Ayed Bada made changes -
        Remaining Estimate 0 minutes [ 0 ] 3 hours [ 10800 ]
        Time Spent 7 hours [ 25200 ] 4 hours [ 14400 ]
        Worklog Id 291607 [ 291607 ]
        Ayed Bada made changes -
        Remaining Estimate 3 hours [ 10800 ] 0 minutes [ 0 ]
        Time Spent 4 hours [ 14400 ] 1 day, 1 hour [ 32400 ]
        Worklog Id 291608 [ 291608 ]

          People

          • Assignee:
            Ayed Bada
            Reporter:
            Ayed Bada
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Planned Start:
              Planned End:
              Actual Start:
              Date of Baselining:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 day, 1 hour
              1d 1h

                Drag and Drop