Profiled Service Call builder inputs for a SOAP serviceAdded by IBM on August 31, 2010 | Version 1 (Original)
|This topic describes the inputs that the Profiled Service Call builder takes for a SOAP service.
This topic describes the inputs that the Profiled Service Call builder takes for a SOAP service.
- General inputs
- Service call arguments and Endpoint URL
- SOAP Inputs
- HTTP Inputs
- Advanced 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 SOAP 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
|Endpoint URL||Enter the URL for the service. The URL is not included in the SOAP envelope and must be known prior to creating the service call.|
|Arguments||Enter the argument name, type (required for SOAP), and value for each argument to pass to the service.|
|Reply Type||Enter the name of the type for the service response, for example, string or int.|
Table 3. SOAP Inputs
|Method Name||Required for SOAP. Enter a SOAP method name.|
For example: getServiceRsponsePublic
|Method Namespace URI||Required for SOAP. Enter a method namespace URI.|
For example: urn:xmethods-Temperature
|Schema Namespace URI||By default, this input refers to the 2001 XML schema at:|
To use an alternate schema, enter a schema namespace URI.
|SOAP Action (optional)||Enter a SOAP Action URI. The default is an empty string ("").|
|Literal Data||When disabled, this input indicates the SOAP body contains arguments and values. |
Enable this input if the SOAP body contains only one literal (XML) value.
|SOAP Headers (optional)||To include a header in the SOAP request, enter a name and select a variable or method that contains or returns the value of the header 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 headers you have to manipulate, enable this input to display a table containing multiple SOAP headers.Reference
Enable this input to display a single input box and reference chooser by which you can select a single SOAP header.
Table 4. HTTP 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||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 name 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 5. Advanced Inputs
|Timeout (seconds)||Time in seconds to wait before terminating service request.|
|(optional) Log request/response||Enable this input to display the SOAP request and response in the application server console and to 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 can enable this input for testing purposes so that you can run the model without exercising the service.
|Basic Auth UserID||User ID (if needed) for basic authentication at service runtime.|
|Basic Auth Password||Password (if needed) for basic authentication at service runtime.|
|Continue on Error||Enable this input to allow the model to continue to run even if this builder returns an error during runtime generation.|
For example, a generation error occurs if the service is unavailable.
|AutoCreate Input Vars||Enable this input to force the 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 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 either choose the new variable with the picker for that input field, or just un-check and re-check the AutoCreate Input Vars input. This technique allows hard coded and auto-created variables to be used in the inputs without loss of pre-existing typed in values.
Parent topic: Profiled Service Call builder: wpf7