Monthly Archives: October 2013

Bitcoin Web Services with vCO: Part 1, Coinbase

In the past I’ve done adhoc perl and php scripting scheduled via cron to do random duties.  I wanted to explore how easy it would be to replace one of them with vCO and turns out it’s dead simple.   Once I got the process down here in part 1, I did part 2 in literally only a few moments with only a few clicks to add a totally different service.   So lets get started..

Don’t know what Bitcoin is?   That’s ok, read here. And watch a video here.

Now that you know that, what are we doing?  Part 1 shows how to check the buy price for bit coin on a website called Coinbase.  I’ve found that to be the simplest way to purchase btc quickly with american dollars.   Part 2 shows how to modify the structure of this workflow to check an average current price across all exchanges on a website called Bitcoin Average.

Check out the API reference for Coinbase here.

Simplest REST operation I want to use is:
https://coinbase.com/api/v1/prices/buy?qty=1

Which currently gives the results:

Screen Shot 2013-10-24 at 2.03.56 PM

Alright great, we have the variables we want.   For this exercise I just want to access total.amount which is 197.01 at the time of this post.

For this new workflow I want to better implant modules than I have in the past.  So the workflow we run won’t actually do the alerting, but will call a different workflow ‘Pushover Alert’ for that.  Side benefit of this is I can keep the api key’s for pushover stored only in the one location.

The ‘Check Price’ script calls the rest operation, picks out the variable we want and formats the text part of the alert (if it’s needed).   ‘Decision’ simply forks based on if the value is under a certain about, for now I’m using 100 (wow it changed fast, I originally created this a few weeks ago before it jumped).  And lastly it either simply ends if above 100, or calls ‘Pushover Alert’ if over.

Screen Shot 2013-10-24 at 1.50.44 PM

The script for ‘Check Price’ is pretty straight forward and still using a bunch of system.log calls for troubleshooting:

Screen Shot 2013-10-24 at 2.14.03 PM

The first improvement I know I need to make is making the alert threshold a configureable variable but off the top I didn’t see a way to do it:

Screen Shot 2013-10-24 at 2.19.49 PM

As a test I changed the value to 250 to show an alert, and here’s what it looks like:

photo-2

There we have it, simple and useful.  The skeleton of this workflow can be duplicated to apply to other services very quickly as we’ll show next.    I may start posting an export of these workflows if there is any interest in it, let me know.

Tagged , , ,

Weather Underground Part 2: Send alerts to Pushover API /w vCO

Continuing on from Part 1 where we explored pulling data from Weather Underground.

In this post we’ll look at how to use a service called Pushover.  In their own words ‘Pushover is a service to receive instant push notifications on your phone or tablet from a variety of sources.’   I’ve used it in the past with perl and PHP scripts for my home automation system.  I’ve had it send alerts on everything from home theatre PC TV episode alerts to temperature warnings in my kegerator to bitcoin prices on Coinbase.   I lead an exciting life, really.   It’s tightly integrated into IFTTT so it’s a really easy alerting engine to use with that service.

To recall where we left it in Part 1, we were using a nested workflow to pull JSON formatted data from Weather Underground and output a few specific variables to the error log.

Weather_wf_schema

To make that a little more useful, in this new workflow, Weather Underground 002, we’re going to add in another nested workflow to send that data to the Pushover web service.  The schema looks like this:

Weather2_Schema

We modify the attributes of this parent workflow to include the API Key for Pushover, User Key for Pushover, and the name of the vCO REST Operation.   Pushover has you register a key for your application AND a key for your user. Presumably so one could re-use someone else’s application.  We will now use this message variable to move data from one workflow to the other – it will contain the body of what we send to pushover.

Weather2_Attributes

Inputs and outputs for the parent workflow remain unchanged because we are only changing what happens inside of it.  I did do a bit of cleanup on the embedded workflow while troubleshooting to remove the default parameters but you really don’t have to.  The POST method threw me off for a bit but I got it working this way.

Registering the Pushover REST host is easy enough in vCO:

Weather2_Pushover_Host

Registering the REST Operation is a little more complicated as this is a POST method instead of a GET:

Weather2_Pushover_Operation

Back to our workflows, we need to be sure we match up our bindings.  Key is the message data that is coming as the output from the previous workflow:

Weather2_2_VisualBinding

Validate for any bugs and you should be good.  Run this new workflow and you should see the same basic message that we created in the previous step.   Yup still cold.

Weather2_Pushover

So that’s all fun and stuff, but what’s the real implication of it?   Well, this is an extremely simple monitoring solution that doesn’t require and text message or email gateway. Any monitoring alert or error you want to trap in the vCO environment, you can have piped right to your devices via a canned workflow you can drop in.

Tagged , , , ,

Weather Underground Part 1: Invoking a GET method on a REST web service /w an API key in vCO

Consider this part 1 of 2 using Weather Underground.   First we need to gather data.

UPDATES:
Feb 22 2014 – Typo in workflow name updated.  Thanks Phil
!

This post is a bit less exciting than the last FOAAS post. The concept here is important to grok however to be able to build on and do anything more advanced.

Introducing the REST interface for Weather Underground.  The API reference is here.  This page gives a good visual example of forming a API request and seeing the return as JSON.

JSON_example

Awesome, simple enough.  Shouldn’t be too different than dealing with curse words.     Because I always have been and always will be a lazy sys admin, we’re going to build on existing modules.   Add the Weather Underground host to vCO:

Weather_rest_host

And form the URL in an REST operation in vCO as follows.  Note we’re using parameters in the URL template for KEY, STATE and CITY.  This operation is GET http request.

Weather_rest_op

Now if you haven’t done it already, we need to sign up on Weather Underground for an API key.  Most web services work this way.  Instead of doing http authentication, you have a long unique key that you pass to prove you are who you are so they can track you.    It’s free on this site for 500 calls per day and 10 calls per minute.  Perfect.  Do that here.

We have our key, let’s test our connection with the built in ‘Invoke a REST Operation’ workflow.  Use the API key you were give, put in a State and a City:

Weather_test

And if all goes well, in the logs we should see the JSON formatted output (remember the last line of the workflow to posting the response as a string).  Snippet of the output:

Weather_JSON_output

Excellent!   This gives us a lot to work with.   Now let’s make this more real.  Duplicate this ‘Invoke a REST operation’ to one of your own, I call it ‘Invoke REST 2’  (never-mind the #2, i’m blogging this out of order as I’ve already done part two of this blog post).   I create a brand new workflow that passes parameters to that one to show how to nest workflows.

But first let’s modify the new ‘Invoke REST 2’ workflow.  Through some trial and error I figured out how to address individual parameters that we are returned in the JSON response.  For example, to make this stuff more meaningful it would be great to get the temperature in fahrenheit.   So we run the JSON.parse subroutine, and pull out the data as such.  Also we’re going to grab the time and location:

Weather_JSON_parse

Now just to prove it still works, we can run just this one workflow real quick, pass the parameters and we get:

Weather_test_parse

Excellent (and BRRRRR it’s cold this morning.  What the heck, winter is here?!)     Now that we’re doing something a little more fancy with the data, let’s create this brand new workflow I alluded to.   I’m calling this ‘Weather Underground 001’.

This workflow will have attributes for the api key, the name of the rest operation that we added, and the message body (this will be used later to pass data further along the workflow).  These are the hard coded attributes for this workflow.

Weather_wf_attributes

The inputs we’re going to prompt for all City and State:

Weather_wf_inputs

The outputs (irrelevant for this part as we are not passing them anywhere, but important for part two), are as follows:

Weather_wf_outputs

And now some of the awesomeness of workflows – the “smart visio” schema.   This is how we drop elements into the workflow to do work.  For this part we’re just using the ‘Invoke REST 2’ workflow, so drop that in there:

Weather_wf_schema

Staying a bit high level for now, we need to connect up what is being passed into and out of this workflow with the Visual Bindings tab.  This is where we tell it what we need to do with city, state and key (and what the name of the REST Operation is).   This is also where we get the message variable we will do something with later.

This concept is key to using vCO as it’s intended.  We are re-using workflows, not re-creating them.  So there is no special scripting to do as it was already done in the workflow we embedded.

Weather_wf_visual_binding

Save the workflow and increment the version.   Run this guy and you should see similar output to when we just ran the embedded workflow stand alone:

Weather_wf_output_final

Still cold!    Awesome.  This is how we can connect to a REST web service, use an API key and pull out a specific value or three.    In the next part we will show embedding a second workflow and passing a value to that one to do some work with.

Tagged , , , ,

Fuck Off As A Service /w vCO and REST API

Consider this a Hello, World exercise for vCenter Orchestrator (vCO) and a REST API plugin.   With vulgarity.  Put the kid to bed, or drop a dollar in the curse word can because it’s about to get ugly.

There’s a web service I came across this summer called Fuck Off As A Service that is a RESTful service that will respond via plain text, JSON, or HTML based on the data you send it.   Let’s explore the most basic use case.

The first one listed is:

Image

If you format it in a web browser with the URL http://foaas.com/off/Congress/The_People   you get back:

Image

Neat huh?   So let’s do something in vCO to prove we can talk to a REST web service.   I’ll leave to to Those Better Than I to describe how to set up vCO and what not.  So I’ll jump in after the REST plugin is installed and vCO is restarted.

First, we need to add the web service as a host.

Image

We want to give it a name, and enter the URL:

Image

Since this is a totally public service we do not need any authentication:

Image

You’ll notice the green check mark indicating a successful add.   Now we need to add the operation.  Think of the operation as a specific action we are calling.

ImageT

This workflow has a few more boxes to fill in.  We need to choose the host the action will always be taken on.   We give it a name.  We form the template – this is key.  This corresponds to the API documentation of the web service we are dealing with.  Use stuff in brackets {blah} to indicate the parameters.  In this case we need to give it two names.  And a HTTP method.

Image

Save it and we should be good to go:

Image

OK now let’s see if it works.   Just to do a simple test we’re provided a pre-built workflow to invoke rest operations.  So right click and start that guy:

Image

Choose the “off” operation we were just adding:

Image

Since this is just a pre-built demo workflow it’s not properly asking for the names but it does know we have two parameters.  So enter the NAME and FROM parameters here:

EDIT: I didn’t realize spaces causes it to puke, not sure if it’s on the vCO side or the FOAAS side but put an underscore in there and you’re golden

Image

Unless we broke something along the way, we should see it run successfully as such:

Image

Now to see the output click on the Logs tab of the workflow we ran.  At the very bottom you should see:

Image

Boom.   Take that, Congress.   So this is a very simple example but shows that we do have the power to interact with a web service from within vCO.   You can do any number of things with this now.  You could make a popup error message in a VMware product contain this kind of vulgarity.    A user tries to deploy more VMs in vCD than they have quota for and you could respond with a customized message with their user name.    Vulgar awesomeness can be done.  Or at least vulgar wastes of time while you learn yourself some vCO.

Tagged , , , ,

New IFTTT triggers for congressional votes via New York Times

Ok so this is just too cool I had to post about it real quick.   IFTTT posted today about additions to their New York TImes Channel that supports a trigger for the congressional vote.   That’s so awesome…and current.    News As A Service?

Image

This is just too cool…  The House of Representatives for example, has a list of 18 variables (they call ingredients) that you can use to filter the triggers on.    If you absolutely positively must know everything about everything as soon as possible…..IFTTT news channel is for you!

Image

EDIT:  I take that back.   Ingredients are used for the CONTENT of what you do with it, not to filter on.   So you can do the following with them, this example is an example receipe I found someone already made:

Screen Shot 2013-10-02 at 12.35.47 PM

Tagged ,