Practical part: Testing X-Road dataservice Module 7 Practical part: Testing X-Road dataservice Name Date

Testing X-Road dataservice Explanation of the figure: four different layers are specified in the test environment: Green box – organisational layer Dark red boxes – information system layer Physical layer – servers Applications layer

Testing dataservice with SoapUI tool First, test the dataservice with SoapUI directly from the interfacing component Activate SoapUI Create a new SOAP project by selecting in the menu: File -> New SOAP project Enter data: Initial WSDL: – enter the WSDL address of your dataservice, e.g.: http://localhost:8080/person_register/services/p erson_registerSOAP?wsdl Select ‘OK’

In the ‘Navigator’ view of the project, open the service input window under the created project (Request 1) The generated request input is displayed on the left, request response after activating the request on the right. (SoapUI generated a request input; input fields and header fields are filled with any generated text) Activate a request by clicking the green activation button left at the top. Ensure that: SOAP request response is displayed in right part of the window. In the request response, values of X-Road header fields are the same as in the request input. Data of request response are filled with data in Java code.

Setting service in X-Road security server Set up WSDL in the security server as described in the chapter: 19.3. Adding a WSDL:  https://moodle.ria.ee/mod/book/view.php?id=352&chapterid=303 Data to be entered: To add WSDL, use the available subsystem <DEVTRAINING_XX_A> Enter the WSDL address of your development unit as WSDL address, with IP address instead of localhost. Enable WSDL of your subsystem in the security server as described in the chapter: 19.5. Enabling and disabling a WSDL:https://moodle.ria.ee/mod/book/view.php?id=352&chapterid=305 Set the dataservice endpoint address as described in the chapter: 19.6. Changing the address of a WSDL: https://moodle.ria.ee/mod/book/view.php?id=352&chapterid=306. In the ‘Service URL’ field of the security server, enter the endpoint address of your dataservice. Grant access rights for the service as described in the chapter: 21.4. Changing the access rights of a service: https://moodle.ria.ee/mod/book/view.php?id=353&chapterid=312 Grant access to the subsystem <DEVTRAINING_XX_B>

Testing dataservice with SoapUI tool in X-Road security server After setting up the dataservice in the X-Road security server and granting the rights, it is possible to test the service through the X-Road security server. Testing X-Road service through security server with SoapUI: Change endpoint field in SoapUI request window, entering the value: http://<security_server_IP_address> Change the header fields of the request in the request input window: Service/xRoadInstance: ee-dev (we operate in X-Road development instance) Service/ memberClass: COM Service/ memberCode: <XRD_MEMBER> Service/ subsystemCode: <DEVTRAINING_XX_A> Service/ serviceCode: <name of dataservice> Service/ serviceVersion: <dataservice version no> protocolVersion: 4.0 client /xRoadInstance: ee-dev (we operate in X-Road development instance) client / memberClass: COM client / memberCode: <XRD_MEMBER> client / subsystemCode: <DEVTRAINING_XX_A> Here, <XRD_MEMBER> is the X-Road member code used for the training prepared before training. <DEVTRAINING_XX_A> and <DEVTRAINING_XX_B> are subsystems of the dataservice provider and user prepared for the training, where XX represents the number of the participant; each participant uses a separate subsystem marked with their code. Activate the request by clicking the green activation button in the upper left corner. Check the request response

Introduction of MISP2 application MISP2 (mini-information system-portal) is a portal intended for authorities which enables using X-Road dataservices open for the authority. Any authority affiliated to X-Road can install the MISP2 portal and it enables the organisation to start quickly using X-Road services without the need to realise relevant functionality in other information systems of the authority. Installation of MISP2: Installation packages and installation manual are available to the public and referred to in the directory of reusable X-Road components (https://github.com/jointxroad/components/blob/master/component_descrip tions.md#x-road-portal-misp2) MISP2 generates automatically the user interface of X-Road services, and the input and output forms of services. Thus, MISP2 can be used in cases when dataservices are used via graphic user interface

Introduction of MISP2 application MISP2 uses the XForms standard for creating the user interface for X-Road dataservices. MISP2 generates interfaces in the XForms format, which can be changed in MISP2 portal with a special XForms editing form and adapted to your needs. However, this operation requires preliminary knowledge of the XForms standard (see also clause 7.6, more information about XForms). MISP2 complex services: XForms technology also enables realising complex services with more complicated logic, which realise a more complex business process, by using internally different X-Road dataservices. This can be done either by combining different generated service interfaces and modifying these as required, or by creating a new XForms service form manually from the beginning.

XForms technology MISP2 portal uses XForms technology for internal creation and activation of user interfaces of X-Road dataservices. XForms is a new generation form description language standardised by W3C. XForms is a XML-based standard which enables describing the forms of a service user interface, as well as service inputs/outputs in SOAP format and their interaction logic. XForms is intended for use in another XML language, usually XHTML. This means that a typical XForms file includes a mix of XHTML and XForms tags. XForms is structured with MVC (model-view-controller) principle. This means that data and their validation rules are described in a model usually located in <xhtml:head> section, while the display and the entry of data are located between other tags in <xhtml:body> section. For further studying of XForms technology: short instruction for creating new XForms complex service based on XForms generated in MISP2 application: http://x- road.ee/misp2/docs/est/misp2_kompleksteenuste_koostamine.pdf Further information about XForms standard is available at the address: https://www.w3.org/MarkUp/Forms/ For the realisation of XForms support, Orbeon XForms Forms Runner component is integrated in MISP2 application. Further information about Orbeon XForms is available at the address: https://doc.orbeon.com/xforms/tutorial/introduction.html

MISP2 server of training environment MISP2 server has been installed in the training environment for testing: MISP2 server login URL: https://x.x.x.x/misp2 User accounts are created for training, authentication with password: User name/password: assigned to each participant User account of the training has roles: regular user, service administrator, access rights administrator

Setting MISP2 server for testing X-Road services In MISP2 portal, the portal has been set up for testing and the user account used for testing has the following roles in this portal: service administrator, access rights administrator. In the X-Road security server used for testing, WSDL and dataservices have been set up for the test subsystem, and rights have been granted to the test subsystem for using these dataservices. Enter MISP2 portal and select ‘Service administrator’ in the role options for setting the services Explanation: initially the list is empty in the displayed table of active databases (or subsystems). In order to start using the X-Road services in MISP2 portal, the used subsystems must be added into the list of active subsystems Eeldused testimiseks: MISP2 portaalis on valmis seadistatud testimiseks portaal ja testimisel kasutataval kasutajakontol on olemas selles portaalis järgmised rollid: teenuste haldur, pääsuõiguste haldur. Testimisel kasutatavas X-tee turvaserveris on testitavale alamsüsteemile seadistatud WSDL ja andmeteenused ning antud testimisel kasutatavale alamsüsteemile õigused neid andeteenuseid kasutada. Selgituseks: viimane tegevus kuvab MISP2 andmebaasist kõik (seal hetkel olemasolevad) X-tee alamsüsteemid. Algselt on ka MISP2 andmebaasis alamsüsteemide nimekiri tühi ning MISP2 baasi tuleb uuendada X-tee turvaserverist.

Updating the list of X-Road subsystems from the security server: Click the button: ‘Update list of databases’ Explanation: this operation activates a request to the X-Road security server, from where the complete list of X-Road subsystems is requested. The received list is displayed to the user.

To save the list of active subsystems: In the displayed list of X-Road subsystems, find the subsystem set up in the security server for testing Tick the subsystem Click ‘Save active databases’

For updating the list of required active services of a subsystem, select a subsystem: In the table of active subsystems, select a subsystem for testing (which appeared in the table after saving the list):

On the following form, the list of open services must be updated from the X- Road security server Click: ‘Allowed from security server’ Explanation: this operation activates the request for the list of allowed services (allowedMethods) to the X-Road security server. MISP2 requests from the X-Road security server the list of services open in the X-Road security server for the subsystem set up in the portal. The list of open services is then displayed on the same form, as shown on the following figure.

Next, user interface must be generated for the service: Select ‘check box’ on the service name line Click: Update XForms descriptions of selected services: ‘Generate from security server’ Explanation: this operation activates the generation of the user interface (XForms) for selected service(s). After a successful completion of the generation, a message is displayer (XForms description updated! (<name of service>)), as shown on the following figure, and on the text field after the name of the service a text is displayed ‘Generated database <date time>’. After a successful generation of the user interface of the service, the administrator can activate the service for testing from the same form

Testing X-Road service in MISP2 application Before the administrator starts to grant rights to regular users for using X-Road services in MISP2 portal, they should check whether the use of the service through MISP2 is problem-free. In order to ensure that forms have been generated correctly, the administrator can open the generated form for testing and use it for testing the activation of the X-Road service. To open the user interface of the service: Click on the blue triangular icon beside the name of the service:

Generated user interface of the service opens Generated user interface of the service opens. Design of the displayed user interface depends on the description of each specific service or WSDL. To activate the service on input form, click the standard button: ‘Submit request’: Explanation: this operation activates the service and the SOAP request drafted based on the data entered on the input form is sent to the X-Road security server. Data of response received from the security server are displayed to the user in the service response form.

An example of a service response form

Using Orbeon Inspector When ‘developer view’ is enabled in the MISP2 administrator interface, during the testing of an X- Road service, it is possible to use the tool ‘Orbeon Inspector’. This enables viewing the request and response in SOAP format. To activate Orbeon Inspector, click on the link ‘Orbeon Inspector’: The form will open: ‘Orbeon Forms XForms Inspector’ On the form, you can view the request input and output by selecting in the ‘Instance’ menu either the <request name>.input or <request name>.output:

Testing services between authorities (group task) Testing of services of another authority or X-Road subsystem requires that a subsystem has opened their service in the security server for use by another subsystem Testing party in the role of service provider: Open the service of your subsystem in the security server for another subsystem wishing to test your service. This operation is further described in the ‘Learning material for X-Road security server administrator’: 21.4. Changing the access rights of a service: https://moodle.ria.ee/mod/book/view.php?id=353&chapterid=312

Testing services between authorities (group task) Testing party in the role of user of the service: Testing service of another subsystem with SoapUI: first, you should know the parameters of the service of the subsystem to be tested: <DEVTRAINING_XX_A>, <serviceCode>,<serviceVersion> Test as described below, ensuring that names of another subsystem and service are used as values of service header fields (not those of your own subsystem, as tested in chapter 6). Add a new SoapUI project with the test subsystem parameters Activate SoapUI Create a new SOAP project, select in the menu: File -> New SOAP project Enter data: Initial WSDL: – enter the WSDL address of the test service via the security server in the form: http://<turvaserveri_IP>/wsdl?xRoadInstance=ee- dev&memberClass=COM&memberCode=<XRD_MEMBER>&subsystemCode=<DEVTRA INING_XX_A>&serviceCode=<serviceCode>&version=v1 Select ‘OK’

Testing services between authorities (group task) Testing dataservice of another subsystem with SoapUI tool via X-Road security server: Change the endpoint field in SoapUI request window by entering the value: http://<security_server_IP_address> Change the header fields of the request in the request input window: Service/xRoadInstance: ee-dev (we operate in X-Road development instance) Service/ memberClass: COM Service/ memberCode: <XRD_MEMBER> Service/ subsystemCode: <DEVTRAINING_XX_A> Service/ serviceCode: <name of dataservice of another subsystem> Service/ serviceVersion: <version no of dataservice of another subsystem> protocolVersion: 4.0 client /xRoadInstance: ee-dev (we operate in an X-Road development instance) client / memberClass: COM client / memberCode: <XRD_MEMBER> client / subsystemCode: <DEVTRAINING_XX_B> Here, <XRD_MEMBER> is X-Road member code used for training, which is prepared before training. <DEVTRAINING_XX_A> and <DEVTRAINING_XX_B> are the subsystems of the service provider and the user prepared for the training, where XX represents the number of the participant; each participant uses a separate subsystem marked with their code. 3. Activate request by clicking the green activation button in the upper left corner. 4. Check the request response.

Testing the service of another subsystem with MISP2 Refresh the list of services of another subsystem and generate forms as described in clause 7.3.

Thank You! First name Surname firstname.surname@amet.ee The training materials for developers of X-Road interfaces have been compiled with funding from the structural funds support scheme “Raising Public Awareness about the Information Society” of the European Regional Development Fund.