Setting Up Web Services
You must apply the Oracle Clinical web services to a computer running Oracle Fusion Middleware, which can be the Oracle Clinical Middle-tier server, the SOA Suite server, or any other server running Oracle Fusion Middleware.
The Oracle Clinical web services are installed in OPA_HOME\webservices\X\OracleClinical.ear, where the X represents the currently installed version. For example, 11g.
For more information, see:
Parent topic: Web Services
Prerequisites
Before you begin to set up the web services, you should check that you meet the following requirements:
- Have administrative access to the AIA server so that you can perform setup tasks in the SOA Home.
- Have administrative access to the Oracle Clinical or RDC web server.
- Have an X.509 and root certificate from a trusted certificate authority.
Note:
The steps in this chapter generate a self-validating certificate, not a trusted certificate. Oracle does not recommend that you secure your system with generated, self-signed certificates, but instead recommends that you obtain an X.509 and root certificate from a trusted certificate authority. Allow some time for the certificate to be issued. - Have downloaded the Oracle Repository Creation Utility (RCU).
- Have downloaded OpenSSL for Windows.
Parent topic: Setting Up Web Services
Installing the Oracle Clinical Web Services
You should apply the Oracle Clinical web services to a computer running Oracle Fusion Middleware. Alternately, you can use the Oracle Clinical Middle-tier server for this purpose.
If you are upgrading to Oracle Clinical Release 5.2 web service usage, you must set up the web service client with the oracle/wss11_x509_token_with_message_protection_client_policy
assertion to sign messages before the Study, Subject, and Visit Synch for the Siebel Clinical - Oracle Clinical PIP can call the Oracle Clinical web services. To enforce this policy for the client, follow the instructions in step 5 of Client Side Configuration
To install the Oracle Clinical web services, follow the high-levels steps below, in the given order.
For more information, see:
- Installing the Oracle Web Service Manager (OWSM)
- Installing the Oracle Clinical Web Services in the Oracle WebLogic Server
Parent topic: Setting Up 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.
Caution:
The Oracle Repository Creation Utility (RCU) must be run prior to installing the Oracle Web Service Manager (OWSM).To install OWSM:
You can access the admin server console for the new domain at http://middletier_name:admin_server_port/console
.
Parent topic: Installing the Oracle Clinical Web Services
Installing the Oracle Clinical Web Services in the Oracle WebLogic Server
- To install the Oracle Clinical Wrb Services in the Oracle WebLogic Server:
-
- Log into the Oracle WebLogic Server console as a WebLogic user.
- In the Domain Configurations panel, under the Deployed Resources section, select Deployments.
The system displays all of the applications currently deployed on this server.
- Click Install to deploy all of the options.
- Click the Upload your file(s) option to upload the .ear file from your local machine.
- Click Next.
- Click Next and then choose the option Install this deployment as an application.
- Click Next.
- Choose from the available targets, such as soa_server1, and click Next.
- 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.
- Click Finish.
- To confirm that the web services deployed successfully:
-
- 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, then Servers.
- 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 below for instructions on how to do this. You can create the data source in the current session.
- 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.
- Go to the list of Deployments and verify that the OC Webservices project is in the Active state.
- To create a data source:
-
- 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.
- Click New.
Three options are available.
- Select the Generic Data Source option.
- In the Create Screen, name the datasource OracleClinicalCoreDS.
- In the JNDI Name column, enter jdbc/OracleClinicalCoreDS.
Note:
Do not change any other settings from their default values. - Click Next.
- Click Next.
- 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.
- Click Next.
- Select your SOA server as the target. For example, select soa_server1.
- Click Finish. The data source is created and deployed on the target server.
- 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.
- Select the Testing tab and test the data source.
- In the same console screen from the previous section, under Domain Structure, click Services, and then click Data Sources.
Parent topic: Installing the Oracle Clinical Web Services
Configuring Certificates
Configuring the certificates between the Oracle Clinical web service server and the AIA SOA server involves populating keystores and generating public certificates that you copy between the servers.
In the WebLogic server, a keystore is used to store credentials, such as certificates. The Credential Store Framework (CSF) provides a way to store, retrieve, and delete credentials for a web service and other applications. OWSM uses the CSF to manage the credentials in a secure form, for example, by retrieving alias names and passwords for keys in the Java keystore or usernames and passwords used for authentication.
Keytool is a utility that Oracle delivers with Java. The system uses this utility to manage the import and export of certificates from the keystores. You must have access to the Keytool utility to continue with the installation. If it isn't already, you need to add it to your environment variable path, the JDK path up to bin.
When using WSS11 policies, configuration is required on both sides, as follows:
- On the service side, where the Oracle Clinical web service is deployed, set up private keys and define them as the encryption key alias in the OWSM Keystore Configuration screen.
- On the client side, the AIA server, you need to configure the client-side trust by obtaining the server's certificate.
- Obtaining a CA Certificate
-
You need to request a certificate from a Certificate Authority (CA) vendor such as Thawte, Entrust, or Verisign, then include it in the keystore.
To get the certificate, you must create a certificate request and submit it to the CA. The CA authenticates the certificate requestor and creates a digital certificate based on the request. Allow some time for the certificate to be issued.
Note:
If you do not have an X.509 certificate, you can generate a certificate using the Keytool utility, but Oracle does not recommend that you secure your system with generated self-signed certificates.
- Sample Configuration
-
The Server Side Configuration and Client Side Configuration sections that follow serve as an example of how to set up and implement AIA to call an Oracle Clinical web service in a different domain. The process also involves securing the AIA client and web service using a policy that is created based on the
oracle/wss11_x509_token_with_message_protection_service_policy
, and changing its configuration to only sign the header and not the encryption.
For more information, see:
Server Side Configuration
In this sample configuration we are using the OpenSSL certificate management tool to demonstrate the process.
Parent topic: Configuring Certificates
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
.
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.
Note:
For an Oracle Clinical web service associated with anoracle/wss11_x509_token_with_message_protection_service_policy
policy file, published as an attachment to the WSDL by default, the static WSDL file in the web service archive file (JAR or WAR) is different from the dynamic WSDL of the deployed web service because only the latter includes specific <SecurityToken> elements.
To configure the client side:
Parent topic: Configuring Certificates