Custom workitem handlers not supported

[matus-m]

The VS code version of the editor does not seem to support custom work item handlers. The custom WIH can be defined in /src/main/resources/META-INF/WorkDefinitions.wid when using the java/maven structure for kjars. Is there a way how to register custom WIH in VS code BPMN editor? Expected behaviour: Custom WIH should be visible in the pallete under service tasks, or under custom group. The properties panel should support edit of custom properties for custom WIH nodes. Thanks

[ederign]

Hi @yntelectual first of all, thanks for using our tools!

On VS Code extension you can add your WID files to the same folder of your BPMN or after, 0.9.0, in the 'global' directory of your project (on the same level of your src folder).

Please let me know if this works for you.

[matus-m]

hi @ederign thanks for quick response, unfortunately I cant get it to work. I am using the 0.9.0 version, and tried to move the .wid file both to project root and next to the .bpmn file but the editors still does not recognise the custom WIH( neither in palette not when I click an existing node of such WIH in editor) Here is the .wid (working fine when used in the Eclipse/RHPAM editor)

import org.drools.core.process.core.datatype.impl.type.StringDataType;

[
    [
        "name" : "ProcessMessageDrivenWIH",
        "displayName" : "Process message Driven WIH",
         "parameters" : [
             "autoRetryEnabled" : new BooleanDataType(),
             "autoRetryMaxCount" : new IntegerDataType()
         ]
    ],
    [
         "name" : "BusinessErrorHandlerWIH",
         "parameters" : [
             "resolutionSignalId" : new StringDataType(),
             "referencedStepId" : new StringDataType(),
             "resolutionActions" : new StringDataType()
         ],
         "displayName" : "Business Error Handler",
         "icon" : ""
    ]
]

Has the format of the file changed perhaps? Or could you point me to the corresponding documentation if there is any?

[tiagobento]

@yntelectual Hi! So I just gave it a try and yeah, this WID file you shared is indeed not working. However, if I remove the first line with the import, I get the icons appearing. cc @romartin.

Please note that WIDs are fetched from two locations:

1. <workspace-root>/global/*.wid
2. ./*.wid

In your case I can see you have the WIDs on the same diretory as the process, which is ok.

[romartin]

Thanks guys for your feedback and research on this. I'm also agree with the above comment from @tiagobento , it looks parsers are not properly parsing the import statements. Will let @hasys to take a look on this and if any problem exist, just try to fix / report it.

Please @hasys can you quickly take a look on this? If some fix is required, maybe can we introduce it within the actual PR also related to WID parsers? https://github.com/kiegroup/kogito-editors-java/pull/19 WDYT?

Thanks in advance!

[hasys]

Hi @romartin, current PR already approved, so I suggest to move it further if no other issues will be found.

In general I guess it will be good to remove import statement since it is not used even in the Business Central. I suggest just show notification that WID file should start with [ symbol or whitespaces.

[romartin]

@hasys thinking about imports... maybe it makes sense from the runtime point of view, not sure how the parsers on runtime handles it. The thing is that in case using any of our built-in datatypes (eg: StringDataType) there are no issues, but in some (not common) case where a user creates it own datatype, if not using the import declaration on top of the mvel file, he should be instantiating the datatype by using FQCN again and again. Does this makes sense to you?

@ederign @yntelectual The workaround to this is just to remove the import declaration on top of the mvel file. We're keeping track of this topic (RHPAM-3619), so we'll provide feedback as soon as possible, but hope you go ahead with your work @yntelectual

So a a fix has been introduced, there exist workaround for the import thing, and other issues being tracked as well on JIRA, I think this github ticket can be closed. Any comments or concerns about closing?

Thanks everyone for the feedback and collaboration!

[ederign]

@yntelectual while RHPAM-3619 is not ready, please use the workaround described by @romartin !

If you need anything else just let us know!

Thanks again for using our tools.