33 Test Console

The Oracle 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, or 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. To learn more about the test console, see "Using the Test Console" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Only users in the IntegrationAdmin and IntegrationDeployer roles can use the test console. For more information about roles, see "Roles in Oracle Service Bus" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Note:

If you receive an error saying the test console service is not running, try setting the Admin server listen address to a specific valid address, such as localhost. In the Oracle WebLogic Server Console, go to Environment > Servers > admin_server_name > Configuration > General to set the Listen Address.

This chapter contains the following topics:

Section 33.1, "Testing Services"
Section 33.2, "Testing Transformations"
Section 33.3, "Performing XQuery Testing"
Section 33.4, "Understanding How the Run Time Uses the Transport Settings in the Test Console"

33.1 Testing Services

This section includes the following topics:

Section 33.1.1, "Testing Proxy Services"
Section 33.1.2, "Configuring Proxy Services Test Data"
Section 33.1.3, "Viewing Proxy Services Test Results"
Section 33.1.4, "Tracing Proxy Services"
Section 33.1.5, "Testing Business Services"
Section 33.1.6, "Configuring Business Services Test Data"

33.1.1 Testing Proxy Services

You can test the following types of proxy services: any XML, any SOAP, Messaging, XML, and SOAP. You can test SOAP proxy services with Web Service Security (WSS) policies. See Web Service Security in Section 33.1.2, "Configuring Proxy Services Test Data."

Note:

When the test console invokes a proxy with HTTP custom token authentication, the authentication check is not done.

Caution:

Testing proxy services with the direct call option enabled bypasses some important security steps, including access control. Oracle recommends that you not use the test service in production systems.

Click Activate under Change Center to enable the test feature in the console.

You can test proxy services from the Resource Browser or Project Explorer.
Select Resource Browser > Proxy Services to display the Summary of Proxy Services page.
Under Actions, click the Launch Test Console icon associated with the proxy service you want to test.

The test console opens the Proxy Service Testing page. For example, using the examples provided with the product, click the icon associated with the LoanGateway1 proxy service.

Note:
In a clustered domain, you cannot use the test console to test any configured business service or proxy service which routes to a business service.
For SOAP and XML services, select the WSDL operation you want to test.
Configure the test data for the proxy service. This must be the data that the proxy service expects from the client.

By default, both test configuration options, Direct Call and Include Tracing, are enabled. You can clear the Direct Call option, which also clears 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 selected) and disable tracing; simply clear the Include Tracing check box.
Click Execute. The Proxy Service Testing page displays the results. For information about interpreting the test results, see Section 33.1.3, "Viewing Proxy Services Test Results."
To run the test again, click Back. Repeat steps 5–8.

33.1.2 Configuring Proxy Services Test Data

Table 33-1 lists the configuration options for testing proxy services. The fields for accepting input to the request document are based on the service type.

Table 33-1 Proxy Services Configuration Options

Section	Options/Fields
Name	The name of the proxy service being tested.
Available Operations	Operations associated with the proxy service.
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	Set the testing configuration options. Direct Call - Send a message to the proxy service without using the Oracle 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 clearing 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 - Tracing shows the state of the message as it passes through the system.
Request Document	The input fields generate the request message that is sent to the proxy service. Click Execute to run the test with the values you entered. The test console displays the request message and the service's response message and metadata. Input in the Request Document section is service-type specific. The service types and a description of the input required by each are listed in the following sections. 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 enter the message content in the text box. 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 enter the message content in the text box. 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. Oracle recommends entering binary input from a file. Data entered in the text area is converted to binary input using the system encoding. Data entered from files 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 enter the message content in the text box. 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. 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 the 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 the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. Username - The user name in Web Service security username tokens generated from the test service. This field is optional. This user name 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. This must be a valid user name and password in the local security realm. An invalid user name or invalid password causes a client-side error on the test service. Password - The password in Web Service security user name tokens generated from the test service.
Transport	The Transport section is collapsed by default. The fields and values depend on the test configuration.
Authentication	Username - The user name for setting the security context used by the test service when invoking the proxy service. If the proxy service 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 "Using SAML with Oracle Service Bus" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus. Do not confuse this field with the Web Service Security (WSS) username field. This must be a valid user name and password in the local security realm. An invalid user name or invalid password will cause a client-side error on the test service. Note: When the test console invokes a proxy with HTTP custom token authentication, the authentication check is not done. Password - The associated password for the Username.
Invocation Mode	Request/Response - This option is only displayed when testing any SOAP or any XML proxy service. Clear the Request/Response check box for one-way service invocations.
Message Metadata	See Table 33-10
Transport Headers	See Table 33-10

Note:

The secured SOAP message is displayed printed with extra white spaces. Because white spaces can affect the semantics of the document, this SOAP message cannot always be used as the literal data. For example, digital signatures are white space-sensitive and can become invalid.

33.1.3 Viewing Proxy Services Test Results

Table 33-2 describes proxy service testing results. Tracing is only enabled if you have selected both the Direct Call and the Include Tracing options.

Table 33-2 Testing 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	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. If WS-Security has been applied, this section will contain two SOAP messages—the first message is the clear text message; the second is the secured SOAP message.
Response Document	The message response. For a SOAP service with a WS-Security response, 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.
Section 33.1.4, "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. For more information on tracing, see Section 33.1.4, "Tracing Proxy Services"

33.1.4 Tracing Proxy Services

Tracing is enabled when you test proxy services using a direct call. The Include Tracing check box is selected by default with the Direct Call option. If you do not want tracing, clear the Include Tracing check box. When you enable tracing, the test results include the details of the trace. Use tracing to track problems in the system and to isolate them for correction. The trace information shows the path taken through the request and response paths in the code.

Click Activate under Change Center to enable the test feature in the console.
Select Resource Browser > Proxy Services to display the Summary of Proxy Services page.
Under Actions, click the Launch Test Console icon associated with the service you want to test. The test console opens the Proxy Service Testing page.
Configure the test data for the proxy service. You must have the Direct Call and Include Tracing options selected to enable tracing. See Section 33.1.2, "Configuring Proxy Services Test Data."
Click Execute. The Proxy Service Testing page displays the test results for the service and the tracing information.
Scroll down to the Invocation Trace section.

This section displays a graphical representation 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.
Click the + plus sign to expand the message flow to view more detail.

While viewing the trace you can also view the message flow in the Oracle Service Bus Console. This helps you relate the trace to the stages and actions in the message flow. You can modify the message flow and run the trace again to view the output.

33.1.5 Testing Business Services

You can test the following types of business services: any XML, any SOAP, Messaging, XML, and SOAP. You can test SOAP business services with Web Service Security policies. For more information, see "Testing Services with Web Service Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Note:

In a clustered domain, you cannot use the test console to test any configured business service or proxy service which routes to a business service.

Click Activate under Change Center to enable the test feature in the console.
Select Resource Browser > Business Services to display the Summary of Business Services page.
Under Actions, click the Launch Test Console icon associated with the service you want to test. The test console opens the Business Service Testing page. For example, using the tutorials provided with the product, click the icon associated with loanSaleProcessor.
For SOAP and XML services, select an operation from the Available Operations field.
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). The Direct Call and Include Tracing options that are available when testing proxy services are not available for business services. By default, business services are tested using the Direct Call option, meaning that the messages pass through the transport layer.
Click Execute.

The Business Service Testing page displays the results. For more information, see Section 33.1.7, "Viewing Business Services Test Results."

33.1.5.1 Testing Attachments in Business Services

This section describes how to use the Test Console to test attachments on business services.

For illustration purposes, this section assumes that a WSDL-based HTTP business service uses a "submitAttachment" operation to send a ZIP file as an attachment in a SOAP message. Modify the settings as appropriate for different types of binary attachments.

In the Test Console for the business service, go to the XML page and enter the following SOAP Envelope for the test message:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Header/>
   <env:Body>
      <m:submitAttachment xmlns:m="http://www.alsb.com/SOAPwithAttachment/">
         <submitAttachment>
            <fileName>c:\yourfile.zip</fileName>
         </submitAttachment>
         <zipFile href="cid:zipFile"/>
      </m:submitAttachment>
   </env:Body>
</env:Envelope>

In the Attachment section of the Test Console:
1. Content-Type: application/zip (as defined in the WSDL)
2. Content-ID: zipFile (must match the value of href="cid:zipFile" in the test message)
3. File: Click Browse, and select the ZIP file you specified in the SOAP Envelope.
4. Click Add.
Click Execute to send the test message with the attachment.

To confirm success of the sent attachment, check the server console for a message similar to the following, which is logged by the submitAttachment operation:

WS called - received the following properties:
submitAttachment is:
      com.alsb.soapwithattachment.SubmitAttachmentRequestType@e2abb0
zipFile is: javax.activation.DataHandler@175cf0a

33.1.6 Configuring Business Services Test Data

Table 33-3 lists the configuration options for testing business services. The fields for accepting input to the request document are based on the service type.

Table 33-3 Business Services Configuration Options

Section	Options/Fields
Name	The name of the business service being tested.
Available Operations	Operations associated with the business service.
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 input fields generate the request message that is sent to the business service. Click Execute to run the test with the values you entered. The test console displays the request message and the service's response message. Input in the Request Document section is service-type specific. The service types and a description of the input required by each are listed in the following sections. 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 enter the message content in the text box. 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 enter the message content in the text box. 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. Oracle recommends entering binary input from a file. Data entered in the text area are converted to binary using the system encoding. Data entered from files 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 enter the message content in the text box. This is a WSDL-based service with multiple operations defined. Oracle provides a 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 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. 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 the 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 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 the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. Username - The user name in Web Service security username tokens generated from the test service. This field is optional. This user name 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. This must be a valid user name and password in the local security realm. An invalid user name or invalid password will cause a client-side error on the test service. In some scenarios, this user name and password may also be used when the test service generates a SAML assertion. Password - The password in Web Service security username tokens generated from the test service.
Transport	The Transport section is collapsed by default. The fields and values depend on the test configuration.
Authentication	Username - The user name for setting 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 "Using SAML with Oracle Service Bus" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus. This must be a valid user name and password in the local security realm. An invalid user name or invalid password will cause a client-side error on the test service. Password - The associated password. For more information, see Username. Service Key Provider - This field is used when testing an HTTPS business service with CLIENT-CERT authentication.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 option is only displayed when testing an any SOAP or any XML business service. Clear the Request/Response check box for one-way service invocations.
Message Metadata	See Table 33-10.
Transport Headers	See Table 33-10.

33.1.7 Viewing Business Services Test Results

Table 33-4 describes business service testing results.

Table 33-4 Testing 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	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. If WS-Security has been applied, this section will contain two SOAP messages. The first message is the clear text message. The second is the secured SOAP message.
Response Document	The message response. For a SOAP service with a WS-Security response, 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	The metadata returned with the message response.

Note:

The secured SOAP message is displayed pretty printed, for example, with extra white spaces. This SOAP message cannot always be used as the literal data as white spaces can affect the semantics of the document. For example, digital signatures are white space-sensitive and can become invalid.

33.2 Testing Transformations

You can test transformations after activating a session or during a session to ensure that the resources operate with the expected behavior. You must activate the session to test the run time, otherwise the testing is done at design time using your local changes.

You can test the following transformations:

Section 33.2.1, "Testing MFL Transformations"
Section 33.2.2, "Testing XSLT Transformations"
Section 33.2.3, "Testing XQuery Transformations"

33.2.1 Testing MFL Transformations

A Message Format Language (MFL) document is a specialized XML document used to describe the layout of binary data. MFL resources support two transformations. Each transformation only accepts one input and provides a single output: XML to binary, or binary to XML.

Table 33-5 describes MFL configuration options.

Table 33-5 Configuring MFL Options

Section	Description
Name	The name of the resource being tested.
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	XML Input - Required for XML to binary transformations: 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 the file you want to use in your test. Binary Input - Required for binary to XML transformations: The binary input can be file-based or text-based. Referencing a file for input takes precedence over textual input. Browse and select the file you want to use in your test.

You can test the design time or the run time.

Click Activate if you want to test the run time. Do not activate the session to test the design time.
Select Resource Browser > MFLs to display the Summary of MFL Files page.
Under Actions, click the Launch Test Console icon associated with the resource you want to test. The test console opens the Resource Testing page.
Select the transformation you want to test.
Configure the test data for the MFL resource. For more information, see Table 33-5.
Click Execute. The Resource Testing page displays the results.
To retest, click Back. You can close the test console, modify, and retest the resource.

33.2.2 Testing XSLT Transformations

eXtensible Stylesheet Language Transformations (XSLT) describe XML-to-XML mappings in Oracle Service Bus. To test an XSLT resource you must supply the input XML document and the test console 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 them.

Table 33-6 describes XSLT configuration options.

Table 33-6 Configuring XSLT Options

Section

Description

Name

The name of the resource being tested.

Test Console Actions

Execute - Apply the transformation.
Reset - Reset the input field(s).
Close - Cancel the current operation.

Input and Parameters

The input document and parameters for testing the XSLT resource.

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 the file you want to use in your test. XML input is required.
<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. Select the check box associated with the parameter name to identify a parameter of type XML.

You can test the design time or the run time.

Click Activate if you want to test the run time. Do not activate the session to test the design time.
Select Project Explorer > XSLTs to display the Summary of XSLTs page.
Under Actions, click the Launch Test Console icon associated with the resource you want to test. The test console opens the Resource Testing page.
Configure the test data for the resource in the Input and Parameters section of the page. For more information, see Table 33-6.
Click Execute. The Resource Testing page displays the results.
To retest, click Back. You can close the test console, modify, and retest the resource.

33.2.3 Testing XQuery Transformations

XQuery maps can describe XML-to-XML, XML to non-XML, and non-XML to XML mappings. 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 a sequence of these types. The output value can be a 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.

Table 33-7 describes XQuery configuration options.

Table 33-7 Configuring XQuery Options

Section Description

Name

The name of the resource being tested.

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 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. Select the check box 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 the 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.

You can test the design time or the run time.

Click Activate if you want to test the run time. Do not activate the session to test the design time.
Select Project Explorer > XQueries to display the Summary of XQueries page.
Under Actions, click the Launch Test Console icon associated with the resource you want to test. The test console opens the Resource Testing page.
Configure the test data for the resource in the Variables section of the page. For more information, see Table 33-7.
Click Execute. The Resource Testing page displays the results.
To retest, click Back. You can close the test console, modify, and retest the resource.

33.3 Performing XQuery Testing

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

Note:

You must disable the pop-up blockers in your browser for XQuery testing to work. 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.

This section includes the following topics:

Section 33.3.1, "Using the XQuery Expression and XQuery Condition Editors"
Section 33.3.2, "Using the XPath Expression Editor"

33.3.1 Using the XQuery Expression and XQuery Condition Editors

You use XQuery expressions to create the data content for the message context variables (or part of a message context variable) during the execution of the message flow. You can use the test console directly in the XQuery Expression Editor to test the definition of the expression.

Similarly, you use XQuery conditions to evaluate Boolean conditions in the message flow. You can use the test console directly in the XQuery Condition Editor to test the definition of the condition.

An XQuery can take multiple inputs and returns one output. Each input corresponds to an XQuery unbound variable defined in the XQuery. The value of an XQuery input can be a primitive value (String, integer, date, and so on), an XML document, or a sequence of these types. The output value can be a 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.

Table 33-8 describes XQuery configuration options.

Table 33-8 Configuring XQuery Testing

Section	Description
Name	The type of expression being tested.
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 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 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. Select the check box 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 the 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. The default type is XML.

Section

Description

Name

The type of expression being tested.

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 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 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. Select the check box 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 the 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. The default type is XML.

Access the test console when editing an action in the message flow of a pipeline.
- To access the XQuery Expression Editor, see Section 23.1, "Creating and Editing Inline XQuery and XPath Expressions."
- To access the XQuery Condition Editor, see Section 23.1, "Creating and Editing Inline XQuery and XPath Expressions."
The XQuery Testing Expression page is displayed. All input variables requested are displayed on the page.
Configure the test data for the XQuery in the Variables section of the page. For more information, see Table 33-8.
Click Execute. The testing page displays the results.
Once you have completed a test, you can click Back to execute a new test. To execute a new test after making changes to the XQuery, you must close and reopen the test console for the changes to take effect.

33.3.2 Using the XPath Expression Editor

You use XPath expressions to select a subset of an XML message context variable. You can use the test console in the XPath Expression Editor to test the definition of the XPath expression. An XPath expression takes a single XML document as input and generates a sequence of XML documents, primitives types, or both as output.

Table 33-9 describes XPath expression configuration options.

Table 33-9 Configuring XPath Options

Section	Description
Name	The type of expression being tested.
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 against which this XPath expression is being tested. The XML input can be file-based or text-based. Referencing a file for input takes precedence over textual input. Browse and select the file you want to use in your test.

Section

Description

Name

The type of expression being tested.

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 against which this XPath expression is being tested.

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

Access the test console when editing an action in the message flow of a pipeline. To access the XPath Expression Editor, see Section 23.1, "Creating and Editing Inline XQuery and XPath Expressions."
Configure the test data for the XPath expression in the Variables section of the page. For more information, see Table 33-9.
Click Execute. The testing page displays the results.
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.

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

Section 33.1.2, "Configuring Proxy Services Test Data" and Section 33.1.6, "Configuring Business Services Test Data" describe how you configure the values of the transport headers, transport metadata, and transport-related security data for outbound requests when you test proxy services or business services in the test console. However, 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 Oracle Service Bus at run time when the test is executed. The headers and metadata for which there are limitations are described in Table 33-10.

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

Transport	Service Type	Description of Limitation	Transport Headers Affected
HTTP(S)^Foot 1	Proxy Services	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
HTTP(S)	Business Services	The Oracle Service Bus run time overrides any values you set for these parameters.	Content-Length Content-Type relative-URI client-host client-address
JMS	Proxy Services	When the Direct Call option is used, all transport headers and other fields you set are preserved at run time.	All
JMS	Proxy Services	When the Direct Call option is not used, the same limitations apply as those for a transport header action configuration.	See the limitations for JMS transport headers described in "Limitations to Transport Header Values You Specify in Transport Header Actions" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
JMS	Business Services	The same limitations apply as those for a transport header action configuration.	See the limitations for JMS transport headers described in "Limitations to Transport Header Values You Specify in Transport Header Actions" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
E-Mail	Proxy Services	No limitations. Any transport headers and other fields you set are honored at run time. This is true whether or not Direct Call is specified.	None
E-Mail	Business Services	The Oracle Service Bus run time overrides any values you set for these parameters	Content-Type
File	Proxy Services	No limitations. Any transport headers and other fields you set are honored at run time.^Foot 2	None
File	Business Services	No limitations	None
FTP	Proxy Services	No limitations. Any transport headers and other fields you set are honored at run time.	None
FTP	Business Services	No limitations	None

^Footnote 1When you test proxy services, the test console never sends a HTTP request over the network, therefore transport-level access control is not applied.

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