Objectives

The purpose of this lab is to introduce actor-model programming principles using picos.  

Reading

• Using the Scatter-Gather Pattern to Asynchronously Create Fuse Reports Links to an external site.
• Do the Pico-Based Systems Lesson Links to an external site.
• Do the Pico to Pico Subscriptions Lesson Links to an external site.

Implementation Notes

• This lab is less prescriptive than the Reactive Programming: Single Pico Lab. You have more freedom to define event and function names. 
• Even though another event may be the primary result of a rule firing, you can use directives to see what's happening for debugging purposes. 

Part 1: Building a Fleet

In Reactive Programming: Single Pico you created a ruleset that stores trips. In this lesson, you'll build a fleet pico and program it to create multiple vehicle picos. When you create a vehicle pico, you will install the Subscriptions, trip_store, and modified track_trips rulesets (from Reactive Programming: Single Pico). 

Do the following:

1. Create a new pico that represents a fleet of vehicles. This pico may be a child of the pico you used in Reactive Programming: Single Pico or a new account. It doesn't matter. Install the Subscriptions ruleset in this pico.
2. Create, register, and install a ruleset called manage_fleet in the fleet pico.
3. Write a rule called create_vehicle that responds to a car:new_vehicle event by 
1. creating a new pico
2. creating a subscription (in a new rule) between the fleet pico and the new vehicle pico. Be sure the roles (fleet and vehicle) are correct and that the subscription has a name based on an appropriate event attribute in the car:new_vehicle event. 
3. installs the Subscriptions, trip_store, and track_trips rulesets in the new vehicle. 
4. Write a function in the manage_fleet ruleset called vehicles that returns the fleet's vehicle subscriptions.  
5. Write a rule called delete_vehicle that responds to a car:unneeded_vehicle event by 
   1. deleting the appropriate vehicle pico (identified by an event attribute)
   2. cleans up the subscription between the fleet pico and the deleted vehicle pico. 
6. Test the rules and functions you defined by:
1. creating vehicles, 
2. delete at least one vehicle
3. you should end up with at least three vehicles
7. Test the vehicles by sending them trips. Use the trips and long_trips functions to ensure they are working. You may want to script something with curl to send vehicles a number of random trips for testing purposes. You'll need a variety of trips in the vehicles for the next two parts. 

Part 2: Generating Reports via Functions

In this part of the lab, you'll generate a fleet trip report using the trips function.

Write a function in the manage_fleet ruleset that calls the trips function in each of the vehicles that the fleet knows about. The result should be JSON (note 4). 

Be sure that the function continues to work even if vehicles are added or deleted. 

Part 3: Generating Reports via Scatter-Gather

In this part of the lab, you'll generate a fleet trip report using the scatter-gather pattern. 

1. You will need a rule in the  manage_fleet ruleset that sends an event to each vehicle (and only vehicles) in the fleet notifying them that a new fleet report is needed. 
2. You will need a rule in the track_trips ruleset that sees the event sent in (1), calls its own trips function (do NOT use skyQuery for this), and sends an event back to the originator of the event with the result. The originator is usually the fleet, but assume only that it is a pico in the same engine.
3. You will need a rule in the  manage_fleet ruleset that selects on the event from (2) and stores the results in a fleet trip report. Be sure the report includes a counter of the number of responding vehicles. 
4. Add a function that returns a JSON structure with the five (5) latest fleet trip reports. 

Notes:

1. Be sure to use a correlation identifier to ensure that you're storing data about the right trips. Note that due to an implementation decision in KRL (some might call it a bug), you should not use a number as the correlation ID. It's OK to use a random number, but prefix it with a string so that it's not a number. 
2. You don't have to deal with any failures of the vehicles to respond with retries. 
3. The fleet might have subscriptions to picos other than the vehicles. Be sure you are only asking vehicles for reports. 
4. A fleet report is simply a JSON structure that includes the reports from each vehicle (you may assume the Subscriptions ruleset's skyQuery never fails), a count of how many vehicles are in the fleet, and a count of how many responded. For example: 

{<vehicle_0_id>: {"vehicles" : 4,
                  "responding" : 3,
                  "trips" : <trip report from vehicle>
                 },
 ...
}

Deliverables  

1. A diagram showing the relationships (i.e. subscriptions) between the picos.
2. The source URLs for your rulesets
3. The RIDs for your rulesets
4. ECIs for the picos that your rulesets are installed in.
5. The ECIs and events for adding trips to the vehicle picos.
6. A URL for generating a fleet report via the function method.
7. An ECI and event for generating a fleet report via the scatter-gather method
8. Answer the following questions:

Questions

1. Can a vehicle be in more than one fleet based on the code your wrote? Why or why not? What are the implications of a vehicle being in more than one fleet? 
2. How did you solve the problem of only notifying vehicles that you needed a report? 
3. How could you ensure that only certain picos can raise an event that causes a fleet report to be generated?  
4. How do the debug logs differ for Part 2 (Generating Reports via Functions) and Part 3 (Generating Reports via Scatter-Gather)?
5. How can you know a report is done and all the vehicles that are going to respond have reported? 
6. Given your answer in (3), how would you recover if the number of responding vehicles is less than the total number of vehicles?