IDM 10.1.4.3 installed

Just to update everyone those who ere waiting for IDM 10.1.4.3 patchset results. We have successfully implemented this is our test environment and the issue which were reported during 10.1.4.0.1 installation with Kerberose related to "Administer Partner Application" is resolved in 10.1.4.3 patch. Moreover one more issue we found in older version, there were huge error files generation in $ORACLE_HOME/hostname_domain.com_IDM10143/sysman/recv/errors which we didn't found in this patch. I guess those who were waiting can install this one.

Happy Troubleshooting !!!

Responsibility not Appearing

I have some strange issue with one user. This user has 4 resposibilites assigned to him in dev, due to security issue we have to end his two responsibility. Now user want this "Sysadmin Inquiry" responsibility again. I did end date and told him about that. Now after 24 hrs he came back and asked what is the status. That means he is not able to see this responsbility under his ID.I did enable and disable other responsibilities under his id, he can see immediate impact of that. But not this one. Now for checking I did assigned this responsibility to my id and can see it without any issue. I did ran all these
1. Navigate to the define user form (FNDSCAUS).
2. Query up the user (that is having the issue) and insure the responsibility is NOT end dated.
3. END DATE the USER (not the responsibility) and save the record.
4. UNEND DATE the USER and save the record.
5. Run the request 'Sync responsibility role data into the WF table'.6
. Run the request "Synchronize WF LOCAL tables".
7. Run the request "Workflow Directory Services User/Role Validation" (with parameters 10000, yes, yes, yes).
8. Have the user log off and back on and verify that the responsibility appears.
but no help. Not sure why only one responsbility is creating problem for this user. After this got good help from one of the friend in Oracle Forum, he suggested to read note 466135.1, Man it reaaly helped a lot to resolve this issue. Thanks Hussein

Happy Troubleshooting !!!

ActiveChgImp:Error in Mapping EngineODIException: DIP_GEN_INITIALIZATION_EXCEPTION

Seems like this week will go to resolve OID issues for us. We had another issue in our dev OID setup, where synchronization with AD is not happening and log says this:
=======================================================
ActiveChgImp:Error in Mapping EngineODIException: DIP_GEN_INITIALIZATION_EXCEPTION
java.lang.NullPointerException
at oracle.ldap.odip.util.DirUtils.getLastChgNum(DirUtils.java:48)
at oracle.ldap.odip.gsi.LDAPReader.initAvailableChgKey(LDAPReader.java:884)
at oracle.ldap.odip.gsi.LDAPReader.initialise(LDAPReader.java:250)
at oracle.ldap.odip.engine.AgentThread.readerInitialise(AgentThread.java:460)
at oracle.ldap.odip.engine.AgentThread.mapInitialise(AgentThread.java:509)
at oracle.ldap.odip.engine.AgentThread.execMapping(AgentThread.java:375)
at oracle.ldap.odip.engine.AgentThread.run(AgentThread.java:237)
ActiveChgImp:about to Update exec status
Updated Attributes
orclodipLastExecutionTime: 20090518024937
orclodipConDirLastAppliedChgNum: 0
orclOdipSynchronizationStatus: Mapping Failure, Agent Execution Not Attempted
orclOdipSynchronizationErrors: Profile Initialization Failure
============================================================
Metalink note: 276481.1 does help to understand the issue and that is with dipassistance. After checking $ORACLE_HOME/ldap/odi/conf/ActiveChgImp.cfg file we realized the issue. As this is not the correct file. To make is correct. I have to stop our second odiserv instance and disable ActiveChgImp profile from oidadmin.
Once that is done. We again modified the Import Connector profile with correct cfg file. and enable ActiveChgImp profile and start odiserv instance and vola now log file looks better.

Happy Troubleshooting !!!

APP-FND-01564: ORACLE error 31202 in changepassword

We had this issue in our production this morning. Our dedicated sysadmin team were not able to change any user password from frontend. They were receiving following error "ORA-20001: Unable to call fnd_ldap_wrapper.update_user".
Issue came to us and we tried changing via FNDCPASS and in log we saw following message"
===============================================================
APP-FND-01564: ORACLE error 31202 in changepassword
Cause: changepassword failed due to ORA-31202: DBMS_LDAP: LDAP client/server error: Invalid credentials. Password Policy Error :9000: GSL_PWDEXPIRED_EXCP :Your Password has expired. Please contact the Administrator to change your password.ORA-06512: at "APPS.FND_LDAP_UTIL",.
The SQL statement being executed at the time of the error was: begin :r := fnd_web_sec.change_password(:u,:p); end; and was executed from the file &ERRFILE.
================================================================
Message was clear that we had some issue with our OID account. Metalink note id 401836.1 helped us to crack this issue. Issue was appsDN password in OID got expired and we have to reset the password. Here is how to resolve this error:

To implement the solution, login to the E-Business Suite database as the 'APPS' user and execute the following steps:
(1) SQL> select fnd_preference.get('#INTERNAL', 'LDAP_SYNCH','USERNAME') Apps_Instance_OID_Account from dual;
Example:
APPS_INSTANCE_OID_ACCOUNT
-------------------------------------------------------------------------------- orclApplicationCommonName="MYAPPSINSTANCE",cn="EBusiness",cn=Products,cn=OracleContext,dc=mycompany,dc=com (2) SQL> select fnd_preference.eget('#INTERNAL', 'LDAP_SYNCH','EPWD','LDAP_PWD') Apps_Password from dual;
Example:
APPS_PASSWORD
-------------------------------------------------------------------------------- mypassword1
(3) Now test the above credentials with ldapbind,
Example:
> ldapbind -h -p -D orclApplicationCommonName="MYAPPSINSTANCE",cn="EBusiness",cn=Products,cn=OracleContext,dc=mycompany,dc=com -w mypassword1 invalid credentials
Password Policy Error :9000: GSL_PWDEXPIRED_EXCP :Your Password has expired.
Note: If above returns the same password expired message, then login to oidadmin (Oracle Directory Manager) and expand Entry Management and navigate to the Apps User DN entry expanding backwards on the DN, ie:
+ dc=com
+ dc=mycompany
+ cn=OracleContext
+ cn=Products
+ cn="EBusiness"
+ orclApplicationCommonName="MYAPPSINSTANCE"
And type the same password returned from the sql query on step 2 as value for userpassword attribute, then click Apply.
(4) Then retest the previous ldapbind and it should now work:
> ldapbind -h -p -D orclApplicationCommonName="MYAPPSINSTANCE",cn="EBusiness",cn=Products,cn=OracleContext,dc=mycompany,dc=com -w mypassword1
bind successful

Happy Troubleshooting !!!

Better way to check Applied Patches

Being an Apps DBA patching is our bread and butter. And they way we check it make the difference. We had one issue and I was going through metalink note : 364439.1, which had this query. So thought of sharing with you all. Here you go:
===================================================
set serveroutput on
DECLARE
TYPE p_patch_array_type is varray(10) of varchar2(10);
--
p_patchlist p_patch_array_type;
p_appltop_name varchar2(50);
p_patch_status varchar2(15);
p_appl_top_id number;
--
CURSOR alist IS
select appl_top_id, name
from ad_appl_tops;
--
procedure println(msg in varchar2)
is
begin
dbms_output.enable;
dbms_output.put_line(msg);
end;
--
BEGIN
open alist;
--
p_patchlist:= p_patch_array_type('3240000','3460000','4204335','4125550','3942483','4733943');
--
LOOP
FETCH alist INTO p_appl_top_id,p_appltop_name;
EXIT WHEN alist%NOTFOUND;
--
IF p_appltop_name NOT IN ('GLOBAL','*PRESEEDED*')
THEN
println(p_appltop_name ':');
for i in 1..p_patchlist.count
loop
p_patch_status := ad_patch.is_patch_applied('11i',p_appl_top_id,p_patchlist(i));
println('..Patch ' p_patchlist(i) ' was ' p_patch_status);
end loop;
END if;
println('.');
END LOOP;
--
close alist;
END;
/
===========================================================

Sample Output
---------------------------
Server1:
..Patch 3240000 was NOT_APPLIED
..Patch 3460000 was EXPLICIT
..Patch 4204335 was NOT_APPLIED
..Patch 4125550 was EXPLICIT
..Patch 3942483 was NOT_APPLIED
..Patch 4733943 was EXPLICIT
.
.
Server2:
..Patch 3240000 was NOT_APPLIED
..Patch 3460000 was NOT_APPLIED
..Patch 4204335 was NOT_APPLIED
..Patch 4125550 was EXPLICIT
..Patch 3942483 was EXPLICIT
..Patch 4733943 was NOT_APPLIED
.
.
Server3:
..Patch 3240000 was NOT_APPLIED
..Patch 3460000 was NOT_APPLIED
..Patch 4204335 was NOT_APPLIED
..Patch 4125550 was NOT_APPLIED.
.Patch 3942483 was NOT_APPLIED
..Patch 4733943 was NOT_APPLIED
---------------
Happy Troubleshooting !!!