Profiled Service Call Builder

 

In this topic ...

Quick Tips

Specifying Inputs

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:

  1. Choose the type of service you want to call: WSDL, SOAP, HTTP, or Local.

  2. Enter the URL for the service.

  3. 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 = permeate

The 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.