Home » Eclipse Projects » Eclipse Titan » Using JSON in TTCN-3 and Titan Part I: Testing REST / JSON web services: (Test of JSON -based REST web services)
|Using JSON in TTCN-3 and Titan Part I: Testing REST / JSON web services: [message #1702445]
||Wed, 22 July 2015 11:49
|| Elemer Lelik
Registered: January 2015
The ability to move back and forth between JSON and TTCN-3 constructs is a new, and yet unstandardised feature in Titan. We are working on the appropriate standard but due to the nature of standardization it will probably take some time, measurable in months, until the standard will hit the public libraries.
JSON is becoming more and more popular as a data interchange format, especially in the realm of the web, due to its' low overhead, simplicity and capabilities. Similar to XML, it even has a schema (http://json-schema.org/ ), which does not seems to be very popular among users, as it is considered unnecessary, main reason for that being the dynamically typed nature of languages in which JSON has its' roots: a JSON instance can be converted into a dynamically created class without any formal description being needed.
However, as TTCN-3 is a statically typed and strict language used in verification, the concept of schema is important, as schemas constitute the reference in decisions to be made by the code. As in XML, a JSON schema is the counterpart of a TTCN-3 type, while a JSON instance or document is the equivalent of a TTCN-3 variable/constant/template. TTCN-3 instances can be encoded into JSON instances and vice-versa.
TTCN-3 types can be used to generate the equivalent JSON schemes using the built-in Titan converter (--ttcn2json option). Conversion from JSON schemas to TTCN-3 types is not (yet) available in Titan, although it's quite straightforward; using the relevant chapter in the reference guide, this can be done manually.
Let's examine a number of use cases and associated work flows.
Test of JSON -based REST web services
The general layout of testing a JSON-based web service is the following:
we create some TTCN-3 templates which need to be encoded in JSON and sent to the web server to the endpoint and with the method indicated in the REST API. The reply, in JSON format has to be decoded and confronted to a reception template in TTCN-3.
To be able to encode/decode, we need to create TTCN-3 types equivalent to the JSON schema which could generate the JSON instances involved. Most of the time, there is no such JSON schema; TTCN-3 types can be written manually from JSON samples just by looking and them and converting them mentally. It might help to generate a schema from the JSON instance; if so, the JSON schema generator at http://jsonschema.net/ could be used.
Let's take the example of the geoplugin web service , one that cannot be simplified any further:
a GET request sent to http://www.geoplugin.net/json.gp?ip=22.214.171.124 will return some geo etc. data in JSON format:
curl -v http://www.geoplugin.net/json.gp?ip=126.96.36.199
* About to connect() to proxy www-proxy.ericsson.se port 8080 (#0)
* Trying 188.8.131.52... connected
* Connected to www-proxy.ericsson.se (184.108.40.206) port 8080 (#0)
> GET http://www.geoplugin.net/json.gp?ip=220.127.116.11 HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: www.geoplugin.net
> Pragma: no-cache
> Accept: */*
> Proxy-Connection: Keep-Alive
< HTTP/1.1 200 OK
< Server: geoPlugin/3.2.6
< Date: Tue, 14 Jul 2015 10:28:53 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 753
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
"geoplugin_credit":"Some of the returned data includes GeoLite data created by MaxMind, available from <a href=\\'http:\/\/www.maxmind.com\\'>http:\/\/www.maxmind.com<\/a>.",
* Connection #0 to host www-proxy.ericsson.se left intact
* Closing connection #0
Let's try to create the equivalent TTCN-3 type; obviously it's a record where the fields are mainly strings, , there's one integer (geoplugin_status) and one float (number in JSON-geoplugin_currencyConverter).
Let's name this type Geoplugin_response:
type record Geoplugin_response
integer geoplugin_status ,
charstring geoplugin_credit ,
charstring geoplugin_region ,
charstring geoplugin_areaCode ,
charstring geoplugin_dmaCode ,
charstring geoplugin_countryCode ,
charstring geoplugin_countryName ,
charstring geoplugin_continentCode ,
charstring geoplugin_latitude ,
charstring geoplugin_longitude ,
charstring geoplugin_regionCode ,
charstring geoplugin_regionName ,
charstring geoplugin_currencyCode ,
charstring geoplugin_currencySymbol ,
charstring geoplugin_currencySymbol_UTF8 ,
Now we can declare the encoding-decoding functions for this type; Titan will do the rest automatically.
What if we have several different JSON structures? It would be awkward to be in need of separate encoding-decoding structures for each; so let's collect them all into a union which we can name appropriately JSON_PDU (PDU for Protocol Data Unit , as these JSON messages are in fact protocol messages in the client -server communication):
In our case the union will have a single alternative:
type union JSON_PDU
There's a problem though: if we encode a geoplugin_response type template , the encoded JSON will reflect the nested union/record structure:
"geoplugin_request" : "18.104.22.168",
"geoplugin_status" : 200,
"geoplugin_credit" : "AAAAAAAAAAAAAAA",
"geoplugin_city" : "Part",
"geoplugin_region" : "Zala",
"geoplugin_areaCode" : "0",
"geoplugin_dmaCode" : "0",
"geoplugin_countryCode" : "HU",
"geoplugin_countryName" : "Hungary",
"geoplugin_continentCode" : "EU",
"geoplugin_latitude" : "46.549999",
"geoplugin_longitude" : "16.9167",
"geoplugin_regionCode" : "24",
"geoplugin_regionName" : "Zala",
"geoplugin_currencyCode" : "HUF",
"geoplugin_currencySymbol" : "Ft",
"geoplugin_currencySymbol_UTF8" : "Ft",
"geoplugin_currencyConverter" : 300.000000 }
To circumvent this, we have to use the
variant "JSON : as value"
encoding instruction to tell the codec that special treatment is needed: at encoding,
the nesting union has to be ignored, while at decoding, it has to be reconstituted.
To trigger the generation of JSON codecs by Titan, we need to decorate the geoplugin.ttcn module
The rest of the code does not require much explanation: an HTTP GET with the appropriate headers is sent to the server using the HTTP test port; the received JSON is extracted from the body and decoded/matched etc.
How to use the attached code:
Unpack to a SimpleREST directory
The Makefile was generated with:
makefilegen -s -e REST *.ttcn *.cc *.hh
|Re: Using JSON in TTCN-3 and Titan Part I: Testing REST / JSON web services: [message #1814660 is a reply to message #1814548]
||Mon, 16 September 2019 07:48
|| Sean Kuo
Registered: August 2019
Thanks for your reply & concern, I got some sleep by finished my ttcn progression with your generous help.
Current state of my work is, ttcn test is temporarily put aside due to some new tasks out of ttcn.
Most of my question is currently answered in [message #1814461], but still great thanks to you for confirming my conclusion about the type stuff in wireshark.
Probably won't be here for a couple days, or weeks ( hope that I can get back here soon, since I finally get familiar with titan and ttcn).
P.S. Sorry for replying sooo late, Fri 13th ( oof but I'm a christian so it is fine) Sep was Moon Fest. in our country that most labor could get a paid day off.
So, the Fri and weekends forms a little vacation.
And I have to express my gratitude again, I had a very sweet vacation without any overtime working due to so many of your helps and answers.
[Updated on: Mon, 16 September 2019 07:55]
Report message to a moderator
Current Time: Sat Jul 31 06:33:53 GMT 2021
Powered by FUDForum
. Page generated in 0.01524 seconds