This chapter describes testing your installation, and incudes the following information:
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.
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.
wsTest
ScriptsThe 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.
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
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.
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.
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.
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.