3 Testing the Installation

This chapter describes testing your installation, and incudes the following information:

Testing Overview

You can test DIVA Enterprise Connect using standard SOAP or REST test clients that can consume WSDL (Web Services Description Language) documents, WADL (Web Application Description Language) documents, or both. The DIVArchive Web Services also contains a set of scripts that make testing the DIVArchive Web Services easier.

Using Automated Testing Tools

Many open source and commercial tools exist for testing Web Services. Many of them can parse a WSDL or WADL document to enable Web Services testing. You must supply the following URL of the WSDL or WADL to use these tools:

http://127.0.0.1:9443/diva/service/soap/2.2/DIVArchiveWS_SOAP?WSDL

http://127.0.0.1:9443/diva/service/rest/2.2/DIVArchiveWS_REST/application.wadl

Substitute the actual network address of the DIVArchive Web Services platform in the URL. You may need to provide a user name and password to access the WSDL, or WADL, document from.

Using the wsTest Scripts

The DIVA Enterprise Connect release includes Linux shell scripts that can be used for testing. If you have access to the DIVA Enterprise Connect release, these scripts can make testing DIVArchive Web Services easier.

The wsTest scripts use the standard cURL utility to invoke the DIVArchive Web Services. The scripts automatically create a session for each call by default. This simplifies the testing process for the Web Service calls. The wsTest scripts are located in the $DIVAS_HOME/scripts/wsTest directory.

You use the following syntax to execute the scripts:

./wsTestRest.sh {baseUrl} {version} {templateCommand}
./wsTestSoap.sh {baseUrl} {version} {templateCommand}

The following is a list of the parameters used with the scripts:

baseUrl

This parameter identifies the base URL of the DIVArchive Web Service (for example, http://127.0.0.1:9443/diva/service).

version

This parameter identifies the protocol version level of the DIVArchive Web Service API (the current protocol release is the string v2.2). This is not the software release level of the DIVA Enterprise Connect.

templateCommand

This parameter identifies the Web Services command to execute. The parameters for the command are looked up in the template file, which contains a section for each call. The templates are located in the soapTemplate.sh script for SOAP, and in the restTemplate.sh script for REST. Each template depicts a sample call with all parameters populated with test data. You must edit these scripts to supply the desired parameters for each command.

--nosess

This is an optional parameter. Normally, the scripts will attempt to obtain a Web Services session ID before executing each command. You can use this argument to supply your own session ID in the template.

Example Call

The following is an example execution of the wsTest scripts. The getRequestInfo() call is being tested in the example. In this example, a new session ID will be fetched if needed. The parameters for this call are retrieved from the restTemplate.sh file.

./wsTestRest.sh http://127.0.0.1:9443/diva/service v2.2 getRequestInfo

Creating Sessions Automatically

Caution:

You must only use the automatic session creation feature for testing, and not in production.

The scripts are configured to automatically create the required session ID to run each service. The scripts generate the new session ID, and then pass it in the chosen web service request. The wsTest scripts save the new session ID in a file, so it can be reused on the next call. Sessions (by default) last for 30 minutes, and then they expire.

If you do not want the wsTest scripts to automatically create the session ID, you must include the --nosess parameter in the command line when executing the test script. You can assign a fixed value for the SESS_ID variable in the template file. If you call registerClient() yourself, and populate your own session code, the code will eventually expire, and you will have to repeat the process.

Editing the Templates

If you view the restTemplate.sh or soapTemplate.sh shell scripts, you will see a shell variable representing each Web Service call, and XML parameters. You can edit the XML to customize the arguments to the Web Service. Some parameter values in the template are derived from a shell variable. For example, the following is a section in the restTemplate.sh file that defines the parameters for the getObjectInfo() request:

getObjectInfo='
<p:getObjectInfo xmlns:p="http://interaction.api.ws.diva.fpdigital.com/xsd">
   <p:sessionCode>'$SESS_ID'</p:sessionCode>
   <p:objectName>'$OBJ_NAME'</p:objectName>
   <p:objectCategory>'$OBJ_CATEGORY'</p:objectCategory>
</p:getObjectInfo>'

The $OBJ_NAME variable is defined at the top of the template script. The variables let you easily customize parameters for many commands. You can choose to populate the variable at the top of the template, or remove the variable and hard code the objectName directly in the getObjectInfo() command.

Authentication

Because basic authentication for Web Services is turned on by default, you must populate the $CLIENT_ID and $AUTH_KEY variables at the top of restTemplate.sh, or soapTemplate.sh if you are using SOAP. You must use values that were created by executing the DIVA Enterprise Connect Key Generator, or preset values assigned to you by Oracle Support.

Calling the cURL Tool Directly

The cURL command line tool enables transferring data to, or from, a server using one of the supported protocols. The cURL utility supports HTTP transfers and basic authentication. The wsTest scripts use cURL in the implementation, but you can call cURL directly as needed. The cURL tool is a standard utility in Oracle Linux 7 and later. See Chapter 2 for examples of calls using cURL.