Using TCP forwarding to overcome connectivity issues
Recently we had an issue with the axis handler and were getting a no method exception.
It turned out that the AXIS library files had some older version of commons codec files and we rebuilt the SDA package. We use this handler for two scenarios.
-One scenario is used for internal A2A scenarios and is easy to test in SBX where we test the library builds.
– Second Scenario is for B2B applications : we were facing error here and we don’t have connectivity with external parties in SBX systems.
As there are multiple projects getting tested in RTE ( regression testing environment) and they can have a negative impact with this bean, we have to test it exhaustively in SBX before we deploy in RTE.
Summary of our problem: How do we test the new axis library without deploying the changes to RTE system where B2B connectivity exists?
SOLUTION : Use a TCP forwarding tool to send messages from SBX to RTE and then forward it to B2B test site.
At a high level we understand that we need to use a tool which can receive traffic on a listener port and then can forward it to a target host /port.
I used two solutions.
Use a GUI based TCP forwarder/traffic analyzer tool. An example is TCP Gateway.
- Download it from service market place – SAP Note 856597.
- FTP the jar file to our regression testing PI server. In our case it’s a unix host so ftp to remote host.
- Find a port open between SBX to RTE server
- Before we launch TCP Gateway tool, we need to perform steps as the unix host output won’t appear on our desktop. You’ll need exceed application
Launch this application on your local PC.
- You need to export the display to your local PC’s IP address/ hostname.
- Check it’s working properly by running xclock. You can verify xclock is running.
- Once confirmed, you can execute TCP Gateway monitor running.
Link to blog about TCP Gateway tool.
In case it’s not possible to execute Exceed as it’s a licensed product, we can write a lightweight TCP Forwarder. Here’s the link.
It’s pretty basic with the source port, destination host and destination port hardcoded in the program. However, it’s good enough for the job.
Here’s output from a sample run.
Addition : I added listener port, target host and target port as a parameter. here’s the link.
I’ve found it handy to use in scenarios where we don’t have direct connectivity as in this example.
There is a native mechanism in SSH which can do this – SSH Tunneling which can do this as well.