Disclaimer: I am in no way affiliated with SAP-AG nor know of anyone from SAP, telling me of info regarding the hidden features of saprouter. The info written in this article are already publicly available in SAP Help, SCN discussions, and other online articles.
It has been many months or probably a year now since the last time I have written something.
I thought it is high time to contribute once again to the community.
I cannot find a more appropriate title for this article but I hope it's enough anyway to catch your attention :lol:
This may not necessarily be a secret but I'm sure it is something that is undocumented and either well hidden or not really talked about specially by SAP.
Here's a scenario which you may/can relate to:
You can connect to an ABAP system via SAPGUI (because the Basis guy said they have setup saprouters) but nothing else.
What about web browser, or plugins on Excel, or Developer Studio, or some other fancy SAP tool?
If SAPGUI works then why not the others?
The simple answer that any Basis person will tell you is, the saprouter only routes SAPGUI (DIAG protocol).
To connect to the other services a direct connection (e.g. via VPN) is required.
Or if it is just HTTP then the Web Dispatcher can do the job of being a reverse proxy.
OK but then you remembered, how in the world does SAP-support logon to the same SAP system to any SAP service (HTTP, Windows Terminal, telnet, etc. etc.) when they themselves dont have direct connectivity either by VPN or direct connection? They do for sure use the same saprouter technology, so how then do they do it?
There has been a number of discussions going around in SCN that SAP-AG is using a special "proxy" software to connect for example using a web browser. Up until now (well at least for me), no one really knows how it works! and no one is telling anything, quite possibly even the SAP-support guy couldn't be bothered to know how it actually works as long as he can connect to the customer's system using that magical tool.
So how does it work?
In the quest of searching for an answer, I stumbled upon the saprouter Reverse Invoke configuration.
This tells me that saprouter has more features than usually known. I asked the question, what if the saprouter can just bounce off network packets or what is better known as "port forwarding". Then viola! A Google search for the term landed me to this old SAP help (which by the way is strangely no longer maintained and published in the later Netweaver versions).
So piecing in the 2 together:
1) Reverse Invoke - to form the proxy
2) Existing saprouters - as port forwarders
is the secret to connecting to any protocol using nothing but just the saprouter! :wink:
I will illustrate how it works. Let us say you already have SAPGUI working with the following entry.
So connection goes like this for SAPGUI.
PC (SAPGUI) -> router1 (port 3299) -> router2 (port 3299) -> sapob1.mycompany.lan (port 3200)
This works because SAPGUI knows what to do and how to route the saprouter string "/H/router1/H/router2".
What about the HTTP to the ICM?
We know it cannot be a simple:
PC (web browser) -> router1 -> router2 -> sapob1 (8000)
as a normal web browser doesnt know what a saprouter string is.
Taking the hint that there is a "proxy" tool used by SAP support, then putting the proxy in between the Web Browser and router1 like the Reverse Invoke Configuration might do the trick!
Here's the answer to the secret!
Using the port numbers as in the example provided in the SAP Help:
PC (web browser) -> RI-router1 (4001) -> RI-router2 (5002) -> router1 (3299) -> router2 (3299) -> sapob1 (8000)
Which translates to the following route parameter of RI-router1's config.
route=/H/RI-router1/S/4001/H/RI-router2/S/5002/H/router1/H/router2/H/sapob1.mycompany.lan/S/8000
So to connect to the HTTP (ICM) of ABAP system OB1 is as easy as typing in the following URL in the browser:
Cheers!
5 Comments
