This post is an introducton into the Generic SOAP Service otherwise known as IDCWS in Webcenter Content. This service is available in both Fusion Applications SaaS environment and also on on-premise installations as well.
From Release 10 onward, the Generic SOAP Service is available for use on every Fusion Applications SaaS environment without additional configuration. It is also available on Release 9 but an Oracle Support Request is needed to configure the firewall and Oracle Http Server to allow access to it from the internet. This is the recommended approach to connect to the Oracle Webcenter Content inside a Fusion Applications SaaS environment. Previously the RIDC client may have been the preferred interface, but from Release 10 this is the preferred approach.
Webcenter Content is built around IdcServices. Different IdcServices execute different operations. For example the GET_SEARCH_RESULTS IdcService executes content search. The IdcService CHECKIN_NEW is used to upload a new content item. The Generic Soap Service is a mechanism to execute Webcenter Content IdcServices and takes IdcService as a mandatory parameter. Since the Generic Web Service is a wrapper there is only one operation called genericSoapOperation which executes the IdcService specified in the request.
The Generic SOAP Service is secured by policies set in Oracle Web Service Manager (OWSM). There are two web service policies that are currently utilized with the Generic SOAP Service. These are the oracle/wss_username_token_service_policy and the oracle/wss11_username_token_with_message_protection_client_policy. As you will see in the walk through in the next blog post, the security policy needs to be specified in the security header in the SOAP request envelope in the client application.
It’s important to note that the Generic SOAP Service in a Fusion Applications SaaS environment is only available over SSL. Therefore it’s important to make sure that the client application has access to the relevant client SSL certificates so that it is able to communicate with the Fusion Applications SaaS environment. By default a browser environment already is able to do this. If the client is implemented in a JAVA file then the certificates store may need to be specified explicitly.
There is also a further option to encrypt messages as they are transmitted back and forth between the SaaS environment and the client application. To set up this functionality a default-keystore.jks must first be created on the Fusion Applications SaaS environment. In a Fusion Applications SaaS environment this can only be done with help from Oracle Support. After creating the key store on the server, files need to be copied to the client as well for the encryption to work.
In the next post we will walk through a sample Java application that executes a Generic Soap Service request.