Can we add 'hiddden' property in JavaTask

[jjfutt]

We'd like to know if we can add a hidden property in the interface definition of a JavaTask (when implementing custom JavaTasks for the palette), that are not available for the creators of itinerary/orchestration designers, but can be retrieved by the JavaDelegate implementation class.

For example, the screenshot below shows two properties (isBillable, and demoDate) being exposed for the JavaTask in question. If we wanted to hide one of these properties, (and just hardcode its value), it would allow us to keep it hidden from the Process Authors yet make it available to the delegate implementation class. Is this possible?

[attachment=0]JavaTask-InterfaceScreenshot.png[/attachment]

Thanks in advance.

[tiesebarrell]

Hi,

no, there's no way to do that at the moment if you mark the property as a @Property. But since you're hard coding the value, that would mean you're dependent on the CST anyway from your Delegation, so if you simply put a static value in the CST, you could solve it that way. Or am I missing the point?

[jjfutt]

Hi Tiesebarrell:

Thanks for responding.

I am not sure what you meant by 'CST' - but I kind of understand your suggestion. Yes since the value is hardcoded, in my Java Implementation (that implementation JavaDelgate or ActivityBehavior interface) I can call 'WhateverSericeInterfaceDefinition'.getHardCodedValue(); However, that would be our last resort. Our first choice would be to able to say in the implementation class

execution.retrieveAllPropertiesOfTheCallingJavaTaskInterface();

This way, the implementation class doesn't have to know the exact class that was use to define the JavaTask node in the Service Palette.

Did I explain it properly?

Any suggestions or hints would be welcome.

[tiesebarrell]

Ah, I see. BTW: CST means CustomServiceTask, which is what you are making

Well, I don't think you'll be able to do that. The reason for this is that the BPMN that's executed for the process is in no way related to the modelled CST other than the properties are in Activiti-specific fields. The only way to get information from one to the other is through injected properties as you've been using or by using a static reference.

What you could do, which gets you a little closer, is to have the fields injected in the delegate, annotate them yourself (e.g. with your own annotation) and then create some kind of abstract class that contains a way to read all of those annotated properties. Since you're looking for specific things in the properties however, I don't really see a real advantage to that, since you're basically creating a general list of properties from a specific set, while you're also looking for specific properties in the first place. Seems like a lot of work with little purpose. Maybe I don't really understand what you're after.