Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-7222

Enhance specification of Excel2DMN utility

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • dmn engine
    • None
    • NEW
    • NEW
    • ---
    • ---

      As a DMN modeller, I would like to have more flexibility with decision tables from Excel. In order to work properly, the excel file should be in a formalised way. I would like these rules to be reconsidered, to enable the following features:

      1) Enable some way to explicitly declare a sheet to be transformed or ignored. This allows for extra sheets that could be relevant for the maintenance of the sheet, but are not relevant for transformation. It could be considered as comment. A suggestion to implement this is to ignore any sheet where the name of that sheet is different as the name of the output column. A warning about the ignoring could be in the log.

      2) Enable some way to explicitly declare a column in a sheet to be transformed or ignored. This allows for columns to contain comment. A suggestion to implement this is to ignore columns where the header of that column is empty. A warning about the ignoring could be in the log. 

      3) Enable some way to explicity declare the type of the column. Currently, after transforming into a .dmn file, all variables are of type <any>. Think of the excel sheet as something business people will maintain. That means, that whenever there is a change, the entire file will be transformed again using the utility. Any manual postprocessing after transforming should be avoided, because it is errorprone and combersome. A suggestion is to implement this by adding an extra row to the header, containing the type.

       4) Enable some way to explicitly define the hit policy of the table. Currently, after transforming into a .dmn file, the hit policy of each decision table is `Any`, and must be modified manually as a postprocessing step.

      I realise that these features will change the current specs. Feature 3) could even break it. If backwards compatibility is required, that might be solved by specifying version numbers for the formilization rules. The version number could than be given as a parameter when using the CLI. 

              tzimanyi@redhat.com Tibor Zimányi
              hanjoosten Han Joosten (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: