Storing Groovy scripts through FileDescriptor and using them in Scheduled Task

Ideas
#1

Hi,

i tried out the Scripting feature which allows me to dynamically run code that sits in configuration directories outside the war file. Using that together with scheduled tasks is pretty interesting.

But i was thinking about one feature that would be a little more convenient: Instead of referencing the groovy scripts just by name in the scheduled task, would it be also possible to store the information in the database (the source code) or just as references to a sys$FileDescriptor which holds the groovy file. This way the administrator would be able to execute code while not having the need to access the filesystem of the server directly, but instead go through the UI of CUBA. This might either be because of laziness or perhaps because of security or organisational reasons as well (the tomcat admin doesn’t need to be the same person as the app admin).

Since pretty much all building blocks are already there (like sys$FileDescriptor entity, the SourceCodeEditor as well as the scheduled tasks or the scripting interface to execute code dynamically), it would be cool to see coming all of this together and create another cool feature.

It could be up to the app dev to decide to develop something like this, but perhaps this is something a lot of people are interested about.

Bye
Mario

#2

Hi Mario,

We’ve thought about some convenient facilities to execute Groovy and/or JPQL scripts from administrative UI and scheduled tasks, but never had time to implement it. So I’ve created an issue, hopefully we’ll deal with it in the near future.

#3

:ticket: See the following issue in our bug tracker:

https://youtrack.cuba-platform.com/issue/PL-8687

#4

Hi,

Following the issue tracker, it seems that it is suggested that we use the Admin-tools addon.

But I agree with Mario that what we need is a mechanism or method for Scheduled Task to execute Groovy scripts which are stored in the Database records OR files uploaded via the File Upload mechanism, without all the other additional functions (shell, SQL, etc).

The use case for this is to allow for customer-specific scripts (data uploading,housekeeping, integration, etc) to be created on site and executed on schedule, rather than hard coded in the source code.

Can you re-consider Mario’s proposal please ?