For using DBA Planning Calendar to schedule BR*Tools for remote Oracle database AS Java systems I have successfully implemented both the Secure Shell and SAP gateway methods in [Note 1025707 - DBA Cockpit: Planning calendar and remote Oracle databases|https://service.sap.com/sap/support/notes/1025707] and was interested in which of these two methods others have found to be more supportable and maintainable?
-
In more detail, the note has these two methods for non-ABAP remote systems:
2. Connection through Remote/Secure Shell
Specifically Secure Shell. Rejecting remote shell as too old and insecure a protocol.
3 Connection through SAP gateway
The note provides clues as to how these methods work. Expanding on that:
With #2, central ABAP system calls out to its OS user level to execute the ssh client (after gw/rem_start has been set to the non-default value SSH_SHELL) which it finds in the location specified in gw/ssh (default value is /usr/bin/ssh). It must use password-less authentication and the key-based authentication must also not require a passphrase. (Using ssh-agent is not an option since this is being called from SAP, not from your own script.)
It remotely runs via ssh a command, sapxpg, which must be found in the PATH of the remote user. (This is why the note, which has you place this exe sapxpg and a subset of the BR*Tools in the home dir of the remote user, also has you make sure the home dir is included in the path--your OS might or might not include the user's home dir in the path in the default shell environment for a new user.)
Then via sapxpg, the BR*Tools are invoked.
One thing that may be confusing here is you have to check at least one gateway parameter 'gw/...' in the central system to get the method #2 the non-gateway method to work--this is because the two methods are technically almost the same: in #2, secure shell is used to basically start a gateway on the fly with sapxpg in order to call the BR*Tools each time a DBA Planning Calendar action runs or you view DBA or Backup logs of the remote system from the central system. With #3, the gateway runs continuously on the remote system.
With #3, central system connects to remote SAP standalone gateway, which executes the BR*Tools installed in the standard SAP kernel directory of the SAP gateway. This method is simpler to describe so it sounds like it has less components than the secure shell method, however you do have an entire SAP system running, although it is just a standalone gateway.
-
Thoughts:
These pros/cons are UNIX/Linux-oriented since I assume most Windows environments do not have added 3rd-party products that provide secure shell so SAP gateway is the only method.
Secure shell
+ Less software required (not counting secure shell which comes with the operating system distribution): just a few SAP executables placed in the home dir of an ordinary user on the remote system.
+ Secure shell service probably automatically starts upon boot of the remote system operating system.
+ Secure shell is a widely used tool outside of SAP for executing commands remotely without passwords.
- Installation is non-standard: shell environment of remote user is not adapted by SAP installer since SAP installer is not used, SAP executables in the home dir of the remote user is non-standard. Has to be setup manually.
- Requires setting up secure shell key-based authentication, which should be known by UNIX/Linux admins or combined Basis/UNIX/Linux admins, but might be less familiar to SAP Web AS only admins.
- If your admin config policy is to have SAP interact as little possible with the OS level for interfaces with other systems, here you are relying on the OS-level secure shell.
- Using a private key that does not require a passphrase on the central system may not fit with your security policies if you have standards for secure shell configuration.
SAP gateway
+ The gateway is a standard installation, performed with SAP installation tool, with the exception of a few additional environment settings that have to be added after the installation. BR*Tools are installed in the standard location. Can use standard procedures for updating this software.
+ Only uses SAP software.
- More software on remote system: standalone gateway just to run BR*Tools and view logs.
- SAP Kernel of remote gateway should probably be updated whenever you do SAP kernel updates across your systems for consistency. One more system to update.
- Shell environment of remote user that runs the gateway looks like something setup by the SAP installer but is not standard because it has a few additional environment variables added.
- Need to make sure the SAP gateway is started on the remote system.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.