The new Service Layer allows to access EFS key functionalities from outside EFS. Thus, applications relying on EFS data and functionalities can be created outside EFS with quite different technologies. EFS functions which are of interest to customers will be made available as well. The services can be called from outside via HTTP or HTTPS. Various data exchange formats can be used (e.g. JSON). The Service Layer covers the scope of functionality of the old Web-Services, which should no longer be used.
Configuring the Services
A dedicated configuration menu allows to view and configure the services which are available on your EFS installation. The menu is in Options → Service-Layer → Service-Layer. The menu has the same structure as the menu for the deprecated SOAP services (Options → Service-Layer → Web services). The Service-Layer menu is only available if Questback’s Support-Team has activated usage of services for your installation. To view and access the menu, you need either read rights for the ACL right webservice_conf or membership in the root team.
The following steps are necessary to use a specific service:
Questback’s Support-Team has to add the service.
The service must be activated. If necessary, the button Activate all services allows to activate all services available on the installation en bloc.
The staff account used to access the service is allocated to a specific staff team. This staff team must have the necessary access rights to the service. Access rights to individual services can be assigned on the tab Access groups.
Furthermore, many services include a check for object rights. To use sur- vey.questionnaire.createPage or survey.questionnaire.deletePage, for example, the staff team needs write rights for the target project.
All calls are logged on the Access log tab. The entries can be searched by IP address, name of the admin account used, service name and date.
Access Modes
The service layer offers two access modes:
Description: In this modus, the service layer will describe itself. In SOAP format, for example, a WSDL will be generated and delivered. This modus allows clients to find out which services are provided and which parameters they have
Transaction: In this modus, a service method is called and executed. How you address these modes depends on the format handler used.
Format Handler
Currently the service layer supports HTTP/HTTPS and three internal formats:
PHP-serialized: Here, the input and output parameters are transferred as serialized PHP arrays. This is the recommended approach for PHP clients.
To activate the handler, use the URL parameter "handler" with the value "php".
The name of the invoked method is handed over in the URL parameter "meth- od". The method name is structured as follows: MODU- LENAME.ACTORNAME.METHODNAME (separator: periods).
If the request is an HTTP GET request, the description mode will be triggered. Otherwise, the transaction mode will be used.
JSON: Data are transferred in JSON encoding. See the example below.
To activate the handler, use the URL parameter "handler" with the value "json".
The name of the invoked method is handed over in the URL parameter "meth- od". The method name is structured as follows: MODU- LENAME.ACTORNAME.METHODNAME (separator: periods)
If the request is an HTTP GET request, the description mode will be triggered. Otherwise, the transaction mode will be used.
SOAP: SOAP is used to transfer data. See the example below.
To activate the handler, use the URL parameter "handler" with the value "soap".
The name of the invoked method is handed over in the URL parameter "method". The method name is structured as follows: MODU- LENAME_ACTORNAME_METHODNAME (separator: underlines _).
If the URL parameter "wsdl" is set in the request, the description mode will be triggered and a WSDL will be generated. Otherwise, the transaction mode will be used.
REST: See REST API documentation on this page
To activate the handler, use the URL parameter "handler" with the value "rest".
If the URL parameter "raml=1" is set in the request, the description mode will be triggered and a RAML of available API services will be generated. Otherwise, the transaction mode will be used.
Authentication
Two authentication methods can be used:
Tokens: QuestBack Support can provide tokens for you and your staff members. These tokens can be used for authentication when invoking a service (parameter name: "to- ken").
Account name and password for the EFS admin area: The easiest authentication meth- od, as any staff member with admin area access already owns an account. But please mind: When calling the services via http, account name and password will be trans- ferred unencrypted, i.e. it is possible to log them e.g. on proxies and use them to access the admin area. Therefore, QuestBack recommends to use tokens or to call the services via SSL.
Calling the Service Description
Self-description of the PHP handler:
http://your-domain.com/service/?handler=php
Calling the WSDL:
http://your-domain.com/service/?handler=soap&wsdl=1
The new service layer allows to configure access rights individually for each service and each staff team. Therefore, when accessing the service layer, you will now find a dynamic list of services. There is no central WSDL file anymore, instead the WSDL file will be generated dynamically each time someone invokes the services according to that per- son’s access rights. That way, the invoking users will see a WSDL for the very services they are allowed to use.
Important Parameters
These are the most important parameters:
handler: name of the format handler (php, json, soap).
method: name of the called method for PHP and JSON handler.
version: optionally-used version number of the Service API.
token: contains the token for authentication.
wsdl: generates the WSDL if the SOAP handler is used.
Examples
Below are two examples. The first example illustrates JSON call with http authentication and the second illustrates SOAP call with http authentication.
Example: JSON call with http authentication
/**
*Please adapt **/
$baseUrl="http://your.server.name/"; $userName="user1"; $passwd="topsecret";
/* *********************** */
/**
*if necessary please adapt */
set_include_path(get_include_path().':'.dirname(__FILE__).'/../wcp/3rd/');
/* **************** */
require 'Zend/Http/Client.php';
$call = array('method'=>'efs.system.getLoad','params'=>array());
$url=$baseUrl."service/index.php?handler=json";
$client=new Zend_Http_Client(); $client->setUri($url); $client->setAuth($userName,$passwd); $client->setMethod(Zend_Http_Client::POST);
$client-
>setRawDa- ta(json_encode(array('method'=>$call['method'],'jsonrpc'=>'2.0','id'=>1,'params'=>$call[' params'])));
$response=$client->request();
/**
*Get JSON result */
$return=$response->getBody();
Example: SOAP call with http authentication
/**
*Please adapt **/
$baseUrl="http://your.server.name/"; $userName="user1"; $passwd="topsecret";
/* *********************** */
ini_set("soap.wsdl_cache_enabled",0); ini_set("default_socket_timeout",10);
/**
*if necessary please adapt */
set_include_path(get_include_path().':'.dirname(__FILE__).'/../wcp/3rd/');
/* **************** */
$call = array('method'=>'efs.system.getLoad','params'=>array());
$client = new SoapClient($baseUrl."service/index.php?handler=soap&wsdl=1",array( "style"=>SOAP_RPC,
"use"=>SOAP_ENCODED, "encoding"=>"UTF-8", "login"=>$userName, "password"=>$passwd, "trace"=>1,
));
$r=call_user_func_array(array($client,str_replace('.','_',$call['method'])),$call['params']);
/**
*Get result as XML String **/
$req = $s->__getLastRequest();
Overview of the REST API’s
Besides the legacy adapters SOAP, PHP and JSON-RPC, a new handler has been implemented to follow the RESTful services paradigm.
The new REST Api is addressed by URIs that contain more than 3 path-elements i.e. https://myinstallation.questback.com/service/survey/surveys/
/service/ element is mandatory to address the service layer for any adapter
If further path elements exist, REST adapter will automatically be used:
/service/survey/surveys/ → REST adapter will automatically be involved and handler parameter isn't needed
/service/index.php → This format is used to access SOAP, PHP and JSON-RPC API. REST adapter will not be involved and a handler parameter must be declared i.e. /service/index.php?handler=soap.
The REST api provides a service-description in RAML 0.8 format.
Description will be delivered if parameters raml=1 and handler=rest are provided in URL:
https://myinstallation.questback.com/service/?handler=rest&raml=1
This description can be used to automatically create test-suites as well as service-stubs for various programming languages, see http://raml.org/ for further information.
Description is created dynamically and will contain only methods, which are accessible by the currently logged-in service layer user.
As with other service layer adapters, individual services need to be activated for the user/ group in order to be used by that user/ group. (See System > Options > Services in EFS)
The content type of all requests containing a HTTP body must be application/json
That means that BODY content must be JSON-Encoded.