Andreas

Hi Rafael, Technical Hurdles We recently identified the limitation of boolean and numeric input fields in a YADE configuration not allowing use of variables. This is available starting from release 2.8.3. Automation & Management: The approach looks good to me. You will have considered holding the JSON format of Workflows Templates in your database (it comes with challenges generating the JSON for workflows and jobs from a script). You might think using JS7 - Job Templates that you manage with JOC...

Hi Daniel, thank you. We recently identified the problem which is confirmed by your post. The issue is addressed by JOC-2222: Deployment History should consider relocation of workflows We will check for a workaround in the next few days.

Hi Rafael, it's somewhat ambiguous that you post to the "Early Warnings" forum. Whom do you want to warn? When you're done, then maybe we can move the thread to the 'Success' forum :) Let me suggest that I will take the role to question your assumptions: thousands of different workflows: Most probably you will not need this. Workflows are triggerd by orders that can hold variables. The variables can be injected in your YADE XML configuration using the ${variable} syntax. This allows designing generic...

Question about the recommended ownership and permission model for JS7 Controller when using js7_install_controller.sh

Hi, for simplicity and clarity, I recommend applying the same ownership layout to both Controller and JOC Cockpit. Which of the two options discussed in this thread you prefer, is up to you: The fact that directory permissions are relevant for shared access to files, is how Unix file systems work. You could say, a Unix admin knows. And you could say, it's a hurdle that is not immediately evident to everybody. Both statements are true. Using a shared group makes things evident to everybody. It further...

Question about the recommended ownership and permission model for JS7 Controller when using js7_install_controller.sh

Hi, while permissions for controller_instance.sh look good, a prominent reason for failing permissions is the fact that all directories along the hierarchy of /opt/sos-berlin.com/js7/controller/bin|lib must have the executable bit set individually. Other than that, directories owned by root will not be readable to the scheduler user account. Instead of relying on world executable permissions, that allow any account executing the Controller Instance Start Sript, you can use a shared group for owners...

Hi Josias, concerning your questions: If you use a schedule, then you do not use file watching. This means the workflow will start only when scheduled. If you use file watching, then you do not use schedules as orders are created automatically from incoming files. Definitely not. In addition it creates overhead from unsuccessful polling when no files are present. File watching is the preferred approach for near real-time triggering of workflows. If you want to limit execution of the related workflow...