In order to request WSDL's and WADL's (which contain information on how a service can be called), understanding how URL's are build up in Oracle SOA Suite helps.
A nice new feature in Oracle SOA Suite 12c is the support for WADL's. In order to obtain information about which (composite) resources are available at which URL, the SOA Infra application provides a WADL. On the integrated Weblogic server domain, this WADL can be accessed at: http://localhost:7101/soa-infra/resources/application.wadl
This WADL provides information on the different ways resources can be requested. For example, I have deployed an HelloWorldREST composite with a HelloWorldRestService service.
I am able to determine the service endpoint:
And since it is a RESTful service, I can request the WADL which provides information on possible service endpoints and how to call them at
The following URL is not accessible:
SOAP services follow a similar scheme to allow accessing services. The URL slightly differs though.
This allows accessing the default revision of an endpoint of a service. If you want to call a specific revision, the below URL allows specifying the revision.
It is also possible to target a specific deployment of a composite. This can be dangerous because this changes upon redeployment.
The last URL has an identifier called 'label'. Labels are used in the MDS (http://docs.oracle.com/cd/E25178_01/core.1111/e10105/repos.htm#CIHCAJHA). Composites are deployed to the MDS and get an automatically generated label upon deployment. This changes after every deployment of a composite with the same name/partition/revision. I have not tried manipulating labels of deployed composites and the effects that might have.
WSDL's can be obtained by using the servicename and append ?WSDL to it. For example to access my HelloWorld service WSDL, the following URL can be used:
If you open the endpoint(/service URL) in a browser, you get forwarded to the Webservice Test Client (on development servers):
Not only by means of constructing the URL manually, can resource URL's be determined. There are also several supporting tools available such as the test console in the Enterprise Manager and the Webservice Test Client. The Webservice Test Client is only installed on development servers. The Enterprise Manager Test console can be used if you have access to the Enterprise Manager. The Monitor role is enough to be able to use the EM test console.
Obtain the concrete default WSDL from the test console
The WSDL can be obtained from the test console in the Enterprise Manager. This is a concrete WSDL generated upon deployment of a SOA Suite composite. It contains references to the default revision of the composite and also a reference in the documentation tag to the abstract WSDL;
If the WSDL URL in the EM test console contains an MDS label and you don't expect it, something is probably wrong and you should try an undeploy and redeploy under different revision and/or a server restart.
Obtain the abstract default WSDL from the composite
As suggested in the previous screenshot of the WSDL, the abstract WSDL can be obtained directly from the composite:
This trick can also be used to obtain XSD's from inside a composite, by for example going to an URL like (on my development environment); http://localhost:7101/soa-infra/services/default/HelloWorld!1.0/Schemas/HelloWorldBPEL.xsd
If the abstract WSDL is placed in the MDS, the reference to the WSDL's and XSD's also refer to an MDS path. This allows by means of relative URL's to access the entire MDS (this was possible in SOA Suite 11g. I have not checked this in SOA Suite 12c yet). In such a case, composite resources cannot be accessed.
Webservice test client
I am mentioning the testclient because you get forwarded to it when opening a service endpoint and it allows you to obtain information about the WSDL and XSD of a service. Also you do not need specific privileges to access the webservice test client.
The Webservice Test client can be used to test SOAP services. It cannot be used for services solely described by a WADL. The Webservice Test client provides a webinterface for calling a SOAP service. In my example I can open the URL obtained from my concrete WSDL of my service in the browser: http://localhost:7101/soa-infra/services/default/HelloWorld/helloworldbpel_client_ep
The URL is translated into the folowing: http://localhost:7101/ws_utc/?wsdlUrl=http://localhost:7101/soa-infra/services/default/HelloWorld!1.0*soa_2c171323-5b85-4d1f-876e-eecda27e5bc6/helloworldbpel_client_ep?WSDL. This is a call to the ws_utc; the Webservices Test Client.
Webservice test client not available?
At first I tried to use the Webservice test client on my production mode server. The client however is only installed when the server is in development mode. Then I read the following: https://community.oracle.com/thread/978505?tstart=0. The post does describe a manual way to install the client on an 11g SOA Suite production mode installation. I could however not find the wlstestclient.ear in SOA Suite 12c. The following looked like it might be the test client in 12.1.3: [ORACLE_HOME]/oracle_common/modules/com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3.ear. After deployment, this ear allowed ws_utc to be called. However, it gave me a HTTP 503 response. I also found the following which might have helped: http://www.thesoaman.com/2011/12/change-weblogic-server-mode-from.html. At this time I decided to try this with the integrated development Weblogic server in JDeveloper instead of patching my production server.