Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Wrangler does much of the heavy lifting in managing subscriptions. The introduce_myself rule simply stated that a subscription was needed and Wrangler not only created the pending outbound subscription for the TempSensor, but also sent an event to the subscription provider, Thermostat, so that a pending inbound subscription could be created there. Then, when we approved the subscription in Thermostat, Wrangler again, made the job easy. Wrangler made the pending inbound subscription into a subscription, created a channel for the subscriber (TempSensor) to use, sent an event to the subscriber with the new channel, and changed the subscription in TempSensor from outbound. 

Deleting a Subscription

To come...We delete a subscription between two picos in a similar manner. The following rule shows how to use Wrangler to do that:

Code Block
languagejs
themeConfluence
rule remove_subscription {
  select when pico_systems subscription_deletion_requested
  pre {
    pending_sub_name = event:attr("sub_name");
  }
  if ( not pending_sub_name.isnull()
     ) then
       send_directive("subscription_approved")
         with options = {"pending_sub_name" : pending_sub_name }
 fired {
   raise wrangler event 'subscription_cancellation'
         with channel_name = pending_sub_name;
   log "Approving subscription " + pending_sub_name;
 } else {
   log "No subscription name provided"
 }
}

After determining that it has a non-null name for the subscription, the rule raises the wrangler:subscription_cancellation event with the correct channel name. Wrangler not only deletes the subscription in the pico where this event is raised, along with it's attendant channel, but also signals to the partner pico in the subscription that it should do the same.  As a result the subscription is completely removed from both picos.