Skip to content
CA API Gateway - 9.3
Documentation powered by DocOps

Route via Raw TCP Assertion

Last update April 6, 2018

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

  1. 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.
  2. When adding the assertion, the Raw TCP Routing Properties automatically appear; when modifying the assertion, right-click Route via Raw TCP in the policy window and select Raw TCP Routing Properties or double-click the assertion in the policy window. The assertion properties are displayed. 
  3. Configure the properties as follows.

    Setting Description
    Destination hostname or address

    Enter the hostname or IP address to which the Gateway should connect to send the request message. You may reference context variables.
    Port Enter the port number to use. Alternatively, enter a context variable.
    Connection timeout Enter the connection timeout for socket connection in milliseconds. Default: 30000 ms Or you can set the value for system property, com.l7tech.external.assertions.rawtcp.defaultConnectionTimeout.
    Request message source

    Use 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 timeout

    The amount of time the Gateway should wait for acknowledgment of writes to the server before giving up (also known as socket write timeout).

    • Select the check box to enable the timeout and then enter the timeout period, in milliseconds. The default is 2000 milliseconds.
    • 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 type Enter the MIME Content-Type to assume for the response (for example, "text/xml"). You may reference context variables.
    Response message destination

    Indicate 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 timeout

    How long the Gateway should wait for reads from the server to result in additional data before giving up (also known as socket read timeout).

    • Select the check box to enable the timeout and then enter the timeout period, in milliseconds. The default is 2000 milliseconds.
    • 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 size

    Select this check box to override the permitted maximum size of the routing message. Clear this check box to use the value set in the io.xmlPartMaxBytes cluster 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.
  4. Click [OK] when done.  
Was this helpful?

Please log in to post comments.