Configuring Proxy Services Test Data

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

Table 30-1 Proxy Services Configuration Options 
Section
Options/Fields
Description
Name
The name of the proxy service being tested.
Available Operations
Operations associated with the proxy service.
Test Console Actions
Execute
Run the test.
Reset
Reset the input values.
Close
Close the test console and do not run the test.
Test Configuration
Set the testing configuration options.
Direct Call
Send a message to the proxy service without using the ALSB transport layer. The input data to the test console must be that which is sent from the client to the proxy service.
The opposite of the direct call is an indirect call. It can be invoked by clearing the Direct Call option. It is performed by default for business services. The indirect call sends messages through the transport layer. In this case, the input data to the test console must be that which is being sent from a proxy service to the invoked service.
Include Tracing
Tracing shows the state of the message as it passes through the system.
Request Document
The input fields generate the request message that is sent to the proxy service. Click Execute to run the test with the values you entered. The test console displays the request message and the service's response message and metadata.
Input in the Request Document section is service-type specific. The service types and a description of the input required by each are listed in the following sections.
any XML
The service requests input in the form of a payload.The payload is the content of the message being sent. The content is expected to be an XML document. You can browse to a file or enter the message content in the text box.
Request Document continued
any SOAP
The service requests input in the form of a payload. The payload is the content of the message being sent. The content is expected to be the SOAP envelope. You can browse to a file or enter the message content in the text box.
Messaging
Messaging services define four possible input types: none, XML, Binary or Text. The service requests a single input-either file-based or text-based, except for the type none that does not require any input.
BEA recommends entering binary input from a file. Data entered in the text area is converted to binary input using the system encoding.
Data entered from files for text services must be converted to text. The encoding input field is used to specify the encoding to apply during the conversion. The system encoding is used if this field is not configured. By default, the encoding field is initialized with the encoding value configured on the proxy service endpoint.
XML
The service requests input in the form of a payload.The payload is the content of the message being sent. The content is expected to be an XML document. You can browse to a file or enter the message content in the text box.
If your proxy service is a WSDL-based service with multiple operations defined, the test console generates and provides a sample document to use when testing the service. You can use this sample data directly, edit it and then run the test, or provide your own test data.
All operations are listed at the top of the page.
Request Document continued
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.
Request Document continued
SOAP RPC
For SOAP RPC, the SOAP envelope is composed of zero or more headers, and zero or more arguments.
The Form and XML tabs provide alternative ways to specify the content.
The Form tab contains a single input for SOAP headers, and one input field for each argument (the name of the input field corresponds to the name of the argument). The content of the SOAP Header field is expected to be a SOAP Header tag (this allows for the definition of more than one header).
The WSDL is used to detect the type of each argument. A single-line input field is used for primitive types; a multi-line input field is used for XML types. A sample document is automatically generated to facilitate testing.
The headers and arguments are used by the test console to generate the SOAP envelope.
The XML tab contains a single input field. The content of this field is expected to be the SOAP envelope being sent. The payload (XML input) can be file-based or text-based. Referencing a file for input takes precedence over textual input. Browse and select the file you want to use in your test.
Web Service Security
This section is available only for SOAP services when the selected operation has a Web Service Security (WSS) policy.
Service Provider
The test service gets all client-side PKI (key-pair) credentials for Web Service security operations (digital signature and encryption) from this service provider. This field is optional. Certain scenarios require a service provider, depending on the request/response policy for the operation. For more information, see "Testing Services with Web Service Security" in Using the Test Console in the AquaLogic Service Bus User Guide.
Username
The user name in Web Service security username tokens generated from the test service. This field is optional. This user name is only needed in some scenarios where the operation's request policy specifies an identity assertion.
Do not confuse this field with the transport security context username field.
This must be a valid user name and password in the local security realm. An invalid user name or invalid password causes a client-side error on the test service.
Password
The password in Web Service security user name tokens generated from the test service.
Transport
The Transport section is collapsed by default. The fields and values depend on the test configuration.
Authentication
Username
The user name for setting the security context used by the test service when invoking the proxy service.
If the proxy service routes the message to a business service that expects a SAML token, this is the identity that will be represented by the token. For more information, see Using SAML for Authentication in the AquaLogic Service Bus Security Guide.
Do not confuse this field with the Web Service Security (WSS) username field. This must be a valid user name and password in the local security realm. An invalid user name or invalid password will cause a client-side error on the test service.
Note: When the test console invokes a proxy with HTTP custom token authentication, the authentication check is not done.
Password
The associated password. For more information, see Username.
Invocation Mode
Request/Response
This option is only displayed when testing any SOAP or any XML proxy service. Clear the Request/Response check box for one-way service invocations.
Message Metadata
Transport Headers

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