Skip navigation.

Using the AquaLogic Service Bus Console

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Test Console

This section includes the following topics:

 


Overview of the Test Console

The BEA AquaLogic Service Bus Test Console is a browser based test environment used to validate and test the design of your system. You can configure the object of your test (proxy service, business service, resource), execute the test and view the results in the test console. In some instances you can trace through the code and examine the state of the message at specific trace points.

The Test Console can be invoked to test any proxy or business service and certain resources used by these services. You can also do inline XQuery testing. You can invoke the test console in a number of ways in the AquaLogic Service Bus Console depending on what part of your process you want to test. The output from the tests is also displayed in the test console.

You can invoke the test console from:

Note: Only users in the IntegrationAdmin and IntegrationDeployer roles are allowed to use the Test Console.

Related Topics

Testing Proxy Services

Configuring Proxy Service Test Data

Viewing Proxy Service Test Results

Tracing Proxy Services

Testing Business Services

Configuring Business Service Test Data

Testing Transformations

Performing Inline XQuery Testing

Understanding How the Run Time Uses the Transport Settings in the Test Console

 


Testing Services

This section includes the following topics:

Testing Proxy Services

You must have activated a session to test a proxy service. You can test a proxy service from the Resource Browser or Project Explorer. You can test the following types of proxy services:

Note: You can test SOAP proxy services with Web-Service Security (WSS) policies. See Web-Service Security in Configuring Proxy Service Test Data.

To Test a Proxy Service

  1. Log in to the AquaLogic Service Bus Console.
  2. Click Activate to activate your session. This enables the test feature in the console.
  3. Select Project Explorer or Resource Browser from the left navigation pane. The Summary of Proxy Services page is displayed.
  4. In Resources, under the Actions column on the page, click the Launch Test Console icon associated with the proxy service you want to test.
  5. The Test Console is opened on the Proxy Service Testing page. For example, using the examples provided with the product (see BEA AquaLogic Service Bus Examples), click the icon associated with the LoanGateway1 proxy service.

  6. For SOAP and XML services, select the WSDL operation you want to test.
  7. Configure the test data for the proxy service—note that this must be the data that the proxy service expects from the client.
  8. Note that by default both test Configuration options, Direct Call and Include Tracing are enabled. You can unselect the Direct Call option, which automatically unselects the Include Tracing option. By doing so, testing is performed using the indirect call method where the message is sent through the transport layer.

    You can use the direct call option (leave Direct Call checked) and disable tracing. To disable tracing, simply unselect the associated checkbox.

  9. Click Execute to run the test. The Proxy Service Testing page is refreshed to display the results of running the test. For information about interpreting the test results, see Viewing Proxy Service Test Results.
  10. To run the test again, click Back. Repeat steps 5-8 to test as many times as desired.

Configuring Proxy Service Test Data

The following is a description of the configuration page that appears in the test console when you launch it to test a proxy service.

Note: The fields that appear on the console for accepting input to the request document are based on the service type.

Table 23-1 Description of the Test Console Configuration Page for a Proxy Service

Section

Options/Fields

Description

Name

The name of the proxy service being tested is written on the top of the page

Available Operations

If there are any operations associated with the proxy service, they are displayed showing the details for the proxy service. An arrow indicates the currently selected operation.

Test Console Actions



Execute

Run the test


Reset

Reset the input values


Close

Close the test console and do not run the test

Test Configuration

You can set the testing configuration to execute in a number of ways depending on the options you select in this section.


Direct Call

Send a message to the proxy service without using the AquaLogic Service Bus transport layer. The input data to the test console must be that which is sent from the client to the proxy service.

The opposite of the Direct Call is an Indirect Call. It can be invoked by unselecting the Direct Call option. It is performed by default for Business services. The Indirect call sends messages through the transport layer. In this case, the input data to the test console must be that which is being sent from a proxy service to the invoked service.


Include Tracing


Request Document

The configuration data entered here represents the request message.

The list of input fields is used to generate the request message that is sent to the proxy service. Click Execute to run the test with the values entered. The test console displays the request message and the service's response message and metadata.

The set of inputs for which you are prompted in the Request Document page are specific to the service type—the service types are listed in the following sections and a description of the input required by each.

This section is organized by service type.


any XML

The service requests input in the form of a payload.The payload is the content of the message being sent. The content is expected to be an XML document.

You can browse to a file or you can enter the message content in the text box provided.


any SOAP

The service requests input in the form of a payload. The payload is the content of the message being sent. The content is expected to be the SOAP envelope.

You can browse to a file or you can enter the message content in the text box provided.


Messaging

Messaging Services define four possible input types: none, XML, Binary or Text. The service requests a single input—either file-based or text-based, except for the type none that does not require any input.

It is recommended to enter binary input from a file. Data entered in the text area are converted to binary using the system encoding.

Data entered from file for Text Services must be converted to text. The encoding input field is used to specify the encoding to apply during the conversion. The system encoding is used if this field is not configured. By default, the encoding field is initialized with the encoding value configured on the Proxy Service endpoint.


XML

The service requests input in the form of a payload.The payload is the content of the message being sent. The content is expected to be an XML document.

You can browse to a file or you can enter the message content in the text box provided.

If your proxy service is a WSDL-based service with multiple operations defined, the test console generates and provides a sample document to use when testing the service. You can use this sample data directly, edit it and then run the test, or provide your own test data.

All operations are listed at the top of the page with an arrow highlighting the selected operation.


SOAP Document

For a SOAP Document, the SOAP envelope is usually composed of zero or more headers and one body payload. The Form and XML tabs provide alternative ways to specify the content.

The Form tab contains a SOAP Header field and a SOAP Body field.

The content of the SOAP Header field is expected to be a SOAP Header tag (this allows for the definition of more than one header).

The SOAP Body field contains the data that is actually sent as part of the message. The content is expected to be an XML document.

Both the header and the body are used to generate the SOAP envelope.


SOAP RPC

For SOAP RPC, the SOAP envelope is composed of zero or more headers, and zero or more arguments.

The Form and XML tabs provide alternative ways to specify the content.

The Form Tab contains a single input for SOAP headers, and one input field for each argument (the name of the input field corresponds to the name of the argument).

The content of the SOAP Header field is expected to be a SOAP Header tag (this allows for the definition of more than one header).

The WSDL is used to detect the type of each argument. A single-line input field is used for primitive types; a multi-line input field is used for XML types. A sample document is automatically generated to facilitate testing.

The headers and arguments are used by the Test Console to generate the SOAP envelope.

The XML Tab contains a single input field. The content of this field is expected to be the SOAP envelope being sent.

The payload (XML input) can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.

Web-Service Security

This section is available only for SOAP services when the selected operation has a Web-Service Security (WSS) policy.


Service Provider

The test service gets all client-side PKI (key-pair) credentials for Web Service Security operations (digital signature and encryption) from this service provider. This field is optional. Certain scenarios require a service provider, depending on the request/response policy for the operation. For more information, see "Testing Services with Web Service Security" in Using the Test Console in the BEA AquaLogic Service Bus User Guide.


Username

This is the username used in Web Service Security Username tokens generated from the test service. This field is optional. This username is only needed in some scenarios where the operation's request policy specifies an identity assertion.

Do not confuse this field with the transport security context username field.

Note: This must be a valid username and password in the local security realm. An invalid username or invalid password causes a client-side error on the test service.


Password

This is the password used in Web Service Security Username tokens generated from the test service.

Transport

The Transport section is collapsed by default as it is an advance option. The fields and value of the fields displayed for the transports depend on the test configuration.

Authentication

Username

This username and the associated password are used to set the security context used by the test service when invoking the proxy service.

If the proxy servie routes the message to a business service that expects a SAML token, this is the identity that will be represented by the token. For more information, see "SAML Support " in Securing Inbound and Outbound Messages in the BEA AquaLogic Service Bus User Guide.

Do not confuse this field with the Web Service Security (WSS) username field.

Note: That this must be a valid username and password in the local security realm. An invalid username or invalid password will cause a client-side error on the test service.


Password

This is the associated password. For more information, see Username.

Invocation Mode

Request/Response

This option is only displayed when testing on any SOAP or any XML proxy service. Unselect Request/Response for one-way service invocations.

Message Metadata

See Limitations to Transport Header and Metadata Values You Specify in the Test Console When Testing a Service

Transport Headers

See Limitations to Transport Header and Metadata Values You Specify in the Test Console When Testing a Service

Note: The secured SOAP message is displayed printed with extra whitespaces. Because whitespaces can affect the semantic of the document, this SOAP message cannot always be used as the literal data. For example, digital signatures are whitespace sensitive and can become invalid.

Viewing Proxy Service Test Results

The Results page displays the results of testing the proxy service. Note that tracing is only enabled if the Direct Call and the Include Tracing options are selected. If they are not enabled, then tracing will not appear as part of your test results. A description of the Results page is provides in Table 23-2.

Table 23-2 Description of the Test Console Test Results for Proxy Services

Section

Description

Proxy Service Name

The name of the proxy service that is being tested

Test Console Actions

Back displays the previous browser page

Close closes the test console

Request Document

This is the request message sent to the proxy service by the test console.

This section is initially collapsed if the test console did not modify the request message. This section is initially expanded for SOAP services configured using the Form tab, or if WS-Security has been applied.

In the case WS-Security applies, this section will contain two SOAP messages—the first message is the clear text message; the second is the secured SOAP message.

Response Document

This is the message response.

For SOAP service with response WS-Security, this section contains two SOAP messages. The first SOAP message is the secured message as received by the client. The second SOAP message is the corresponding clear text message..

Response Metadata

The metadata retuned with the message response.

Tracing Proxy Services

Tracing shows the state of the message as it passes through the system.When the Direct Call option is not selected, tracing is not performed and not displayed on the Results page for the proxy service.For more information on tracing, see Tracing Proxy Services.

Tracing Proxy Services

Tracing is enabled when you test a proxy service using a Direct Call. The Invocation Trace checkbox is automatically selected with the Direct Call option. If you do not want to enable tracing, then you must uncheck the checkbox.When you turn tracing on the test results include the details of the trace. Tracing enables you to track problems in the system and to isolate them for corection.The trace information shows the path taken through the request and response paths in the code.

For each stage, the trace includes the changes that occurred to the message context and all the services invoked during the stage execution. The following information is available in the trace:

The trace contains similar information for the Route Node. In this case, the trace contains four categories:

To Trace a Message

  1. Log in to the AquaLogic Service Bus Console.
  2. Click Activate to activate your session. This enables testing proxy services.
  3. Select Project Explorer or Resource Browser from the left navigation pane. The Project page/Summary of Proxy Services page is displayed.
  4. In Resources, in the Actions column, click the Launch Test Console icon associated with the the service you want to test. The test console is opened on the Proxy Service Testing page.
  5. Configure the test data for the proxy service. Note that you must have the Direct Call and Include Tracing options selected to enable tracing. See Configuring Proxy Service Test Data.
  6. Click Execute to run the test. The Proxy Service Testing page displays the test results for the service and the tracing information.
  7. Scroll down to the Invocation Trace section
    This section graphically displays the message flow. You can trace the message through the service and view the state of the message at pre-selected points in the trace. The trace points are automatically set.
  8. Click the + Icon to expand the message flow to view more detail.
    While viewing the trace you can also view the message flow itself in the AquaLogic Service Bus Console to relate the trace to the actual stages and actions in the flow. You can modify the message flow and run the trace again to view the output.

Testing Business Services

You must have activated a session to test a business service. You can test the following types of business services:

Note: You can test SOAP Business Services with Web-Service Security policies. For more information, see "Testing Services with Web Service Security" in Using the Test Console in the BEA AquaLogic Service Bus User Guide.

When testing business services you always send the message through the transport layer. The Direct Call option is not available. The configuration data that you provide to the test console to test the service is that which represents the state of the message that is expected to be sent to that business service—for example from a Route Node or a Service Callout action of another proxy service. The test console is in the role of the caller proxy service when you use it to test a business service.

To Test a Business Service

  1. Log in to the AquaLogic Service Bus Console.
  2. Click Activate to activate your session. This enables the test feature in the console.
  3. Select Project Explorer or Resource Browser from the left navigation pane. The Summary of Business Services page/Project page is displayed.
  4. In Resources, under the Actions column on the page, click the Launch Test Console icon associated with the service you want to test. The Test Console is opened on the Business Service Testing page. For Example, using the tutorials provided with the product, click the icon associated with LoanGateway1.
  5. For SOAP and XML services, select the WSDL operation you want to test.
  6. Configure the test data for the business service (the input data should be the message being sent by the proxy service to the business service). Note that the Direct Call and Include Tracing options that are available for a Proxy service are not available for a business service. Business services are automatically tested using the in the Direct Call option, meaning that the messages pass through the transport layer.
  7. Click Execute to run the test. The Business Service Testing Page is refreshed to display the results of running the test. For more information, see Viewing Business Service Test Results.

Configuring Business Service Test Data

In this section we describe the configuration page that appears in the test console when you select to test a business service. The fields that appear on the test console for accepting input to the request document are based on the service type.

Table 23-3 describes the configuration page for the test Console.

Table 23-3 Description of the Business Service Test Console Configuration.

Section

Options/Fields

Description

Name

The name of the business service being tested in written on the top of the page

Available Operations

If there are any operations associated with the business service they are displayed showing the details for the business service.An arrow indicates the curently selected operation.

Test Console Actions



Execute

Run the test.


Reset

Reset the input values.


Close

Close the window and do not run the test.

Request Document

The configuration data entered here represents the request message.

The list of input fields is used to generate the request message that is sent to the Business Service. Click Execute to run the test with the values entered. The test console page refreshes to display the request message and the service's response.

The set of inputs displayed is specific to each service type. The service types are listed in the following sections and a description of the input required by each.

This section is organized by service type.


any XML

The service requests input in the form of a payload. The payload is the content of the message being sent. The content is expected to be an XML document.

You can browse to a file or you can enter the message content in the text box provided.


any SOAP

The service requests input in the form of a payload. The payload is the content of the message being sent. The content is expected to be the SOAP envelope.

You can browse to a file or you can enter the message content in the text box provided.


Messaging

Messaging Services define 4 possible input types: none, XML, Binary or Text. The service requests a single input either file based or text based, except for the type none that does no require any input.

It is recommended to enter binary input from a file. Data entered in the text area are converted to binary using the system encoding.

Data entered from file for Text Services must be converted to text. The encoding input field is used to specify the encoding to apply during the conversion. The system encoding is used if this field is not configured. By default, the encoding field is initialized with the encoding value configured on the Proxy Service endpoint.


XML

The service requests input in the form of a payload. The payload is the content of the message being sent. The content is expected to be an XML document.

You can browse to a file or you can enter the message content in the text box provided.

This is a WSDL based service with multiple operations defined. We provide the sample document to use in testing this service. All operations are listed at the top of the page with an arrow highlighting the selected operation.


SOAP Document

For SOAP Document, the SOAP envelope is usually composed of zero or more headers and one body payload.

The Form and XML tabs provide alternative ways to specify the content.


The Form tab contains a SOAP Header field and a SOAP Body field.

The content of the SOAP Header field is expected to be a SOAP Header tag (this allows for the definition of more than one header).

The SOAP Body field contains the data that is actually sent as part of the message. The content is expected to be an XML document.

Both the header and the body are used to generate the SOAP envelope.

The XML Tab contains a single input field. The content of this field is expected to be the SOAP envelope being sent.


SOAP RPC

For SOAP RPC, the SOAP envelope is composed of zero or more headers, and zero or more arguments.

The Form and XML tabs provide alternative ways to specify the content.

The Form Tab contains a single input for SOAP headers, and one input field for each argument (the name of the input field corresponds to the name of the argument).

The content of the SOAP Header field is expected to be a SOAP Header tag (this allows for the definition of more than one header).

The WSDL is used to detect the type of each argument. A single-line input field is used for primitive types; a multi-line input field is used for XML types. A sample document is automatically generated to facilitate testing.

The headers and arguments are used by the Test Console to generate the SOAP envelope.

The XML Tab contains a single input field. The content of this field is expected to be the SOAP envelope being sent.

The payload (XML input) can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.

Web-Service Security

This section is available only for SOAP service when the selected operation has a Web-Service Security policy.


Service Provider

The test service gets all client-side PKI (key-pair) credentials for Web service security operations (digital signature and encryption) from this service provider. This field is optional. Certain scenarios require a service provider, depending on the request/response policy for the operation. For more information, see "Testing Services with Web Service Security" in Using the Test Console in the BEA AquaLogic Service Bus User Guide.


Username

This is the username used in Web Service Security Username tokens generated from the test service. This field is optional. This username is only needed in some scenarios where the operation's request policy specifies an identity assertion.

Do not confuse this field with the transport security context username field. NOTE: this must be a valid username and password in the local security realm. An invalid username or invalid password will cause a client-side error on the test service.

In some scenarios, this username/password may also be used when the test service generates a SAML assertion.


Password

This is the password used in Web Service security username tokens generated from the test service.

Transport

The Transport section is collapsed by default as it is an advance option. The fields and value of the fields displayed for the transports depend on the test configuration.

Authentication




Username

This username and the associated password are used to set the security context used by the test service when invoking the business service. If the business service expects a SAML token, this identity may be propagated in the SAML token. See (link to ALSB SAML identity propagation). NOTE: this must be a valid username/password in the local security realm. An invalid username or invalid password will cause a client-side error on the test service.


Password

This is the associated password. For more information, see Username.


Service Provider

This field is used when testing an HTTPS business service with CLIENT-CERT authentication, (see {link to outbound HTTPS section in ALSB UG}). The service provider must have an associated SSL client credential. The test service will use that credential during the SSL handshake

Invocation Mode

Request\Response

This checkbox is only displayed when testing an any SOAP or any XML Business Service. Unselect the checkbox for one-way service invocations.

Message Metadata

See Limitations to Transport Header and Metadata Values You Specify in the Test Console When Testing a Service.

Transport Headers

See Limitations to Transport Header and Metadata Values You Specify in the Test Console When Testing a Service.

Viewing Business Service Test Results

The Results page displays the results of testing the business service. A description of the Business Service Results page is provided in Table 23-4. :

Table 23-4 Description of the Test Console Test Results for Business Services

Section

Description

Business Service Name

The name of the business service.

Test Console Actions

Click Back to display the previous browser page.

Click Close to close the test console window.

Request Document

This is the request message sent to the business service by the test console.

This section is initially collapsed if the test console did not modify the request message. This section is initially expanded for SOAP services configured using the Form tab, or if WS-Security has been applied.

In the case WS-Security applies, this section will contain two SOAP messages. The first message is the clear text message. The second is the secured SOAP message.

Response Document

This is the message response.

For SOAP service with response WS-Security, this section will contain two SOAP messages. The first SOAP message is the secured message as received by the client. The second SOAP message is the corresponding clear text message.

Response Metadata

This is the metadata returned with the message response.

Note: The secured SOAP message is displayed pretty printed, i.e. with extra whitespaces. This SOAP message cannot always be used as the literal data as whitespaces can affect the semantic of the document. For example, digital signatures are whitespace sensitive and could become invalid.

Related Topics

Overview of the Test Console

Testing Transformations

Performing Inline XQuery Testing

Understanding How the Run Time Uses the Transport Settings in the Test Console

 


Testing Transformations

You can test transformations after activating a session or during a session to ensure that the resources operate with the expected behavior.

Note: You must activate the session to test the runtime, otherwise your testing is done at design time using your local changes.

You can test the following transformations:

This topic includes the following sections:

MFL

MFL resources support two transformations:

Each transformation only accepts one input and provides a single output.

Configuring the MFL Resource

A description of the Configuration page for the MFL resource is provides in Table 23-5.

Table 23-5 Configuring the MFL Resource

Section


Description

Name

The name of the resource being tested is written on the top of the page.

Supported transformations

To select a specific transformation, select the transformation name.

test console actions



Execute

Apply the transformation.


Reset

Reset the input field (for XML to binary, the sample XML document is reset).


Close

Cancel the current operation.

MFL Transformation Configuration Page Description


*XML Input

This field is displayed when the XML to Binary transformation is selected.

The XML schema for the MFL document can be inferred. A sample XML document is automatically entered in the text field.

The XML input can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.

* indicates a required field. For the MFL XML to Binary transformation, the XML input is required.


*Binary Input

Displayed when the Binary to XML transformation is selected.

The binary input can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.

* indicates a required field. For the MFL Binary to XML transformation, the binary input is required.

To Test an MFL

  1. Log in to the AquaLogic Service Bus Console.

Note: You can test the design time or the runtime. Click Activate if you want to test the runtime.Do not activate the session to test the design time.

  1. Select Project Explorer or Resource Browser from the left navigation pane. The Project page/Summary of Proxy Services page is displayed.
  2. In Resources, in the Actions column, click the Launch Test Console icon associated with the resource you want to test. The test console is opened on the Resource Testing page.
  3. Select the transformation you want to run.
  4. Configure the test data for the resource. For more information, see Configuring the MFL Resource.
  5. Click Execute to run the test. The Resource Testing page is refreshed to display the results of running the test.
  6. To retest, click Back. You can close the test console and immediately modify and retest the resource.

XSLT

To test an XSLT resource you must supply the input XML document and it returns the output XML document. XSLT transformations may have additional named parameters. All parameters required by the transformation are displayed on the configuration page. Default values are available but you can override the values.

Configuring the XSLT Resource

A description of the Configuration page for the XSLT resource is provided in Table 23-6:

Table 23-6 Configuring the XSLT Resource

Section


Description

Name

The name of the resource being tested is written on the top of the page.

Test Console Actions



Execute

Apply the transformation.


Reset

Reset the input field(s).


Close

Cancel the current operation.

Input and Parameters

This is the document sent to the resource along with the parameters entered.* indicates a required input parameter.


*XML Input

The XML input can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test. XML input is a required input.


<param_name> ([] as XML)

param_name is a named XSLT parameter.

There are two types of input: XML and primitive (string, integer, float, and so on). The default input type is string. Check the checkbox associated with the parameter name to identity a parameter of type XML.

To Test an XSLT

  1. Log in to the AquaLogic Service Bus Console.

Note: You can test the design time or the runtime. Click Activate if you want to test the runtime.Do not activate the session to test the design time.

  1. Select Project Explorer or Resource Browser from the left navigation pane. The Project page/Summary of Proxy Services page is displayed.
  2. In Resources, in the Actions column, click the Launch Test Console icon associated with the resource you want to test. The test console is opened on the Resource Testing page.
  3. Configure the test data for the resource in the Input and Parameters section of the page. This is where the resource requirements are specified. For more information, see Configuring the XSLT Resource.
  4. Click Execute to run the test. The Resource Testing Page is refreshed to display the results of running the test.
  5. To retest, click Back. You can close the test console and immediately modify and retest the resource.

XQuery

An XQuery transformation can take multiple inputs and returns one output. Each input corresponds to an XQuery external variable declared in the XQuery resource. The value of an XQuery input variable can be a primitive value (string, integer, date, and so on), an XML document, or an sequence of these types. The output value can be primitive value (string, integer, date, and so on ), an XML document, or a sequence of these types.

Note: The test console does not support sequences on input.

Configuring the XQuery Resource

A description of the configuration page for the XQuery resource is provided in Table 23-7

Table 23-7 Configuring the XQuery Resource

Section


Description

Name

The name of the resource being tested is written on the top of the page.

Test Console Actions



Execute

Execute the transformation.


Reset

Reset the input field(s).


Close

Close the test console.

Variables

This section contains one input field for each of the XQuery external variables..


<param_name> ([] as XML)

param_name is a XQuery variable name presented in the XQuery resource.

In the test console, a single-line edit box is displayed if the type is a simple type. A multi-line edit box is displayed if the data is XML.

A combination input (<param_name> ([] as XML)) is used when the variable is not typed.You must declare the variable type using the checkbox. Check the checkbox to identify a parameter of type XML.

An XML input can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.

Input in the test Console is rendered based on the type to make it easier to understand the type of data you must enter. When untyped, the default type is XML.

To Test an XQuery

  1. Log in to the AquaLogic Service Bus Console

Note: You can test the design time or the runtime. Click Activate if you want to test the runtime.Do not activate the session to test the design time.

  1. Select Project Explorer or Resource Browser from the left navigation pane. The Project page/Summary of Proxy Services page is displayed.
  2. In Resources, in the Actions column, click the Launch Test Console icon associated with the resource you want to test. The test console is opened on the Resource Testing page.
  3. Configure the test data for the resource in the Variables section of the page. For more information, see Configuring the XQuery Resource.
  4. Click Execute to run the test. The Resource Testing page is refreshed to display the results of running the test.
  5. To retest, click Back. You can close the test console and immediately modify and retest the resource.

Related Topics

Overview of the Test Console

Testing Services

Performing Inline XQuery Testing

Understanding How the Run Time Uses the Transport Settings in the Test Console

 


Performing Inline XQuery Testing

Testing takes the same form for both the XQuery Editor and the Condition Editor. However the scenario is different for the XPath Expression Editor because it takes only one input. You can edit and test an action in the message flow using the following editors:

Note: You must disable the pop-up blockers in your browser for the inline XQuery testing to work. Note that if you have toolbars in the IE browser, you may need to disable the pop-up blockers from under the options menu as well as for all toolbars that are configured to block them.

Using the XQuery Expression/Condition Editors

In-line XQuery Expressions are used to create the data content for the message context variables (or part of a message context variable) during the execution of the flow. The Test Console can be used directly in the XQuery Expression Editor to test the correct definition of the expression.

Similarly, Inlined XQuery Conditions are used to evaluate boolean conditions used in the flow. The Test Console can be used directly in the XQuery Condition Editor to test the correct definition of the condition.

An Inlined XQuery can take multiple inputs and returns one output. Each input corresponds to an XQuery unbound variable defined in the in-line XQuery. The value of an XQuery input can be a primitive value (string, integer, date), an XML document, or a sequence of these types. The output value can be primitive value (string, integer, date), an XML document, or a sequence of these types.

Note: The test console does not support sequences on input.

Configuring the Inlined XQuery

A description of the configuration page for the Inlined XQuery is provided in Table 23-8

Table 23-8 Configuring the XQuery

Section


Description

Name

The type of expression being tested is written on the top of the page.

Test Console Actions



Execute

Apply the transformation.


Reset

Reset the input field(s).


Close

Cancel the current operation.

Variables

This section contains one input field for each of the Inlined XQuery unbound variables.


<param_name> ([] as XML)

param_name is the name of the corresponding XQuery unbound variable.

In the test console, a single-line edit box is displayed if we know that the type is a simple type. A multi-line edit box is displayed if we know that the data is XML. A combination input (<param_name> ([] as XML)) will be used when the variable is not typed.You must declare the variable type using the checkbox. Check the checkbox to identify a parameter of type XML.

An XML input can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.

Input in the test Console is rendered based on the type to make it easier to understand the type of data you must enter. When untypes, he default type is XML.

Note: Testing an Inlined XQuery is done in the same way as you test an XQuery resource, except to note that this is an Inline XQuery, not a resource.

To Test an Inlined XQuery

  1. Access the test console when editing an action in the message flow of a pipeline.
  2. The XQuery Testing Expression page is displayed.
    All input variables requested are displayed on the page.
  3. Configure the test data for the inlined XQuery in the Variables section of the page. For more information, see Configuring the XQuery.
  4. Click Execute to run the test. The testing page is refreshed to display the results of running the test.

Note: When performing Inline XQuery testing with the test console, once you have completed a test, you can click Back to execute a new test. To execure a new test after making changes to the Inlined XQuery, you must closeand reopen the test console for the changes to take effect.

Using the XPath Expression Editor

XPath Expressions are used to select a subset of an XML message context variable. The Test Console can be used directly in the XPath Expression Editor to test the correct definition of the xpath. An XPath expression takes a single XML document as input and generates a sequence of XML documents and/or primitives types for result.

Configuring the Inlined XPath

A description of the configuration page for the Inlined XPath is provided in Table 23-9

Table 23-9 Configuring the XPath

Section


Description

Name

The type of expression being tested is written on the top of the page.

Test Console Actions



Execute

Apply the transformation.


Reset

Reset the input field.


Close

Cancel the current operation.

Variables

This section contains a single input field corresponding to the XML document this XPath expression is run against.


The XML input can be file based or text based. Referencing a file for input takes precedence over textual input. Browse and select a specific file you want to use in your test.



.

To Test an XPath

  1. Access the test console when editing an action in the message flow of a pipeline. To access the XPath Expression Editor, see Using the XPath Expression Editor.
  2. Configure the test data for the XPath expression in the Variables section of the page. For more information, see Configuring the Inlined XPath.
  3. Click Execute to run the test. The testing page is refreshed to display the results of running the test.
  4. When performing Inlined XPath testing with the test console, once you have completed a test, you can use the Back button to execute a new test. To execute a new test after making changes to the XPath expression, you must close and reopen the test console for the changes to take effect.

Related Topics

Overview of the Test Console

Testing Services

Testing Transformations

Understanding How the Run Time Uses the Transport Settings in the Test Console

 


Understanding How the Run Time Uses the Transport Settings in the Test Console

The preceding topics in this section describe how the values of the transport headers, transport metadata, and transport-related security data for outbound requests can be configured when you run the test console to test a proxy service or a business service.

Warning: Some specifications you can make in the test console are not honored at run time. That is, the values of certain headers or metadata are overwritten, or ignored by the AquaLogic Service Bus run time when the test is executed. The headers and metadata for which there are limitations when using the test console are described in Table 23-10.

Table 23-10 Limitations to Transport Header and Metadata Values You Specify in the Test Console When Testing a Service

Transport

Testing this Service Type

Description of Limitation

Transport Headers Affected

HTTP(S)



Proxy Service

All transport headers and other fields you set are preserved at run time.

This is true whether or not the Direct Call option is set.

All

Business Service

The AquaLogic Service Bus run time overrides any values you set for these parameters


  • Content-Length

  • Content-Type

  • relative-URI

  • client-host

  • client-address

JMS



Proxy Service


Direct Call

When the Direct Call option is used, all transport headers and other fields you set are preserved at run time

All

Direct Call

When the Direct Call option is not used, the same limitations apply as for a transport header action configuration

See the limitations for JMS transport headers described in Table 16-5

Business Service

The same limitations apply as for a transport header action configuration

See the limitations for JMS transport headers described in Table 16-5

EMail



Proxy Service

No limitations. In other words, any transport headers and other fields you set are honored by the run time. This is true whether or not Direct Call is specified.


Business Service

The AquaLogic Service Bus run time overrides any values you set for these parameters

  • Content-Type

File



Proxy Service

No limitations. In other words, any transport headers and other fields you set are honored by the run time.1


Business Service

FTP



Proxy Service

No limitations. In other words, any transport headers and other fields you set are honored by the run time.



Business Service


1. For example, FileName (Transport metadata)—the value you assign is used to append to the output file name. For example, 1698922710078805308-b3fc544.1073968e0ab.-7e8e-{$FileName}


 

 

Skip navigation bar  Back to Top Previous Next