This video will walk through exercise 3 step by step. We'll start by opening postman
and navigating to the collection containing our class exercises.
Postman is a free application for testing HTTP requests that gives us more capability
and control than we would have through a web browser; it allows us to use any HTTP verb,
control the headers that are passed include bodies in our requests and save requests for later use.
The first step is to set up authorization. Postman allows us to set authorization for a
whole collection and then we'll add the necessary header to each of our requests. For this section
we will be using basic authorization which is an authentication type where a username
and password are base64 encoded and passed in the authorization header. Throughout the
collection you will see the variable PI Web API in double curly braces. Hovering over the
variable shows what the value is set to, this allows us to avoid copying the full base URL
into each request. Variables are also useful for making collections more reusable and shareable.
For our first request we want to use the asset database controller's
GetByPath method to return the NuGreen database;
the path is entered in the URL parameter and we can see our database is returned.
If we click over to the headers tab of our request we can see the temporarily
added headers from postman that were automatically generated for us. This
includes our basic authorization header; to confirm that this contains the username and
password we set we can use a base64 decoding tool to see what that string corresponds to.
Sure enough it is our user name and password that we entered separated by a semicolon.
We can use the web ID returned for NuGreen in our next step in the exercise which is
to create a new AF element at the root level using the asset database
controller's create element method. This request is a post request and we
will need to include a valid request body describing the element we want to create.
In PI System Explorer we can refresh to see our newly-created element.
In the location header of our response we can find the web ID of our newly created
element. We will use that web ID of our new root element in the next request
which uses the element controller's create element method, this request will add a new
child element under the parent element specified by the web ID that we pass.
Again we can look at the location header of the response to get the
web ID for our newly created child element.
The next step in our exercise is to create an attribute for this child
element using the element controller's create attribute method. Since we're
not defining a data reference plug-in this will be created as a static data reference.
Step five asks us to now create a tag on the data archive using the data server controller's
CreatePoint method. This method requires us to pass the web ID of the data archive which
we can find by either querying in postman or going back through the hierarchy in Chrome.
We can see in PI System management tools that the tag was successfully created.
Now that our tag is created the next step in the exercise is to turn off compression. We can do
this by updating it with a put request using the point controllers update attribute value method.
We pass a value of zero in the request body to turn off compression .
Now let's go back and change our generator power attribute to be a
PI point data reference and point it to our newly created PI tag.
This can be done with a pat request using the attribute controller's update method.
Step eight asks us to write a set of three values to our point using
the PI tags web ID and the stream controller's update values method.
Since we have linked our power attribute's data reference to
that PI tag we should be able to read back the values we just wrote using
the stream controller by passing the AF attributes web ID instead.
We see the values that were just written and this shows that the attribute and
tag are in fact linked. The last step of this exercise is intended to show
the caching behavior in PI Web API and the effect of the cache control header.
First we will use the element controller's GetElements method to return the children
of the old green element we created. We can see that the generator element has no description.
Let's add a description for this element in PI System Explorer and query for the element again.
We can see that our newly added description is not reflected in what PI Web API returns.
This is because that result is being served from the cache and the cache refresh time
has not yet passed. However, we can add a cache control no cache header and rerun the request.
This instructs the PI Web API to bypass the cache and fetch the most current version of
the elements directly from the AF server. We see now that our new description is in fact returned.