Due to various reasons, it may be desired to run the SNP Java Connector outside of SAP infrastructure.
This page describes topics that need to be considered in such a scenario 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 load?

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

3. Does the SAP system require encrypted communication with external programs or not?

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 maintaining SAP app. server: JCO instance 1:1 relation.

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 and thus each JCO instance only needs to process the 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, thus 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 would become 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 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 https://datavard.atlassian.net/wiki/spaces/DATAVARD/pages/2229602754/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

In our examples, we will use the as1jco username (analogy to as1adm on the SAP side, related to AS1 SAP SID).

Two directories are used for standalone JCO deployment:

• A general directory containing libraries and the JCO .jar file.

• Instance directory containing logs and configuration files pertaining to particular JCO instance.

The default directory where JCO libraries are copied during the deployment is /opt/snpjco.
The default instance directory consists of /app followed by /<JCO user>. We will use a sample JCO instance directory /app/as1jco, 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 identifiers, e.g. instance number (/app/as1jco00, /app/as1jco01, etc.)

(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 in (SM-Latest) Java Connector Setup | SNC configuration, but with 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 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 performs 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:

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: