The BEA AquaLogic Service Bus Test Console is a browser-based test environment used to validate and test the design of your system. It is an extension of the AquaLogic Service Bus Console. You can configure the object of your test (proxy service, business service, XQuery, XSLT, MFL resource), execute the test, and view the results in the console. In some instances 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 test console can test specific parts of your system in isolation and it can test your system as a unit.
You can run and test a proxy service that makes a call to another proxy service or business service and vice versa. You can test the resources used by your services. When testing services you must be aware of the information that is passing from the test console to the service and vice versa.
A Direct Call is used to test a proxy service that is collocated in the AquaLogic Service Bus domain. Using the Direct Call option, messages are sent directly to the proxy service, bypassing the transport layer. When you employ the Direct Call option, tracing is turned on by default, allowing you to diagnose and troubleshoot a message flow in the test console. By default, testing of proxy services is done using the Direct Call option.
When you use the Direct Call option to test a proxy service, the configuration data you input to the test console must be that which is expected by the proxy service from the client that invokes it. In other words, the test console plays the role of the client invoking the proxy service.
A Direct Call strategy is best suited for testing proxy services' internal message flow logic. Your test data should simulate the expected message state at the time it is dispatched. Use this test approach in conjunction with setting custom (inbound) transport headers in the test console's Transport section to accurately simulate the service call.
When you test a proxy service with an indirect call (that is, when the Direct Call option is not checked), 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 effect is to invoke a proxy service to proxy service invocation run-time path.
This testing strategy is recommended when testing a proxy service to proxy service interface when both services run in the same JVM. Use this test approach in conjunction with setting custom (outbound) transport headers in the test console's Transport panel to accurately simulate the service call. To learn more about the Transport settings in the test console, see Test Console Transport Settings.
Using the indirect call, the configuration data you input to the test is the data being sent from a proxy service (for example from a Route Node or a Service Callout action of another proxy service). In the indirect call scenario, the test console plays the role of the proxy service that routes to, or makes a callout to, another service.
(This transport-level access control is achieved through the Web Application layer—in other words, even in the case that an indirect call is made through the AquaLogic Service Bus Console transport layer, an HTTP request is not sent over the network and this transport-level access control is not applied.) For information about the AquaLogic Service Bus Console architecture, see Overview in BEA AquaLogic Service Bus Concepts and Architecture.
For information about transport settings, see Understanding How the Run Time Uses the Transport Settings in the Test Console.
When testing business services, the messages are always routed through the transport layer. The Direct Calls option is not available. The configuration data that you provide to the test console to test the service is that which represents the state of the message that is expected to be sent to that business service—for example from a Route Node or a Service Callout action of a proxy service. The test console is in the role of the caller proxy service when you use it to test a business service.
When using the test console to test HTTP(S) business services with BASIC authentication, the test console authenticates with the username/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 with the service account associated with the business service.
In the scenario depicted in the following figure, a client invokes the proxy service (P1). The message flow invokes business service B1, then proxy service P2, then proxy service P3 before returning a message to the client. Interfaces are identified by number.
Tracing the message through a proxy service 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 AquaLogic Service Bus. AquaLogic Service Bus defines tracing for stages, error handlers and route nodes.
outboundvariable, the value of the
attachmentvariables for both the request and response messages.
To learn how to start the example domain and run the examples provided there, see BEA WebLogic Service Bus Samples. This example scenario uses the proxy service named
loanGateway3, associated with the Validating a Loan Application example.
The message flow for
loanGateway3 is represented in the following figure. The figure is annotated with the configuration for the validate loan application stage and the configuration for the route node.
LoanGateway3proxy service. The
LoanGateway3page is displayed. Note that the Direct Call and the Include Tracing options are selected.
Compare the output in the trace with the nodes in the message flow shown in Figure 4-4.
$inboundchanged as a result of the processing of the message through the
applicationstage. These changes are seen at the end of the message flow.
faultcontext variable (
$fault) is shown as a result of the Stage Error Handler handling the validation error. (The non-integer value (20.5) you entered for the <java:NumOfYear> element in Listing 4-1 caused the validation error in this case.)
For more information about this loan application scenario, see Tutorial 3: Validating a Loan Application in BEA AquaLogic Service Bus Tutorials.
It is left as an exercise to the reader to test the service using different input parameters, or to change the behavior of the message flow in the AquaLogic Service Bus Console Project Explorer, and run the test again to view the results.
The following example describes an XML input file to be tested in the test console. When you invoke the test console to test the MFL file, sample XML data is generated. Execute the test using the sample XML—in this case, a successful test results in the transformation of the message content of the input XML document in to binary format. The following Example section describes the MFL, the test XML, and the data resulting from the test.
The XML input generated by the test console to test the MFL file in the Listing 4-2 is described in the following listing.
eXtensible Stylesheet Language Transformation (XSLT) describes XML-to-XML mappings in AquaLogic Service Bus. You can use XSL Transformations when you edit XQuery expressions in the message flow of proxy services
To test an XSLT resource, you must supply an input XML document. The test console displays the output XML document as a result of the test. You can create parameters in your document to assist with a transformation. XSLT parameters accept either primitive values or XML document values. You cannot identify the types of parameters from the XSL transformation. In the Input and parameters section of the XSLT Resource Testing page in the test console, you must provide the values to bind to the XSLT parameters defined in your document.
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 primitive value (string, integer, date), an XML document, a sequence of the previous types.
In the test console, a single-line edit box is displayed if the expected type is a simple type. A multiple-line edit box is displayed if the expected data is XML. A combination input is used when the variable is not typed. The test console provides the following field in which you can declare the variable type:
 as XML. Input in the test console is rendered based on the type. This makes it easy to understand the type of data you must enter.
You must disable the pop-up blockers in your browser for the inline XQuery testing to work. Note that if you have toolbars in the Internet Explorer browser, you may need to disable pop-up blockers from under the browser's Options menu as well as for all toolbars that are configured to block them.
When performing in-line XQuery testing with the test console, you can use the Back button to return to the page from where you can execute a new test. But if you want to execute a new test after making changes to the in-line XQuery, you must close and re-open the test console for the changes to take effect.
The test console supports testing proxy services and business services protected with Web Service Security (WSS). A SOAP service is protected with WSS if it has WS-Policies with WS-Security assertions assigned to it. Specifically, a service operation is protected with WS-Security if the operation's effective request and/or response WS-Policy includes WS-Security assertions. WS-Policies are assigned to a service by a mechanism called WS-PolicyAttachment. See Web Services Policy Attachment. Note that an operation may have both a request policy and a response policy.
When an operation has a request WS-Policy or response WS-Policy, the message exchange between the test console and the service is protected by the mechanisms of WS-Security. According to the operation's policy, the test service digitally signs and/or encrypts the message (more precisely, parts of the message) and includes any applicable security tokens. The input to the digital signature and encryption operations is the clear-text SOAP envelope specified by the user as described in "Configuring Proxy Service Test Data" and "Configuring Business Service Test Data" in Test Console in the BEA AquaLogic Service Bus User Guide.
Similarly, the service processes the response according to the operation's response policy. The response may be encrypted or digitally signed. The test service then processes this response and decrypts the message and/or verifies the digital signature.
If you specify a proxy service provider in the test console, all client-side PKI key-pair credentials required by WS-Security are retrieved from the proxy service provider. For more information, see Proxy Service Providers. You use the username and password fields when an operation's request policy specifies an Identity assertion and Username Token is one of the supported token types. For more information, see Web Service Policy.
The Service Provider, Username, and Password fields are displayed whenever the operation has a request or response policy. Whether the values are required depends on the actual request and response policies.
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 proxy service provider of the proxy service.
When testing a business service, the encryption certificate is embedded in the WSDL of the business service. The test service automatically retrieves this WSDL from the WSDL repository and extracts the encryption certificate from the WSDL.
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 proxy service provider must be specified and must have an associated encryption credential.
If both request and response encryption are supported, different credentials must be used. For more information, see Client Request and Proxy Service Response and About Outbound Web Services Security.
In the case that the current security realm is configured to do Certificate Lookup and Validation, then the certificate that maps to the proxy service provider must be registered valid in the certificate lookup and validation framework.
For more information on Certificate Lookup and Validation, see ''Configuring the Credential Lookup and Validation Framework" in Configuring WebLogic Security Providers in Securing WebLogic Server.
Supported Token Types1
The user must specify a username and password in the security section or a username and password in the transport section. If both are specified, the one from the security section is used as the identity in the SAML token.
The user must specify a username and password in the security section or a proxy service provider in the security section with an associated WSS X.509 credential. If both are specified, only a UNT token is generated.
In both cases the user must specify a username and password—the SAML assertion will be on behalf of this user. If SAML holder-of-key is configured as an integrity policy, the user must also specify a proxy service provider. The proxy service provider must have a digital signature credential assigned to it. This case is special because this is the only case where a username 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 printed with extra white spaces. Because white spaces can affect the semantic 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.
The transport panel in the test console provides the functionality to specify the metadata and transport headers for messages in your test system. The following figure shows an example of a Transport panel on the test console.
You can set the metadata and the transport headers in the message flow of a proxy service. In doing this, you influence the actions of the outbound transport. You can test the metadata, the message, and the headers so that you can see the output you get in the pipeline. 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 presents depending on the proxy service. The same set of transport parameters are displayed on the page for every HTTP-based request.
Metadata fields are grouped in the Transport panel, below the Username and Password fields and above the group of transport header fields. The fields displayed are based on the transport type of the service. Certain fields are pre populated in the test console depending on the operation selection algorithm you selected for the service when you defined it.
For example, in the case of the transport panel displayed in Figure 4-9, the
SOAPAction header field is populated with "
http://example.orgprocessLoanApp". This value was taken from the service definition (the selection algorithm selected for this proxy service was
SOAPAction Header). For more information about the selection algorithms, see "Adding a Proxy Service" in Proxy Services in Using the AquaLogic Service Bus Console.
When you specify values for fields in the transport panel, be aware whether you opted to test the service using a direct or indirect call—see Direct Calls and Indirect Calls—and specify the values according to whether the message will be processed through the transport layer or not.
When testing a proxy service with a direct call, the test data must represent the message as if it had been processed through the transport layer. That is, the test data should represent the message in the state expected at the point it leaves the transport layer and enters the service. When testing a proxy or business service, using an indirect call, the test data represents the data that is sent from a route node or a service callout. The test message is processed through the transport layer.
For information about specific headers and metadata and how they are handled by the test framework, see Understanding How the Run Time Uses the Transport Settings in the Test Console.
The test console allows you to specify header values and metadata. However, when the message is sent out, some headers and metadata may be modified or removed, and the underlying transport may in turn, ignore some of the headers and use its own values when the test is executed.
See the limitations for JMS transport headers described in "Transport Headers" in Proxy Services: Actions in Using the AquaLogic Service Bus Console.
See the limitations for JMS transport headers described in "Transport Headers" in Proxy Services: Actions in Using the AquaLogic Service Bus Console.
No limitations. In other words, any transport headers and other fields you set are honored by the run time.2