If you have been paying attention to the previous blogs, then you will know that currently I have deployed several instances into the AWS cloud.
These instances are being configured and functionality customized by the functional consultants.
As usual not everything works out-of-the-box, which requires either program correctional instructions from SAP or SAP to connect to the system to fix it.
During our POC, this was not something we really needed, so this was a new requirement – completely unexpected and yet completely normal in a standard landscape.
So once the shock had passed that there was something else that slipped past the POC team, I set about looking at what OSS provision can be implemented quickly and easily.
OSS Connection theory
OSS connections come in many flavors, the 3 main types are
1. VPN connection to SAPServ1
2. SNC Connection to SAPServ2
3. ISDN Connection to SAPServ3
So looking at the three options, we can rule out number 3, there is no ISDN provision as we do not have any physical presence available to us. That and the fact that ISDN is horrifically slow, expensive and generally annoying.
So we are left with communication over the Internet, either using a Site to Site VPN or a Secure Network Communication (SNC) link.
Both of which I have set up many times before – the key difference between both the types is-
- Site to Site VPNs – require specialised hardware which sets up an encrypted tunnel using a Pre-shared key or certificate.
- SNC connections – require no specialised hardware and work in the same way as SSL HTTP connections, they use a Public and Private certificate to encrypt and verify identities
Knowing this information is becomes clear which option is both the easiest to set up and most likely to work 1st time – Option 2. This is because we have no direct access to the hardware required to define the pre-shared information with SAP, so we have to use a software based solution which we can control end to end.
Setting up the connection is reasonably easy, following the excellent SAP documentation found here.
Before you start, you do need to collect important pieces of information
- The Public IP address of the SAP Router machine – easy for me as I have given all my machines Elastic-IP addresses
- The DNS name of the SAP Router machine
- Open an SAP Message to have your SAP Router to be entered into the system data of your OSS Account. This will make it available to use in the Service Connector, remember that the connection you want is to SAPServ2 not SAPServ1
- Open the port 3299 to the SAPServ2 IP address to allow SAP to connect to your instances – there are other ports required but open this one to enable SAP to test the connection.
Once this is done then you can go about installing the SAP Router software and generating the certificates required to secure your connection to SAP.
You will need to, once it is created, add your SAP Router information to your System data on the SAP Marketplace. This will allow you to open a connection SAP and let them test connectivity before moving ahead, if they can make a simple Gui connection then all the certificates are fine – any other problems are on your side.
At this point all I need is a SAPGui connection so my life is quite simple, I have provisioned for a Portal HTTP connection but have not had to ask SAP to use it yet (fingers crossed on that one)
SAP have been able to successfully make a connection to the systems and my OSS connection is stable.
So far, it looks like SNC is the way to go for AWS OSS connections. There might be other options if you are using the VPC for your Cloud landscape, this would allow you to use your own firewalls to provide a DMZ and route OSS traffic into the Cloud landscape, but that it outside the scope and capability of my current tests.
SAP’s network people are excellent, they really understand their subject and if you run into difficulties I always find it better to get them on the phone and talking to your network specialist – guaranteed 10mins later you’ll have a working OSS connection 🙂