Behind the Demo: Part 2 – A RESTFul Development

In our first episode, Island Training took on a challenge for IBM’s InterConnect conference: create an interesting and engaging live demo of an end-to-end DevOps process for the Expo Hall. We set a 10-minute limit for the full demo cycle, from requirement to deployed personalized tickets. In Part 1, we explained how we took advantage of the links between DNG and RTC to create work items from requirements.

In this chapter, we use the REST API to generate our deliverable text file.

For our demonstration, we need to create a text file with all the names that we gather from Drink Order requirements. Manually creating the file will eat valuable time from the 10-minute demo—automation is critical to the demo’s speed/success. So, we need to programmatically connect to either RTC or DNG. But how?

Give it a REST

RTC offers a variety of Application Program Interfaces (API’s) that allow you to interact with the RTC server. DNG offers a REST (REpresentational State Transfer) API. We’re not sure whether we need to grab the names from DNG or from RTC, but since both tools have a REST API, looking at their REST APIs makes sense.

The REST API lets you interact with the server using a HTTP GET or PUT request. The message you send or the response you receive from the request will be either in XML or in JSON format. Most major programming languages have libraries available that can generate the HTTP requests, as well as extract the information from XML or JSON format.

Recall that we discovered in Part 1, that when creating the work items from the requirements, information from the requirement is copied to the work item. In our case, the attendee name that we save as the requirement title is copied to the generated work item as the summary. Because the RTC REST API offers flexibility in terms of where to pull the names than the DNG REST API, we decided to connect to RTC.

Using the RTC REST API we run the Open Stories in Current Sprint query, which returns all the stories we created for that 10-minute session. The query results are in the XML-based response that we save and from which we extract the work item summaries into a text file.

Because we’re looking at a protected resource on the RTC server, we have to start our session with a login. In using the REST API, the login procedure starts as follows:

  1. Attempt to use protected resource. Expect the failure, which will prepare the RTC server for credentials.
  2. Supply credentials in an HTTP POST message to the specific login URL.
  3. Send the request again for the protected resource.

Using Python and the requests library, this login method is below:

Once we have the response in XML format, we can make use of the ElementTree library  to parse through the tree structure and grab the names at the appropriate nodes. When going through the tree structure, we need to expand the XML namespaces that are defined by organizations such as Open Services for Lifecycle Management (OSLC) and the w3.org.

With all the hurdles taken care of, our Python script is ready. This script is below.

Running the script creates the text file we need. This deliverable allows us to demo RTC’s source control and build management capabilities.

The last article of the series will show how we move our text file to a deployment environment using UrbanCode Deploy, and how this helps bring our demonstration to a rousing finish.

About the author

Robert Wen

2 Comments

Leave a comment
    • Off the top of my head, I’d think that the Data Warehouse is out of scope with OSLC and, thus the answer may be “no”. The Data Warehouse is really snapshots of the CCM database for trend reports.

      You may want to ask your question on the Jazz.net forum. You may get a better answer.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

© Island Training Solutions, Inc. All Rights Reserved. Please see our trademark information.

All information on this website is published in good faith and for general information purposes only. The Island Training Blog does not represent or endorse the accuracy or reliability of any information or content contained on, distributed through, or linked, downloaded or accessed from any of the services contained on this website, nor the quality of any products, information or any other material displayed, purchased, or obtained by you as a result of any information or offer on this website or in connection with the services herein.You hereby acknowledge that any reliance upon any information contained herein shall be at your sole risk. The Island Training Blog reserves the right, in its sole discretion and without any obligation, to make improvements to, or correct any error or omissions in any portion of the blog.Unless otherwise indicated, Island Training Solutions, Inc. is the legal owner of all material on The Island Training Blog. No material appearing on The Island Training Blog may be reprinted, reproduced or published without prior written consent from Island Training Solutions, Inc.THE MATERIALS ON THE ISLAND TRAINING BLOG ARE PROVIDED ON AN “AS IS” BASIS, AND THE ISLAND TRAINING BLOG EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR IMPLIED, WITHOUT LIMITATION OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE SERVICE OR ANY MATERIALS AND PRODUCTS. IN NO EVENT SHALL THE ISLAND TRAINING BLOG BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES OF ANY KIND WHATSOEVER WITH RESPECT TO THE SERVICE, THE MATERIALS, AND THE PRODUCTS.