WCC Feature - Show Starting Conditions - Policy Lookup
Article ID: 205617
Updated On:
Products
Issue/Introduction
We have recently upgraded an 11.3 instance of AutoSys to 11.3.6SP8CUM1 running WCC 11.4.7.20190227-b69 and EEM 12.6.0.5. This instance is connected cross-instance to a different instance which is not using EEM for security.
When the feature 'Show Starting Conditions' is enabled in WCC Quick View settings we find users with cross-instance dependencies are now getting the following error:
/pages/report/startingconditionspanel.xhtml @64,75
rendered=”#{row.satisfied == ‘valid’}”: Error reading [satisfied] on type [com.ca.wcc.quickview.beans.autosys.CrossDependencyJobAtomicCondition]
It looks like WCC is trying to perform a permission check against the instance's EEM for the job listed as atomic starting condition even though that job is not part of the same instance and is not using the same EEM for security - as the naming of the job does not match the same naming convention in instance policies these lookups are failing and the error is generated.
We would like to keep the feature enabled if at all possible as it was available in 11.3 (to the best of our ability to recall) without the extra checks.
Is there a canonical way to allow these cross-instance conditions to show up in WCC without needing to have a policy created to allow the viewing of them? I have tried different filtering approaches for policies in EEM but haven't hit on a perfect one just yet (for example it seems we can't use the carrot symbol '^' in the lookup among other things). If there is another way to identify only cross-instance lookups e.g. via resource class or some other method or even a way to turn the cross-instance dependency policy lookup off entirely so cross-instance conditions just pass through... please let us know.
Environment
Release : 11.3.6
Component : CA Workload Automation AE (AutoSys)
Resolution
Broadcom's development has stated that you would need either as-list or as-job access for the users to see the jobs/status for the xinst jobs.
And the issue with the WCC hanging if they lack access is addressed in WCC 12.0 and above. At this time there are no plans to back port a fix for lesser WCC versions.
Feedback
