We would like to have an equivalent task.schedule("<script>.py") implementation for Plugins written in Java/Groovy.
In our use case, we have multiple plugins (e.g., Jenkins) that require asynchronous functionalities on tasks for handling request and response messages in paused or delayed scenarios. This is currently not possible for tasks written in Java/Groovy waiting in the “In progress” state. But it is necessary to stay performant in digital.ai release.
Custom Plugins in Java improve the custom-plugins quality and testing durations due to the compile capabilities, and it avoids using obsolete jython interpreter calls.
This could be a first important step for replacing the end of life of jyhton Version 2.
by: Daniel R. | about a year ago | API & CLI tools
Comments
Thank you for the idea, Daniel.
We would like to have a follow up discussion on this request, and the benefits container-based integrations might bring. I will ask your CSM manager to organize one with Hes, our Product Manager.
One way to solve it is to implement core functionality of custom tasks in Java and have a thin wrapper in Jython around it that does the scheduling.
The Jython part would do the following
- Create a new Java object of the custom library. Since it is Jython (not just Python) we have direct access to Java classes
- Call method on Java object with input properties
- Use task.schedule() to schedule next part
- Or put the result of the call in the output properties
There would be no business logic in the Jython script.
Have you considered this approach?
Yes, we have considered this approach and rolled it out. Unfortuantely it is verfy cumbersome implementing multiple async data flows for cross functional communications to always go through the wrapper. This requires multiple wrapper for each flow which intends additional logic on the wrapper site.We want to avoid that. For instance we have a custom Jenkins Plugin in Java with a strong focus on test automation. This requires shedule waiting for jobs multiple times and covers various logic edges which makes the whole plugin very complex and incomprehensible. We prefere and implement all libraries and plugins mainly in Groovy or Jython and want to avoide the usage of jython.
edit: ..mainly in Groovy or Java and want to avoid the usage of jython.