Profiled Service Call Builder inputs for an HTTP serviceAdded by IBM on June 28, 2011 | Version 1 (Original)
|This topic describes the inputs that the Profiled Service Call builder takes for an HTTP service.
This topic describes the inputs that the Profiled Service Call builder takes for an HTTP service.
The REST Service Call builder is the recommended solution for HTTP-based service calls.
- General inputs
- Service Call Arguments and Endpoint URL
- 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 HTTP radio button to configure a service call to an HTTP service.|
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.|
|Arguments||In the Arguments list, enter each argument name and use the reference chooser to set the value of the argument, or enter a text string directly.|
Table 3. HTTP Inputs
|HTTP Request Type||GET or POST. By default, HTTP service calls have a request type of GET unless you specifically enter POST.|
|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.
|(optional) Cookies||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.
|(optional) Force Content type to||If the response from the HTTP service is something other than HTML, set the content type to the appropriate type. For example, text/xml|
Table 4. 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 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.|
|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. The variables 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