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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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
   

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. Click the Control tab.
4. In the Deployments table, click Service Bus Test Framework.

   The Overview page for the Service Bus Test Framework appears.

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

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

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()