OSI / OTI table data mismatch, OTI being subset of OSI

Question

Hi,
We have a custom application where we fetch count and data for all provisioning records assigned to logged in user.
To fetch details of open provisioning tasks, Oracle recommendation is to use OTI table.
When we studied current system, we had below findings regarding behavior of OSI and OTI tables -
1. When request is submitted to OIM, approval process is triggered depending upon approval policy.
2. this workflow is responsbile for creating approval tasks.
3. when approval tasks are approved, request in OIM is closed and provisioning task for the system gets created.
4. OIM database tables which are used to fetch these provisioning tasks are OSI/OTI.
5. According to Oracle documentation, OTI table is subset of OSI table.
6. when we checked both these tables, we found that entry in both these tables is not exactly same.
7. For a particular request, OSI table had OSI_ASSIGN_TYPE as 'Group' and OTI table had OSI_ASSIGN_TYPE as 'User'.
8. As OTI table has osi_assigned_to_ugp_key value as null, this table cannot be used.
Iit looks like OTI table does not hold correct data. And OSI table has around 9.6 million records. So when we query OSI table we get correct data but it takes 6min to get the data.
We are now looking for the issue why there is this mismatch and how can it be solved ?
Regards,
Deepika

Answer 1

Hi Kevin,
Thanks for these details.
We would try this query in our environment and see the result.
But regarding OSI /OTI data mismatch, i understand that OTI contains tasks that are still opened, like Rejected, and Pending. And these tasks are also there in OSI, when we check the record in OSI those tasks are assigned to user while when we see same record those are getting assign type changes.
Is that intended functionality or is it something wrong here.
Because of this we cannot get correct data directly from OTI table and have to use OSI(which is hampering performance)
This is the query that we are using:
select distinct oti.orc_key, a.usr_login, (select min(inner.oti_create) from oti inner where inner.orc_key = oti.orc_key)
as oti_create from oti inner join oiu on oti.orc_key = oiu.orc_key inner join usr a on oiu.usr_key = a.usr_key
inner join osi on oti.sch_key = osi.sch_key where sch_status in ('P', 'R') and obj_key in
(select obj_key from obj where obj_name in ('DB App', 'K2 App', 'LDAP App', 'SPML App', 'Manual App'))
and (osi.osi_assign_type = 'Group' and osi.osi_assigned_to_ugp_key in
(select ugp_key from usg where usr_key = " + Long.toString(Oim.getCurrentUser().getKey()) + "))
UNION ALL
select distinct oti.orc_key, a.usr_login, (select min(inner.oti_create) from oti inner where inner.orc_key = oti.orc_key)
as oti_create from oti inner join oiu on oti.orc_key = oiu.orc_key inner join usr a on oiu.usr_key = a.usr_key
inner join osi on oti.sch_key = osi.sch_key where sch_status in ('P', 'R') and obj_key in
(select obj_key from obj where obj_name in ('DB App', 'K2 App', 'LDAP App', 'SPML App', 'Manual App'))
and (osi.osi_assign_type in ('User', 'Default task assignment') and
osi.osi_assigned_to_usr_key = " + Long.toString(Oim.getCurrentUser().getKey()) + ")
order by oti_create
Regards,
Deepika