Troubleshooting of presets access failure in Documentum

It is speechless. After updating a version to Webtop, it is found that the presets under administration are unavailable and become gray. In fact, the presets are still available when the original Webtop is used for access.

There is no other way, so we have to start tracking step by step.Source codeUnder the presetutils class, you can find an ispresetrepositoryaccessible function. log on to login and use the generated session as the basis for the next step. The login user and password are obtained in this way:

Idflogininfo logininfo = new dflogininfo ();

Logininfo. setuser (presetcontext. getpresetrepositoryusername ());

Logininfo. setpassword (presetcontext. getpresetrepositoryuserpassword ());

Logininfo. setdomain (presetcontext. getpresetrepositoryuserdomain ());

I'm curious. I want to see what I got through context and print out the corresponding content. The result is surprising. Here I get the user and password, it is not the user and password of the Administrator we log on to, but the default user specified by another system: dmc_wdk_presets_owner. The password is also the default value: Webtop does not know where it was obtained, I used it to log on to the system first, but it was unsuccessful. I remembered that I had modified the user's password before, causing login failure. Step by step.

1. Restore the password of the dmc_wdk_presets_owner user to Webtop;

2. log in with the modified username and password again. The logon is successful;

3. Restart the javamethods and tomcat services;

4. log on to Webtop with the Administrator account again.

OK. Presets can be viewed and used normally.

 

Note that the docbase Information read by presets during login is from DFC. properties file, so make sure that the corresponding docbroker information is clearly specified in our DFC configuration file. Similar to the following format

Dfc.doc broker. Host [1] = 192.168.1.xxx

Dfc.doc broker. Port [1] = 1489

DFC. globalregistry. repository = xxx

DFC. globalregistry. Username = xxxx

DFC. globalregistry. Password = xxxxxx

We have been tracking this issue for several hours. The cache + meaningless password modification + the properties files in my tomcat are inconsistent. What else can we say. Together

I don't know if there are other causes of this problem. I will explore it later ......