Where you can replace SYMAPI_SERVER with a service name of your choosing - this is what you want to put into the datasource configuration - and the IP address should point to your productive Sorlutions Enabler server, that's the one that has gatekeeper devices provisioned to and is actually able to communicate with the VMAX arrays.
You would want to register the server names in the local /etc/hosts (on both the OCI server and the remote SE server) in case you run into any SSL handshake failure issues. The mechanism how SSL certificates are validated is tied to name resolution. So if the host name in the ssl certs (mostly self signed) don't match the hostname that you can resolve, the connectivity will be prohibited. Alternatively you can turn off ssl verification on both sides or allow NONSECURE connections which by default is not allowed (probably requires restarting the storsvd service though). But otherwise, no, the server names in the netcfg file don't necessarily need to be registered in the hosts file.
1. If not done already, install Solutions Enabler on the OCI Server. Be aware that there is a version dependancy - the SE server version on the OCI Server needs to be the same as that of the remote (productive) SE server.
2. Modify the netcfg file on the OCI server and point to the remote (productive) SE Server. The netcfg file on the remote SE server does not need any editing or modification.
3. Make sure port 2707/TCP is open between the OCI server and the remote SE server
4. Put the service name from the netcfg file (on the OCI server) in the datasource configuration.
So in effect, you have two SE Server instances "talking" to each other. One on the OCI server (where you need to modify the netcfg file) and the SE server that should already be in place in your environment and has access to the VMAX arrays via the gatekeepers issuing SCSI commands. OCI hichhikes the local SE Sever's CLI in order to collect data from the remote SE server.