Web service aliases usage in webMethods

A web service alias can be used effectively to manage the endpoints and the credentials for a web service outside of the code. Using web service aliases will remove the need for code changes or property file changes while pointing the web services to different environments.

"A Web service endpoint alias represents the network address and, optionally, any
security credentials to be used with Web services. The network address properties can be
used to enable dynamic addressing for Web services. The security credentials can be used
to control both transport-level and message-level security for Web services."

- Administering_Integration_Server.pdf

As long as the WSDL context remains the same and only the endpoint or the port changes between different environments of the Consumer WSDL, the aliases can be used to re-point the web service from the IS Admin page with out a need for a deployment.


Steps for HTTP web service alias:

1. Create a consumer HTTP web service alias on the IS Admin page with the endpoint settings from the consumer WSDL.
2. Consume a WSDL on to the webMethods Developer and open the WSD. Click on the binders tab and select the binder.
3. In the properties pane click on the drop down for port alias and select the port alias created in step 1. If it does not show up then reload the package and try again.
4. Now save the consumer WSD and start calling the web service connector. The connection details for this WSD will be taken from the web service alias.

Steps for HTTP web service alias:

1. Create a Keystore alias and a key alias with the client certificate configured.
2. Create a HTTPS web service alias with the end point details from the WSDL. Use the keystore and key alias created in step1 while configuring the HTTPS alias.
3. Consume the WSDL on to the webMethods Developer and open the WSD. Click on the binders tab and select the binder.
4. In the properties pane click on the drop down for the port alias and select the port alias created in step 2. If it does not show up then reload the package and try again.
5. Now save the consumer WSD and start calling the web service connector. The connection details for thisWSD will be takem from the web service alias.

Note:

• A HTTP web service alias will not show up as an available port alias for a HTTPS WSD and vice versa.
• IS will interpret the WSDL as-is and generate a HTTP or HTTPS WSD based on the endpoint definition in the WSDL. If you want to generate a HTTPS WSD for a HTTP WSDL then edit the WSDL and change the address location to HTTPS.

For ex:

If the WSDL has an endpoint defined as below, IS will create a HTTP WSD.

<service name="CreditScoreWebService">
    <port name=" CreditScoreEndpointPort" binding="tns: CreditScoreServiceEndpointPortBinding">
      <soap:address location="http://test.google.com:5555/creditscore/ CreditScoreWebService"/>
    </port>
  </service>


If the same WSDL has an endpoint defined as below, IS will create a HTTPS WSD.

<service name="CreditScoreWebService">
    <port name=" CreditScoreEndpointPort" binding="tns: CreditScoreServiceEndpointPortBinding">
      <soap:address location="https://test.google.com:5555/creditscore/ CreditScoreWebService"/>
    </port>
  </service>

Enable SOAP Request/Response Logging

In webMethods while trouble shooting issues with third party web services integration can be done using the Flow service level logging, in order to capture the raw SOAP request at the server level the following extended settings need to be set to true.

watt.server.SoapRPC.debug
watt.server.SoapRPC.trace
watt.server.SoapRPC.verbose

Enabling these settings will capture the raw SOAP request and reponses at the IS level.

Steps:

1. Go to the extended settings on the IS Admin page.
2. Click the show and hide keys URL.
3. select the above mentioned three settings and click save.
4. After the options show up on the extended settings page, edit the settings to set to true to enable the SOAP logging or set to false to disable the logging.

Note:

Enabling this logging setting for a prolonged period of time is not recommended as this will flood the logs with all the SOAP request/responses happening on the server.