Profiled Service Call Builder inputs for a WSDL ServiceAdded by IBM on August 31, 2010 | Version 1 (Original)
|This topic describes the inputs that the Profiled Service Call builder takes for a WSDL service.
This topic describes the inputs that the Profiled Service Call builder takes for a WSDL service.
- General inputs
- Service Call Arguments and Endpoint URL
- WSDL Inputs
- SOAP Inputs
- HTTP Inputs
Table 1. General inputs
|Name||Enter a name for this builder call. The WebSphere® Portlet Factory Designer displays this name in the builder call list.|
|Service Call Type||Enable the WSDL radio button.|
Note: This input only displays when you work with a model that was created in previous versions of IBM® WebSphere Portlet Factory. Models created with WebSphere Portlet Factory version 6.1.5 and later do not display this input and the builder automatically configures itself for calling WSDL services.
Service Call Arguments and Endpoint URL
Table 2. Service Call Arguments and Endpoint URL inputs
|Arguments||The builder call editor allows you to enter argument names for the selected operation as inputs to the Service Call. The names you enter here must match exactly the names as they appear in the service WSDL document.|
If you are not sure about the names, use the Web Service Call builder to fetch the WSDL document. Examine the argument names that are returned and then enter them in this builder exactly as they appear in the WSDL document.
You can also use the Reference Chooser to specify an appropriate value from a model element or you can enter a text string directly. ("Type" does not apply to the WSDL services.)
Table 3. WSDL Inputs inputs
|WSDL URL||Enter the URL for the WSDL document describing the service.|
This document is fetched at generation time.
|Operation (optional)||Enter the service operations in by hand or use an indirect reference to point to the operations.|
|Basic Auth User ID (optional)||If the service requires basic user authentication, enter the user name to use for the request.|
|Basic Auth Password (optional)||If the service requires basic user authentication, enter the password for the specified user.|
Table 4. SOAP Inputs inputs
|SOAP Headers (optional)||If you want to include a header in the SOAP request, select a variable or method that contains or returns the value of the header that you want to send.|
|SOAP Headers UI Style||Allows you to specify a single SOAP header reference or multiple header references in the form of an action table.|
If you know how many SOAP headers you have to manipulate, enable this to display a table containing multiple SOAP headers.Reference
Enable this to display a single input box and reference chooser by which you can select a single SOAP header.
Table 5. HTTP Inputs inputs
|HTTP Headers (optional)||In the HTTP Header list, enter any HTTP Header names and set the header values using the Reference Chooser, or enter a text string directly.|
|HTTP Headers UI Style||Allows you to specify a single HTTP header reference or multiple header references in the form of an action table.|
If you know how many headers you have to manipulate, enable this to display a table containing multiple HTTP headers.Reference
Enable this to display a single input box and reference chooser by which you can select a single HTTP header.
|Cookies (optional)||Enter the value for the cookie to include with the request and select the variable or method that contains or returns the cookie object.|
|Cookies UI Style||Allows you to specify a single Cookie reference or multiple Cookie references in the form of an action table.|
If you know how many Cookies you have to manipulate, enable this to display a table containing multiple Cookies.Reference
Enable this to display a single input box and reference chooser by which you can select a single Cookie.
Table 6. Advanced inputs
|Timeout (Seconds)||Time in seconds to wait before terminating service request.|
|Log Request/Response||Enable this check box if you want to display the SOAP request and response in the application server's console as well as log this information in WebSphere Portlet Factory log file.|
|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 during application development so the model this builder is in can run without exercising the service.
|Basic Auth User ID||User ID (if needed) for basic authentication at service runtime.|
|Basic Auth Password||Password (if needed) for basic authentication at service runtime.|
|Service URL (override)||Only applies to services you control or if your are using TCP Tunnel to debug a service call.|
You can override the service URL specified in the WSDL document for a service you have created (or have control over) by entering the new service URL to use 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 enter the URL that takes into account the host name, port, and application context of the deployed environment.
|Service Hostname (override)||Only applies to services you control or if you are using TCP Tunnel.|
You can override the host name for the service by entering the new host name here.
|Service Port (override)||Only applies to services you control or if your are using TCP Tunnel. |
You can override the port number for the service by entering the port number here.
|Continue on error||Enable this check box to allow the model to continue to run even if this builder returns an error during runtime generation.|
For example, a regen error would occur if the service was unavailable.
|Designtime Fetch only||Do not enable this feature. Since this builder fetches service information at runtime, this input is not applicable.|
|AutoCreate Input Vars||Enable this checkbox to force the builder regen to create input variables for each of the service call inputs.|
You can see these variables in the Variable section of the Application Tree after clicking Apply on the builder call, the names being 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 Reference Chooser.
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 then either choose the new variable with the picker for that input field, or just un-check and re-check the AutoCreate Input Vars check box. This technique allows hard coded and auto-created variables to be used in the inputs without loss of pre-existing typed in values.
|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. Clear the input to have the builder use the Axis 1 implementation for outbound SOAP calls. If the input is set and the application server does not contain a compatible version of JAX-WS, the builder uses the Axis 1 implementation for outbound SOAP calls. |
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.
Parent topic: Profiled Service Call builder: wpf7