For various reasons, it may be desirable to run the SNP Java Connector outside of the SAP infrastructure.
This page describes topics that must be considered in such cases and the configuration steps necessary for successful standalone Java Connector (JCO) deployment.

Architecture decision

Before the start of the implementation following questions need to be answered, as they have a practical impact on the deployment procedure as well as expected performance:

1. What is the expected data load?

2. Are there any requirements for the High Availability of the solution?

3. Does the SAP system require encrypted communication with external programs (SNC)?

The description of the following two deployment scenarios should provide guidance in the decision-making process about the standalone JCO architecture:

a) Standalone JCO architecture connecting “its own” JCO instance to each SAP application server.

In this scenario, the JCO instances are running on a separate host (possibly multiple hosts), but the idea of each SAP application server having its own JCO instance is preserved. With this setup, the workload is automatically load-balanced by the SAP scheduler, which schedules the replication jobs evenly among SAP servers (or within a specified server group) and thus each JCO instance only needs to process a part of the load assigned to one SAP app. server.

The server(s) hosting JCO instances need to be sized appropriately concerning the number of background jobs used for data transfer on the SAP side taking into account the frequency and volume of data replicated. This can vary widely, so in practice, it is not possible to provide an explicit calculation for computing resources necessary, but as a rule of thumb, it is recommended to start with 4 vCPUs and 8 GB RAM per JCO instance.

b) Single standalone JCO instance connected to the gateway of a specific SAP application server.

This scenario expects a low workload, therefore a single JCO instance is sufficient to cover the data transfer needs. Independent of the number of SAP application servers, the JCO is connected to exactly one specified SAP gateway and all communication between the SAP system and the target platform will be routed through that gateway.

The expected workload is a crucial factor in the decision. The bright side of the solution is that the architecture can be changed later on if the low workload becomes not so low after all. With Virtual Machine and Cloud elasticity in mind, it is possible to reconfigure the JCO according to the actual needs. There is always an option to add more CPU and memory to the JCO VM or add another VM to provide more computing resources for JCO processing.

Default values for minimal JCO setup (suitable for most PoC scenarios) could be as small as 2 vCPUs, 4 GB RAM, and 4 GB of disk space.

The operating system of the JCO host needs to be Linux (practically any official distribution) on x64 architecture.

Software delivery

Standalone SNP Java Connector software is currently delivered as a gzipped tar archive. For the download link, contact the SNP representative.

Once uploaded to the JCO VM, the archive can be decompressed and unpacked using the following command (archive name can vary):

The archive contains the following items:

After completing the preparation steps described below the JCO can be deployed by executing deploy_snpjco.sh script under the root user.

Preparation on the SAP side

SAP technical user and Access Control List

To allow JCO program registration on the SAP gateway it is necessary to create:

• SAP technical user for authentication and authorization

• Entry in reginfo file to allow program registration

The technical user creation and role assignment are described in(SM-Latest) Java Connector Setup | SAP RFC role and user.

Reginfo update is described in(SM-Latest) Java Connector Setup | SAP Gateway Access.

An additional step is the generation of an encrypted password which will serve as one of the JCO configuration parameters. This is done by executing report /DVD/XOR_GEN in SE38:

Open

^{/DVD/XOR_GEN report execution}

Enter the password and Execute (F8)

Open

Store the encrypted password string to use later during the JCO deployment.

RFC Destination

To establish a communication channel between SAP and JCO, the RFC destination of TCP/IP type needs to be created.
Depending on the architecture, the destination will either route the communication via the default gateway of every SAP app. server or an explicitly defined gateway service.
The configurable parameter is the program name, which can be chosen freely. In our example, we are using the program name SNP_CONNECTOR.
Further information at (SM-Latest) Java Connector Setup | Java Connector RFC.

Preparation on the JCO VM side

JCO OS user and directories

Two directories are used for standalone JCO deployment:

• A general directory containing OpenJDK Java Runtime, libraries, and SNP JCO .jar file - default location /opt/snpjco.

• Instance directory containing logs and configuration files about particular JCO instance

The default instance directory consists of /app followed by /<JCO user>. We will use a sample JCO instance directory /app/gl1jco, imitating <sidadm>.
If multiple instances are deployed on the same host, paired with application servers of the same SAP system, the instance directories need to be differentiated by additional identifier, like an incremental number or target app. server hostname (e.g.: /app/gl1jco_00, /app/gl1jco_01, /app/gl1jco_02).

(Optional) Secure Network Communication setup (SNC)

Depending on the SAP system configuration, there may be a need to connect JCO in snc_enabled mode. This is fully described(SM-Latest) Java Connector Setup | SNC configuration, but with a standalone JCO setup there are a few modifications to the procedure:

• SECUDIR directory must be created and defined on the JCO server for the user(s) running the JCO service.

• libsapcrypto.so and sapgenpse need to be available on the JCO server. Recent versions of these for Linux x64 are part of the SNP JCO archive.

• THE JCO PSE file needs to be copied to the JCO server into SECUDIR.

• cred_v2 file must be created in JCO SECUDIR using the sapgenpse utility under the root user.

Example of the configuration:

Input parameters for JCO configuration

The following information needs to be collected to populate the contents of the JCO configuration files config.jcoServer and config_as.jcoDestination:

• IP address or hostname of respective SAP application server(s), used for connection from JCO host to SAP

• Instance number(s) of respective SAP application server(s).

• Program ID, as defined in the RFC destination.

• SAP client number in which the SAP technical user was created

• SAP technical username used for JCO program registration

• SAP technical user’s password in an encrypted format

If the JCO will be running in SNC-enabled mode, instead of user & password the following input is required:

• The canonical name of SNP JCO (in format p: CN=… ).

• The canonical name of the SAP system (in format p: CN=… ).

• SNC Quality of Protection level (abbrev. QoP, default = 3).

JCO Deployment and Start

Having preparation done, the next step is the execution of the deployment script.

The script must be executed under the root user and perform the following actions:

• Copies necessary libraries and runtime environment to a defined directory (default: /opt/snpjco).

• Checks existing configuration and collects input parameters.

• Creates configuration files based on gathered input data in the specified directory (default: /app/<jco_username>).

• Generates a start script & start command.

• Starts up the JCO as a background process (detached from the terminal).

Example of deployment script run (with SNC enabled; some parameters differ from non-SNC connection):

Special runtime parameters

If there is a proxy server sitting between the JCO VM and the target platform, it may be necessary to enhance the JCO start script with relevant parameters.
To maintain a secure connection on all segments of data transfer, HTTPS protocol should be enforced for communication with the proxy:

Sample start script from our previous example enhanced with proxy parameters would look like this:

Similarly, if there are issues in communication between JCO and the target service or SAP system, the debug can be activated with the following parameters:

Monitoring Standalone JCO from SAP

Transaction /DVD/JCO_MON provides an interface similar to /DVD/JCO_MNG.
It has significantly reduced options since the whole JCO configuration and operation is done remotely.
However, it allows two important actions:
1) Reading JCO log files via SAPGUI (useful in data flow troubleshooting)
2) Stopping the JCO (relevant during maintenance)

Configuration of the transaction is very simple - click the Connect Standalone JCO button and enter the RFC destination used for communication with the JCO.

Converting SNP JCO into systemctl service

It is possible to create a systemctl service that automatically starts the JCO when the underlying host is restated or a JCO Stop is executed from the aforementioned transaction /DVD/JCO_MON.
For convenience, we deliver the make_service.sh shell script which creates the service with a single parameter being the JCO configuration directory.

Example of the script execution: