After completing this lesson, you will be able to:
hello_worldruleset from the Quickstart registered in the pico engine, and installed in a pico
A pico (quoting from Rebuilding KRL):
The Sky Event API describes the event API pattern for a pico including what components are important and how those components are encoded in an HTTP method (GET or POST). The specific API for a given pico, however, depends on which rules are installed since it is rules that respond to events. Similarly, the Sky Cloud API defines the patterns for queries that a pico understands. Again this is a meta-API since the queries that any given pico responds to depend on the modules installed. Queries are thus implementable with different code than the event processing and, in practice, tend to be much faster.
A pico has multiple URL's that can be used to query its state and send it events.
Here is a sample URL that sends an event to a pico like the one you created in the Pico Engine Quickstart:
Breaking this URL into components:
Here is a sample URL that sends a query to a pico:
This URL shares some components with the URL above for an event. The new components are:
As you can see in the URL for events and queries, channels are the way in which a pico can be identified by the pico engine.
A pico can have multiple channels. Best practice is to create a channel for each purpose or correspondent. There are several reasons for this:
Each channel has a name and a type.
To create a new channel, visit the "Channels" tab:
Note that the channel identifiers you will see are assigned by your pico engine, and will differ from the ones seen in these screenshots.
Enter "lesson" in the box whose placeholder is "name" and "temporary" in the box whose placeholder is "type" and click the "add channel" button to create a new channel.
Congratulations! You have created your first channel.
Note that you are able to delete channels that you create.
Make a note of the event channel identifier (ECI) assigned to your temporary channel. You will be using this "lesson" channel throughout the rest of this lesson.
Since a pico is a first-class Internet citizen, there are many ways in which you can send it an event. We will look at three such ways here:
Construct a URL that identifies your Pico by the channel id that you created in the previous section. Remember to replace the channel identifier in the sample URL with the identifier of your "lesson" channel. Also, you may choose your own event identifier (rather than use "5", as we did for this screenshot).
You can use the URL in any Internet client. For example, you could use it in the `curl` command in a Bash shell.
Here we will use a tab in the browser. Place the URL in the location area of your browser, and press the Enter key.
The result will look something like this:
Congratulations! You just received your first directive from an event you raised.
Directives allow picos to direct endpoints to react a certain way to an event. Our rule's directive just says hello, but it could be used to do more complex things. Directives allow the program's logic to be placed in the rules, not in the end points. Placing logic in the rules provides loose coupling with easier scaling and maintenance.
The Kynetx event console is a Google Chrome application that you can add to your browser to make it easy to send events. You can find it on GitHub and install it into your browser following the instructions. You can then launch it and enter in the host:port of your pico engine, the channel identifier and the event domain and type. You will need to un-check the box beside "Use HTTPS".
Click the "Raise Event" button to send the event to your pico engine, and the app will scroll to the Results section, where you can see the directives generated by your event.
Notice that the event identifier was chosen by the event console.
When you develop a ruleset, you may choose to use the "Testing" tab of the "My Picos" page which can provide a simple UI for your event. The "Testing" tab works by querying your ruleset to see if it shares the name
__testing and if it does, it parses the structure that
__testing points to and builds simple forms to test each of the queries and events which the structure defines.
The value bound to
__testing is a structure that describes those portions of our ruleset that we wish to expose in the "Testing" tab. You do not need to expose every aspect of your ruleset, but only those that you wish to appear in the "Testing" tab.
Add this code into the global block of your ruleset:
You have added a new name,
__testing (double underscore), which defines two queries and one event, to the "global" block of the ruleset.
This name must also be shared, so you will need to add it to the "shares" entry in the "meta" block of the ruleset. The "shares" keyword is followed by a comma-separated list of names defined in the globals section which we wish to use outside of the ruleset. Any names not mentioned in "shares" are for the private use of the the ruleset and are not exposed outside the ruleset. Edit the "meta" block of your ruleset to look like this:
Be sure to validate your source code, using one of the techniques in Developer Tips for Pico Engine to ensure that you have introduced no syntax errors into your ruleset. Once you get the "ok", go ahead and push your changes and re-install the ruleset into your pico. (Review the Pico Engine Quickstart page if necessary)
Refresh your "My Picos" page, and click on the "Testing" tab. Notice under your ruleset identifier that there are three forms, one for each of the queries and the event that you described in your ruleset.
Notice the button "echo/hello", representing this event for your ruleset named "hello_world". Click on this button to send the event.
Notice in the directive returned by the event that the "Testing" tab uses the event identifier "__testing".
Look at the console from which you started your pico engine.
You should see entries like this one:
This console log may be useful in debugging events.
For example, try introducing a typo in the URL for the event, say by spelling "echo" incorrectly as "ecco". In the console log, you will see that the event is received, and the Pico selected (based on its ECI), but you will not see that the event has fired.
Create a URL for your Pico which uses your "lesson" channel identifier. It will look something like
Places where your URL will differ from the one shown above:
Enter your URL into the location line of your browser, or use it in a `curl` command in a Bash shell.
You can also enter the value for the argument in the "Testing" tab, in the box whose placeholder is "obj", and click on the link "hello".
Congratulations! You know how to send queries to a pico, either directly using a URL, or through the UI.
KRL provides an operator, klog(), which allows us to print information into the logs. It is an operator, rather than a statement, so it is applied to an expression. It prints into the log the message passed to it as an argument, followed by the value of the expression on which it operates. Finally, it returns the value of the expression on which it operates, unchanged. This makes it easy to add to or remove from your KRL code without changing its meaning.
As an example, modify your "hello_world" rule to expect an attribute, named "name" and use it to customize the message returned in the directive.
Modify your rule so that it looks like this:
This is the first use in these lessons of a prelude block within a rule. This is where we bind values to names which can then be used within the rule. Here, we obtain the value of the event attribute named "name" and bind that value to a name which is also named "name". We apply the "klog" operator to that value, which simply passes the value along, but as a side-effect logs its argument followed by the value.
Let's also modify the structure bound to
__testing, as follows:
After making these changes to your ruleset, be sure to validate it, then push your change, and re-install into your pico.
With these changes, refresh the "Testing" tab and you can now enter a value into the box whose placeholder is "name" before clicking on the "echo/hello" button to send the event.
Examine the terminal or console from which you launched your engine. You will see the expected message from the klog operator, which will look like this (embedded in other logging messages, just before the rule fires):
Click on the "Logging" tab for your pico.
Notice that logging is disabled. The ruleset required for logging is pre-registered in your pico engine. Click on the "Rulesets" tab, and notice that it appears in a dropdown list named "Available Rulesets".
Click on the "install ruleset" button to install the "io.picolabs.logging" ruleset in your pico.
Click again on the "Logging" tab.
Logging is now available for this pico, but is turned off. Click the "On" button, and refresh the "My Picos" page.
You should see one episode, for the event that turned logging on. Now go to the testing tab and do a query and an event for your hello_world ruleset. Refresh the page, and you will see logging episodes that match your testing activity. Select a couple of these to see the detailed logging.
Here we see the logging for a query and an event.
You now know how to send events to, and make queries of, a pico. You have also learned some debugging techniques.
Next, learn about persistence, the "P" of pico, by working through Pico State Lesson.
Do the following:
ecco/helloto your pico. What do you observe? Why?
echo/monkeyand responds with "Hello Monkey" unless an event attribute named
nameis given, in which case it will respond with "Hello " followed by the given name. Hint: use the
.defaultsTo()operator. Use the
.klog()operator to log the value that is used.