Post

1 follower Follow
0
Avatar

Defining infrastructure with Dojo and JavaScript

XL Deploy's REST API can be easily called from Dojo/JavaScript scripts to define new infrastructure in the repository.  An earlier article (https://support.xebialabs.com/entries/45957249-How-to-create-read-update-and-delete-configuration-items-using-the-XL-Deploy-REST-API) explained the basics, so let's look at how Dojo and JavaScript can be used to perform the same sort of operations.

Here is the function that make the POST call to the REST API.

 
function defineConfigItem(ciPath, postDataText) {
// console.log("Starting defineConfigItem()");
dojo.xhrPost({
url: "http://localhost:4516/deployit/repository/ci/" + ciPath,
user: "admin",
password: "admin",
headers: {"Content-Type": "application/xml"},
sync: true,
postData: postDataText,
//timeout: 10000,
handleAs: "xml",
load: function(result, ioargs) {
dojo.publish("xldStatus", [{message: "DefineConfigItem HTTP status code " + ioargs.xhr.status,
type: "message", duration: 2000}]);
},
error: commonError
});
// console.log("Exiting defineConfigItem()");
}

As you can see, we use a POST call with the path to the new configuration item at the end of the url.  As a reminder, XL Deploy's paths can be easily copied from the GUI by going into edit mode on the CI, right-clicking the id field and selecting Copy.  Besides passing in the path, we also pass the post data as a string in XML format, as in this example:

<overthere.SshHost id="Infrastructure/my-new-ci">  
  <os>UNIX</os>  
<address>1.1.1.1</address>  
<port>22</port>  
</overthere.SshHost>

And of course we must code the rest of the parameters required for xhrPost.  The url, username, password and headers operate as in any HTTP call.  You have a choice between sync (wait for the call to return) and timeout (execute asynchronously but error out after the specified number of milliseconds).  The handeAs parameter refers to what is returned, so it is superfluous in this case.  The last two properties are callbacks:, load defines a function called for a good result and error defines an "errback" function called otherwise.

The remainder of the scripting serves to supply propertly formatted data to defineConfigItem.  The xldDriver function receives a number of parameters derived from an input source, assembles the postDataText XML string, and makes the function call.  Any XML formatter can stand in here, but let's just concatenate tags and values the old-fashioned way for now:

function xldDriver(ciPath,ciType,deploymentGroup,os,connectionType,address,myPort,username,password,sudoUsername) {  
// console.log("0: Executing xldDriver");  
postDataText =  
"<" + ciType + " id='" + ciPath + "'>" +  
"<tags/>"+  
"<deploymentGroup>" + deploymentGroup + "</deploymentGroup>" +  
"<os>" + os + "</os>" +  
"<connectionType>" + connectionType + "</connectionType>" +  
"<address>" + address + "</address>" +  
"<port>" + myPort + "</port>" +  
"<username>" + username + "</username>" +  
"<password>" + password + "</password>" +  
"<sudoUsername>" + sudoUsername + "</sudoUsername>" +  
"</" + ciType +">";  
defineConfigItem(ciPath, postDataText);  
}

And commonError provides a means of alerting the user to bad return codes from our HTTP calls:

function commonError(text, ioargs) {  
error = true;  
dojo.publish("xhrError", [{message: "HTTP status code " + ioargs.xhr.status, type: "error", duration: 2000}]);  
return text;  
}

Note that we use dojo.publish to publish good and bad results to the dojo.Toaster objects xldStatus and xhrError respectively.  With these three functions, any provisioning tool that supports JavaScript calls can communicate its results directly to XL Deploy.

Dave Roberts

Please sign in to leave a comment.