Problem with TCP/IP (Socket) Connectivity through API Gateway

Document ID : KB000110990
Last Modified Date : 14/08/2018
Show Technical Document Details
We are having trouble getting access to the data in the request from Tactical Assertion :  "Extensible Socket Connector"

The documentation for the tactical assertion says in the policy ${request.mainpart} should give access to the request data - but this does not work for us. 

We have setup a socket listening on port : 8888 , with message delimiter of x0a (LF) - as per the additional documentation.  And we have test client where we can send in a request and get a response..

The test client sends in a request, the policy is run correctly and a response is returned - but the response ${request.mainpart} is always blank in our test cases. 

Clearly we need access to the request data. 
APi Gateway 9.2 
API Gateway 9.3

With Tactical Assertion :  "Extensible Socket Connector"
It seems the ${request.mainpart} variable is not set unless a new "Validate or Change Content Type" assertion is added to the policy. As detailed below.

To fill the details into ${request.mainpart} we needed to add an assertion : "Validate or Change Content Type".

It was set to : Change content-type; New value: text/xml (or text/plain - both worked in our testing )
And - this needed to be set : 
       [x] Re-initiaize message The check box on re-initialize is the important one.

Here is screenshot of the response policy that is triggered by the request on the socket.
Highlighted is the "Validate Content Type" with the settings needed to re-calculate the request.mainpart variable: 
User-added image

The response we have setup is basic echo of the request data, surrounded by X..Y values : 
User-added image

Testing the Solution : 
For testing we are using the public domain tool :
It allows us to connect a tcp socket to the backend gateway server on port 8888 and send a \n delimited message: 
User-added image

We click send the message "TestMessage" to the gateway and get back a response : 
User-added image
When it is working then the response we get back is XTestMessageY.

Previously we were getting back an empty string. 

Additional Information:

Setting up the Extensioble Socket Connector Assertion: 

After installing the "Extensible Socket Connector" Tactical Assertion (it is described fairly well in the documentation that comes with it).  We then setup the policy as follows : 

We manage our Socket Connections (new menu item with this assertion) : 
User-added image

And create an inbound assertion called :LFSocket".   Under the general settings tab we set it as an Inbound socket, and the Data Protocol being a terminated message : 
User-added image

Under the Inbound settings tab we indicate which socket to listen on 8888, and which policy will be triggered to handle the request. 
User-added image

On the Protocol Settings tab, we indicate that 0a (lf) is the message terminator character to be used : 
User-added image

We then create the following policy which is triggered for any message arriving on port 8888.

In the policy we are just doing simple things, logging the ${request.mainpart}.  Validating the Content-Type (which is the step we need to add), and then returning a template response. 
User-added image