SAP IPS Logs

Product: SAP Information Platform Server (IPS, CMS), SAP BusinessObject Data Services (BODS)

Version: 4.2.x - 4.3.x

OS: Windows, Linux

There is no documentation about the log files created by SAP CMS software that bundled with SAP BODS software.  This post is mainly covering the log files

Following are the log files created by SAP CMS software, and they mix together with CMS' Tomcat application server:

aps_ORDSUPWDS01.AdaptiveProcessingServer_gc.log

aps_ORDSUPWDS01.AdaptiveProcessingServer_ncs.trc

aps_ORDSUPWDS01.AdaptiveProcessingServer_trace.000001.glf

aps_ORDSUPWDS01.EIMAdaptiveProcessingServer_gc.log

aps_ORDSUPWDS01.EIMAdaptiveProcessingServer_ncs.trc

aps_ORDSUPWDS01.EIMAdaptiveProcessingServer_trace.000001.glf

cms_ORDSUPWDS01.CentralManagementServer_ncs.trc

cms_ORDSUPWDS01.CentralManagementServer_trace.000001.glf

DS.AdminService_2025079_7444820959_0.log

DS.AdminService_2025079_7444820959_0.log.lck

DS.JobLauncherService_2025079_7444817762_0.log

DS.JobLauncherService_2025079_7444817762_0.log.lck

DS.RFCService_2025079_7444811058_0.log

DS.RFCService_2025079_7444811058_0.log.lck

fileserver_ORDSUPWDS01.InputFileRepository_ncs.trc

fileserver_ORDSUPWDS01.OutputFileRepository_ncs.trc

ICC.MetadataService_ord-sup-wds01_2025079_74448304_60_0.log

ICC.MetadataService_ord-sup-wds01_2025079_74448304_60_0.log.lck

ICC.ViewdataService_ord-sup-wds01_2025079_74448177_63_0.log

ICC.ViewdataService_ord-sup-wds01_2025079_74448177_63_0.log.lck

jobserver_ORDSUPWDS01.AdaptiveJobServer_ncs.trc

jobserver_ORDSUPWDS01.AdaptiveJobServer_trace.000001.glf

ORDSUPWDS01_gc.log

SIA_ORDSUPWDS01_trace.000001.glf

Purpose

1. File extension ".lck" is lock file or a flag file which to imply the CMS daemon is running.  CMS has following daemons, and each has their own .lck lock file
1. DS.AdminService_2025079_7444820959_0.log.lck
2. DS.JobLauncherService_2025079_7444817762_0.log.lck
3. DS.RFCService_2025079_7444811058_0.log.lck
4. ICC.MetadataService_ord-sup-wds01_2025079_74448304_60_0.log.lck
5. ICC.ViewdataService_ord-sup-wds01_2025079_74448177_63_0.log.lck
2. File suffix "_gc" and extention ".log" (...._gc.log) is Java garbage collection log.  CMS daemon has no reason to has high Java memory usage, so these log files can be ignore
3. The rest of the log files are useful for troubleshoot SAP CMS daemons, and needs to read everyone of them

SAP BODS Designer Central Repository Not Showing Up When Adding

Product: SAP Data Services
Version: 4.2.x - 4.3.x

Problem Description

There are multiple BODS central repositories in the system.  Few of the central repositories are cloned from existing central repositories for following reasons:

1. Setting up more central repositories in identical BODS versions for current env
2. Setup another central repositories in identical BODS versions for different env. Issue occurs after 2nd attempt of refresh after DS Designer added the central repositories on 1st attempt
3. During upgrade, clone into a different DB user (Oracle), or logical database (MS SQL Server), then uses BODS Repository Manager to upgrade it without disrupting older BODS version

In DS Designer, menu Tools > Central Repository

After clicked "Add" button, it is either display a screen to add more central repository, or following message:

Even if it shows a list of central repositories to add, users are not able to see the desired central repository from the list.

DSMC central repository user and group setup has been done, even for secured central repository, when login to DS Designer as administrator user account.

Information to Gather

1. Login to central repository and determine the unique ID for the central repository.  This is called GUID, which will be added into local repository when users add it.  Run following SQL

select guid from al_version;

2. Repeat above for each of the central repository to get all the GUID

3. Login to local repository which failed to see other central repository

4. Run following SQL to show the central repository name and central repository GUID

select name, guid, object_key, object_type from al_lang where object_type = 5 and object_key in (select parent_objid from al_setoptions where parent_objid = al_lang.object_key and option_name = 'datastore_repotype' and option_value = 'central');

Sample output:

5. Explanation of above in local repository table AL_LANG

5.1. AL_LANG stores all object entries, including secure and non-secure central repositories

5.2. object_type = 5 is for datastores, secure repositories, non-secure repositories

5.3. al_SetOptions stores more detail for secure and non-secure central repository for Option_Name = datastore_repotype with Option_Value = 'central'

5.4. If you want to further filter by secure repository, then filter al_SetOptions by Option_Name = CENTRAL_REPO_SECURE, Option_Value = yes

Analysis

1. Compares the GUID from Step 1 with Step 4 for the same central repository name

2. Identify which central repository has the same GUID

3. This should be the central repository which is not visible in DS Designer's adding central repository screen

4. If you removed the central repository with the same GUID from DS Designer, then the list will be able to show all the central repository, even their GUID are identical

5. However, once you added one of those duplicate GUID into DS Designer, when try to add central repository again, you won't be able to see the central repository that has duplicate GUID

6. This is a consistent behavior in all local repositories

Root Cause

The AL_Version table was cloned from one central repository to another one, which leads to identical unique ID on column GUID.  Local repositories expect each central repository to have a unique GUID, else DS Designer assumes the central repository (with the same GUID) has been added, and will hide it.

Resolution

The supported approach is to use Repository Manager to re-initialize the central repository (all content will be lost), so that it will assign a new GUID.  Due to all central repository's content will be lost, if you want to keep its existing content, then find a local repository which can be used to check-out all content into it, then check back in to the central repository after it is initialized

SAP BODS JobServer: Enabling IPv6

Product: SAP Data Services

Version: 4.2.x

Overview

SAP BODS product bundled with following 2 software:

• IPS
• Data Services JobServer - I will refer to it as JobServer
• Tomcat

Following are the default ports each listening on

• IPS - TCP port 6400
• JobServer - TCP port 3500
• Tomcat - TCP port 8080

This post mainly write about IPv6, as certain people might have IPv6 setup, and would like to use it.  I won't discuss about Tomcat, as its IPv4 & IPv6 network configuration follows Apache Tomcat's documentation.

IPS has both IPv4 and IPv6 enabled during installation.  However, JobServer only enable IPv4, and the product document does not show how to enable IPv6.  The confusing part is that their product document, and SAP KB have several places that indicate IPv6 is supported, yet no documentation how to enable it.

Enabling IPv6 for JobServer

Follow these steps to enable IPv6 (and keeps IPv4) for JobServer

1. cd $LINK_DIR/bin

2. Append SAP_IPv6_ACTIVE=Y into al_env.sh: echo "export SAP_IPv6_ACTIVE=Y >> al_env.sh"

3. Restart JobServer: svrcfg

3.1. In the menu, choose stop JobServer, then start JobServer

Verify IPv6 enabled for JobServer

When I raised SAP support ticket, SAP keeps saying IPv6 is enabled, so I have to provide proof that it is not.  You can use this command to verify that IPv6 is enable

1. Linux: netstat -an | grep 3500 | grep LISTEN

2. Windows: Run cmd as Administrator

2..1. netstat -an | findstr "3500" | findstr "LISTEN"

Sample output that shows IPv6 works in port 3500

tcp   0    0 0.0.0.0:3500    0.0.0.0:*    LISTEN

tcp6   0    0 0.0.0.0:3500    0.0.0.0:*    LISTEN

The first column, "tcp6"means it is for IPv6, while "tcp" means it is for IPv4

SAP Data Services Job Server - SSL Configuration

Product: SAP Data Services
Component: JobServer
Version: 4.2SP0 - 4.2SP14
OS: Windows

SAP Doc #1: https://help.sap.com/docs/SAP_DATA_SERVICES/2d2abbb0fab34071a4c53b7de873241b/571a69626d6d1014b3fc9283b0e91070.html?locale=en-US

SAP Doc #2: https://help.sap.com/docs/SAP_DATA_SERVICES/e54136ab6a4a43e6a370265bf0a2d744/571dc02c6d6d1014b3fc9283b0e91070.html?locale=en-US&version=4.2.8

SAP Doc #3: https://help.sap.com/docs/SAP_DATA_SERVICES/e54136ab6a4a43e6a370265bf0a2d744/571db2eb6d6d1014b3fc9283b0e91070.html?locale=en-US&version=4.2.8

SAP has a relatively poor documentation about custom SSL certificate setup for BODS Data Services, which is Job Server.  They break it into several different chapters and failed to leverage "Related information" section to help customer to bridge the information together.

There are 2 main directories, and 1 tool (Data Services Server Manager in Windows, and svrcfg in Linux) to configure the SSL certificate:

• %LINK_DIR%\ssl\server
• %LINK_DIR%\ssl\trusted_certs

The most common mistaken about SSL certificate is that administrator failed to read SAP's doc that their program only recognize PEM format SSL certificate (there are DER, PKCS12 that are common).

Let me list down a list of files and directory of each, which is applicable to both self-signed, or paid SSL cert:

1. Custom root CA SSL cert > %LINK_DIR%\ssl\trusted_certs
2. Custom root CA SSL cert private key, password file > not required
3. Custom intermediate #1 CA SSL cert > %LINK_DIR%\ssl\trusted_certs
4. Custom intermediate #1 CA SSL cert private key, password file
5. Custom intermediate #2 CA SSL cert > %LINK_DIR%\ssl\trusted_certs
6. Custom intermediate #2 CA SSL cert private key, password file
7. Custom intermediate #3 CA SSL cert > %LINK_DIR%\ssl\trusted_certs
8. Custom intermediate #3 CA SSL cert private key, password file
9. Custom BODS server SSL cert > %LINK_DIR%\ssl\server
10. Custom BODS server SSL cert private key > %LINK_DIR%\ssl\server
11. Custom BODS server SSL cert password file > %LINK_DIR%\ssl\server
12. There is no SSL certificate keystore for Job Server configuration

There are several catch that SAP document doesn't cover, as well as misleading info in SAP KB:

1. %LINK_DIR%\ssl\trusted_certs can contains additional SSL certs files
2. %LINK_DIR%\ssl\trusted_certs cannot contains other files that are not SSL cert files, or it will complain error "Unable to load verify locations"
3. If %LINK_DIR%\ssl\trusted_certs contains private key PEM file, Server Manager will complain error "Unable to load verify locations" as the same reason explained in #2 above
4. %LINK_DIR%\ssl\trusted_certs can contains unused SSL certs, such as put new self-signed or paid cert files together with OOTB self-signed cert files
5. SSL cert that is V1 or V3 are both accepted
6. SSL cert that is RSA 1024-bit or 4096-bit are all accepted
7. The program is not able to produce meaningful log, and no way to enable debugging log
8. The openssl command in SAP's doc implies to generate PEM format certificate, but that command is actually generates "certificate request" file, and not the final certificate
9. SAP document wrote to put all the signed SSL certs into "%LINK_DIR%\ssl\trusted_certs" but you just need to put the root, intermediate, and parent SSL certs into it (as PEM format)
10. You can have SSL file extension other than crt: crt, cer, pem
11. The SSL cert that issue to BODS server should put under %LINK_DIR%\ssl\server directory, which SAP doc failed to mention.  This is for consistency of their design, and won't break application functionality.  I recommend to keep existing architecture instead of follow their doc
12. In Data Services Server Manager > SSL tab, configures
1. Server certificate file: Location of the PEM SSL cert file that issued to this BODS server.  It should be in  %LINK_DIR%\ssl\server directory
2. Server private key file: Part 2/3 file for above SSL cert. It should be PEM format, and located in same dir as above
3. Use Server private key password file: Recommends to has a password file for above SSL cert.  Recommends to keep in same dir as above
4. Trusted certificates folder: No need to change, but ensures copy all the root and intermediate cert files into dir %LINK_DIR%\ssl\trusted_certs (default).  You do not need to change this location

You can use both Windows, or bundled openssl utility to convert SSL certificate to PEM format that recognized by BODS.  PEM format file is ASCII file, which you can open it up in text editor to confirm that it is not binary file.

Following is openssl command to convert DER format SSL cert file to PEM format:

%LINK_DIR%\bin\openssl x509 -inform DER -in custom.cert1.crt -out custom.cert1.pem.crt