Tags
API, API Platform, code, development, node.js, Oracle, PlatformTest, policies
When configuring API Policies in the the Oracle API Platform it helps if there is a simple back end that can take the received payload and record the sent values (header & body) as well as reflect the call details back as the response, or possibly respond with a test payload (so that response policies, particularly policies that require payload navigation can be exercised correctly). By having this facility it becomes a lot easier to determine whether the policies are executing correctly in terms of routing, transforming, filtering etc. without needing to worry about whether the API implementation is correct. You could say that this is a kind of mock for testing the API Platform.
The added benefit of having a mock back end is that it is easy to ‘smoke test’ a gateway deployment very easily. Particularly if the mock is happy to receive any form of call.
Whilst implementing such a capability can be done in pretty much any language and platform you like. We have in the past for example built a Springboot Java application that can have the dependencies configured to then deploy into WebLogic for example. We have come to refer these test apps/mocks as PlatformTests as that’s exactly what they help do. A Node.js implementation of a PlatformTest such as as the following implementation is particularly appealing as the Node.js footprint is small and simple to deploy and undeploy. A basic Node.js implementation can also consume any URL and operation you choose to use. The nature of JavaScript makes it very quick to adapt the mock if need be. Although in the ideal world, we write the solution once and then use simple configuration to tune behavior.
The following code looks for a local file called testResponse.json if found then returns the content of the file (assumed to be JSON) otherwise it reflects back in the body, the received header and body. This reflection makes it extremely easy to see how the policies have changed the inbound call. The content is also logged to the console – making it easy to also see what came through to the back end.
The implementation also assumes port 8080, but changing the port is exceptionally easy.
There one enhancement planned, and this is to allow the response test payload to be handled as XML. This will need a little tweaking of the code as presently a JSON Object is currently stringified.
The code is also available in my GitHub repository – https://github.com/mp3monster/Utils/blob/master/PlatformTest.js and an example test response file is at https://github.com/mp3monster/Utils/blob/master/testResponse.json
const http = require('http');
const fs = require('fs');
// create a simple HTTP server that will handle the requests
http.createServer((request, response) => {
const { headers, method, url } = request;
console.log("Called at " + new Date().toLocaleDateString());
let body = [];
request.on('error', (err) => {
console.log("Svr Error Handler :" + err.toString);
response.statusCode(400);
response.end();
}).on('data', (chunk) => {
body.push(chunk);
}).on('end', () => {
body = Buffer.concat(body).toString();
// At this point, we have the headers, method, url and body, and can now
// do whatever we need to in order to respond to this request.
});
// record in the console what details have been received
console.log ("Received:\nMethod:" + method.toString() +
"\n URL:"+ url.toString + "\nheaders:\n"+headers.toString() +
"\nBody:\n" + body);
// now build the response
response.setHeader('Content-Type', 'application/json');
response.setHeader('PlatformTestTime', new Date().toLocaleDateString());
// initialise our response object so that if we don't load a response
// file then we reflect the content
var responseBody = { headers, method, url, body };
try {
// try reading a response file
fs.readFile('testResponse.json', function(err, data) {
console.log("handling file");
if (err != null) {
if (err.code === 'ENOENT') {
console.log("on return file - will reflect");
} else {
console.log("Read error:" + err.toString());
}
} else {
// a file exists - but is empty?
if ((data != null) && (data.length > 0)) {
// we have a file with content - lets process so it into a JSON
// object
if (Buffer.isBuffer(data)) {
// convert the buffer from hex to an ASCII string
body = data.toString('utf8');
console.log("test response:" + body);
responseBody = JSON.parse(body);
}
}
}
// create an array with our values and then make it
// JSON with stringfy
var output = JSON.stringify(responseBody);
response.write(output);
console.log("Returning:" + output);
response.statusCode = 200;
response.end();
});
} catch (err) {
if (err.code === 'ENOENT') {
console.log("on return file - will reflect");
} else {
console.log(err.toString());
}
var output = JSON.stringify(responseBody);
response.write(output);
console.log("Returning:" + output);
response.statusCode = 200;
response.end();
}
}).listen(8080); // Activates this server, listening on port 8080.
As you can see in the preceeding diagram I created two functions within a project called OMCS. From here you can create more functions in your project or drill into an individual function, as the following view shows:
Monday night (18th December) I co-hosted with 
With the presentation and discussions finding a suitable pause, it was an opportunity for a call to arms to be made, and for people to try using developing APIs. With a mission defined which we hope people will try to continue with as it will contribute to the next Meetup. You don’t need to have attended last night’s event to participate in the next Meetup. If you want see what we’re going to try achieve take a look at the end of the slide deck. We think it will be be very entertaining and the source of a lot of laughter and amusement.
Phil (aka MP3Monster)'s Blog 
You must be logged in to post a comment.