...
| Forward proxy | You can choose a Forward Proxy HTTP Listener that you defined when creating the proxy (see Creating Proxies) from the drop-down menu or add a new Forward Proxy HTTP Listener. To add Forward Proxy HTTP Listeners from this dialog:
|
|---|---|
| Host | Enter the host name of the service whose traffic you want to monitor. This determines which hosts are recorded, sent to the live service, or sent to a virtual asset. To allow monitoring for all traffic, select "choose [All]" from the drop-down menu. |
| Path | Enter a path that you want to monitor on the resource. This works in conjunction with what has been entered in the Host field to match incoming requests. Wild cards are not allowed. To match all paths on the host, leave this field blank or select "choose [All]" from the drop-down menu. In the event that there are multiple proxy connections configured that could match to an incoming request, the one with the combination of best host match and longest matching path is selected, with the host match being the more heavily weighted factor. For example, suppose there was an incoming target URL of "
In such a situation like that, proxy #4 would be selected because, even though #2 has the more exact Path match, #4 has the better Host match and, unlike #3, at least a partial Path match. |
...
| Service URL | Contains the full URL for the target application (comprising the service host, service port, and forward path). You can enter a complete URL here and/or edit specific components in the associated fields. Updates made in one area will be propagated to the other (for example, if you modify the port in the Service URL field, the value in the Service port field will be updated automatically). |
|---|---|
| Service host | Enter the host name of the machine where the service resides. This is the machine to which the proxy will send messages. 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. For example, a virtual asset deployed on The Service host may also be set to " [Passthrough], " which will route the request to the original host requested by the client, or " [Virtualize], " which will instead route the request to Virtualize to be handled by a Virtual Asset or Message Proxy. Select either option from the drop-down menu. |
| Service port | Enter the port where the service is listening. This is the port to which the proxy will send messages. |
| Service forward path | (Optional) Enter the path to which the proxy should forward the messages that it receives. If blank, the proxy will forward messages along the original incoming path without modification. If the proxy is sending messages to localhost, you must enter a Service forward path as the proxy doesn't allow forwarding to itself. If the Service forward path sends a redirect, the proxy will follow the redirect and then respond back. It will not pass the redirect back to the client. |
...
| Info | ||
|---|---|---|
| ||
Message Responders can be configured to bypass this proxy failover for internally routed messages by enabling the "Skip message proxy failover" option. |
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.
...
Assume that we want to create a message for a service that is normally accessed at http://parabank.parasoft.com. We could create an HTTP Forward proxy with the settings:
...
This configuration will watch for traffic sent to host "parabank.parasoft.com" and and pass traffic to the live service as usual.
...
This will route traffic intended for parabank.parasoft.com to a different service on coyote.parasoft.com:8080.
Example: Sending Traffic to a Virtual Asset
...
Because CA certificates in Android are stored by their hashed name with the file extension .0, you will need to copy and rename the Parasoft certificate. To do that, open a command prompt and navigate to <VIRT_-INSTALL_-DIR>/plugins/com.parasoft.ptest.libs.web_<version><VERSION>/root/lib then run the following command:
...
iOS Emulator
| Anchor | ||||
|---|---|---|---|---|
|
- Host the parasoft.cer file on a file server or email the parasoft.cer file to an address the iOS emulator can receive. You will find the parasoft.cer file in
<VIRT_INSTALL_DIR>/plugins/com.parasoft.ptest.libs.web_<version>/root/lib. - Open a browser to the URL of the parasoft.cer file or open the email and follow the dialog prompts and accept the configuration profile.
- Go to
Settings > General > Device Managementand select "choose Parasoft Root Certificate Authority. " Click through the installation dialogs leaving the default settings in place.
...
- Go to
Settings > General > About > Certificate Trust Settings. - Under “Enable Enable full trust for root certificates”certificates, turn on trust for the Parasoft Certificate.
...