APM

SCR Initialization Failure in APM 7.7

By IMWUC Community Team posted Tue October 15, 2019 02:36 AM

  

by Aldo Bucossi

In APM 7.7, the SCR (Service Component Repository) is used as application and resources repository, to facilitate exchange of resource model and application information between APM UI itself and the other components. By default, it uses an instance of Derby database to store data but of course in a production context it is strongly suggested to leverage on an enterprise database like DB2.

Recently I migrated my SCR database from the native Derby to DB2, following the steps available in the APM UI 7.7 User's Guide manual, Chapter 6, in the section called "Configuring the application repository to point to a different datastore". After I completed all the suggested steps and I have restarted SCR, I noticed it was not working as expected.

The scrserver.log file (log file for SCR component saved into

Exception:  com.ibm.ws.jdbc.DataSourceService incompatible with javax.sql.DataSource

This is not a product error, it deals more with jdbc and java interaction, so I also tried googling around to look for possible explanation related to similar scenarios. Most of the entries I found dealt with code changes related to JNDI and possible issues with JDBC drivers. So I made lot of tests by defining new paths for specific JRE, tried to copy newer jdbc drivers in the WAS Liberty jar folder, but nothing helped. 

The explanation for above error message was instead much easier and was clearly explained into another useful log file, called messages.log, also this one created into folder

CWWKE0701E: [com.ibm.ws.jdbc.dataSource.properties.db2.jcc(213)] The activate method has thrown an exception Bundle:com.ibm.ws.jdbc(id=84)
com.ibm.ws.crypto.util.UnsupportedCryptoAlgorithmException

and then

J2CA8030E: Unable to find properties null for dataSource jdbc/scr.com.ibm.ws.jdbc.DataSourceService 587

 

So, the error message I initially found into scrserver.log was only a consequence of a problem in password decryption. Passing a clear text password in the server.xml, the SCR was able to initialize and work fine. Next step was to understand why WAS Liberty was failing to decrypt the password previously encrypted with tool securityUtility. The syntax I used was:

securityUtility encode --encoding=aes --key=APMUI_KEY 

 

After some additional investigation and testing, I realized that the WAS Liberty profile used for SCR works with the default key for decrypting passwords, while I was instead forcing to use an alternative key (APMUI_KEY). The correct syntax should be then:

securityUtility encode --encoding=aes

 

Using the encrypted password generated with this command syntax in the SCR server.xml file, will allow SCR to complete initialization as expected. Making short a long story: do not use the flag --key when you are encrypting password for SCR component, otherwise it will not be able to start. If you really want to use an alternative hash key to generate a password for SCR, you then need to instruct WAS Liberty profile to use that key instead of the default one to decrypt the password, by setting a property called wlp.password.encryption.key. Additional details about the required steps can be found at:

http://www-01.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/cwlp_pwd_encrypt.html?cp=SS7K4U_8.5.5&lang=en 

and 

http://stackoverflow.com/questions/25679414/how-to-set-wlp-password-encryption-key-value-in-liberty-profile

0 comments
2 views

Permalink