Common pitfalls with GpsGate Scripting
If you've already read Script Expressions and Tips when developing Script Expressions and started scripting but got stuck, this article should help.
Good Questions - Save Time!
- What states do I want in my state machine?
- How do I move between these states?
- What should happen when moving between the states?
- Have I written the above state diagram that solves my business case?
- Have I updated all plugins?
Start coding if “yes”!
Tips & Tricks
There is only one screen dump in this blog, see below. All the numbers you’ll find here, are found in that screen dump.
Testing your script with real data
Your “Exposed objects and test values” on your right, see “4” below, will be automatically updated when clicking on a user and its track points, see “2” below, with some exceptions described further down. Documentation is found in “1” by clicking on the respective object.
Test what happens when moving between different states. You can create suitable test data triggering these moves with the device simulator to speed up the work. But remember that not all objects, in the test environment, are updated when clicking on a user and its track points, e.g. the session objects: user, vehicle and driver. Those objects will always include the latest data sent to the server. At least you can be sure of that what you have under “Exposed objects and test values”, (see “4”), is the input to your script.
Recreate the problem
Please export the event rule and relevant track points, matching your screen dumps, as well as a screen dump of the mapped variables in your device mapper, so that we can easily recreate the issue, in case we suspect a bug in our platform.
When working with states, make sure to initialize them correctly. Here’s one example taken from another article.
Use the context.state text box to monitor the state while testing, (see “4” in screen dump). Make sure to empty this text box when testing the initialization.
Keep in mind that the script is run once for each track point.
With the EV1000 Event Rule, use context.setVariable(“Variable1”, variable); and in 5.Notifications use the type Report Argument in which you fill in the header name e.g. “Header Name” and value e.g. “Variable1”.
Later in the EV1000 Event Rule Report, the first Report Argument in the list, will be found in [EventArgument], the second one in [EventArgument01], the third one in [EventArgument02] etc.
Keep in mind that these event arguments will be assigned with values taken from e.g. “Variable1” only when the event rule goes from true to false, resulting in a row in the Event Rule Report.
Explain what you actually expected and why!
We’re constantly building on our scripting capabilities. Therefore, please let us know if you would like to have a new feature. Be sure to explain how it would help your customers be more profitable.
Should you see unexpected behavior of our platform, please state how the behavior doesn’t match our documentation, (see “1”) and send one or several screen dumps to firstname.lastname@example.org:
- The problematic track point highlighted, (see “2”) and its data found in “Exposed objects and test values”, (see “4”).
- The test output of the script, (see “3”)
- The context.state text box if states are used, (see “4”).
- Explanation what you actually expected and why, see template below.
Ticket Template for Unexpected Behavior
One way to explain your unexpected behavior is this:
According to the documentation, the object context.state is supposed to “store data between evaluations” (see “1”).
Now, for the track point of X (see “2”), state.DriverOrVehicle returns “undefined” (see “3”), despite of what we see in the text box for the context.state,(see “4”), and despite of [...] shown in my other screen dumps (see “XY”).
I don’t see how the test output (see “3”) makes sense in my particular case. What more should I look at to make sure that everything is working as it should, and that the unexpected behavior is not from the server, but from the script or even from the state diagram?
See attached screen dumps, relevant exported track data, state diagram and event rule.
Direct questions about features to support!
We can answer direct questions related to the features in GpsGate, but that does not mean we will develop a script for you, or troubleshoot complex customization you might have created. Only provide solutions to your customers that you understand and can control. We can also give you a contact to a GpsGate Solution Provider who might be able to help you with your customization needs, including scripting.