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

Stunner does not read all parameters defined in WID

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Done
    • None
    • None
    • Designer
    • 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)
    • NEW
    • NEW
    • ---
    • ---

    Description

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

      Acceptance Criteria

      Custom Tasks by default have same parameters, icons, categories and other parameters as WID in the engine.

      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.
      
      "

      Attachments

        Issue Links

          Activity

            People

              kgaevski@redhat.com Kirill Gaevskii
              ftirados Francisco Javier Tirado Sarti
              Lubomir Terifaj Lubomir Terifaj
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: