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

Stunner does not read all parameters defined in WID

XMLWordPrintable

    • False
    • False
    • Release Notes
    • CR1
    • ?
    • Undefined
    • ---
    • ---
    • 2020 Week 40-42 (from Sep 28), 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30)

      WID are out of sync with engine Custom Tasks. They should be synchronized.

      Initial jira issue and discussions

      Stunner is not reading all parameters in WID and exposing them as DataInput Assignments.
      
      Examples are the built-in Rest WID and EMAIL WID, which does not have all the parameters declared in WID exposed in stunner due to this bug.
      
      Below an old requirement to enhance Rest WID, when runtime team investigated the issue to implement it was noticed that actually all parameters was there, so the issue is actually in the editor side.
      
      ------------
      
      Feedback from Andy Yuen:
      
      "
      
      The Rest service task's default 7 input parameters are not sufficient to call a non-trivial Rest service:
      
      [
       "name" : "Rest",
       "parameters" : [
       "ContentData" : new StringDataType(),
       "Url" : new StringDataType(),
       "Method" : new StringDataType(),
       "ConnectTimeout" : new StringDataType(),
       "ReadTimeout" : new StringDataType(),
       "Username" : new StringDataType(),
       "Password" : new StringDataType()
       ],
       "results" : [
       "Result" : new ObjectDataType(),
       ],
       "displayName" : "REST",
       "icon" : "defaultservicenodeicon.png"
       ],
      
      In my opinion, to provide something usable out-ot-the-box, it requires at least 2 more parameters:
       ContentType
       ResultClass
      
      The first one is used to specify "application/json", without it, the handler will fail to transform the ContentData object
       The 2nd one is needed to return a non-trivial result by specifying its fully qualified class name. Without this parameter, the handler will not be able to "transform" the result into the kind of object targeted.
      
      This is a simple thing to do, I am baffled why the default "WorkitemDefinitions" did not include these 2 parameters leaving the user wondering why his Rest call is not working and spending considerable time trying to resolve it.
      
      "

      Acceptance Criteria

      Custom Tasks by default have the same visual parameters, icons, categories and other parameters as current implementation (at the time when the PR is reviewed/merged) of WIDs in the engine.

      • WIDs can be found in work item handler classes in org.jbpm.process.workitem package in jbpm repo.

      No dynamic updates are implemented by this bug-fix.

      • As a result, in case the WID is changed only in the engine, the bug will be probably present again.

        1. added parameters.png
          55 kB
          Kirill Gaevskii
        2. parameters in new task.png
          73 kB
          Kirill Gaevskii
        3. Screenshot from 2020-10-13 20-04-08.png
          46 kB
          Ivo Bek

              kgaevski@redhat.com Kirill Gaevskii
              ibek1@redhat.com Ivo Bek
              Lubomir Terifaj Lubomir Terifaj
              Lubomir Terifaj Lubomir Terifaj
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: