Uploaded image for project: 'Red Hat Decision Manager'
  1. Red Hat Decision Manager
  2. RHDM-1688

DMN DT Analysis Collect 1NF as Warning

    XMLWordPrintable

Details

    • Bug
    • Status: Verified (View Workflow)
    • Major
    • Resolution: Done
    • None
    • 7.11.0.GA
    • DMN
    • None

    Description

      For the FIRST and RULE_ORDER we already emit a Warning that those tables are by their nature already violating the 1NF and we suggest a more appropriate Hit Policy.

      In any case as of today, if there are duplicate rules, we emit an Error of the 1NF violation for the duplicate rows/rules.

      This enhancement (DROOLS-6267) changes the behaviour for Collect hit policy tables only for this to be emitted as a Warning, instead of an Error.
      All other scenarios of duplicate rules unchanged (will remain reported as Error).

      Detailed Examples

      Example 1

      An genuine example where a 1NF violation message in C table is indeed meaningful
      Use-case: determine Hospital depending on status

      In this case [2,3] and [4,5] are violating the 1NF.

      In this specific case, this is indeed a Methodology issue and this table is better to be normalised (at the growing of symptoms, this table would become hard to manage).

      In this specific case, this can be normalised on Hospital (becoming each Hospital its own Decision "can treat yes/no") or alternatively with other ways like collapsing the duplicates and emit a list of hospitals, etc.

      Example 2

      Use-case: Trigger on drug expiration a set of notifications(plural intentional) to be dispatched via Process

      Of course the table can be way bigger, but the gist is that duplicate rules like [1,2] would increasingly be reported, related on the number of output fields of the Notification and input Triggers.

      Example 3

      Use-case: Determine SLAs(plural intentional) for loan applicant

      Comments on these examples

      We can always argue that all these C tables can be refactored differently, or even be refactored by including some BPMN steps too.
      But in all these cases it was a deliberate choice of the User to define it as a Collect table.
      All the users acknowledge the 1NF message content is valid, but the fact it is an Error made them think it was a showstopper for the use of the system.
      One User after the support clarifications mentioned also by themselves, they would be fine if this was reported as a Warning instead for the Collect table.

      Conclusion

      For Collect tables only to tune the 1NF duplicate rule message from Error to Warning.
      All other cases will remain as Error.

      Attachments

        1. screenshot-1.png
          screenshot-1.png
          36 kB
        2. screenshot-2.png
          screenshot-2.png
          47 kB
        3. screenshot-3.png
          screenshot-3.png
          62 kB

        Issue Links

          Activity

            People

              mmortari@redhat.com Matteo Mortari
              rhn-support-omolinab Oscar Molina
              Daniel Rosa Daniel Rosa
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: