Troubleshooting
Problem
The OpenPages with Watson 8.2 release introduced a change to the reporting schema where multi-actor fields are now persisted in a parsed state. This change improves performance of multi-actor related field requests but there are some edge cases that might cause an issue in your environment. The two scenarios are:
1) You attempt to update the reporting schema and encounter an error. When you investigate the logs, the error details look similar to the following:
2) An error is encountered when security rule or filter is modified or when running update reporting schema:
Example of a security rule failure:
Example of a filter failure:
Example of an update reporting schema failure:
Note - While the error indicators for the use cases in Scenario 2 are different, the root cause of these errors all map to the same underlying issue.
Cause
Multi-actor fields are defined by adding the multi-actor selector display type to the field in a profile. When you perform this action, an internal flag is updated to mark the field as requiring reporting schema support. If you later remove this field from all profiles, then a mismatch occurs between the profile definition and the internal flag.
Environment
All environments
Diagnosing The Problem
To diagnose the problem from scenario 1, log in to the database as the OpenPages database user and execute the following query:
select propertydefid, bundlename, name, actor_disp_type_state
from propertydefs p
where actor_disp_type_state in ('S','P','M')
and not exists (select property_def_id
from OBJ_PROF_AT_PROP_DEFS op,
DISPLAY_TYPES d
where op.property_def_id = p.propertydefid
and op.display_type_id = d.display_type_id
and CLASS_NAME = 'com.openpages.sdk.admin.displaytype.ActorSelector')
and not exists (select base_property
from rps_obj_columns
where base_property = p.propertydefid
and mval_obj_id is not null);
If this query returns any rows, a mismatch scenario exists in your environment.
To diagnose the problem from scenario 2, log in to the database as the OpenPages database user and execute the following query:
select propertydefid, bundlename, name, actor_disp_type_state
from propertydefs p
where actor_disp_type_state in ('M')
and exists (select property_def_id
from OBJ_PROF_AT_PROP_DEFS op,
DISPLAY_TYPES d
where op.property_def_id = p.propertydefid
and op.display_type_id = d.display_type_id
and CLASS_NAME = 'com.openpages.sdk.admin.displaytype.ActorSelector')
and not exists (select base_property
from rps_obj_columns
where base_property = p.propertydefid
and mval_obj_id is not null);
If this query returns any rows, a mismatch scenario exists in your environment.
Resolving The Problem
The solution to this issue varies depending on the use case.
For scenario 1, this issue is caused by entries from the diagnostic query showing an actor_disp_type_state of P. To correct these entries, you can either add the field back into any profile or you can execute the anonymous PL/SQL block shown here to correct the data. You can identify the impacted fields by checking the bundle name (field group) and name (field name) columns from the diagnostic query.
Note - If any of one or more impacted fields contain a value of S or M, then you must instead execute the anonymous PL/SQL block to correct the data.
To run the data correction script, log in to the database as the OpenPages database user and execute the following code block:
Begin
For rec In (select propertydefid, bundlename, name, actor_disp_type_state
from propertydefs p
where actor_disp_type_state in ('S','P','M')
and not exists (select property_def_id
from OBJ_PROF_AT_PROP_DEFS op,
DISPLAY_TYPES d
where op.property_def_id = p.propertydefid
and op.display_type_id = d.display_type_id
and CLASS_NAME = 'com.openpages.sdk.admin.displaytype.ActorSelector')
and not exists (select base_property
from rps_obj_columns
where base_property = p.propertydefid
and mval_obj_id is not null))
Loop
OP_OBJ_MODEL_MGR.SET_ACTOR_DISPLAY_STATE(rec.propertydefid, OP_OBJ_MODEL_MGR.gc_Actor_Disp_Not_Actor);
End Loop;
Commit;
End;
/
Once the workaround is applied, you can rerun the failed operation.
For scenario 2, this issue is caused by entries from the diagnostic query showing an actor_disp_type_state of M but the corresponding reporting schema table does not exist. To correct these entries, you must execute the anonymous PL/SQL block shown here to correct the data.
Begin
For rec In (select propertydefid, bundlename, name, actor_disp_type_state
from propertydefs p
where actor_disp_type_state in ('M')
and exists (select property_def_id
from OBJ_PROF_AT_PROP_DEFS op,
DISPLAY_TYPES d
where op.property_def_id = p.propertydefid
and op.display_type_id = d.display_type_id
and CLASS_NAME = 'com.openpages.sdk.admin.displaytype.ActorSelector')
and not exists (select base_property
from rps_obj_columns
where base_property = p.propertydefid
and mval_obj_id is not null))
Loop
Update PROPERTYDEFS p
Set p.ACTOR_DISP_TYPE_STATE = OP_OBJ_MODEL_MGR.gc_Actor_Disp_Multi_Pending
Where p.PROPERTYDEFID = rec.propertydefid;
End Loop;
Commit;
End;
/
Once the workaround is applied, restart the OpenPages application services and then rerun the failed operation.
Note - Running these correction scripts does not impact any customer data. This code simply identifies fields that contain a mismatch and corrects the internal flag used to drive the corresponding process.
Document Location
Worldwide
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSFUEU","label":"IBM OpenPages with Watson"},"ARM Category":[{"code":"a8m50000000ClALAA0","label":"Administration and Configuration"},{"code":"a8m50000000ClB9AAK","label":"Reporting Schema"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.2.0","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Was this topic helpful?
Document Information
Modified date:
28 July 2020
UID
ibm16220540