This definitely looked like issue with Standard Manager. But bouncing
Standard manager didn’t resolve the issue. Later on I decided to bounce
CCM tier but that also didn’t help.
Later on I looked into the specialization rule defined for Standard Manager and found that one of the developers had defined a specialization rule ‘INCLUDE’ for this manager for one of his concurrent program. And this was the root cause of all issue.
A specialization rule such as ‘INCLUDE’ which is used in the standard manager, tells the manager to process ONLY those requests whose job is specified in the INCLUDE rule. It drastically limits which programs the Standard Manager is supposed to process.
By default all jobs are defined to be handled by Standard Manager unless a specialization rule ‘EXCLUDE’ is explicitly defined. Hence in our case, both the reported requests/jobs are not defined with EXCLUDE in Standard Manager, they were going into ‘Inactive No Manager’ status. ‘INCLUDE’ is NEVER defined for Standard Manager.
Once the ‘INCLUDE’ specialization rule is removed, jobs started getting processed normally under Standard Manager.
Later on I looked into the specialization rule defined for Standard Manager and found that one of the developers had defined a specialization rule ‘INCLUDE’ for this manager for one of his concurrent program. And this was the root cause of all issue.
A specialization rule such as ‘INCLUDE’ which is used in the standard manager, tells the manager to process ONLY those requests whose job is specified in the INCLUDE rule. It drastically limits which programs the Standard Manager is supposed to process.
By default all jobs are defined to be handled by Standard Manager unless a specialization rule ‘EXCLUDE’ is explicitly defined. Hence in our case, both the reported requests/jobs are not defined with EXCLUDE in Standard Manager, they were going into ‘Inactive No Manager’ status. ‘INCLUDE’ is NEVER defined for Standard Manager.
Once the ‘INCLUDE’ specialization rule is removed, jobs started getting processed normally under Standard Manager.
Query to check the specialization rule defined for any concurrent program
SELECT decode(A.INCLUDE_FLAG,'I','Included','Excluded'), A.QUEUE_APPLICATION_ID, C.USER_CONCURRENT_QUEUE_NAME, B.CONCURRENT_PROGRAM_NAME FROM APPLSYS.FND_CONCURRENT_QUEUE_CONTENT A, APPLSYS.FND_CONCURRENT_PROGRAMS B, APPS.FND_CONCURRENT_QUEUES_VL C WHERE type_id = b.concurrent_program_id and b.concurrent_program_name = '&prog_Concurrent requests show Inactive No Manager? Then?
Solution:
1. Get the request id from the user,
2. Go to SYSADMIN --> System Administrator --> Others --> View Requests screen, search for the request. Click on Tools --> Manager log to see under which manager this program is being executed. Check the status of the manager in Concurrent --> Manager --> Administer and take necessary action.
3. If the Manager screen doesn't show any entry, this means the program is not attached to any manager. The application team needs to include this program under one of the managers.
All Concurrent Requests Have Status of Inactive No Manager
symptom: All concurrent requests have status of Inactive No Manager
cause: The cause of this problem is still undetermined.
Solution:-
1. Deactivate manager
2. Remove all specialization rules
a. Login to Oracle Applications as System Administrator responsibility
b. Navigate to: Concurrent > Manager > Define > Query for desired
manager
c. Click Specialization Rules tab
d. Delete entries
3. Activate manager
4. Add specialization rules back
a. Login to Oracle Applications as System Administrator responsibility
b. Navigate to: Concurrent > Manager > Define > Query for desired
manager
c. Click Specialization Rules tab
d. Add entries
No comments:
Post a Comment