This is a public Forum  publicRSS


    Vinay Kumar
    How to pull Loaded Entity Instances from OSC into OPA...
    Topic posted August 20, 2018 by Vinay KumarExplorer 
    215 Views, 6 Comments
    How to pull Loaded Entity Instances from OSC into OPA DropDown as List Values

    I am loading OSC Data to OPA Attribute as instances based on Entity Condition.How to pull Loaded Entity Instances from OSC into OPA DropDown  as List Values.  For Example, i am loading 10 Vehicles based on Model Condition. How to display these loaded 10 Vehicles under One-DropDown. I want to see that 10 Vehicle Numbers under that Drop-down.Is it Feasible in OPA Configuration or need to approach through Java Script?



    May 01 2018



    • Matt Sevin

      Apologies, but I don't follow the question.   OPA Entity instances and attributes are two different things.   An Entity may have many attributes.  A specific instance of an entity may have 1 value for each attribute.   Entities are related to one another through relationships (e.g. "The vehicle's owner" is a relationship between the vehicle and the person) A specific vehicle is owned by a specific person).

      If vehicles in your model are already instantiated, then a drop-down list of those vehicles would be being used to relate one or more of those instances to some other entity (e.g. "the person's vehicles"  in which the person is known and the drop down is asking "which of the vehicles are owned by this person?").  Such a drop down would be collecting a "relationship" and not have anything to do with an attribute of either the person nor the vehicle (other than the vehicle's have an identifying attribute which would appear in the drop-down list to differentiate between the instances).

      See this topic for more info:


    • Blessing Matore

      Hi Vinay, there is no out of the box way to do this in OPA. Javascript is the only way to get this to work. 

    • Vinay Kumar

      Hi Matt Sevin,

      I Can't see any Option to make Reference relationship control Mandatory in OPA Interview Tab. for now i created a reference relationship and able to pull loaded OSC Instances to Reference relationship  dropdown and can't able to make it mandatory. I do have one complex scenario, from OSC Object i am Loading Category,Sub-Category,Sub-category-Description as Instances based on Entity Condition.Now,Based on Category,the Dynamic load of Sub-category should happen and again based on Sub-Category the Dynamic Load of Sub-category-Description in Drop-down should happen.For Example,Based on Entity Condition Category instances are 1,2 & Sub-category Instances are A,B,C,D and Sub-category-Description Instances are a,b,c,d. Now for Category-1,it Loaded  Subcategory-A,B,C,D  and for every Subcategory-A,B,C,D it should be shown with Sub-category-Description - a,b,c,d as drop-down values.
      Any Idea on this will be very helpful for me

    • Matt Sevin

      For mandatory, see:

      For multi-value hierarchical lists, see:


    • Vinay Kumar

      Hi Matt Sevin,

      Thanks a lot for sharing your knowledge. In Control State Button Option, there is no Option to make a Reference Relationship Control Mandatory(As Drop Down) that collecting Instances loading from OSC on Entity Condition.In Documentation,it was mentioned that Reference Relation can be made as Mandatory. PFA Attached file where you can see where Reference relationship on Interview collecting Instances has only options Show or Read-Only in Control State Button.

      Coming to  multi-value hierarchical lists, our requirement is dynamic load of Category,Sub-category,Description will be loaded as Instances to that Entity not as Value-Lists of that Metadata Connection. Dynamically Loaded Instances of Category,Sub-category,Description  should be shown as three drop-downs on OPA Interview.To Create Value lists,Values in drop-down on OPA Interview are not Static Values as Values in the drop-down are Dynamically loaded Instances of Entity. Is there any feasibility to go with OPA Functionality or need to go with Java Script? 

      For Example it's like Country,State,City are loaded as Instances of Entity based on Entity Condition from OSC. Now, Country,State,City Instances of that entity should be in a there different drop-downs where Cities are Filtered by State and States are Filtered by Country.

    • Matt Sevin

      The shown control looks like part of an entity collect and not a reference relationship control.

      What is the reference relationship you are trying to collect that you cannot make mandatory?  (i.e.  Please share the specifics form the model related to the source and target entities as well as the containment relationships in which each of those entities "exist")   A reference relationship "selects" instances from a known set to participate in the relationship with the source entity instance.  Seems as though you may be attempting to do something similar with Category, subcategory, etc. 

      Sounds like "lists" was off-target with respect to Category,.etc.:  If you are loading instances to be selected from, then you should be collecting a relationship between one entity and another or more specifically "relating" instances of one entity to an instance of another.  (i.e. Family is an entity, Children of the family are know and the reference relationship being collected (i.e. the family's eldest child) might prompt with Select the eldest child of the family).  This approach works with selecting from known instances of the target entity in the context of the source entity screen.  

      For dynamic loading during an interview see:

      However, note that dynamic loading is often used to load the set (or subset) of possible instances and a reference relationship is still needed to represent and collect the "selected" instance from the set of possible instances.  (e.g. Dynamic loading might load all allowable subcategories based on a known category,  but for a specific incident, a reference relationship between the incident and the sub category must be selected in order to represent which subcategory is relevant to this instance of an incident).

      There are many different approaches to representing and collecting such information. As the complexity increases it becomes even more important to have a well-considered design to enumerate the possibilities, identify which approaches will be used and why, as well as clearly identify the entities, relationships, attributes be used and what each represents (including which must be known (system inputs) and which are to be collected (user inputs) and which are to be determined by rules (determinations).  Perhaps a review of your policy model design should be done to ensure you have the necessary instances being loaded and reference relationships in place to collect on screens. (Note: Reviewing or commenting on such a design document would be beyond the scope of a forum and best performed with or by experienced and preferably certified OPA consultants).