JSPM/SDM - precheck J2EE_ADMIN password from secure store?

[Former Member]

Hi,

I have to upgrade a dual stack system and am constantly faced with the potential issue of an out-of-sync J2EE_ADMIN password between the ABAP stack and the secure store.

During the upgrade of production systems I would like to reduce the effort and time wasted of being hit with this issue.

Can anyone tell me if it's possible to get JSPM (SDM) to pre-check if it has the correct J2EE_ADMIN password before it starts off down the deployment route?

[Former Member]

Not sure about your question completely. But you can try to login with j2ee_admin via NWA, visual admin and check.

Following note may help you

Note 701654 - Deployment aborts due to wrong J2EE Engine login information

[Former Member]

Thanks. The question is not how to solve the problem of having an incorrect password.

How can I get JSPM/SDM to check it has the right password before I start the patching process?

If you've ever patched a system with a stack update, you know JSPM can take about 5 minutes just to verify all SCA files before it actually starts deploying. Then only some of the files for deployment require the J2EE_ADMIN login.

Couple that with the fact that modifying the secure store password with ConfigTool takes a little experience since you have to make sure that the password is actually removed first. All of this adds complexity to the process when the majority of pre-checking could be done before hand and not during the downtime.

[sunny_pahuja2]

Hi,

You can try to login to SDM if it allows to login in SDM then it means that password in secure store is correct.

Thanks

Sunny

[Former Member]

OK, so I've changed the password for the J2EE_ADMIN user in the secure store using ConfigTool ("File -> Apply" to save).

It's been set to "test", which is not the correct password.

I then restart the entire SAP instance.

When it is up and running I can still log into the SDM.

[peter_dzurov]

Well, I guess you have made some mistake during changing password with configtool..

Please check here:

http://help.sap.com/saphelp_nw04/helpdata/en/ae/b7ceff3e40fd42be3a6503236f9746/content.htm

General approach is that you change password for j2ee_admin in ABAP (in case ABAP stack is used as UME) and afterwards correct it in secure store.

[Former Member]

If you have upgraded JDK during the upgrade then you may want to try deleting following files (take the backup of these files just in case -anyway they will be recreated on the next restart of the engine):

/usr/sap/<SID>/<INSTANCE>/j2ee/cluster/instance.properties.vmprop

/usr/sap/<SID>/<INSTANCE>/SDM/program/config/sdm_jstartup.properties.vmprop

[Former Member]

Thanks. The question is not how to solve the problem of having an incorrect password.

Imagine that I don't know if the J2EE_ADMIN password has changed and I don't know if anyone has updated the password in the secure store.

Are we saying that I have to update the secure store every time I start to patch the system with JSPM? Just because I'm not sure if the password has changed. This is not efficient.

How can I get JSPM/SDM to check it has the right password before I start the patching process?

Is there a command line option to perform a test import?

Is there a command line option for SDM to verify the J2EE_ADMIN password?

[sunny_pahuja2]

Hi,

No, you need not to change j2ee_Admin password everytime.

If you are able to login to SDM/JSPM after providing password then it means that password in secure store is correct.

Thanks

Sunny

[Former Member]

> How can I get JSPM/SDM to check it has the right password before I start the patching process?

> Is there a command line option to perform a test import?

> Is there a command line option for SDM to verify the J2EE_ADMIN password?

Why are you conflating SDM and J2EE_ADMIN? They have separate passwords. To test the SDM password, simply launch the SDM and use the connect icon.

Regards,

Sean

[Former Member]

Hi,

Please read the initial question.

If you have never done a stack upgrade (or changed J2EE_ADMIN password followed by a stack upgrade), then you may not have seen the problem I'm describing.

Thanks.