Calculating derived attributes using java instead of Javascript
Hello everybody
It is possible to use Java code inside advisors to calculated derived attributes instead of javascript? If I put the code in Participants then, the workItem was already saved and you have to save it again, but it is possible to modify workitemNew with your own modifications to save? Thanks
Accepted answer
Hi Amaury,
you can use Java to do things like that. You can not use an Advisor if you want to modify the element that triggers the save. An advisor should advise and not modify anyway. You need to do it in a participant, if you want to update the work item that triggered the action. See https://rsjazz.wordpress.com/2012/07/31/rtc-update-parent-duration-estimation-and-effort-participant/ as an example that updates a parent. However, you could also update the triggering element in the participant as https://rsjazz.wordpress.com/2012/11/30/a-create-approval-work-item-save-participant/ shows.
You can also create a Java Extension as value provider instead of JavaScript that shows up in the Attribute Customization section, as described here: https://rsjazz.wordpress.com/2013/06/26/attribute-customization-java-based-value-providers-conditions-and-validators/
The limitation of providers is, the return value only works for the attribute it is configured for.
you can use Java to do things like that. You can not use an Advisor if you want to modify the element that triggers the save. An advisor should advise and not modify anyway. You need to do it in a participant, if you want to update the work item that triggered the action. See https://rsjazz.wordpress.com/2012/07/31/rtc-update-parent-duration-estimation-and-effort-participant/ as an example that updates a parent. However, you could also update the triggering element in the participant as https://rsjazz.wordpress.com/2012/11/30/a-create-approval-work-item-save-participant/ shows.
You can also create a Java Extension as value provider instead of JavaScript that shows up in the Attribute Customization section, as described here: https://rsjazz.wordpress.com/2013/06/26/attribute-customization-java-based-value-providers-conditions-and-validators/
The limitation of providers is, the return value only works for the attribute it is configured for.
One other answer
Thanks for your answer Ralph,
I did exactly the same you propposed in your excelente review
https://rsjazz.wordpress.com/2012/11/30/a-create-approval-work-item-save-participant/
That works, but in that case you save the current workItem twice and I was looking to avoid the 2 saves operation for performance reasons, if you dig into the workitem history, you can tell the 2 operations
Thanks!!!
Amaury
Comments
Hi Amaury, if you want to avoid the second safe, you would have to use a java Based provider. Some examples are here: https://rsjazz.wordpress.com/2013/06/26/attribute-customization-java-based-value-providers-conditions-and-validators/. You would basically calculate the value in Java instead of JavaScript. It is harder to deploy, because you will have to deploy it on client and server. The follow up action works for all clients and also if you use the API, whereas the provider only work for the Web UI and the Eclipse client if the providers are deployed. JavaScript would avoid deploying, but would also not work with Visual Studio or API calls.
Thank you very much Ralph
It is a good solution, but I think in terms of simplicity, I prefer the previous one (two saves) because in our case we need to update more than one attribute at the same time, depending on other values, the we would need to create one Provider for each one (too much work) and beside that the logic will be split in 2 parts, (not good for maintenance purposes)
the second approach wiil work for other purpose and I wiil start to use that way, thank you!!