These pages present the XML contents of the call and provide access to data correlation in three different forms
In the Form view, add the XML headers that are required for standard
web service calls. On the Header bar, click Add () to create the default
XML header structure for WS-Addressing, WS-ReliableMessaging or WS-Coordination
requests, or click More for other standards.
You can enable or disable XML header elements and specify the correct
values for each XML element. Checks are performed to ensure that the
XML content is valid.
This view provides a hierarchical view of the XML structure of the message, including elements, namespaces, and the associated values. You can use Add, Insert, Remove, Up, and Down to edit the XML elements and namespaces in the tree.
Click Filter to hide or show namespace, attribute, or text nodes, depending on your requirements.
Click Allow only valid modifications to enable smart editing, based on a specified XML schema document (XSD). To specify a set of XSD documents for the workbench, in the test navigator, right-click the project and select Properties and Schema Catalog. Disable Allow only valid modifications if you do not have an XSD or if you want to bypass the schema.
You can right-click an XML element to convert it to an XML fragment. This enables you to perform data correlation (use datapools and create references) on the entire XML fragment instead of only on the value.
This page lists the MIME attachments that are attached to the call. The contents of this view correspond to the specification of Multipurpose Internet Mail Extensions (MIME). You can use this page to add workbench resources as MIME attachments and change properties.
The Content ID is the identifier that the call uses to refer to the attachments. The method for using this identifier depends on your server requirements.
This page covers the protocol that is used to send the call. The protocol can be either HTTP or Java™ Message Service (JMS) on a message-by-message basis.
This option enables you to specify either HTTP 1.0 or HTTP 1.1.
This field enables you to specify the URL of the XML call.
This section enables you to add headers to your call. Headers must be compatible with the specified HTTP method.
This section enables you to manage cookies. You can add, edit and remove cookies, and create references.
This page enables you to add string properties that are attached to the call for a local JMS configuration. These will be sent as message properties through JMS.
This page enables you to override settings that are attached to the call for a local WebSphere® MQ configuration.
The calls and message returns are associated by the correlation ID in the MQ message, which means that the report setting of the message is set to MQC.MQRO_COPY_MSG_ID_TO_CORREL_ID. The server must follow this constraint. This supports the transport for SOAP feature provided by WebSphere MQ.
If the Web Services Description Language (WSDL) that is used to create the message call uses a supported JMS URI to point to the WebSphere MQ server, then the SSL configuration is created automatically. If the test generator was unable to create the SSL configuration, you must create a new one manually.
If the WSDL was generated with the WebSphere MQ service (amqwdeployWMService), edit the WSDL to change the transport binding from HTTP to JMS in order to prevent the test generator to produce an HTTP configuration.
This page allows you to add a custom security algorithm that is implemented in a Java class. Custom algorithms can be applied to the XML contents that are sent to and received from the server.
After adding a custom security algorithm to the stack. With this window, you can specify the Java class that implements the algorithm. The Java class uses the following interface:
/**
* ***************************************************************
* IBM Confidential
*
* (c) Copyright IBM Corporation. 2008. All Rights Reserved.
*
* The source code for this program is not published or otherwise
* divested of its trade secrets, irrespective of what has been
* deposited with the U.S. Copyright Office.
* ***************************************************************
*
*/
package com.ibm.rational.test.lt.models.wscore.datamodel.security.xmlsec;
import java.util.Properties;
import org.w3c.dom.Document;
public interface ICustomSecurityAlgorithm {
/**
* The following methods can be used in both case:
* Execution in the workbench and execution of the test.
*/
/**
* Called to process de Document that is sent over a transport.
* @param subject
*/
void process(Document subject);
/**
* Called to un process a document that is received from a server.
* @param subject
*/
void unProcess(Document subject);
/**
* Properties defined in the UI of the CustomSecurityAlgorithm.
* @param map
*/
void setProperties(Properties map);
/**
* The following methods can only be used in terms of cast to test service interface,
* or in terms of access to the previous XML information, when the jar containing
* the custom security algorithm is deployed in the performance test project. In
* this case you cannot use the algorimth directly from the workbench.
*/
/**
* This object corresponds to the ITestExecutionService object.
* This applies only to an algorithm that must link to the execution of the test.
* If you plan to use this object you will need to deploy the jar containing the
* implementation into your performance test project and not directly into the JRE.
*
* In case of a need of the previous xml document received from the execution you can
* obtain the value using:
* IDataArea area = ((ITestExecutionService)executionObject).findDataArea(IDataArea.VIRTUALUSER);
*String previousXML = (String) area.get("PREVIOUS_XML"); //$NON-NLS-1$
*
*/
void setExecutionContext(Object executionObject);