When one enables extended logging in both Jasper and SDM, the following will be observed when testing the sdm_ds datasource for connectivity from Jasper to SDM
CA Service Management 17.1 and higher with Jasper integration
The following testing was done in a non-prod instance, where both SDM and Jasper Services were recycled, and no JDBC related entries were initially found in the SDM slump connection listings immediately after restart.
When doing a test connection on the sdm_ds datasource with debug enabled on the Jasper JDBC driver, this will present in the jasperserver.log (for a successful connection test):
20XX-01-01T19:04:33,097 DEBUG DalJdbcDriver,http-nio-8080-exec-2:135 - In connect, slump: com.ca.ServicePlus.slump.SLUMP@419da012
20XX-01-01T19:04:33,097 DEBUG DalJdbcDriver,http-nio-8080-exec-2:137 - URL: jdbc:sdm:bop:@SDM-SERVER1.DOMAIN.COM:2100;impersonateUserUuid=, properties: user:JasperUser1;password:********;
20XX-01-01T19:04:33,097 DEBUG DalJdbcDriver,http-nio-8080-exec-2:171 - In DalJdbcDriver: logged in
20XX-01-01T19:04:33,097 DEBUG DalJdbcDriver,http-nio-8080-exec-2:175 - username=JasperUser1, impersonateUserUuid=null, roleId=null
20XX-01-01T19:04:33,410 DEBUG DalJdbcDriver,http-nio-8080-exec-2:236 - token: 422722461
20XX-01-01T19:04:33,878 DEBUG DalJdbcDriver,http-nio-8080-exec-2:301 - Got the CABI hostname : JASPERSERVER1 from MDB
In the corresponding stdlogs on the SDM Server, noticing for "token: 422722461" as referenced in the above Jasperserver.log logging, that this is the session ID that SDM is using to facilitate SDM/Jasper connection. This is evident when SDM logging is enabled during the same Jasper connection test and in the resultant stdlogs, one then does a search for the token number 422722461:
stdlog.0:01/01 15:04:32.95 SDM-SERVER1 boplgin 8964 TRACE sys_kpi.c 672 Inserted session with id 422722461 into session_history
stdlog.0:01/01 15:04:32.96 SDM-SERVER1 sqlagt:select0 8452 MILESTONE sqlclass.c 1063 The following statement took 4 milliseconds: Clause (SELECT session_log.id FROM session_log WHERE session_log.id = ?) Input (<int>422722461)
stdlog.0:01/01 15:04:32.97 SDM-SERVER1 boplgin 8964 TRACE bplaccess.c 7661 New session (422722461) started for userid (JasperUser1)
stdlog.0:01/01 15:04:32.98 SDM-SERVER1 domsrvr 1800 TRACE sec_mgr.c 5375 Queuing message get_DomSession from @|BOP-LOGIN|PQAAAA got_dom_session to wait for setup for DomSession 422722461
stdlog.0:01/01 15:04:33.01 SDM-SERVER1 domsrvr 1800 TRACE sec_mgr.c 3217 Created new UserCntInfo cnt:3A516B3BFA7A904CB21A073545576C2A (0x000001C70F828250) for DomSession 422722461-cnt:3A516B3BFA7A904CB21A073545576C2A (0x000001C7127BD890); refcount 0; UserCntInfo count 2
Furthermore, if one views the slump connection listings after the sdm_ds datasource test in Jasper, one will find an entry like this to be present:
dal_jdbc_driver_JASPERSERVER1 849 871 Tue Jan 1 15:04:33 20XX
To view the above, one would run the command slstat on the given SDM-SERVER1. The above entry would not be present in SDM immediately after restart and before the Jasper data source test.
The SDM logging in this example is taken from running these commands:
pdm_logstat -n boplgin TRACE
pdm_logstat -f sqlclass.c TRACE
pdm_logstat -n domsrvr TRACE
To turn off the logging, run:
pdm_logstat -n boplgin
pdm_logstat -f sqlclass.c
pdm_logstat -n domsrvr
The Jasper logging is derived from instructions described in KB Article 247835
Please do not enable the above logging in a production instance without direction from Support.