(SM-2405) SNP JCO FAQ & Best Practices (draft)

Table of Contents:

Q: What is the ideal SNP JCO deployment?

Ideally, every SAP application server runs its own JCO instance.
This way, each JCO instance is a program registered locally on each application server’s gateway. Whenever an SAP job needs to communicate with the external platform, the communication flows through a defined TCP/IP RFC destination to a connected local JCO instance, which in turn connects to the configured target.

Having this setup preserves the load balancing logic of the SAP system, executing the jobs on the least loaded application server, thus utilizing the JCO instances evenly as well.

Q: Can local JCO be deployed in the “RISE with SAP” infrastructure?

The short answer is: yes.
However, it needs to be communicated to the vendor (SAP), that SNP JCO instances will be running alongside the application servers. The management of JCO instances is outside of SAP’s responsibility and as such should be excluded from SAP’s monitoring.
The main concern from SAP’s side has been the Java Runtime, with Oracle JDK being a licensed software.
SNP JCO is delivered with OpenJDK JRE, so there are no licensing constraints attached.

Q: What are SNP JCO transport contents?

SNP JCO transport contains the following items:

• Application .jar file

• Library bundle, including SAP JCO libraries for Windows and Linux on x86_64

• OpenJDK 11 Java Runtime Environments for Linux and Windows on x64 CPU architecture

Q: How to handle the JCO during SAP system maintenance?

A common mistake is to forget about the JCO during SAP system maintenance. While the JCO can reconnect to the SAP application server after its restart (without full server restart), this may cause communication issues because initial program registration and information exchange become invalid.

Correct handling of the JCO during maintenance is following:

1) Suspend any activity that might need to use the JCO (pause Glue schedulers, let existing replication or offloading jobs finish)
2) Stop all JCO instances
3) After maintenance is finished, start all JCO instances
4) Resume the replication/offloading jobs

The main idea is to let the JCO undergo a clean program registration process after each SAP app. server restart.

Q: What happens during the first JCO start?

When the JCO configuration is finalized and the [Restart] button is clicked for the first time on the respective SAP application server, the following operations are done:

• JCO installation directory is checked and created if it doesn’t exist yet

• JCO configuration files are created in the installation directory

• If embedded JRE is to be used, it is extracted in the installation directory

• SNP JCO .jar file and necessary libraries are extracted

• A lock file with JCO program ID is created, preventing the unwanted start of multiple JCO instances on the same host

• JCO process starts, authenticating and registering on the SAP gateway

Q: What are the supported platforms for SNP JCO?

“Out of the box” deployment works on Linux and Windows operating systems with x64 CPU architecture.
Any other platforms with functional Java Runtime should be usable, but there are manual actions needed to replace OS/CPU-dependent libraries.
It is important to point out that SNP JCO is not tested on AIX, HP-UX, or Solaris operating systems or non-x86_64 CPU architectures.

Q: What are the ideal JCO parameter values?

There is no single configuration that would fit all scenarios.
The goal of the JCO parameters' customization should be to avoid any kind of bottleneck on the JCO side.
Keeping this in mind, the influential parameters are:

• Maximum memory available to the JCO, translated to -Xmx start parameter, defining the JVM heap space.
  This needs to reflect the expected data package size multiplied by the number of SAP background work processes sending the data to the JCO simultaneously (parameter “Max RAM used” in /DVD/JCO_MNG interface).
  It is worth mentioning that memory requirements are typically higher in streaming scenarios or when the data needs to be converted to parquet/avro formats (operation done by the JCO).

• The number of connections established between JCO and SAP gateway.
  This should roughly match the expected number of SAP background work processes sending the data to the JCO simultaneously (parameter “Connection count” in /DVD/JCO_MNG interface)

• Maximum number of JVM threads.
  This parameter is limiting the number of internal JVM threads and should be set to the number of established connections plus a few threads for internal JVM processing. For example with 20 connections, the maximum number of threads might be set to 30 (parameter “Work thread MAX” in /DVD/JCO_MNG interface).

Q: Can the default JCO installation directory be changed?

While the /DVD/JCO_MNG interface provides the option to change the installation directory, it is not recommended. The default installation directory value is a concatenation of the SAP work directory and /dvd_conn/jco<version> path, resulting in /usr/sap/<SID>/<instance>/work/dvd_conn/jco<version>. This ensures that while there is the SINGLE configuration value, the path will be different on every SAP application server (with the instance directory being the differentiator). That is needed for the separation of JCO configuration and log files which need to be different on each app. server.
If the default path is not desired for whatever reason, the installation directory can be configured to a custom single directory path, but the separation of the physical directories between application servers must be preserved (example: /usr/sap/SID/snpjco2402).

Q: What are the options for the JCO deployment to support the HA/DR environment?

If the JCO is deployed locally, there already is out-of-the-box high availability included, having an independent JCO instance for each application server.
The main high availability concern for the JCO is in the standalone deployment.
The goal is standard: to avoid any single point of failure, which would disrupt the operation.
In a productive environment, there should again be a JCO instance connected to every SAP application server, providing redundancy.
Of course, the possibility of the virtual machine hosting the JCO(s) crashing or becoming unresponsive needs to be counted, so employing strategies like multiple VMs hosting the JCOs and/or having the option to migrate the VM to the alternate physical server (build in functionality in cloud infrastructure) should be implemented.

To cover a disaster recovery scenario, it is always possible to either create a replica of the JCO VM or simply copy the whole JCO installation/configuration directories to a host in an alternate location. This enables the JCO startup elsewhere in case of original JCO host becomes compromised. Of course, in this case, it is imperative to preserve the network interfaces and rules, enabling whole end-to-end data flow via alternate routes.