movizon CONTROL Script API Version 2022-10-27 movizon CONTROL Script API movizon CONTROL (mC) without script is only a framework. The software manages access and persistence of resource data and provides a sandboxed environment for scripts to implement logic and logistic. Scripts can utilize the latest JavaScript language standards and benefit from a high-performance engine in the background. Data Exchange Each script task has its own context that lives only as long as the script is running. The running state is different to the activation state. An activated script of type INTERVAl set to a one second interval will be triggered once each second but runs according to its load hopefully only some milliseconds. So the lifetime of any JavaScript object created during runtime is also only some milliseconds. Scripts can not memorize anything (this solves some data integrity problems of the old nashorn script engine). Any data exchange must be done via REST request in string format as this is the common understanding of resource data for scripts, JAVA core, browser UI and database. That requires constant serialization and deserialization. Overall, the scripter's design choices affect performance to a much greater extent than in previous versions of mC. The recommended approach is to keep string size and serialization/deserialization minimal. Avoid too long strings both in the keys and in the values of a resource, round numbers (2.8786511298432165 to 2.88), store values only if necessary and in just one place inside a resource object. Retrieve and parse resources once in your code. Always filter your GET requests to reduce parsing overhead (see REST API documentation for details). Intentionally there are no negated filters (like "get all fields except abc") because you never know what unwanted giant objects you might end up catching. Write single fields instead of the whole resource whenever possible. Also organize your resources into logical resource types in terms of size and task access (e.g. dedicated route resources in contrast to job resources with route field). Resource Locking Each script has one or multiple tasks that execute the code. A task for its own is always single-threaded, but all tasks together form a system where multiple threads attempt to access the same resources at constantly shifting times. The JAVA core synchronizes modifying REST requests within the same resource type, but that doesn't solve the following problem: Task A retrieves a state of a resource via GET, then after changing some fields writes is back to the core via PUT. Changes that are made to a single field of the same resource from task B after the GET request from A will be overwritten when executing the PUT request from task A. This can be solved by locking: Task A locks the resource before the GET request. All modification requests from other tasks/threads are queued now, including the change request from task B. Task A performs the PUT request and unlocks the resource. Now the queued change request from task B can be executed. But if task B would also want to change the entire resource, its PUT request would overwrite the carefully locked change from task A completely. Task B could take the changes of A into account also by locking, but this would slow things down unnecessarily.

movizon CONTROL Script API Version 2022-10-27 moi/izon The recommended approach is to have only one manager task per resource type, the only one that writes entire resources. This manager does the locking. All other tasks that interact with the same resource type only write single fields without locking. In addition to locking, there is a second technique to ensure resource integrity: With field reservation a script can specify that only itself can change certain fields of a resource. Imagine a vehicle manager script that cyclically retrieves raw data from an interface and calculates the position...

movizon CONTROL Script API Version 2022-10-27 moi/izon Example String getType()

movizon CONTROL Script API Version 2022-10-27 moi/izon Description