Learning Objective

After completing this lesson, you will be able to:

Motivation

When thinking about the idea of a pico, you have to understand that a pico is essentially a digital representation of "something". That "something" could be physical (like a temperature sensor) or conceptual (like a collection of sensors). The KRL rulesets installed on a given pico perform the magic that makes this digital representation behave the way you expect. And yet, how does a pico stay in sync with its physical device? How does it keep track of the new sensor you just added to the collection? How does it provide data to outside sources like web apps, or even a terminal using curl?

Here enter Events and Queries. Queries are very simple because the only thing they can do is call a function. This function is defined in the global block of a KRL ruleset installed on your pico. As a result, a query is not capable of changing state or taking action (like sending a text message). On the other hand, events can modify state and perform side effects. Incoming events are handled by the rules defined in a KRL ruleset.

This lesson aims to teach you how to send Events and Queries to a given pico.

Prerequisites

Contents

Video Tutorial

video shows an older developer UI

It is still correct in its discussion of picos and KRL, but doesn't match the current developer UI


Pico as an internet citizen

A pico (quoting from Rebuilding KRL):

Picos respond to events and queries using two different URL formats. Events are sent to a pico using the Sky Event API. Queries are made using the Sky Cloud API. 

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 rulesets 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 rulesets 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.

events

Here is a sample URL that sends an event to a pico like the one you created in the Pico-Engine Quickstart:

http://localhost:3000/sky/event/ckcvuri6r0017conl4siq0q3r/1556/echo/hello

Breaking this URL into components:

queries

Here is a sample URL that sends a query to a pico:

http://localhost:3000/sky/cloud/ckcvuri6r0017conl4siq0q3r/hello_world/hello?obj=Bob

This URL shares some components with the URL above for an event. The new components are:

Create a Channel

As you can see in the URLs 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 unique identifier and one or more tags, along with a policy (which will be discussed in a later lesson).

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.

Use "hello_world" as a tag, "allow echo:*" as the event policy, "hello_world/*" as the query policy, and click the "Add" button to create a new channel.

Congratulations! You have created your first channel. You can confirm its policy by checking the box beside its identifier.

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 "hello_world" channel throughout the rest of this lesson.

Sending events through the channel

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 two of these three ways:

  1. Directly using a URL through a client (ex. a browser, or the `curl` command at the command line)

  2. Using the "Testing" tab of the UI

  3. Using Postman or some other console for RESTful APIs

1. Directly using a URL

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 "hello_world" channel. Also, you may choose your own event identifier (rather than use "5", as we did for this screenshot).

http://localhost:3000/sky/event/ckcvuri6r0017conl4siq0q3r/5/echo/hello

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 event generators 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.

2. Using the "Testing" tab

When you develop a ruleset, you may choose to use the "Testing" tab of the developer UI which can provide a simple UI for the events and queries of the ruleset. The "Testing" tab works by using a map named __testing which is created automatically by the compiler when the ruleset is compiled. The tab builds a simple form to test each of the queries and events which the map defines (again, as generated by the compiler).

This __testing name may also be shared, and if you want to do this you can 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:

  meta {
    name "Hello World"
    description <<
A first ruleset for the Quickstart
>>
    author "Phil Windley"
    logging on
    shares hello, __testing
  }

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 flush the ruleset in your pico. (Review the Pico-Engine Quickstart page if necessary)

Click on the "Testing" tab of the developer UI. Choose the "hello_world" channel from the ECI dropdown. Notice under your ruleset identifier that there are three forms, one for each of the shared functions and the event that you defined in your ruleset.

In the next example, the name __testing is not shared, so there is no button for it in the Testing tab.

Notice the button "echo/hello", representing this event for your ruleset named "hello_world". Click on this button to send the event.

Notice the directive returned by the event.

3. Using postman

You can enter the event URL in postman, and click the Send button. Note the result below:

Send a query through your channel

Create a URL for your Pico which uses your "hello_world" channel identifier. It will look something like

http://localhost:3000/sky/cloud/ckcvuri6r0017conl4siq0q3r/hello_world/hello?obj=Bob

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 "hello" button.

Congratulations! You know how to send queries to a pico, either directly using a URL, or through the "Testing" tab of the UI, or through Postman.

Using logs

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:

  rule hello_world {
    select when echo hello
    pre {
      name = event:attr("name").klog("our passed in name: ")
    }
    send_directive("say", {"something":"Hello " + name})
  }

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.

After making these changes to your ruleset, be sure to validate it, then push your change, and flush it in 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):

{"level":50,"time":"2020-07-21T19:28:25.484Z","picoId":"ckc...",...,"msg":"rule selected"}
{"level":40,"time":"2020-07-21T19:28:25.485Z","picoId":"ckc...",...,"val":"Bob","msg":"our passed in name: "}
{"level":40,"time":"2020-07-21T19:28:25.485Z","picoId":"ckc...",...,"msg":"fired"}

Using the "Logging" tab

Click on the "Logging" tab for your pico.

You should see all of the recent transactions for your pico. Click to open the ones for the "echo:hello" event and the "hello" query:

Here we see the logging for a query and an event.

Note that since the UI works by sending events and queries to the io.pioclabs.pico-engine-ui ruleset, you’ll also see those events and queries in the output. If anyone is interested in contributing to the React code that implements the UI to filter the logs, it is open source.

Congratulations!

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 (version 1.0.0).

Exercises (Beginner)

Do the following:

  1. Create a new channel (pick any tags you like, but set up the same policy). 

    1. Send an event to your pico using the new channel. 

    2. Do you get the same result? Why or why not? 

  2. Delete the channel.

    1. Resend the event using the deleted channel. 

    2. What happens? Why?

  3. Send the event ecco/hello to your pico. What do you observe? Why? 

  4. Add a new rule that selects on echo/monkey and responds with "Hello Monkey" unless an event attribute named name is 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. 

  5. Repeat the previous exercise using the ternary conditional instead of the .defaultsTo() operator.

Exercises (Intermediate, presumes completion of Modules and External APIs Lesson)

Do the following:

  1. Write and register a ruleset named track_trips that contains a rule called process_trips that responds to the car:new_trip event with an attribute mileage. This rule should return a directive named trip with the option trip_length set to the value of the mileage attribute.

  2. Using the Pico Engine UI, create a pico that represents a car and install your track_trips ruleset in it.

  3. Using one of the techniques in Raising Events, test your ruleset.  Try it with and without the mileage attribute.

  4. Modify the select statement in the process_trips rule so that it will not fire unless there is a mileage attribute with the string value of a positive number. Hint: read the docs for the universal operator as().

  5. Modify the process_trips rule to raise an event.with domain explicit and type trip_processed. The explicit event should include any attributes that were in the car:new_trip event. Hint: event:attrs() returns all attributes of the current event.

  6. In the same ruleset, write a new rule named find_long_trips that selects on the explicit:trip_processed event. It should read the mileage attribute and, if it contains a value greater than the numeric value of the global variable named long_trip, raises another explicit event with domain explicit, type found_long_trip, and any atrributes passed along. Note, there are multiple ways to accomplish this.  You can pick any positive value for long_trip that you like.

  7. In the same ruleset, write another rule called trip_fuel_usage that selects on the explicit:trip_processed event. The rule should use the VIN event attribute as input to the vehicle information function you created in Modules and External APIs Lesson to retrieve information about this vehicle. Using the number in the mileage attribute, calculate the gallons of gas used for this trip (assume it was highway). Your rule action should return a directive that contains the miles driven and gallons of gas used for the trip. 

  8. Use ruleset logging and debugging tools to convince yourself that your rules work.