Uploaded image for project: 'Red Hat Process Automation Manager'
  1. Red Hat Process Automation Manager
  2. RHPAM-2695

Component timer expression contains errors

    XMLWordPrintable

Details

    • Documentation (Ref Guide, User Guide, etc.), Release Notes
    • CR1
    • +
    • Hide
      1. In Business Central clone the project from repository: https://github.com/mfpc/bugtimer
      2. Open the process "processo.bpmn"
      3. Click on Boundary Catching Timer event and see the Properties panel -> Implementation/Execution
      4. Set the Fire multiple times property to the value: "R5/2020-02-07T15:36:00Z/PT5S"

      Actual result

      The filled expression is not valid.
      A warning message is shown.

      Expected result

      The filled expression is valid.
      No warning messages are shown.
      Any input String is validated according to ISO-8601 standard for all Timer Settings properties. However, the input String is valid only in case it is supported by jbpm engine.

      Show
      In Business Central clone the project from repository: https://github.com/mfpc/bugtimer Open the process "processo.bpmn" Click on Boundary Catching Timer event and see the Properties panel -> Implementation/Execution Set the Fire multiple times property to the value: "R5/2020-02-07T15:36:00Z/PT5S" Actual result The filled expression is not valid. A warning message is shown. Expected result The filled expression is valid. No warning messages are shown. Any input String is validated according to ISO-8601 standard for all Timer Settings properties. However, the input String is valid only in case it is supported by jbpm engine.
    • 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25)

    Description

      If I put syntactically *correct* iso expression (for example the one above) in a boundary timer event, Designer evaluates it as syntactically incorrect (wrongly) and doesn't allow me to save the process. Screenshot:

      https://ctrlv.cz/dxqt

      Expected behaviour:

      Syntactically correct ISO expressions should not be incorrectly picked up by designer as syntactically incorrect.

      ISO-8601 expressions that are not supported in engine

      These expressions are not considered as valid expressions in Designer either:

      Expressions in both Fire once after duration and Fire multiple times properties

      • The other fractions than second fractions are not supported. For example: "P5Y1M4DT13H30.5M", "P5,6Y2DT13H35M".

      Expressions for both Fire multiple times and Fire at specific date properties

      • Calendar date formats are not supported:
        • `YYYYMMDD`. For example: "20300802T22:30:00+02:00".
        • `YYYY-MM`. For example: "2030-08T24:59:00Z".
      • Week date formats are not supported:
        • `YYYY-Www` For example: "2025-W15T22:30:00+02:00".
        • `YYYYWww` For example: "2025W52T22:30:00+02:00".
        • `YYYY-Www-D` For example: "2025-W01-6T22:30:00+02:00".
        • `YYYYWwwD`. For example: "2025W157T22:30:00+02:00".
      • Ordinal date formats are not supported:
        • `YYYY-DDD`. For example: "2030-254T22:30:00+02:00".
        • `YYYYDDD`. For example: "2030365T22:30:00+02:00".
      • The time formats are not supported:
        • `hhmmss`. For example: "2030-08-20T245900+02:00".
        • The fractions:
          • They are not supported at all.
          • It should be possible to use fractions to any of the three time elements. However, a fraction may only be added to the lowest order time element in the representation. Either a comma or a dot can be used as a separator. For example: "2030-08-20T245901.15+02:00", "2030-08-20T24,5+02:00".
        • `hh`. For example: "2030-08-20T23Z".
        • `hhmm`. For example: "2030-08-20T2214-00:30".

      Fire multiple times property

      • The property doesn't accept these time zone formats:
        • `±hh`. For example: "R1/2020-05-12T18:25:00+02/PT5S".
        • `±hhmm`. For example: "R1/2020-05-12T18:25:00-0230/PT5S".

      Fire at specific date property

      • The property doesn't accept these time zone formats:
        • `±hh`. For example: "2021-03-12T10:50:00-01"
        • `±hhmm`. For example: "2021-03-12T10:50:00+0130"

      Attachments

        Issue Links

          Activity

            People

              handreyrc Handrey Cunha
              rhn-support-mpessanh Marcell Pessanha Cruz
              Lubomir Terifaj Lubomir Terifaj
              Lubomir Terifaj Lubomir Terifaj
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: