This topic describes the inputs that the Web Service Call builder takes for a SOAP service defined in a WSDL document.
|Operation||Select the operation you want to execute. Each operation listed will indicate if the operation type is RPC or Document.|
|AutoCreate Input Vars||Enable this input to force the Web Service Call builder regeneration to create input variables for each of the service call inputs. You can see these variables in the Variable section of the WebApp Tree view after clicking Apply on the builder call. The names are in the form of, buildername_argN_inputname. |
These variables do not appear in the builder call list, but you can get and set their values in methods and they are listed in the Choose Reference dialog.
Note: To preserve pre-existing values in the builder input fields, request parameter inputs with existing content do not get automatically populated with the auto created variable names. To get the automatically created input variable names into the request parameter inputs, you must clear out the current value, and either choose the new variable with the selector for that input field, or just uncheck and recheck the AutoCreate Input Vars input. This technique allows hard-coded and automatically-created variables to be used in the inputs without loss of pre-existing typed in values.
|Argument(s) (named according to WSDL document)||The builder call editor displays the argument names for the selected operation as inputs to the web service call.|
You can use the Choose Reference dialog to specify an appropriate value from a model element or you can enter a text string directly.
If the operation is RPC style, there is an input for each argument. If the operation is doc-literal or document-literal style, the service takes only one argument (an XML document) of the type indicated in the argument label.
In the Service Information group, the builder call editor displays information about the model-based web service. If you expand
, the following information is displayed.
|Service URL (override)||You can override the service URL specified in the WSDL document by entering another service URL here. |
If the WSDL is an interface WSDL with no service URL specified, it can also be supplied here.
For example, if you reference a WSDL in a development environment and expose the service in a deployed environment, the host name, application context, and so on, will most likely be different. In this case, you can enter the URL that takes into account the host name, port, and application context of the deployed environment, or supply these values via a variable that will have the correct values at runtime.
|Service Host name (override)||You can override the host name for the service by entering the new host name here. This can be set to localhost if using TCP tunnel for debugging.|
|Service Port (override)||You can override the port number for the service by entering the port number here. This can be set to your tunnel port if using TCP tunnel for debugging.|
|Timeout (in seconds)||Default is 30. Enter the number of seconds to wait for a response from the service.|
|Additional SOAP Headers||Use this input if you want to include additional SOAP headers in the service call that were not specified in the WSDL. Reference an XML variable that contains the value for the header.|
|HTTP Headers||Use this input to send additional HTTP headers in the request. In the HTTP header list, enter any HTTP header names and set the header values using the Choose Reference dialog, or enter a text string directly.|
|(optional) Logging||Select the type of logging, if any, that you want the builder to perform. Information will be written to the application server's console as well as the IBM WebSphere Portlet Factory runtime's log file and can help in debugging problems with the service. |
You can choose:
To disable logging.Inputs and outputs only
To dump the inputs and the response.Envelopes only
To dump the SOAP request and response envelopes for a WSDL/SOAP service call.All
To dump all the above information.
|Dummy/Stub Result||Supply a value to be returned instead of actually calling the service. For example, you might enable this functionality for testing purposes so that you can run the model without requiring the service to be in place.|
|(optional) Username (Basic Auth)||If the service requires basic user authentication, enter the user name to use for the request here.|
|(optional) Password (Basic Auth)||If the service requires basic user authentication, enter the password for the specified user here.|
|(optional) HTTP Proxy Host||Enter the host name of the proxy server. |
Note: This proxy setting and those below allow the setting of a proxy for this specific web service call. As a result, a system-wide JVM -Dhttp.proxyXXX setting does not need to be used. If a system-wide proxy setting is in effect, proxy settings made here in this builder override the system value.
|(optional) HTTP Proxy Port||Enter the port number of the proxy server. |
|(optional) HTTP Proxy User||Enter a user name for the proxy server.|
|(optional) HTTP Proxy Password||Enter a password associated with the user name given in the HTTP Proxy User input. |
|Filter WSDL Schemas||Set this input to have the builder create in the WebApp only Schema objects for which the namespace of that schema is referred to by the input, output, or SOAP headers defined in the WSDL document for the selected operation. (The Operation input determines the operation.) |
If this input is clear, the builder creates Schema objects for all schemas found in the WSDL document. Typically, the builder adds a Schema object to the WebApp for each schema that it finds embedded in the fetched WSDL document. If you use only one of the multiple operations defined in the WSDL document that contains multiple schemas, the builder can be creating many Schema objects in the WebApp that are not used by the operation.
If you need only a small subset of the WSDL operations and schemas, set this input to prevent the creation of the unused Schema objects and thus use less memory in the WebApp.
|Use JAX-WS If Available||Set this input to have the builder use the JAX-WS implementation for outbound SOAP calls if the application server contains a compatible version of JAX-WS. WebSphere Portlet Factory does not assume that the Axis 1 is installed with a WebSphere Portlet Factory WAR file. If both JAX-WS and Axis 1 are not available, then an error will occur when a model invokes a web service call. If JAX-WS is available, but Axis 1 is not, then JAX-WS will be used by default. and a warning messing will note the change. |
Note: To use Axis 1, you must add to the project the Axis 1 Extension feature set (under Integration Extensions in the Feature Info dialog). This extension adds the Axis 1 jar files to the WEB-INF/lib directory.