Profiled Service Call Builder
In this topic ...
Use this builder to create a service call in which the service URL can be profile driven. This enables you to provide a service based on the user's profile, with different users provided with different services. This functionality is often required in a highly profiled application.
To support this functionality this builder consumes the WSDL document at generation time when the Webapp is built, rather than at design time. The builder then invokes the Factory Service Call builder with builder inputs appropriate to the type of service call in use. As a result, the inputs available in the Profiled Service Call builder are in large part a subset of the inputs available in the Service Call builder.
Quick Tips
- When to use this builder -- Use this builder only if we need to provide a service based on user or group affiliation. If you do not intend to profile the service URL in this builder, use the Service Call builder to invoke the service we need.
Specifying Inputs
The Profiled Service Call builder takes the inputs described in the tables below. For help on inputs common to many or all builders such as those in the Properties and HTML Attributes input groups, see "Using the Builder Call Editor."
Using the Profiled Service Call Builder
The Profiled Service Call builder allows you to execute several types of services. The builder UI will display different inputs according to the type of service you choose. The following steps describe the general process of configuring a Profiled Service Call:
- Choose the type of service you want to call: WSDL, SOAP, HTTP, or Local.
- Enter the URL for the service.
- Depending on the type of service, enter the appropriate inputs for the service.
Many inputs to the Profiled Service Call builder are service-specific, and in the case of WSDL service calls, might be read-only or have default values specified by the WSDL document. Each of the following sections describe how to specify the inputs for a particular service call type.
Click one of the following links to view details about configuring this builder for a specific service type:
Specifying Inputs for a WSDL Service
The Profiled Service Call builder takes the following inputs for a WSDL service:
Input Name Description Name
Enter a name for this builder call. The Designer displays this name in the Builder Call List.
Service Call Type
Enable the WSDL radio button.
Service Call Arguments and Endpoint URL 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's WSDL document.
If you are not sure about the names, use the 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.
We can also use the Reference Chooser to specify an appropriate value from a model element or we can enter a text string directly. ("Type" does not apply to the WSDL services.)
WSDL Inputs WSDL URL
Enter the URL for the WSDL document describing the service.
This document will be 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.
SOAP Inputs SOAP Headers (optional)
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.
- 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 we can select a single SOAP header
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
Allows you to specify a single HTTP header reference or multiple header references in the form of an action table.
- 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 we 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.
- 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 we can select a single Cookie.
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 the Factory's 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.
We 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, etc. 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.
We can override the host name for the service by entering the new host name here.
See "Testing Services" for more information on using TCP Tunnel.
Service Port (override)
Only applies to services you control or if your are using TCP Tunnel.
We can override the port number for the service by entering the port number here.
See "Testing Services" for more information on using TCP Tunnel.
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.
Designetime 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.
We can see these variables in the Variable section of the WebApp Tree" view after hitting "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 we can get and set their values in methods and they are listed in the Reference Chooser.
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 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.
Specifying Inputs for a Local Service
The Profiled Service Call builder takes the following inputs for a Local (model-based) service:
Input Name Description Name
Enter a name for this builder call. The Designer displays this name in the Builder Call List.
Service Call Type
Enable the Local radio button to configure a service call to an HTTP service.
Service Call Arguments and Endpoint URL Argument(s) named according to WSDL document
The Builder Call Editor displays the argument names for the selected operation as inputs to the Service Call.
We can use the Reference Chooser to specify an appropriate value from a model element or we can enter a text string directly. ("Type" does not apply to Local services.)
WSDL Inputs Operation (optional)
Enter the service operations in by hand or use an indirect reference to point to the operations.
Local Model Inputs Model Name
Use the Model Chooser to select the model that contains the method exposed as a Web service.
Such a model must contain a Web Service Enable builder call.
Advanced Inputs (optional) 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 the Factory's 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.
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.
AutoCreate Input Vars
Enable this checkbox to force the builder regen to create input variables for each of the service call inputs.
We can see these variables in the Variable section of the WebApp Tree" view after hitting "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 we can get and set their values in methods and they are listed in the Reference Chooser.
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 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.
Specifying Inputs for a SOAP Service
We can call a SOAP service that is not defined with a WSDL document by entering the information needed to configure the SOAP request. We can use a known SOAP request envelope for that service to get the information we need to configure your own call to that service.
For example, if you had the following SOAP request envelope, you could configure a Profiled Service Call to the target method by extracting the values of the following elements in the SOAP envelope/request:
<SOAP-ENV:Envelope
xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP- ENV:Body>
<ns1:getServiceResponsePublic xmlns:ns1="urn:MyBubble- SoapServices"
SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<service Name xsi:type="xsd:string">Meaning</serviceName>
<inputText xsi:type="xsd:string">permeate</inputText>
</ns1:getServiceResponsePublic>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In this example, the following line represents an argument:
<inputText xsi:type="xsd:string">permeate</inputText>
where
Name = inputText
Type = string
Value = permeateThe Profiled Service Call builder takes the following inputs for a SOAP service:
Input Name Description Name
Enter a name for this builder call. The Designer displays this name in the Builder Call List.
Service Call Type
Enable the SOAP radio button.
Service call arguments and Endpoint URL 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 you want to pass to the service.
Reply Type
Enter the name of the type for the service's response such as String, int, etc.
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 setting refers to the 2001 XML schema at:
http://www.w3.org/2002/XMLSchema
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, indicates the SOAP body contains args and values.
Enable this option 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 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.
- Table - If you know how many 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 we can select a single SOAP header
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
Allows you to specify a single HTTP header reference or multiple header references in the form of an action table.
- 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 we 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.
- 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 we can select a single Cookie.
Advanced Inputs Timeout (seconds)
Time in seconds to wait before terminating service request.
(optional) 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 the Factory's 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 so that we 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 check box to allow the model to continue to run even if this builder returns an error during runtime generation.
For example, a generation error would occur if the service was unavailable.
AutoCreate Input Vars
Enable this checkbox to force the builder regen to create input variables for each of the service call inputs.
We can see these variables in the Variable section of the WebApp Tree" view after hitting "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 we can get and set their values in methods and they are listed in the Reference Chooser.
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 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.
Specifying Inputs for an HTTP Service
The Profiled Service Call builder takes the following inputs for a HTTP service:
Input Name Description Name
Enter a name for this builder call. The 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.
Service Call Arguments and Endpoint URL 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.
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.
- 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 we 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.
- 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 we 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
Advanced Inputs Timeout (seconds)
Time in seconds to wait before terminating service request.
(optional) 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 the Factory's 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 check box to allow the model to continue to run even if this builder returns an error during runtime generation.
For example, a generation error would occur if the service was unavailable.
AutoCreate Input Vars
Enable this checkbox to force the builder regen to create input variables for each of the service call inputs.
We can see these variables in the Variable section of the WebApp Tree" view after hitting "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 we can get and set their values in methods and they are listed in the Reference Chooser.
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 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.