Andreas

Hi Chico, are you referring to the uxdat utilitly available from $U? This is not easily available from JS7 - though it is an interesting feature. Find the proposed solution from the JS7 - How to calculate processing dates using REST Web Services article. I feel doubts that this will make it for a design award. However, we will think moving this to a rule based approach that should be configurable for variables in a schedule. Concerning permissions, you can have two sets of roles holding view permissions...

Hi Kevin, your use case is not about dependencies ("proceed with Order 2 in Workflow B when Order 1 in Workflow A passes a certain node") but about conditions ("if file name = xxx in Workflow A, then start Workflow B"). Your use case suggests a design for Workflow A like this: Job1 .. Job n Case CaseWhen: $filename == "file-B" Job: move file to folder /tmp/B AddOrder: variable: incoming_file = '/tmp/B/' ++ $filename CaseWhen: $filename == "file-C" Job: move file to folder /tmp/C AddOrder: variable:...

Hi Kevin, Notices are not variables that carry values, they are more like events that indicate from their existence if something happend or not. File Order Sources generally cannot be easily parameterized (as opposed to Schedules). Let me put it straight: if the workfow using the ExpectNotices Instruction or ConsumeNotices Instruction needs access to variables of some other workflow that makes use of the PostNotices Instruction, then your workflow design is wrong. In this case both workflows would...

Hi Josias, this is not a cleanup procedure, this is "initial operation" and is therefore discouraged if the purpose is regular maintenance. When dropping the Controller's and Agent's ./state directory you wipe their memory about registration with a Controller, about orders that have not been completed or that are scheduled for a later date. This is why you have to perfrom "initial operation" by forcing the Controller Cluster to couple and resetting Agents to couple them with the Controller. The ./logs...

JS7 JobScheduler LTS Release 2.9.0 available

Hi Kevin, this is currently not available. However, I appreciate the feature request. Next week the JS7 2.9 will be published that brings a new help system, tooltips and glossary. When this is done, we will check to make this available.

JS7 JobScheduler Last Public Maintenance Release 2.8.4 available

Hi, the warning is due to an bug in the log4j2.xml configuration file available from the <jetty-base>/resouces/joc directory that holds the line filePattern="${sys:user.dir}/../logs/service-reports-%d{yyyy-MM-dd}-%i.log.gz" which should be filePattern="${sys:user.dir}/logs/service-reports-%d{yyyy-MM-dd}-%i.log.gz" The message that you find in jetty.log is not harmful though it is qualified an ERROR. The indicated log file is used by the reporting feature that changes its working directory at run-time....