...

In this section: 

...

Primary Connection (outgoing) & Secondary Connection (outgoing)

Options

Mode: Allows you to set the active forwarding connection when a primary and secondary connection exist. For example, during a recording session, a message proxy may forward to the live service as the primary connection and fall back to a virtual service as a secondary connection. In this case, you can set the HTTP mode to Primary and enable Use other connection if selected mode fails.

...

If this option is not enabled, the active connection will be used for recording.

If this option is enabled, select a recording option from the Record dropdownmenu:

• Both connections: Records traffic for both the primary and secondary connections. Error messages from the active connection will not be recorded; instead, the messages will be sent to the backup connection and the responses will be recorded. Errors reported by the backup will be recorded.
• Primary connection only: Records traffic for the active connection. Does not record errors.
• Secondary connection only: Records traffic for the backup connection, including errors.

...

The Service SSL section needs to be completed only completed only if the service you are working with uses SSL.

If the service the service being virtualized  uses virtualized uses SSL and/or other authentication (basic/digest, Kerberos, NTLM), additional configuration may be required.For details on completing the Service SSL fields immediately below these fields, see Security Configuration.

...

You can specify a server for the message proxy in this tab, which enables you to configure a different proxy server for traffic to and from different message proxies. This configuration provides control over which proxy server handles traffic between the application under test and a specific message proxy. 

To specify proxy settings at this level, provide the appropriate details in the proxy’s Proxy Server tab. 

...

You can use wildcard characters to specify dynamic path segments. For example, configuring the path as as /path/*/service would enable the following paths to go to the same proxy: 

...

1. Set the service host and port to that of the Virtualize Server where the virtual asset is deployed. If you want the proxy to forward to a virtual asset on the local server without consuming an HTTP connection, enter, host.virt.internal, localhost, or 127.0.0.1 rather than the actual hostname. When using localhost or 127.0.0.1, the service port must match the port Virtualize is deployed on; when using host.virt.internal, the service port is not used.
2. Set the proxy connection’s Service forward path to the virtual asset’s path (found in the virtual asset’s Transports> Transports > HTTP tab, under HTTP endpoint).
   

...

1. Create a plain text file and specify the properties you want to set (see Reverse Proxy HTTP Listener Message Proxy Performance Properties and Reverse Proxy HTTP Listener Message Proxy SSL Properties). 

2. Save the file to the VirtualAssets directory in your workspace the VirtualAssets directory in your workspace and name it it "embeddedServer.properties".

The file will be read every time a proxy with a Reverse Proxy HTTP Listener is enabled.

...

Reverse Proxy HTTP Listener Message Proxy Performance Properties

...

Reverse Proxy HTTP Listener Message Proxy SSL Properties

Example: Sending Traffic to a Service

Assume that we want to create a message for a service that is normally accessed at http://example.parasoft.com:9080/BookStore. We could create an HTTP Reverse proxy with the settings: 

• Proxy listen path: /BookStore
• Service host: example.parasoft.com
• Service port: 9080
• Service forward path: [empty]
  

This configuration will listen on /BookStore and forward all traffic to the actual book store bookstore service.

If we wanted to listen on a path other than the service path, we would change the configuration of the proxy as follows:

...

This would route traffic from /SomeOtherPath on the proxy to the actual book store bookstore service. 

In both cases, all traffic that goes to those paths (including sub paths) is sent to the service. In the second example, traffic sent to /SomeOtherPath/SubPath would be sent to /BookStore/SubPath. Because queries are preserved, /SomeOtherPath?param=value would be sent to /BookStore?param=value.

Forwarding Requests to Services that Require Case-sensitive Header Names

If you are using the desktop's server, your message proxy headers will be lowercased and may fail to function properly when requests are forwarded to a service that requires case-sensitive HTTP header names.

You can create a _global.headers file in the /VirtualAssets/ directory and add the headers using the specific capitalization you want to pass. Right-click the server in the UI and re-deploy all virtual assets to begin using this file in your environment.

You can also address HTTP header capitalization issues for specific message proxies. Create a <proxy<PROXY-name>NAME>.headers file in the /VirtualAssets/ directory and add the headers using the specific capitalization you want to pass for the specific proxy. This file will apply to specific proxy and override the global file. Right-click the server in the UI and re-deploy all virtual assets to begin using this file in your environment.

...

X-AUTHORIZATION
ANOTHER-HEADER
HEADER3

Example: Sending Traffic to a Virtual Asset

A proxy can also send traffic to a virtual asset. In that case, enter the host and port information for the Virtualize Server as if were just another service.

...

• Proxy listen path: /proxyPath
• Service host: server.parasoft.com
• Service port: 9080
• Service forward path: /assetPath
  

...

Anchor
Proxy-level Configuration Proxy-level Configuration

Proxy-level Configuration

Proxy-level security configuration—which configuration, which is relevant if the service to which you are forwarding the traffic uses SSL and/or access authentication—coversauthentication, covers:

• SSL
• Basic/Digest Authentication
• NTLM Authentication
• Kerberos Authentication

...

For SSL, additional settings are required. In the lower part of the configuration panel, you need to specify whether to:

• Enable trust for self-signed certificates.
• Enable trust for all certificatecertificates.
• Set a trust store to validate server certificates.

Additionally, you need to provide the information needed to use a specific key store and certificate so Parasoft can determine which certificate to present to a server (e.g.for example, for 2-way SSL).

SSL Configuration Panel Fields

Note that the Truststore configuration (described below) is applicable only if Trust all server certificates and Accept self-signed certificates are both unselecteddisabled.

Keystore Configuration Panel Fields

After completing the keystore detail, click the Load and choose the certificate alias to present to the server from the Certificate drop-down menu. If the Certificate dropdown menu is not populated when you click Load, you may have entered the incorrect password or keystore type.

Truststore Configuration Panel Fields

These fields are applicable only if Trust all and Accept self-signed certificates (described above) are both unselecteddisabled.

NTLM Settings Panel Fields

Kerberos Panel Fields

Anchor
Authentication Authentication

Basic/Digest Authentication

...

Server-level Configuration

Server-level security configuration—which configuration, which is relevant if the AUT uses SSL and/or access authentication—can authentication, can involve:

• Configuring the Virtualize Server
• Using NTLM with WAFFLE
• Using Unsupported Configurations (Kerberos with WAFFLE, JAAS)

...

You can change the default port number (9080), enable SSL, and configure other server settings. See Configuring Virtualize Server for details. 

Anchor
Using NTLM with WAFFLE Using NTLM with WAFFLE

Using NTLM with WAFFLE

...

1. Copy the following jar files into tomcat's lib directory: jna.jar, platform.jar, wafflejna.jar.

2. Add the following to the server.xml file in the tomcat/conf/server directory.xml.

   Code Block
   <Context> <Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both"/> <Realm className="waffle.apache.WindowsRealm" /> </Context>

   Info
   title Where is server.xml?
   If you installed SOAtest but not Virtualize: Launch SOAtest, ensure that at least one responder has been created, then modify the server.xml file at <INSTALL><INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml If you installed Virtualize but not SOAtest: Launch Virtualize, ensure that at least one responder has been created, then modify the server.xml file at <INSTALL><INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml If you installed Virtualize and SOAtest together: Launch Virtualize, ensure that at least one responder has been created, then modify the server.xml file at <INSTALL><INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml

3. Add the following to the web.xml file in the tomcat/conf/web.xml directory.

   Code Block
   <security-role> <role-name>Everyone</role-name> </security-role> <security-constraint> <display-name>Waffle Security Constraint</display-name> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>Everyone</role-name> </auth-constraint> </security-constraint>

4. Restart the server.

...