Route via Raw TCP Assertion
The Route via Raw TCP assertion is used if the custom transport protocol "l7.raw.tcp" has been configured for a listen port. This assertion acts as a client of the server-side transport: it will transmit the request, close the sending side, read the response (if possible), and then initialize the response message with a pre-configured Content-Type.
gateway83
The
Route via Raw TCP
assertion is used if the custom transport protocol "l7.raw.tcp
" has been configured for a listen port. This assertion acts as a client of the server-side transport: it will transmit the request, close the sending side, read the response (if possible), and then initialize the response message with a pre-configured Content-Type.This assertion will succeed if the raw TCP routing is successful.
The Route via Raw TCP assertion can also be used as part of dynamic routing. See Working with Dynamic Routing for more information.
Using the Assertion
- Do one of the following:
- To add the assertion to the Policy Development window, see Add an Assertion.
- To change the configuration of an existing assertion, proceed to step 2 below.
- When adding the assertion, theRaw TCP Routing Propertiesautomatically appear; when modifying the assertion, right-clickRoute via Raw TCPin the policy window and selectRaw TCP Routing Propertiesor double-click the assertion in the policy window. The assertion properties are displayed.
- Configure the properties as follows.SettingDescriptionDestination hostname or addressEnter the hostname or IP address to which the Gateway should connect to send the request message. You may reference context variables.PortEnter the port number to use. Alternatively, enter a context variable.Request message sourceUse the drop-down list to select the source for the request message:
- from the default Request
- from a context variable of type Message (this variable must already be defined in the policy before it will appear in the list)
Custom transmit timeoutThe amount of time the Gateway should wait for acknowledgment of writes to the server before giving up (also known assocket write timeout).- Select the check box to enable the timeout and then enter the timeout period, in milliseconds. The default is2000milliseconds.
- Clear the check box to not use a timeout. The Gateway will wait indefinitely.
This is just the socket timeout, so it applies per read or write operation. It does not apply to the entire transaction.Response content typeEnter the MIME Content-Type to assume for the response (for example, "text/xml"). You may reference context variables.Response message destinationIndicate where to store the response:- Default response:Store the response in the default response.
- Save as context variable:Store the response in the specified Message context variable. If this variable does not already exist, it will be created.
Custom receive timeoutHow long the Gateway should wait for reads from the server to result in additional data before giving up (also known assocket read timeout).- Select the check box to enable the timeout and then enter the timeout period, in milliseconds. The default is2000milliseconds.
- Clear the check box to not use a timeout. The Gateway will wait indefinitely.
This is just the socket timeout, so it applies per read or write operation. It does not apply to the entire transaction.Override maximum message sizeSelect this check box to override the permitted maximum size of the routing message. Clear this check box to use the value set in theio.xmlPartMaxBytescluster property.- Restrict messages to:Enter the maximum permitted size of the response message, in bytes. You may specify a context variable.
- Allow unlimited message size (not recommended):Select this option to allow response messages of unlimited size.
- Click [OK] when done.