58 Using the Test Console

This chapter provides guidelines and information on testing services using the Service Bus Test Console, including how to undeploy the Test Console in production environments.

This chapter contains the following topics:

• Introduction to the Test Console

• Accessing the Test Console

• Testing Proxy Services, Business Services, Pipelines, and Split-Joins

• Testing MFL Transformations

• Testing XSLT Transformations (Resources)

• Testing XQuery Transformations (Resources)

• Testing Inline Expressions

• Testing Services With OWSM Security

• About Security and Transports

• Undeploying the Test Console

• Test Console Page Reference for Services

58.1 Introduction to the Test Console

The Service Bus Test Console is a browser-based test environment you use to validate and test the design of your system.

The Test Console is an extension of the Oracle Service Bus Console, and can be accessed from the console, JDeveloper, and Fusion Middleware Control. The Test Console appears as a tabbed window in JDeveloper or in a web browser, depending on the operating system and the JDeveloper configuration.

When you test a Service Bus resource, you configure the object of your test, execute the test, and view the results in the Test Console windows. In some cases, you can trace through the code and examine the state of the message at specific trace points. Design-time testing helps isolate design problems before you deploy a configuration to a production environment. The components you can test using the Test Console include proxy services, business services, pipelines, split-joins, XQuery resources, XSLT resources, MFL resources, and XQuery/XPath expressions.

The Test Console can test specific parts of your system in isolation and it can test your system as a unit. You can use the Test Console in clustered environments. However, Oracle does not recommend deploying the Test Console in production environments. Only users in the IntegrationAdmin and IntegrationDeployer roles can use the Test Console. For more information about roles, see Roles in Administering Oracle Service Bus.

Most services can be tested using the Test Console, however the Test Console cannot invoke a service that expects a Java object as the message input. For example, messaging services that have a message request or response type of Java cannot be tested, and JEJB operations that expect Java objects cannot be tested.

58.1.1 Proxy Service Testing

When you test a proxy service, the message is sent to the proxy service through the transport layer. The transport layer performs manipulation of message headers or metadata as part of the test. The configuration data you enter for the test simulates the data that is sent to the proxy service from the client. The response from a proxy service test is the message that is sent to the next component in the system. This loosely correlates to an indirect call in previous versions of Service Bus.

Use this test approach in conjunction with setting custom (outbound) transport headers in the Test Console Transport section to accurately simulate the service call. For more information on transport settings, see Test Console Transport Settings.

Note:

Testing a request/response MQ or JMS proxy service does not work. The Test Console does not display the response from a call to an MQ or JMS request/response proxy service using a correlation based on a messageID. When you test an MQ or JMS request/response proxy service, the response is retained in the response queue and is not displayed in the Test Console.

58.1.2 Pipeline Testing

When testing pipelines, the input messages are sent directly to the pipeline. Tracing is turned on by default, allowing you to diagnose and troubleshoot a message flow in the Test Console. The input data you enter in the Test Console must be that which is expected by the pipeline from the proxy service that invokes it. In other words, the Test Console plays the role of the proxy service invoking the pipeline. This loosely correlates to a direct call in previous versions of Service Bus.

Testing a pipeline tests the internal message flow logic. Use this test approach in conjunction with setting custom (inbound) transport headers in the Test Console Transport panel to accurately simulate the service call.

58.1.2.1 Execution Tracing in Pipelines Using the Test Console

Tracing a message through a pipeline involves examining the message context and outbound communications at various points in the message flow. The points at which the messages are examined are predefined by Service Bus, which defines tracing for stages, error handlers, and route nodes. For each stage, the trace includes the changes that occur to the message context and all the services invoked during the stage execution.

The following stage information is provided by the trace:

• Initial Message Context: Shows the variables initialized by the proxy service when it is invoked. To see the value of any variable, click the + sign associated with the variable name.

• New variables: The names of all new variables and their values. Expand a variable to view its value.

• Deleted variables: The names of all deleted variables.

• Changed variables: The names of all variables for which the value changed, including $header, $body, and $inbound changes as a result of the processing of the message through the stages. Expand a variable to view the new value.

• Faults: If an error occurs, the contents of the fault context variable ($fault) is shown as a result of the stage error handler handling the validation error.

• Publish: Every publish call is listed. For each publish call, the trace includes the name of the service invoked, and the value of the outbound, header, body, and attachment variables.

• Service callout: Every service callout is listed. For each service callout, the trace includes the name of the service that is invoked, the value of the outbound variable, the value of the header, body, and attachment variables for both the request and response messages.

The trace contains similar information for route nodes as for stages. In the case of route nodes, the trace contains the following categories of information:

• The trace for service invocations on the request path

• The trace for the routed service

• The trace for the service invocations on the response path

• Changes made to the message context between the entry point of the route node (on the request path) and the exit point (on the response path)

Note:

To see tracing in the log file or standard out (server console), WebLogic Server logging must be set to the following severity levels:

• Minimum severity to log: Info

• Log file: Info

• Standard out: Info

For information on setting log severity levels, see "Using Log Severity Levels" in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.

58.1.3 Business Service Testing

The input test data for a business service should be in the form expected by the business service as it would come from the pipeline, split-join, or proxy service that invokes the business service. For example, this could be data from a route node or a service callout action of a pipeline. The Test Console functions in the role of the invoking service when you use it to test a business service. When testing business services, messages are always routed through the transport layer.

When you test a business service, ensure that the user name and password you specify in the Test Console exists in the local Service Bus domain even if the business service being tested is in a remote domain. The test service performs a local authentication before invoking any proxy or business service.

58.1.4 Recommended Approaches to Testing Services

In the scenario depicted in Figure 58-1, a client invokes the proxy service PS1, which in turn invokes the pipeline P1. The pipeline invokes pipeline P2, then business service B1, and then local proxy service PS2 before returning a message to the client. Interfaces are identified by number.

Figure 58-1 Test Scenario Example

Description of "Figure 58-1 Test Scenario Example"

There are many valid test strategies for this scenario. Oracle recommends the following:

• Complete the testing of interfaces other than the initial proxy service first. In the sample scenario illustrated in Figure 58-1, this means that you complete the testing of interfaces 1 through 6 first, then test interface 7.

  Generally, you want to test in the reverse order of the way a message would flow through the system. In this way, the message flow logic in the pipelines can be iteratively changed and tested knowing that the downstream interfaces function correctly.

• Test the pipeline (P1) to business service (B1) interface (1).

• Validate and test all the XQuery expressions in the pipelines prior to testing the pipelines themselves. In Figure 58-1, interface 2 and 5 refer to XQuery expression tests.

• Test the pipeline (P1) to pipeline (P2) interface (3).

• Test the pipeline (P1) to local proxy service (PS2) interface (4).

• Test the initial proxy service (PS1) to pipeline (P1) interface (6).

• Make your final system test simulate the client invoking the proxy service PS1. This test is represented by interface 7 in Figure 58-1.

• Save the message state after executing successful interface tests to facilitate future troubleshooting efforts on the system. Testing interface 6 is in fact a test of the complete system. Knowing that all other interfaces in the system work correctly can help narrow the troubleshooting effort when system errors arise.

58.1.5 HTTP Requests

When you test proxy services, the Test Console never sends an HTTP request over the network, therefore, transport-level access control is not applied. Transport-level access control is achieved through the web application layer. For information about message processing in the transport layer, see Message Processing.. For information about transport settings, see How the Runtime Uses the Transport Settings in the Test Console..

58.2 Accessing the Test Console

There are multiple ways to access the Test Console to test a specific Service Bus service, from the Oracle Service Bus Console, JDeveloper, or Fusion Middleware Control.

Proxy services, business services, pipelines, and split-joins can only be tested outside a session. Transformations can be tested from outside or inside a session.

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 Administration Console, go to Environment > Servers > admin_server_name > Configuration > General to set the Listen Address. Also, in a cluster, make sure all managed nodes are running.

58.2.1 Prerequisites

The following must be in place before you can use the Test Console:

• Service Bus must be running and, if you are testing a service, the session that contains the resource you want to test must be activated. Services can only be tested from outside a session, but transformations can be tested from outside or inside a session.

• Pop-up blockers must be disabled in your browser for XQuery testing to work. If you have toolbars in the Internet Explorer browser, this may mean disabling pop-up blockers from under the Options menu as well as for all toolbars that are configured to block them. XQuery testing is done only in the design-time environment (in an active session).

• If you want the Test Console to generate and send SAML tokens to a proxy service, you must configure the proxy service to require SAML tokens and to be a relying party. For more information on creating a SAML relying party, see Create a SAML 1.1 Relying Party in the Oracle WebLogic Server Administration Console Online Help.

  Note:

  When creating a SAML relying party:

  • Only WSS/Sender-Vouches and WSS/Holder-of-Key SAML profiles are applicable to a proxy service.

  • When you configure the relying party, provide the URI of the proxy service for the target URL value. To view the URI of the proxy service, click the open the proxy service in the Oracle Service Bus Console and click the Transport subtab.

58.2.2 How to Access the Test Console from the Oracle Service Bus Console

On the Oracle Service Bus Console, you can access the Test Console for a service or transformation from that component's definition editor or from the Project or Folder Definition Editor.

58.2.2.1 Accessing the Test Console from a Component's Definition Editor

To access the Test Console from a component's definition editor:

1. In the Oracle Service Bus Console Project Navigator, expand the project and folders containing the service or transformation you want to test.
2. Click the resource to open it in a definition editor.
3. In the upper right section of the definition editor, click Launch Test Console (the green arrow icon).

   The Test Console appears in a new browser window, ready to test the selected component.

58.2.2.2 Accessing the Test Console from the Project or Folder Definition Editor

To access the Test Console from the Project or Folder Definition Editor:

1. In the Oracle Service Bus Console Project Navigator, click the name of the project or folder that contains the component you want to test.

   The definition editor for that folder or project appears.

2. Locate the component you want to test in the resources table.
3. In the Actions column, click Launch Test Console (the green arrow icon).

   The Test Console appears in a new browser window, ready to test the selected component.

58.2.3 How to Access the Test Console from Fusion Middleware Control

In Fusion Middleware Control, you can access the Test Console for a service from that service's Dashboard page. You can only test services from Fusion Middleware Control, and not transformations.

To access the Test Console from Fusion Middleware Control:

1. In the Fusion Middleware Control target navigator, expand SOA, expand service-bus, and click the project that contains the component you want to test.

   The Service Health page for that project appears.

2. If the services associated with the project do not appear in the Services table, perform a search for the service to test.

   Note:

   Only services that have monitoring enabled are displayed on this page.

3. In the Services table, click the name of the service to test.

   The Dashboard for the service appears.

4. To the right of the service name, click Launch Test Console (the green arrow icon).

   The Test Console appears in a new browser window, ready to test the selected component.

58.2.4 How to Access the Test Console from JDeveloper

In JDeveloper, you can access the Test Console for a service or transformation from that service's definition editor or from its context menu. Transformations provide multiple options for testing, including the Test Console and JDeveloper XSLT tester.

58.2.4.1 Accessing the Test Console from JDeveloper

To access the Test Console for a service from JDeveloper:

1. In JDeveloper expand the Service Bus project containing the service you want to test.
2. Do one of the following:

   • Double-click the service to display its editor, and then click the Run icon in the JDeveloper toolbar.

   • Right-click the service and select Run.

   The Test Console appears in a new tabbed window, ready to test the selected service.

58.2.4.2 Accessing the Test Console for a Transformation from JDeveloper

To access the Test Console for a transformation from JDeveloper:

1. In JDeveloper expand the Service Bus project containing the transformation you want to test.
2. Do one of the following:

   • Click the transformation to display its editor, and then click the Run icon in the JDeveloper toolbar.

   • Right-click the transformation and select Run.

     Note:

     Clicking Debug also launches the Test Console, but is typically used in conjunction with breakpoints so you can step through the message flow in sections.

3. If a dialog appears, select In Service Bus Test Console as the choice for how the target should be started.

   The Test Console appears in a new tabbed window, ready to test the selected service.

58.3 Testing Proxy Services, Business Services, Pipelines, and Split-Joins

When testing Service Bus services, you cannot be in an active session. The Test Console lets you test input, transport headers, attachments, and certain security configurations.

For more information about testing services, see Introduction to the Test Console.

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.

• When the Test Console invokes a proxy with HTTP custom token authentication, the authentication check is not performed.

58.3.1 How to Test Service Bus Services

When you launch the Test Console for a service, you can configure the test input, including the operation to test, the message payload, transport headers, and security information. For pipelines, you can trace message processing through the different components. The following figure shows an example of a Test Console page.

Figure 58-2 Pipeline Testing Page on the Test Console

Description of "Figure 58-2 Pipeline Testing Page on the Test Console"

To test a Service Bus service:

1. If applicable, make sure the session in the Oracle Service Bus Console is activated.
2. Locate the proxy service, business service, pipeline, or split-join you want to test, and launch the Test Console, as described in Accessing the Test Console..
3. For SOAP and XML services, select the WSDL operation you want to test.
4. In the Request Document section, enter the test data to use. This must be the data that the service expects to receive.

   For information about filling in this section, see Request Document Test Console Properties.

   Note:

   A secured SOAP message is displayed 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.

5. Configure the remaining sections of the Test Console. For information about the properties you can set, see Test Console Page Reference for Services.
6. Click Execute.

   The Test Console displays the request message and the service's response message and metadata. For information about interpreting the test results, see How to View Service Test Results.

7. To run the test again, click Back. Repeat steps 3 through 6.

58.3.2 How to Test Attachments in Services

You can test message attachments with proxy services, business services, and pipelines.

To test services with attachments:

1. If applicable, make sure the session in the Oracle Service Bus Console is activated.
2. Locate the proxy service, business service, or pipeline you want to test, and launch the Test Console, as described in Accessing the Test Console..
3. For SOAP and XML services, select the WSDL operation you want to test.
4. For pipelines, specify whether to enable tracing. For more information, see How To Trace Pipeline Processing.
5. In the Request Document section, enter the payload for the test message.

   As an example, the following input uses a submitAttachment operation to send a ZIP file as an attachment in a SOAP 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>
   

   For information about filling in this section, see Request Document Test Console Properties.

6. In the Attachment section of the Test Console, enter values for the attachment headers, as described in Attachment Test Console Properties. You must select the file to use as an attachment.
7. Configure the remaining sections of the Test Console. For information about the properties you can set, see Test Console Page Reference for Services.
8. Click Execute.

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

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

58.3.3 How To Trace Pipeline Processing

When you enable tracing for a pipeline, 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. the following figure shows the results of a pipeline trace.

While viewing the trace you can also view the message flow in the Oracle Service Bus Console or JDeveloper. 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.

Figure 58-3 Pipeline Invocation Trace

Description of "Figure 58-3 Pipeline Invocation Trace"

To trace a message through a pipeline:

1. If applicable, make sure the session in the Oracle Service Bus Console is activated.
2. Locate the pipeline you want to test, and launch the Test Console, as described in Accessing the Test Console..
3. For SOAP and XML services, select the WSDL operation you want to test from the available options in the Service Operation section.
4. In the Test Configuration section, make sure Include Tracing is selected.
5. In the Request Document section, enter the test data to use. This must be the data that the pipeline expects to receive.

   For information about filling in this section, see Request Document Test Console Properties.

6. Configure the remaining sections of the Test Console. For information about the properties you can set, see Test Console Page Reference for Services.
7. Click Execute.

   The Test Console displays the request message and the service's response message and metadata. For information about interpreting the test results, see How to View Service Test Results.

8. Scroll down to the Invocation Trace section.

   This section displays a 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.

9. Click the + plus sign to expand the message flow to view more detail.

58.3.4 How to View Service Test Results

When you test a proxy service, business service, pipeline, or split-join, the Test Console displays the results in several sections. Table 58-1 describes the testing results sections.

Table 58-1 Testing Results for Proxy Services

Section	Description
Request Document	The request message sent to the 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 contains two SOAP messages. The first message is the clear text message; the second is the secured SOAP message.
Response Document	The message response generated by the service. This section also indicates if any errors occurred. 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.
Invocation Trace	Tracing is available only for pipelines, and this section shows the state of the message as it passes through the system. This is only performed when you select Include Tracing prior to executing the test.

58.4 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 the following transformations:

• XML to binary: There is one required input (XML) and one output (binary).

• binary to XML: There is one required input (binary) and one output (XML).

Each transformation accepts only one input and provides a single output. You can test MFL transformations using the Test Console, accessed from either JDeveloper or the Oracle Service Bus Console, or using the tester in the Format Builder in JDeveloper.

58.4.1 How to Test MFL Transformations in the Test Console

You can test transformations after activating a session or during a session to ensure that the resources operate with the expected behavior. If you do not active the session, the testing is done at design time using your local changes.

In JDeveloper, you can also use the Format Builder's built-in testing tool. For information about running tests from the Format Builder, see Testing Format Definitions.

To test MFL transformations in the Test Console:

1. To test the runtime, activate the current session. To test the design time, do not activate the session.
2. Locate the MFL resource you want to test, and launch the Test Console, as described in Accessing the Test Console..
3. Configure the test data for the MFL resource. For more information, see Table 58-2.
4. Click Execute.

   The Test Console displays the results.

5. To retest, click Back. You can close the Test Console, modify, and retest the resource.

Table 58-2 MFL Test Console Properties

Section	Description
Supported transformations	To select a specific transformation to test, select the transformation name.
Input Document	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.

58.4.2 MFL Test Console Example

The following example illustrates testing an MFL transformation, and shows the contents of the MFL file, the test input, and the test results. The Test Console generates a sample XML document from the MFL file, and you execute the test using the XML input. A successful test results in the transformation of the message content of the input XML document to binary format.

Example - Contents of the MFL File

Below is an example of an MFL file.

<?xml version='1.0' encoding='windows-1252'?>
<!DOCTYPE MessageFormat SYSTEM 'mfl.dtd'>
  <MessageFormat name='StockPrices' version='2.01'>
   <StructFormat name='PriceQuote' repeat='*'>
    <FieldFormat name='StockSymbol' type='String' delim=':' codepage='windows-1252'/>
    <FieldFormat name='StockPrice' type='String' delim='|'codepage='windows-1252'/>
   </StructFormat>
  </MessageFormat>

Example - Test Console XML Input

The XML document generated by the Test Console to test the MFL file in the previous example is shown below.

<StockPrices>
    <PriceQuote>
        <StockSymbol>StockSymbol_31</StockSymbol>
        <StockPrice>StockPrice_17</StockPrice>
    </PriceQuote>
</StockPrices>

Example - MFL Test Console Results

When you click Execute in the Test Console to run this test, the console displays the following data (the stock symbol and stock price in binary format).

00000000:53 74 6F 63 6B 53 79 6D 62 6F 6C 5F 33 31 3A 53 StockSymbol_31:S
00000010:74 6F 63 6B 50 72 69 63 65 5F 31 37 7C .. .. .. StockPrice_17|...

58.5 Testing XSLT Transformations (Resources)

Extensible Stylesheet Language Transformation (XSLT) describes XML-to-XML mappings in Service Bus. You can use XSLT transformations in XQuery expressions in message flows.

To test an XSLT resource, you must supply an input XML document. The Test Console returns the output XML document. An XSLT transformation can include multiple parameters to assist with a transformation. All parameters required by the transformation are displayed on the Test Console. Default values are available but you can override them. XSLT parameters accept either primitive values or XML document values. You cannot identify the types of parameters from the XSL transformation.

You can access the Test Console for XSLT transformations from the Oracle Service Bus Console or from JDeveloper. In JDeveloper, you can also use the XSLT mapper's built-in tester.

58.5.1 How to Test XSLT Transformations Using the Test Console

XSLT transformations can be tested 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 runtime, otherwise the testing is done at design time using your local changes.

To test an XSLT transformation using the Test Console:

1. To test the runtime, activate the current session. To test the design time, do not activate the session.
2. Locate the XSLT resource you want to test, and launch the Test Console, as described in Accessing the Test Console..
3. Configure the test data for the resource by entering the following information.

   • XML Input: The XML input can be file-based or text-based. If you select a file for input, it takes precedence over textual input. Browse and select the file you want to use in your test. XML input is required.

   • param_name: 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 as XML check box associated with the parameter name to identify a parameter of type XML. For more information about this option, see Testing XQuery Transformations (Resources).

4. Click Execute.

   The Test Console displays the results.

5. To retest, click Back. You can close the Test Console, modify, and retest the resource.

58.5.2 How to Test XSLT Transformations Using the JDeveloper XSLT Mapper

While you can access the Test Console for XSLT transformations from JDeveloper, JDeveloper provides its own tester for XSLT transformations that you can access directly from the XSLT Mapper. Custom XPath functions cannot be tested in the mapper.

For information and instructions about running XSLT transformation tests in JDeveloper, see "Testing the Map" in Developing SOA Applications with Oracle SOA Suite.

58.6 Testing XQuery Transformations (Resources)

XQuery uses the structure of XML to express queries across different kinds of data, whether physically stored in XML or viewed as XML. An XQuery transformation can take multiple inputs and returns one output.

The inputs expected by an XQuery transformation are variable values to bind to each of the XQuery external variables defined. The value of an XQuery input variable can be a primitive value (String, integer, date), an XML document, or a sequence of the previous types. The output value can be a primitive value (String, integer, date), an XML document, or a sequence of the previous types.

XQuery is a typed language, which means every external variable is given a type. The types can be categorized into the following groups:

• Simple/primitive type (string, int, float, and so on)

• XML nodes

• Untyped

In the Test Console, all three variables are listed in the Variables section of the Test Console, and you configure their input when performing the test. By default, XML is selected for the untyped variable as it is the most typical case.

58.6.1 XQuery Transformation Testing Prerequisites and Guidelines

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

When performing XQuery testing in the Test Console, use the Back button to execute a new test. However, if you want to execute a new test after making changes to the XQuery, you must close and re-open the Test Console for the changes to take effect.

58.6.2 How to Test XQuery Transformations in the Test Console

XQuery maps can describe XML-to-XML, XML to non-XML, and non-XML to XML mappings. The Test Console does not support sequences on input. 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 runtime, otherwise the testing is done at design time using your local changes.

To test an XQuery transformation using the Test Console:

1. To test the runtime, activate the current session. To test the design time, do not activate the session.
2. Locate the XQuery resource you want to test, and launch the Test Console, as described in Accessing the Test Console..
3. Configure the test data for the resource by entering the XQuery input. The input is based on the external variables, as described below.

   • There is one input field named for each of the XQuery external variables.

   • 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 field is used when the variable is not typed. You must declare the variable type. Select the as XML 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.

4. Click Execute.

   The Test Console displays the results.

5. To retest, click Back. You can close the Test Console, modify, and retest the resource.

58.7 Testing Inline Expressions

You can test expressions in a message flow action from the XQuery/XSLT Expression Editor, the XQuery Condition Editor, and the XPath Expression Editor when you create or modify an expression or condition in the Oracle Service Bus Console.

You can also access the Test Console from the Expression Builders in JDeveloper. Testing takes the same form for both the XQuery/XSLT expression and condition editors, but is slightly different for the XPath Expression Editor.

58.7.1 How to Test XQuery Expressions

You can test XQuery expressions directly from the XQuery/XSLT Expression Editor and the XQuery Condition Editor.

To test XQuery expressions:

1. Create or update the expression in the pipeline action.
2. Do one of the following:

   • In JDeveloper: Click the Test Expression icon.

   • In the Oracle Service Bus Console: Click Validate to make sure the expression is valid, and then click Test.

   The Test Console appears, and displays the expression being tested.

3. Configure the test data for the resource by entering the XQuery input in the Data Inputs section. The input is based on the external variables, as described below.

   • There is one input field named for each of the XQuery external variables.

   • 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 field is used when the variable is not typed. You must declare the variable type. Select the as XML 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 text 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.

4. Click Execute.

   The Test Console displays the results.

5. To retest, click Back. You can close the Test Console, modify, and retest the resource.

   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.

58.7.2 How to Test XPath Expressions

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.

To test an XPath expression:

1. Create or update the XPath expression in the message flow action.
2. When you are done defining the expression, click Validate to make sure the expression is valid.
3. Click Test.

   The Test Console appears, and displays the expression being tested.

4. Configure the test data for the resource by entering the XML input in the Data Inputs section.

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

5. Click Execute.

   The Test Console displays the results.

6. To retest, click Back. You can close the Test Console, modify, and retest the resource.

   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.

58.8 Testing Services With OWSM Security

The Test Console supports testing proxy services and business services protected with OWSM security policies.

When a service has OWSM policies attached, the message exchange between the Test Console and the service is protected by the mechanisms of the policy. According to the policy, the test service digitally signs or encrypts the message (more precisely, parts of the message) and includes any applicable security tokens. You specify the input to the digital signature and encryption operations in the clear-text SOAP envelope specified as described in Request Document Test Console Properties.

If you specify a service key provider in the Test Console, all client-side PKI key-pair credentials required by WS-Security are retrieved from the service key provider. You use the user name and password fields when an operation's request policy specifies an Identity Assertion and Username Token as one of the supported token types.

Table 58-3 and Table 58-4 describe security scenarios.

Table 58-3 Digital Signature and Encryption Scenarios

Scenario	Is Service Key Provider Required?
The request policy has a Confidentiality assertion.	No. The test service encrypts the request with the service's public key. When testing a proxy service, the test service automatically retrieves the public key from the encryption certificate assigned to the service key provider of the proxy service. When testing a business service, the encryption certificate is embedded in the WSDL file of the business service. The test service automatically retrieves this WSDL file from the WSDL repository and extracts the encryption certificate from the WSDL file.
The response policy has a Confidentiality assertion.	Yes. In this scenario, the operation policy requires the client to send its certificate to the service. The service will use the public key from this certificate to encrypt the response to the client. A service key provider must be specified and must have an associated encryption credential. If both request and response encryption are supported, different credentials must be used.
The request policy has an Integrity assertion.	Yes. The client must sign the request. A service key provider must be specified and must have an associated digital signature credential. Furthermore, if this is a SAML holder-of-key integrity assertion, a user name and password is needed in addition to the service key provider.
The response policy has an Integrity assertion.	No. In this case, the policy specifies that the service must sign the response. The service signs the response with its private key. The Test Console simply verifies this signature. When testing a proxy service, this is the private key associated to the service key provider's digital signature credential for the proxy service. When testing a business service, the service signing key-pair is configured in a product-specific way on the system hosting the service. In the case that the current security realm is configured to do a Certificate Lookup and Validation, the certificate that maps to the service key provider must be registered and valid in the certificate lookup and validation framework. For more information on Certificate Lookup and Validation, see ''Configuring the Certificate Lookup and Validation Framework" in Administering Security for Oracle WebLogic Server.

Table 58-4 Identity Policy Scenarios (Assuming that the Policy has an Identity Assertion)

Supported Token Types (From the Identity Assertion inside the request policy)	Description	Comments
UNT	The service only accepts WSS user name tokens	You must specify a user name and password in the Security panel.
X.509	The service only accepts WSS X.509 tokens	You must specify a service key provider in the Security panel and the service key provider must have an associated WSS X.509 credential.
SAML	The service only accepts WSS SAML tokens	You must specify a user name and password in the Security panel or a user name and password in the Transport panel. If both are specified, the one from the Security panel is used as the identity in the SAML token.
UNT, X.509	The service accepts UNT or X.509 tokens	You must specify a user name and password in the Security panel or a service key provider in the Security panel with an associated WSS X.509 credential. If both are specified, only a UNT token is generated.
UNT, SAML	The service accepts UNT or SAML tokens	You must specify a user name and password in the Security panel or a user name and password in the Transport panel. If both are specified, only a UNT token is sent.
X.509, SAML	The service accepts X.509 or SAML tokens	You must specify one of the following: user name and password in the Security panel user name and password in the Transport panel service key provider with an associated WSS X.509 credential
UNT, X.509, SAML	The service accepts UNT, X.509 or SAML tokens	You must specify one of the following: user name and password in the Security panel user name and password in the Transport panel service key provider with an associated WSS X.509 credential

58.8.1 Limitations for Services and Policies

The following limitations exist for testing proxy services with SAML policies and business services with SAML holder-of-key policies:

• Testing proxy services with inbound SAML policies is not supported.

• Testing business services with a SAML holder-of-key policy is a special case. The SAML holder-of-key scenario can be configured in two ways:

  • As an integrity policy (this is the recommended approach)

  • As an identity policy

  In both cases, you must specify a user name and password; the SAML assertion will be on behalf of this user. If SAML holder-of-key is configured as an integrity policy, you must also specify a service key provider. The service key provider must have a digital signature credential assigned to it. This case is special because this is the only case where a user name and password must be specified even if there is not an identity policy.

  Note:

  After executing a test in the Test Console, the envelope generated with WSS is not always a valid envelope; the results page in the Test Console includes white spaces for improved readability. That is, the secured SOAP message is displayed 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.

58.9 About Security and Transports

When using the Test Console to test HTTP business services with basic authentication, the Test Console authenticates the user name and password from the service account of the business service.

Similarly, when testing JMS, email, or FTP business services that require authentication, the Test Console authenticates the service account associated with the business service.

When you test proxy services, the Test Console never sends a HTTP request over the network. Therefore, transport-level access control is not applied.

58.10 Undeploying the Test Console

Oracle recommends that you not use the test framework in production systems. For example, testing pipelines bypasses some important security steps, including access control.

When you create a Service Bus domain, the Configuration Wizard, by default, includes the ALSB Test Framework (Test Console) as a target on the Admin Server and any Managed Servers. The following section describe different options for undeploying the Test Console:

• Untargeting the Test Console Before Domain Creation

• Untargeting the Test Console when the Server is Running

• Untargeting the Test Console when the Server is Not Running

58.10.1 Untargeting the Test Console Before Domain Creation

To untarget the Test Console in the Oracle Fusion Middleware Configuration Wizard before a domain is created:

1. When creating a Service Bus domain with the Configuration Wizard, select the optional configuration for Deployments and Services.
2. In the related wizard pages that follow, for each server, select Service Bus Test Framework in the Targets panel and click the left-facing arrow to move it to the Deployments panel.

When the wizard creates the domain, the Test Console (OSB_ORACLE_HOME\lib\apps\TestFwk.ear) is not deployed.

58.10.2 Untargeting the Test Console when the Server is Running

You can undeploy the Test Console if it has already been deployed to the Service Bus server and the server is already running.

To undeploy the Test Console on a running Service Bus domain:

1. Start the Oracle WebLogic Server Administration Console and log in.
2. In the left navigation pane under Domain Structure, click Deployments.

   The Summary of Deployments page appears.

3. In the Deployments table, click Service Bus Test Framework.

   The Overview page for the Service Bus Test Framework appears.

4. Click the Targets tab.
5. Select the check box next to Service Bus Test Framework in the Target Assignments table to select all the test framework resources.
6. Click Change Targets.
7. On the Target Deployments page, clear the check boxes next to the Admin Server and all Managed Servers.
8. Click Yes.

   A message is displayed indicating that the settings have been successfully updated.

58.10.3 Untargeting the Test Console when the Server is Not Running

If a Service Bus domain is not running, you can use the WebLogic Scripting Tool (WLST) to untarget the Test Console from the domain..

To untarget the Test Console using WLST:

1. If you have not already set up your environment to use WLST, see Main Steps for Using WLST in Interactive or Script Mode in Understanding the WebLogic Scripting Tool.
2. Run the following command to invoke WLST Offline.

   C:>java weblogic.WLST
   

   Note:

   You must have your environment set up properly for this command. Depending on your operating system, run setWLSEnv.cmd or setWLSEnv.sh from WL_HOME/server/bin.

3. To read the domain that was created using the Configuration Wizard, run the following command:

   wls:/offline>readDomain('C:/oracle/user_projects/domains/domain_name')
   

4. To untarget the Service Bus Test Framework application, run the following command:

   wls:/offline/domain_name>unassign("AppDeployment", "Service Bus Test Framework", "Target", "AdminServer", "ManagedServer_1", "ManagedServer_2")
   

   Include the names of all managed servers in the command.

5. To update the domain, run the following command:

   wls:/offline/base_domain>updateDomain()
   

6. To close the domain, run the following command:

   wls:/offline/base_domain>closeDomain()
   

7. Run the following command to exit from the WLST command prompt:

   wls:/offline>exit()
   

58.11 Test Console Page Reference for Services

This section describes each section displayed on the Oracle Service Bus Test Console when you test a Service Bus service. Not all sections are displayed for all components, and some sections vary depending on the component being tested.

The Test Console request page includes a combination of the following sections, depending on the type of service you are testing and the type of messaging it uses:

• Test Configuration Test Console Properties

• Service Operation Test Console Properties

• Request Document Test Console Properties

• Security Test Console Properties

• Authentication Test Console Properties

• Transport Test Console Properties

• Attachment Test Console Properties

58.11.1 Test Configuration Test Console Properties

This section only appears when testing pipelines, and it includes one field: Include Tracing. Select this check box to include a trace of the state of the message at each stage of processing.

58.11.2 Service Operation Test Console Properties

This section appears when the proxy service, business service, pipeline, or split-join being tested is based on a WSDL file with operations and when testing a RESTful proxy or business service. The fields that appear in this section vary depending on whether the service is WSDL-based or RESTful, and whether you select the SOAP or REST view for a RESTful business service.

For RESTful business services, the REST view displays information as a pure REST service. The SOAP view displays information as the caller (pipeline) would see the data (that is, wrapped as a WSDL SOAP service). The fields for the SOAP view are the same as those for a WSDL-based service.

Table 58-5 Test Console Properties- Service Operation

Property	Description
Operation	Select the WSDL operation to test from the list of operations associated with the service. This field is available for WSDL-based services and on the SOAP view for RESTful business services.
Resource	Select an existing URL resource path from the list. A resource is any source of specific information that can be addressed. This field is only available when testing RESTful services.
Method	Select the REST operation to perform. This field is only available when testing RESTful services.
Accept	Select the accepted media type for the test input from the list of options. Options vary depending on the service configuration. This field is only available when testing RESTful services.

58.11.3 Request Document Test Console Properties

The input fields generate the request message that is sent to the proxy service, business service, pipeline, or split-join. The values you enter in the Request Document section are service-type specific. The service types and a description of the input required by each are listed below.

The Invocation Mode option is only displayed when testing any SOAP or any XML proxy service. Clear the Request/Response check box for one-way service invocations. Select the check box for request/response invocations.

Table 58-6 Test Console Properties - Request Document

Service Type	Description
WSDL	If the 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. Use this sample data directly, edit it, and then run the test, or provide your own test data.
Any XML	Enter the request 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 directly in the text box.
Any SOAP	Enter the request 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	Enter a single input, either file-based or text-based. Messaging services define several different input types, including Binary, Java, MFL, XML, and text. For the type none, no input is required. 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 specifies 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.
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 Test Console uses the WSDL file 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.
REST	The input for a RESTful service varies depending on the resource being tested and whether you are using the SOAP view or the REST view. In the SOAP view, enter the request input in the form of a payload. The payload is the content of the message being sent. Click Browse to navigate to and select a file or enter the message content in the text box. In the REST view, the request input can be in the form of REST parameters or in the form of a payload. If parameter fields are displayed, enter the input for each parameter. If the Payload field is displayed, select the media type from the list of options, and then click Browse to navigate to and select a file or enter the message content in the text box

58.11.4 Security Test Console Properties

If the service being tested is secured using OWSM policies, the Security panel appears on the test console. You can modify override values and add or remove security policies. To test with additional policies, click the Add button and select the policies to test. For more information, see Securing Oracle Service Bus with Oracle Web Services Manager.

Table 58-7 Test Console Properties - Security

Property	Description
Policy Name	Displays the name of the OWSM policies attached to the service being tested.
Property	Displays the name of each available override property for the listed policies. The available properties vary based on the policies that are attached.
Default Value	Displays the default value, if any, for each override property.
Override Value	Enter the value you want to use for the override property when testing the service.
Actions	Click the Delete icon in this column to remove an attached policy for testing purposes.

58.11.5 Authentication Test Console Properties

If the service being tested 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.

Table 58-8 Test Console Properties - Authentication

Property	Description
Username	Enter the user name for setting the security context used by the test service when invoking the service. Do not confuse this field with the Web Services Security (WSS) user name 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	Enter password associated with the user name.
Service Key Provider	Enter the service key provider to use for authentication. This field is used when testing an HTTPS business service with client certificate authentication. The service provider must have an associated SSL client credential. The test service will use that credential during the SSL handshake.

58.11.6 Transport Test Console Properties

Use the Transport panel in the Test Console to specify the metadata and transport headers for messages in your test system. The following sections describe the transport settings and how they affect processing:

• Test Console Transport Settings

• How the Runtime Uses the Transport Settings in the Test Console

58.11.6.1 Test Console Transport Settings

The Transport section of the Test Console varies depending on the type of transport being tested.Figure 58-4 shows the Transport section for a WSDL-based proxy service.

Figure 58-4 Transport Panel in the Test Console

Description of "Figure 58-4 Transport Panel in the Test Console"

By setting the metadata and the transport headers in the pipeline, you influence the actions of the outbound transport. You can test the metadata, the message, and the headers so that you can view the pipeline output. The fields that are displayed in the Transport panel when testing a proxy service represent those headers and metadata that are available in the pipeline. The Test Console cannot filter the fields it displays depending on the proxy service. The same set of transport parameters are displayed for every HTTP-based request.

The Username and Password fields are used to implement basic authentication for the user that is running the proxy service. The Username and Password fields are not specifically transport related.

Metadata fields are located below the Username and Password fields and above the transport header fields. The fields displayed are based on the transport type of the service. Certain fields are pre-populated depending on the operation selection algorithm you selected for the service when you defined it. For more information about the selection algorithms, see Modeling Message Flow in Oracle Service Bus.

Specify the values in the Transport panel fields according to the type of service being tested. When testing a pipeline or split-join, the test data should represent the message in the state expected at the point it leaves the caller and enters the service being tested. When testing a business service, the test data represents the data that is sent from a route node or a service callout.

The following properties are common for most transport types. For information about specific headers and metadata and how they are handled by the test framework, see How the Runtime Uses the Transport Settings in the Test Console..

Table 58-9 Test Console Properties - Transport

Property	Description
Username	Enter a user name to implement basic authentication for the user that is running the test. This is not transport-specific.
Password	Enter the password for the user name entered above.
Request/Response	Clear the Request/Response check box for one-way service invocations. Select the check box for request/response invocations. This option is only displayed when testing any SOAP or any XML proxy service.
Service Key Provider	Enter the service key provider to use for authentication. This field is used when testing an HTTPS business service with client certificate authentication. The service provider must have an associated SSL client credential. The test service will use that credential during the SSL handshake.

58.11.6.2 How the Runtime Uses the Transport Settings in the Test Console

Transport Test Console Properties describes 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 runtime. That is, the values of certain headers or metadata are overwritten, or ignored by Service Bus at runtime when the test is executed. The headers and metadata for which there are limitations are described in Table 58-10.

Table 58-10 Limitations to Transport Header and Metadata Values You Specify in the Test Console

Transport	Service Type	Description of Limitation	Transport Headers Affected
HTTP(S) Note: When you test proxy services, the Test Console never sends a HTTP request over the network, therefore transport-level access control is not applied.	Proxy Services	All transport headers and other fields you set are preserved at runtime.	All
HTTP(S)	Business Services	The Service Bus runtime overrides any values you set for these parameters.	Content-Length Content-Type relative-URI client-host client-address
JMS	Proxy Services	The same limitations apply as those for a transport header action configuration.	See the limitations for JMS transport headers described in Table 12-8.
JMS	Business Services	The same limitations apply as those for a transport header action configuration.	See the limitations for JMS transport headers described in Table 12-8.
email	Proxy Services	No limitations. Any transport headers and other fields you set are honored at runtime.	None
email	Business Services	The Service Bus runtime 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 runtime. For example, FileName (Transport metadata)—the value you assign is appended to the output file name. For example, 1698922710078805308-b3fc544.1073968e0ab.-7e8e-{$FileName}.	None
File	Business Services	No limitations	None
FTP	Proxy Services	No limitations. Any transport headers and other fields you set are honored at runtime.	None
FTP	Business Services	No limitations	None

58.11.7 Attachment Test Console Properties

Use the Attachment section of the Test Console to include attachments as part of the test input. Table 58-11 described the properties in this section.

Table 58-11 Proxy Service Test Console Properties

Property	Description
Content-Type	Enter globally unique reference that identifies the attachment.
Content-ID	Enter the media type and sub-type of the attachment.
Content-Description	Enter brief description of the content.
Content-Disposition	Specify how the attachment should be handled by the proxy service.
Content-Transfer-Encoding	Specify how the attachment is encoded.
File	Browse to and select the file to test as an attachment.
Resp. Attach. Display Limit	The number of characters of the attachment to include in the display of the test results.