Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-8249

Rules activation not canceled in Case Management subprocess

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.19.0.Final
    • 7.16.0.Final, 7.17.0.Final
    • KieServer
    • None
    • NEW
    • NEW
    • Hide

      I have the scenario where two objects of type GeneralRiskRating are inserted into the rules engine by one of many rules that looks like this (see file smoking_risk.gdst):

      rule "Row 1 smoking_risk"
      agenda-group "calculate-risk-rating"
      dialect "mvel"
      when
      $question : Question( questionId == "a.isSmoking" , strAnswer == "No" )
      then
      GeneralRiskRating $risk = new GeneralRiskRating();
      insert( $risk );

      end

      These two objects trigger the activation of another rule (name: "Create new General RiskRatingRollup if not exist" in file: rollup_risk_ratings_insured.drl ) in a different agenda group (the next rule task in the process flow):

      rule "Create new General RiskRatingRollup if not exist"
      agenda-group "rollup-risk-ratings"
      dialect "mvel"
      when
      $risk : GeneralRiskRating(riskType != null)
      $ratings : ArrayList(size > 0)
      from collect( GeneralRiskRating(riskType == $risk.riskType) )

      not RiskRatingRollup(riskType == $risk.riskType )

      then

      RiskRatingRollup $rollup = new RiskRatingRollup();

      $rollup.setRiskType($risk.getRiskType());
      insert($rollup );

      end

      The rule is activated to fire for each of the two newly inserted GeneralRiskRating objects,
      but the condition of the rule (condition: not RiskRatingRollup(riskType == $risk.riskType ) ) is suppose to cancel the activation of the rule for the second object after it fired once for the first GeneralRiskRating object.

      The problem is that the rule "Create new General RiskRatingRollup if not exist" is firing two (2) times instead of one (1) time, thus not canceling the second activation of the rule.

      If the rules are executed outside of a bpm workflow it works fine. If the milestone in the process flow is replaces with a new exact copy the rules fire correctly (thus canceling the second activations)

      To reproduce the issue all that is needed is to create a new case by using the rest interface:

      POST: http://localhost:8080/kie-server/services/rest/server/containers/sample-rules_1.0.0/cases/insurance.application.process/instances

      with payload:

      {
      "case-data" : { },
      "case-user-assignments" : { "applicant" : "pam_user_id",
      "manager" : "pam_user_id",
      "admin" : "pam_user_id",
      "underwriter" : "pam_user_id"

      },
      "case-group-assignments" :

      {"underwriter" : "underwriter" }

      }

      just replace the "pam_user_id" with your username you use to log into jBPM. Also make sure to use the same username/pw for the basic auth in the HTTP request.

      When the request is made, it will start the process (application_process.bpmn2) and all the rules will fire in the subprocess (calculate_questionnaire_risk).
      In the server log you will observe the following log statement TWO times instead of just once:

                  • Create GENERAL RiskRatingRollup for type[SMOKER] ****************

      If the process diagram is reduced to only the rules and no milestone things start to work correctly again. It appears that this given setup (see attached zip file) will allow you to reproduce the issue and hopefully you should be able to identify the issue.

      Show
      I have the scenario where two objects of type GeneralRiskRating are inserted into the rules engine by one of many rules that looks like this (see file smoking_risk.gdst): rule "Row 1 smoking_risk" agenda-group "calculate-risk-rating" dialect "mvel" when $question : Question( questionId == "a.isSmoking" , strAnswer == "No" ) then GeneralRiskRating $risk = new GeneralRiskRating(); insert( $risk ); end These two objects trigger the activation of another rule (name: "Create new General RiskRatingRollup if not exist" in file: rollup_risk_ratings_insured.drl ) in a different agenda group (the next rule task in the process flow): rule "Create new General RiskRatingRollup if not exist" agenda-group "rollup-risk-ratings" dialect "mvel" when $risk : GeneralRiskRating(riskType != null) $ratings : ArrayList(size > 0) from collect( GeneralRiskRating(riskType == $risk.riskType) ) not RiskRatingRollup(riskType == $risk.riskType ) then RiskRatingRollup $rollup = new RiskRatingRollup(); $rollup.setRiskType($risk.getRiskType()); insert($rollup ); end The rule is activated to fire for each of the two newly inserted GeneralRiskRating objects, but the condition of the rule (condition: not RiskRatingRollup(riskType == $risk.riskType ) ) is suppose to cancel the activation of the rule for the second object after it fired once for the first GeneralRiskRating object. The problem is that the rule "Create new General RiskRatingRollup if not exist" is firing two (2) times instead of one (1) time, thus not canceling the second activation of the rule. If the rules are executed outside of a bpm workflow it works fine. If the milestone in the process flow is replaces with a new exact copy the rules fire correctly (thus canceling the second activations) To reproduce the issue all that is needed is to create a new case by using the rest interface: POST: http://localhost:8080/kie-server/services/rest/server/containers/sample-rules_1.0.0/cases/insurance.application.process/instances with payload: { "case-data" : { }, "case-user-assignments" : { "applicant" : " pam_user_id ", "manager" : " pam_user_id ", "admin" : " pam_user_id ", "underwriter" : " pam_user_id " }, "case-group-assignments" : {"underwriter" : "underwriter" } } just replace the "pam_user_id" with your username you use to log into jBPM. Also make sure to use the same username/pw for the basic auth in the HTTP request. When the request is made, it will start the process (application_process.bpmn2) and all the rules will fire in the subprocess (calculate_questionnaire_risk). In the server log you will observe the following log statement TWO times instead of just once: Create GENERAL RiskRatingRollup for type [SMOKER] **************** If the process diagram is reduced to only the rules and no milestone things start to work correctly again. It appears that this given setup (see attached zip file) will allow you to reproduce the issue and hopefully you should be able to identify the issue.
    • 2019 Week 08-10

    Description

      Rules activation not canceled in Case Management subprocess.

      I have the scenario where two objects of type GeneralRiskRating are inserted into the rules engine by one of many rules that looks like this (see file smoking_risk.gdst):

      rule "Row 1 smoking_risk"
      agenda-group "calculate-risk-rating"
      dialect "mvel"
      when
      $question : Question( questionId == "a.isSmoking" , strAnswer == "No" )
      then
      GeneralRiskRating $risk = new GeneralRiskRating();
      insert( $risk );

      end

      These two objects trigger the activation of another rule (name: "Create new General RiskRatingRollup if not exist" in file: rollup_risk_ratings_insured.drl ) in a different agenda group (the next rule task in the process flow):

      rule "Create new General RiskRatingRollup if not exist"
      agenda-group "rollup-risk-ratings"
      dialect "mvel"
      when
      $risk : GeneralRiskRating(riskType != null)
      $ratings : ArrayList(size > 0)
      from collect( GeneralRiskRating(riskType == $risk.riskType) )

      not RiskRatingRollup(riskType == $risk.riskType )

      then

      RiskRatingRollup $rollup = new RiskRatingRollup();

      $rollup.setRiskType($risk.getRiskType());
      insert($rollup );

      end

      The rule is activated to fire for each of the two newly inserted GeneralRiskRating objects,
      but the condition of the rule (condition: not RiskRatingRollup(riskType == $risk.riskType ) ) is suppose to cancel the activation of the rule for the second object after it fired once for the first GeneralRiskRating object.

      The problem is that the rule "Create new General RiskRatingRollup if not exist" is firing two (2) times instead of one (1) time, thus not canceling the second activation of the rule.

      If the rules are executed outside of a bpm workflow it works fine. If the milestone in the process flow is replaces with a new exact copy the rules fire correctly (thus canceling the second activations)

      To reproduce the issue all that is needed is to create a new case by using the rest interface:

      POST: http://localhost:8080/kie-server/services/rest/server/containers/sample-rules_1.0.0/cases/insurance.application.process/instances

      with payload:

      {
      "case-data" : { },
      "case-user-assignments" : { "applicant" : "pam_user_id",
      "manager" : "pam_user_id",
      "admin" : "pam_user_id",
      "underwriter" : "pam_user_id"

      },
      "case-group-assignments" :

      {"underwriter" : "underwriter" }

      }

      just replace the "pam_user_id" with your username you use to log into jBPM. Also make sure to use the same username/pw for the basic auth in the HTTP request.

      When the request is made, it will start the process (application_process.bpmn2) and all the rules will fire in the subprocess (calculate_questionnaire_risk).
      In the server log you will observe the following log statement TWO times instead of just once:

                  • Create GENERAL RiskRatingRollup for type[SMOKER] ****************

      If the process diagram is reduced to only the rules and no milestone things start to work correctly again. It appears that this given setup (see attached zip file) will allow you to reproduce the issue and hopefully you should be able to identify the issue.

      Attachments

        Activity

          People

            swiderski.maciej Maciej Swiderski (Inactive)
            bvanderwalt@vizuri.com Ben-Johan van der Walt (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: