4 Web Services

Installing the Oracle Web Service Manager (OWSM)

The Oracle Web Service Manager (OWSM) applies server policies on the Oracle Clinical web service application. OWSM requires access to a database and you can use any compatible database.

You can install OWSM from the Quick Start installation program that installs the Oracle Enterprise Manager.

To install OWSM:

1. Click on the Windows Start button and select All Programs.

2. Find and click on the Oracle WebLogic folder and select QuickStart.

   The WebLogic Platform Quick Start screen opens.

3. Click on Getting started with WebLogic Server 10.3.6.

   The Fusion Middleware Configuration Wizard opens to the Welcome page.

4. Select Create a new WebLogic domain and click Next.

   The Select Domain Source page opens.

   Note:

   If you already have a domain, you can extend the existing domain to install OWSM. To do so, for this step select the Extend an existing WebLogic domain checkbox and proceed to the next step.

5. Select Generate a domain configured automatically to support the following products and then select the checkboxes for Oracle Enterprise Manager - 11.1.1.0 [oracle_common] and Oracle WSM Policy Manager - 11.1.1.0 [oracle_common]. Oracle JRF - 11.1.1.0 [oracle_common] is automatically selected, leave it as is.

   Click Next.

   The Specify Domain Name and Location page opens.

6. Replace the default values with your domain name and location.

   Note:

   Save the entered domain name and location. This information is required in later steps.

   Click Next.

   The Configure Administrator User Name and Password page opens.

7. Enter your username and password, and then click Next.

   The Configure Server Start Mode and JDK page opens.

8. Select Production Mode in the left pane and Available JDKs in the right pane.

   Click Next.

   The Configure JDBC Component Schema page opens.

9. Fill in the fields with your information. This information should match the information used to run the RCU.

   The Driver information is set by default. Leave it at the default setting.

   Click Next.

   The JDBC Component Schema page opens. This page confirms that the information on the previous page is correct to use when installing the OWSM Policy Manager.

10. Click Next.

    The Select Optional Configuration page opens.

11. If you are installing in a WebLogic server that was installed for Oracle Clinical RDC, select the Administration Server and Managed Servers, Clusters and Machines checkboxes to change the default port numbers for the servers.

    Otherwise, click Next on the following screens without making any changes until you reach the Configuration Summary page, then continue with step 15.

12. Click Next.

    The Configure the Administration Server page opens.

13. Change the default listen port and then click Next.

    Note:

    The port you use must be different from the ones used for any other running servers.

    The Configure Managed Servers page opens.

14. Change the default listen port and then click Next.

    The Configuration Summary page opens.

15. Verify the details of the domain and components that you selected for installation, and then click Create to continue the installation.

    The Creating Domain page opens.

16. When progress reaches 100%, click Done to complete the installation and exit the wizard.

You can access the admin server console for the new domain at http://middletier_name:admin_server_port/console.

Installing the Oracle Clinical Web Services in the WebLogic Server

1. Log into the WebLogic server console as a WebLogic user.

2. In the Domain Configurations panel, under the Deployed Resources section, select Deployments.

   The system displays all of the applications currently deployed on this server.

3. Click Install to deploy all of the options.

4. Click the Upload your file(s) option to upload the .ear file from your local machine.

5. Click Next.

6. Click Next and then choose the option Install this deployment as an application.

7. Click Next.

8. Choose from the available targets, such as soa_server1, and click Next.

9. Set OracleClinical-WS as the name of the application. Then click Next.

   Note:

   Do not change any of the other default values.

   The system displays your configuration details. You can edit the details by navigating back through the screens.

10. Click Finish.

To confirm that the web services deployed successfully:

1. Go to the list of Deployments and verify that the OC Webservices project is in the Active state.

   If it is in the New state, start the managed server from Environment > Servers.

2. Click on the application and select the Testing tab. There should be three Test Points available to check the three web services: InvestigatorService, Site Service, and StudySite Service.

   Before you can test these web services, you must create a data source. See To create a data source: below for instructions on how to do this. You can create the data source in the current session.

3. Once the data source is created, select the link Test Client under Test Point for each web service to check that it is working properly.

To create a data source:

1. In the same console screen from the previous section, under Domain Structure, click Services, and then click Data Sources.

   The system displays all existing data sources.

2. Click New.

   Three options are available.

3. Select the Generic Data Source option.

4. In the Create Screen, name the datasource OracleClinicalCoreDS.

5. In the JNDI Name column, enter jdbc/OracleClinicalCoreDS.

   Note:

   Do not change any other settings from their default values.

6. Click Next.

7. Click Next.

8. Click Next and enter the database name, host name, and port of your Oracle Clinical database. You must enter rxa_ws as the username and the password for the rxa_ws user.

9. Click Next.

10. Select your SOA server as the target. For example, select soa_server1.

11. Click Finish. The data source is created and deployed on the target server.

12. Verify that the data source was successfully created in the list of data sources. Click on the data source and go to the Monitoring tab.

13. Select the Testing tab and test the data source.

Server Side Configuration

In this sample configuration we are using the OpenSSL certificate management tool to demonstrate the process.

1. Download OpenSSL for Windows from https://code.google.com/p/openssl-for-windows/downloads/list

2. Install the application in C:\OpenSSL and place the executables in the C:\OpenSSL\bin folder instead of the Windows system folder.

   You can install the application in another folder, but the above path is recommended.

3. Once the installation is complete, add the new bin folder to your system path as follows:

   1. Right-click on My Computer and select Properties.

   2. Go to the Advanced tab and click Environment Variables.

   3. Under System Variables, select Path and click Edit.

   4. If the Path value does not end with a semicolon, add one.

   5. Add a path to the bin folder. For example, C:\OpenSSL\bin.

   6. Click OK three times to finish.

4. Generate the certificate authority as shown in the steps below, which are performed in the Command Prompt. In the example, the alias webservice is used.

   1. Create directories in which to store the certificates using the below commands:

      mkdir client
      mkdir server
      mkdir ca
      

   2. Generate an RSA private key for the certificate, called ca.key.

      Openssl genrsa -des3 -out ca/ca.key 4096
      

      When the message Enter pass phrase for ca/ca.key: is displayed, type in a password. For example, welcome.

   3. Create the master certificate, called ca.cer, using the key generated before.

      openssl req -new -x509 -days 365 -key ca/ca.key -out ca/ca.cer -subj "/CN=HSGBUSupportCA/OU=HSGBU/O=Oracle/L=Burlington/ST=Massachusetts/C=US" -config OpenSSLpath\openssl.cnf
      

      OpenSSLpath stands for the path for the directory where OpenSSL was installed at step 2.

      When the message Enter pass phrase for ca/ca.key: is displayed, type in the password used for the above step.

5. Generate server certificates by following the steps below:

   1. Use the keytool command -genkeypair to generate the key pair for the alias servercer. The key pair is used for SSL configuration on the server.

      keytool -genkey -keyalg RSA -alias servercer -keypass welcome -keystore server/server_keystore.jks -storepass welcome -dname "CN=<servername>,OU=HSGBU,O=Oracle,L=Burlington,ST=Massachusetts,C=US" -validity 365
      

   2. Generate the certificate request for servercer using the -certreq command. This generates a certificate request for the servercer alias and a certificate signing request (CSR) named server/servercer.csr.

      keytool -certreq -alias servercer -sigalg "SHA1withRSA" -file server/servercer.csr -storetype jks -keystore server/server_keystore.jks -storepass welcome
      

   3. Sign the CSR file using the CA created above. Run the command:

      keytool -list -v -alias servercer -keystore server/server_keystore.jks -storepass welcome
      

      The response for the above command also returns the certificate serial number, which is needed for the following step. You can find it in the line starting with Serial Number.

   4. Submit the CSR file to a CA, which authenticates the request and returns a certificate or certificate chain.

      openssl x509 -req -days 365 -in server/servercer.csr -CA ca/ca.cer -CAkey ca/ca.key -set_serial 0x<serial number from above step> -out server/servercerIssuedByCA.cer
      

   5. Import the CA root certificate, which authenticates the CA's public key.

      keytool -importcert -alias 'oracleHsgbuca' -trustcacerts -file ca/ca.cer -keystore server/server_keystore.jks -storepass welcome
      keytool -list -keystore server/server_keystore.jks -storepass welcome
      

   6. Replace the self-signed certificate with the trusted CA certificate issued by the CA in response to the certificate request using the -importcert keytool command. This replaces the self-signed certificate servercer with the trusted CA certificate named server/servercerIssuedByCA.cer.

      keytool -importcert -trustcacerts -alias servercer -file server/servercerIssuedByCA.cer -keystore server/server_keystore.jks -storepass welcome
      keytool -list -keystore server/server_keystore.jks -storepass welcome
      

      The HSGBUSupportCA (trustedCertEntry) and the servercer (PrivateKeyEntry) certificates are stored in the server/server_keystore.jks. The server/server_keystore.jks file is used to configure web services for the WebLogic server.

6. Generate certificates for the client, the AIA server, by following these steps:

   1. Use the keytool command -genkeypair to generate the key pair for the alias webservice, which is later used for encryption.

      keytool -genkey -keyalg RSA -alias webservice -keypass welcome -keystore client/client_keystore.jks -storepass welcome -dname "CN=webservice" -validity 365
      

   2. Use the -importcert keytool command to import the trusted CA root certificate, named ca/ca.cer here, using the alias ocalehsgbuca, into the client-keystore.jks keystore.

      keytool -importcert -alias "oracleHsgbuca" -trustcacerts -file ca/ca.cer -keystore client/client_keystore.jks -storepass welcome
      

   3. Generate the certificate request using the -certreq keytool command. The below command generates a certificate request for the webservice alias and a CSR named client/webservice.csr.

      keytool -certreq -alias webservice -sigalg "SHA1withRSA" -file client/webservice.csr -storetype jks -keystore client/client_keystore.jks -storepass welcome
      

   4. Get the serial number for the certificate, which is needed in the following step.

      keytool -list -v -alias webservice -keystore client/client_keystore.jks -storepass welcome
      

   5. Submit the CSR file to a CA for authentication. The CA returns a certificate or certificate chain.

      openssl x509 -req -days 365 -in client/webservice.csr -CA ca/ca.cer -CAkey ca/ca.key -set_serial 0x<serial number from above step> -out client/webserviceIssuedByCA.cer
      

   6. Use the -importcert keytool command to replace the self-signed certificate with the trusted CA certificate issued by the CA in response to the certificate request. The following command replaces the self-signed certificate for the alias webservice with the trusted CA certificate named client/webserviceIssuedByCA.cer.

      keytool -importcert -trustcacerts -alias webservice -file client/webserviceIssuedByCA.cer -keystore client/client_keystore.jks -storepass welcome
      

   7. List the content of the keystore client/client_keystore.jks.

      keytool -list -keystore client/client_keystore.jks -storepass welcome
      

   8. Import the public server certificate for the encryption.

      keytool -importcert -trustcacerts -alias servercer -file server/servercerIssuedByCA.cer -keystore client/client_keystore.jks -storepass welcome
      

   9. List the content of the keystore client/client_keystore.jks and server_keystore.jks.

      Keytool -list -keystore client/client_keystore.jks -storepass welcome
      Keytool -list -keystore server_keystore.jks -storepass welcome
      

7. Configure the security provider on Enterprise Manager for the OCWebService domain by following the below steps.

   1. Log into the Fusion Middleware control for the domain at http\\servername:port)\em.

   2. Right-click on the domain you are configuring and select Security, then Security Provider Configuration.

   3. In the Keystore section, click Configure.

   4. Fill in the fields with the below information:

      Keystore Type: JKS

      Keystore Path: C:/x509/server/server_keystore.jks (server keystore location used for step 4-a.)

      Keystore Password: welcome (used in the commands to create the keystore)

      Signature Key Alias: servercer (created using the keytool command)

      Alias Password: welcome (created using the keytool command)

      Encryption Key Alias: servercer (created using the keytool command)

      Alias Password: welcome (created using the keytool command)

   5. Click OK.

8. Configure the credentials for the web service server as shown below.

   1. Right-click on the domain you are configuring and select Security, then Credentials.

   2. Make sure there is an entry under the Credentials tree with the name oracle.owsm.security.

      The content of these entries must be based on the information used in the previous step. The same passwords apply.

   3. Add a new realm from the administration console at http\\servername:port)\console.

      To do so, under Domain, click on Security Realms and select the default realm. Select the Users and Groups tab and click New. Provide the required information, making sure that the name is the same one that was used to generate the certificate on the client side. Click OK.

   4. Once the configuration is complete:

   • Restart all the affected managed servers for the new configurations to take effect.

   • Restart the admin server.

Client Side Configuration

Configuring the client side can be performed by uploading a new WSDL file to the SOA server. In the AIA layer, the Enterprise Business Service (EBS) calls the Oracle Clinical provider using routing rules defined in the EBS. Web Services Description Language (WSDL) requires web services to communicate between Oracle Clinical and the EBS. For details on how to configure EBS and web services, see the Oracle Study, Subject, and Visit Synchronization Integration Pack for Siebel Clinical and Oracle Clinical Implementation Guide, available at http://docs.oracle.com/cd/E51618_01/doc.111/e36156/toc.htm">>http://docs.oracle.com/cd/E51618_01/doc.111/e36156/toc.htm.

After you complete the Oracle Clinical web service installation process, verify that the security policy is configured for web services and save the WSDL files in order to upload them to the client. The Oracle Clinical Web Services Description Language (WSDL) files can be located by accessing the deployed Oracle Clinical web service through any web browser. You can display the WSDL of the web service in your browser to ensure that it has deployed correctly using the following URL:

http://host:port/contextPath/serviceUri?WSDL

Where:

host refers to the computer on which the Oracle Clinical web service, deployed on the WebLogic server is running.

port refers to the port number on which the WebLogic Server is listening.

contextPath refers to the context root of the web service.

serviceUri refers to the value of the serviceUri attribute, such as InvestigatorService, SiteService, or StudySiteService.

To configure the client side:

1. Navigate to $AIA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary/OracleClinical/V1/wsdls.

2. Take the backup of InvestigatorService.wsdl, SiteService.wsdl, and StudySiteService.wsdl.

3. Copy the updated WSDL file.

4. Upload the new WSDL file to the MDS following the instructions below.

   1. Navigate to the $AIA_INSTANCE/config directory.

   2. Create a backup of UpdateMetaDataDp.xml.

   3. Edit UpdateMetaDataDp.xml file as follows:

      <?xml version="1.0" standalone="yes"?>
      <DeploymentPlan component="Metadata" version="3.0">
        <Configurations>
          <UpdateMetadata wlserver="fp" >
            <fileset dir="${AIA_HOME}/AIAMetaData">
              <include name="AIAComponents/ApplicationObjectLibrary/OracleClinical/V1/wsdls/*.wsdl"/>
            </fileset>
          </UpdateMetadata>
        </Configurations>
      </DeploymentPlan>
      

   4. Navigate to the $AIA_INSTANCE/bin directory.

   5. Execute one of the following commands:

      For Windows, execute aiaenv.bat.

      ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml
      

      For Linux, source aiaenv.sh.

      ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml
      

   6. Once the build completes, restart the SOA server.

   Important:

   The SOA server should be restarted every time a new WSDL file is uploaded.

5. Attach the oracle/wss11_x509_token_with_message_protection_client_policy policy to the client side.

   1. Log into the SOA control panel for the domain at http\\SOAservername:port\em.

   2. Under SOA, right-click on UpdateClinicalStudyOCHealthSciencesProvABCSImpl and select Service/References Properties, then select the name of the web service.

   3. Go to the Policies tab and then click Attach/Detach.

      A new window opens.

   4. In the Available Policies pane, find and select the client policy, then click Attach.

   5. Repeat the above steps as necessary to attach the policy to other services.

6. Configure the security provider on Enterprise Manager for the client.

   1. Log into the SOA control for the domain.

   2. Right-click on the domain you want to configure and select Security, then Security Provider Configuration.

   3. In the Keystore section, click Configure.

   4. Provide the information generated in the first section of the document.

      Keystore Type: JKS

      Keystore Path: /slot/ems6679/oracle/Keystore/x509_latest/client/client_keystore.jks (path for the client keystore, used for step 6 of Server Side Configuration)

      Keystore Password: welcome (used in the commands to create the keystore)

      Signature Key Alias: webservice (created using the keytool command)

      Alias Password: welcome (created using the keytool command)

      Encryption Key Alias: webservice (created using the keytool command)

      Alias Password: welcome (created using the keytool command)

   5. Click OK.

   6. On the client machine, navigate to the directory /slot/ems6679/oracle/Middleware/user_projects/domains/soa_domain/bin/.

   7. Open the startWebLogic.sh file.

   8. Change the line SAVE_JAVA_OPTIONS ="${JAVA_OPTIONS}" into SAVE_JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.net.ssl.trustStore=full path to keystore".

7. Configure the credentials for the client server.

   1. Right-click on the domain you are configuring and select Security, then Credentials.

   2. Check that there is an entry called oracle.owsm.security under the Credentials tree.

      If the entry doesn't exist, redo step 6.

8. Add a new realm on the client server.

   1. Go to the administration console at http\\servername:port\console.

   2. Select Security Realms and then click on the default realm.

   3. Select the Users and Groups tab and then click on New in the Users pane.

      The Create a New User page opens.

   4. Set up the details for the new user.

      Note:

      Provide the same alias as used to generate the client side certificate. In this case, webservice.

   5. Click OK.

Create Investigator

This method creates a new Investigator in Oracle Clinical.

Web Service Name: InvestigatorService

Method Name: CreateInvestigator

Return Type: Investigator object set to Active and with INVESTIGATOR_ID and other autopopulated values populated.

Arguments: The following table displays the method's arguments.

Update Investigator

This method updates an existing Investigator in Oracle Clinical. If no current Investigator matches, the method returns an error. If you pass the Oracle Clinical Investigator ID, Oracle Clinical uses that to identify the correct Investigator. If not, the system uses the Investigator code, which may have originated in the source system.

Web Service Name: InvestigatorService

Method Name: UpdateInvestigator

Return Type: Investigator object.

Arguments: The following table displays the method's arguments.

Request Investigator

This method returns the attributes of an Investigator in Oracle Clinical. If you pass the Oracle Clinical Investigator ID, Oracle Clinical uses that to identify the correct Investigator. If not, the system uses the Investigator code, which may have originated in the source system.

Web Service Name: InvestigatorService

Method Name: RequestInvestigator

Return Type: Investigator object.

Arguments: The following table displays the method's arguments.

Delete Investigator

This method deletes an Investigator from Oracle Clinical. If you pass the Oracle Clinical Investigator ID, Oracle Clinical uses that to identify the correct Investigator. If not, the system uses the Investigator code, which may have originated in the source system.

If the Investigator is assigned to a study site or if any patient data has been entered against the Investigator, the method does not delete the Investigator and returns an error.

Web Service Name: InvestigatorService

Method Name: DeleteInvestigator

Return Type: No return value. Raises an exception if there is an error.

Arguments: The following table displays the method's arguments.

Create Site

This method creates a new study site in Oracle Clinical. The study site is created as Active.

Web Service Name: SiteService

Method Name: CreateSite

Return Type: Site object with autopopulated values populated.

Arguments: The following table displays the method's arguments.

Update Site

This method updates an existing study site in Oracle Clinical. The study site is set to Active. This method uses SiteId to identify the study site or, if that value is not passed in, it uses the value of study site. If no current study site matches, it raises an exception.

Web Service Name: SiteService

Method Name: CreateSite

Return Type: Site object.

Arguments: The following table displays the method's arguments.

Request Site

This method returns the attributes of a study site in Oracle Clinical. This method uses SiteId to identify the study site or, if that value is not passed in, it uses the value of study site.

Web Service Name: SiteService

Method Name: RequestSite

Return Type: Site view object.

Arguments: The following table displays the method's arguments.

Delete Site

This method deletes a study site from Oracle Clinical. If the study site is assigned to a study or if any patient data has been entered against it, the method does not delete the study site and returns an error.

Web Service Name: SiteService

Method Name: DeleteSite

Return Type: Void. Raises an exception if there is an error.

Arguments: The following table displays the method's arguments.

Create Study Site

This method creates a new study site in Oracle Clinical.

Web Service Name: StudySiteService

Method Name: CreateStudySite

Return Type: StudySite object with autopopulated values populated.

Arguments: The following table displays the method's arguments.

Update Study Site

This method updates an existing study site in Oracle Clinical, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception.

Web Service Name: StudySiteService

Method Name: UpdateStudySite

Return Type: StudySite object.

Arguments: The following table displays the method's arguments.

Assign Investigator

This method assigns an existing Investigator to a study site in Oracle Clinical, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception. If an Investigator is already assigned to the study site, the existing Investigator assignment is terminated with a termination date of sysdate.

Web Service Name: StudySiteService

Method Name: AssignInvestigator

Return Type: StudySiteRole object.

Arguments: The following table displays the method's arguments.

Request Current Investigator Assignment

This method returns the attributes of the current Investigator assignment to a study site in Oracle Clinical, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception.

Web Service Name: StudySiteService

Method Name: RequestCurrentInvestigatorAssignment

Return Type: StudySiteRole object.

Arguments: The following table displays the method's arguments.

Request Investigator Assignment

This method returns the attributes of an existing Investigator assignment to a study site in Oracle Clinical, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception.

Web Service Name: StudySiteService

Method Name: RequestInvestigatorAssignment

Return Type: StudySiteRole object.

Arguments: The following table displays the method's arguments.

Delete Investigator Assignment

This method terminates the assignment of an Investigator to a study site in Oracle Clinical, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception.

Web Service Name: StudySiteService

Method Name: DeleteInvestigatorAssignment

Return Type: No return value. Raises an exception if there is an error.

Arguments: The following table displays the method's arguments.

Request Study Site

This method returns the attributes of a study site in Oracle Clinical, including past and present Investigators assigned, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception.

Web Service Name: StudySiteService

Method Name: RequestStudySite

Return Type: StudySite with all StudySiteRoles.

Arguments: The following table displays the method's arguments.

Delete Study Site

This method deletes a study site in Oracle Clinical, using the ClinicalStudyId and SiteId to find the correct row. If those values are not passed in, it uses the values of ClinicalStudy and Site. If no matching row exists, the method raises an exception. If an Investigator is assigned to the study site or if any patient data has been entered against it, the method does not delete the study site and returns an error.

Web Service Name: StudySiteService

Method Name: DeleteStudySite

Return Type: No return value. Raises an exception if there is an error.

Arguments: The following table displays the method's arguments.

Testing the PSDV Web Service

You can test the PSDV method of the Data Push Service using the web services test UI in Oracle Enterprise Manager (OEM). Before you proceed, make sure that the OPA server is running on the server where the Java Key Store is configured and that RDC Onsite is deployed and running.

1. Open OEM on the server where the Java Key Store is configured.

   The address for OEM is of the form http://appserver:7101/em, where appserver is replaced by the name of the application server you are using.

2. Log in to OEM using your credentials.

3. In the tree menu on the left, expand the WebLogic Domain option by clicking on the plus icon to its left. The OPADomain option is now visible beneath.

4. Right-click on OPADomain in the tree menu and go to Web Services, then select Test Web Service.

5. In the WSDL field, add the address of the web service WSDL file. The URL is of the form http://appserver:7221/rdcservice/DataPushService?wsdl, where appserver is replaced with the name of the server you are using.

   Note:

   To identify the URL of the WSDL file for the Data Push Service, go to http://appserver:7221/rdcservice/DataPushService, where appserver is replaced with the name of the server you are using.

6. Click Parse WSDL. The details of the identified web service are retrieved and you should see the value populateStudySiteDefaults in the Operation drop-down list if you used the correct WSDL file.

7. In the Security section, select the OWSM Security Policies radio button.

8. From the Compatible Client Policies list, select oracle/wss11_x509_token_with_message_protection_client_policy.

9. Provide the location where the Java Key Store is configured in the JKS Keystore Location field. For example, C:\wss11_x509\client\client_keystore.jks.

10. In the JKS Keystore Password field, enter the password for the keystore above.

11. Click on Load Keys to the right of the fields to import signature key information from the keystore.

12. Select the Advanced Options box.

13. Select the webservice option from the Signature Key Alias drop-down list and then fill in the Signature Key Password field beneath with the password for the webservice alias.

14. In the Input Arguments section, set values for the arguments of the web service. All arguments are mandatory, except for Datasource.

    See Table 4-17 for information on each of the arguments.

15. Click on Test Web Service in the lower right corner of the screen to test the web service with the current settings.

Once the test runs, the Response tab opens. The result of the test is shown in the two fields, result and error. The result field contains the value 0 if the test was successful, or -1 if an error occurred. If an error occurred, the details are shown in the error field.