Testing

Content

Testing

Precondition

The companies that want to test the system have to provide the IP address of their proxy server to RNE. Only the requests that are coming from the announced IP addressed will be accepted. It is also recommended to check of the existence of PCS Core System test user account for the particular organization (e.g. sbb-p or db-f). If an additional user has to be provided, the organization has to contact RNE.

Installation

The web service implementation can be tested with soapUI (http://www.soapui.org/), the Web Services Testing tool.

The tool needs to be first installed on the local system. Installation scenarios are defined in http://www.soapui.org/gettingstarted/index.html. We suggest using Java WebStart for its’ simplicity.

Configuration

In order to allow easy start, PCS Support (support.pcs@rne.eu) provides Soap UI project file *.xml which can be imported in soapUI tool. The file can be found on PCSIP development [12] site under references section (SoapUI Vx clien project).

After you have saved the file to your local system, the procedure for importing it looks like this:

Import Project function

Select PCS soapUI project file

Configured requests for web services call

soapUI test requests

authenticate operation

  • authenticate – shows a valid request example.

Example of valid authenticate request

The request should include user credentials.

For authentication data for PCS development system, please contact RNE. RNE will provide you with the access upon your request. The users that are used to testing on PCS Core System tgv.netcetera.ch can use the same credentials.

The response looks as follows:

<authenticateResponse>

            <status>100</status>

            <authenticateData>

             <sessionid>JSESSIONID=3F3AD698B94308E88EC369B83BAA2C50</sessionid>

            </authenticateData>

</authenticateResponse>

 

In order to continue conversation with the server, the returned JSESSIONID must be included in the request body for all requests in the particular session.

createDossier operation

Caller of this operation can create several dossiers at once. The dossiers are separated with the tag <requestSection> (see the examples given in the soap-ui project xml file).

In order to execute the operation, corresponding JSESSIONID needs to be added to the request body at the end of the given XML structure (look the examples given in IntegrationPlatform-soapui-project.xml):

<authenticateData>          <sessionid>JSESSIONID=3F3AD698B94308E88EC369B83BAA2C50</sessionid>            </authenticateData>

</createDossierRequest>

IMPORTANT: The above snippet has to be adjusted with the valid JSESSIONID for each subsequent request.

getDossier operation

  • getDossier – no version specified, using the latest one

updateDossierRUIMPair operation

  • updateDossierRUIMPair – base request for updateDossierRUIMPair operation, can’t be used without modification.

In order to test updateDossierRUIMPair, one needs to first call getDossier and then copy the result into the updateDossierRUIMPair request (between <getDossierResponse> element, starting with <pathfinderintegration> tag).

Part of getDossier response which needs to be copied is shown on the next two pictures.

Start of copy information

End of copy information

All the requests can be triggered on the mouse click (first, double-click on a corresponding request and after press "Play"  button in the request editor).

Web Services Security enabled endpoint

In addition to the HTTPS endpoint, web services suite contains a Web Services Security enabled endpoint [10] which is configured to support the following WSS actions:

  • Encryption
  • Signature
  • Timestamp

In order to allow easy start, we provide Soap UI project file pcsip-webservices-security-soapui-project.xml file which can be imported in soapUI tool.

Nevertheless, the next chapter contains a step-by-step soapUI configuration tutorial for WSS support.

soapUI configuration for Web Services Security support

This tutorial is an extension to the soapUI provided documentation[11].

First step is the configuration of the client keystore.

soapUI project keystores

For testing purposes, a keystore named clientKeystore-test-rne.jks should be used. It contains two entries:

  • pfipclientkey (private key for the client)
  • pfipservicekey (public key for the server)

soapUI project keystore selection

After the selection of the client keystore, keystore password should be entered. For clientKeystore-test-rne.jks keystore, the password is “cspass”.

soapUI project keystore password input

soapUI project keystore selection result

After the client keystore is added, we need to define Outgoing and Incoming WSS configuration.

soapUI project Outgoing WSS configuration

soapUI project new outgoing WSS configuration

Outgoing WSS configuration should contain the following WSS Entries:

  • Encryption
  • Signature
  • Timestamp

soapUI project new WSS entry

soapUI project WSS entry type selection

For outgoing encryption, the public key of the server should be used.

soapUI project Encryption configuration

soapUI project Encryption configuration (part 2)

All required input for outgoing encryption is captured in the figure below.

soapUI project Encryption configuration result

soapUI project Signature configuration

For outgoing signature, the private key of the client needs to be selected and the same password as the keystore password (“cspass”) should be entered.

All required input for outgoing signature is captured in the figure below.

soapUI project Signature configuration (part 2)

soapUI project Timestamp configuration

All required input for outgoing timestamp is captured in the figure below.

soapUI project Timestamp configuration (part 2)

soapUI project Incoming WSS configuration

soapUI project new Incoming WSS configuration

The incoming WSS configuration should reference the keystore to be used for decryption of the response and verification of the signature. Keystore password should be entered again.

soapUI project new Incoming WSS configuration result

After the soapUI configuration is done, WSS enabled endpoint needs to be added.

WSS enabled endpoint

In order to execute WSS-enabled request, one must to set the outgoing and incoming WSS configuration on the request itself first (shown in the figure below).

WSS enabled request preparation

If everything is configured properly, the response should contain all WSS headers with the decrypted response as in the figure below.

WSS response

Verification

soapUI interface allows analysis of SOAP requests and responses, thus making it easier to troubleshoot the web service implementation. An example is shown on the picture below:

Response for withAllElements request

For createDossier operation, the created dossier can also be verified by login into the PCS Core system (https://pcstest1.rne.eu/pcs/login) using the appropriate PCS user credentials. The newly created dossier should be visible in the user’s dashboard.

The PCS user can also export the particular dossier in the format that is suited for web service communication with the system by choosing the export type “WS XML” in “Basic Data” of the particular dossier.

Create/Get/Update dossier scenario and dedicated update operations

Beside the standard WS operations, the imported soapUI project contains two test suits that show an example of creating get and update dossier.

Test suite for create get and update dossier

The test suite that is shown above can be started by double click on “IProxyIntegrationSoapBinding_v4_0 Create/Get/Update dossier” and  "Play" button. With this test suite is described following scenario: first tray to login with db-f user; than create dossier using “createSingleDossier” operation and get dossier using “getDossier” operation; after that the output response of getDossier operation will be copied to “updateDossierRUIMPair” WS operation and the db-f user will try to change the value of “Highest planned speed” parameter and accept the dossier; next the suit will try to login with cd-p, change the time of ‘Bln Hbf-Le Bf(u’ operation point and accept the dossier; after the dossier is accepted with cd-p, the db-f will promote the dossier to Path request phase; next is login with db-netz and promote the dossier to Path Elaboration. The result is shown on below.

Result of “IProxyIntegrationSoapBinding_v4_0 Create/Get/Update dossier” execution

The second test suite that is part of the imported soap UI project is “IProxyIntegrationSoapBinding_v4_0 DedicatedUpdateOperations”. It can be executed the same way as the first test suite.

Test suite for create get and update dossier using dedicated update operations (updatePath, updatePathSections, updateProgressStatus, updateDossierStatus).

This scenario again creates new dossier using “createSingleDossier” and get dossier using “getDossier” ws operaion; after the dossier is successfully created, the first Applicant timetable is copied in “updatePath” ws operation and the value of traffic period is updated with db-f user; next the first path sections is copied to “updatePathSections” operation and the departure time is updated; after that, the db-f and cd-p accept the dossier using the “updateProgressStatus” operation and finally the dossier is promoted to Path request using the updateDossierStatus operation. The result of this operations is newly created, accepted and promoted dossier to path request phase.

Result of “IProxyIntegrationSoapBinding_v4_0 DedicatedUpdateOperations” execution