This is a public Idea Center  publicRSS

Idea

    OPA - Web Services - Ability to retrieve data model with OPA...
    Idea posted June 15, 2018 by Orlando RodriguesRegular, tagged Policy Automation 
    45 Views, 3 Comments
    Title:
    OPA - Web Services - Ability to retrieve data model with OPA names
    User Story / Description:

    Hi,

     

    Currently, the assess operation has ListGoals method which allows to retrieve goals. The batch assessor can retrieve data model but only with public name.

    In order to generate a data model dictionary, we would need a functionality to:

    - get all input, intermediate and output attributs

    - their public name

    - their opa name

    - their type

     

    Cheers,

    Orlando

    Comment

     

    • Davin Fifield

      Hi Orlando,

      1) What will you use the data dictionary for? Static validation of hand-coded calls being made from another system? Or something else?

      2) In addition to the basic type (text, boolean, currency, date etc.) would you want to know any validations in place for attributes, too? E.g. min/max values and regular expressions.

      4) Would you want know about value-lists types - including the list of values defined?

      5) Why do you need intermediates?

      6) Do you want everything in the OPA data model, regardless of whether it has a public name or not? If so, why?

      7) What do you plan to use the attribute text for? Boolean attributes have a positive form (the person is eligible) but also has other forms (the person is not eligible, the person might be eligible) - would you want those other forms, too? 

      If you can provide some answers to these questions, we will know whether what you are asking to fits into some features we have already been thinking about adding.

      Thanks,

      Davin.

       

    • Orlando Rodrigues

      Hi Davin,

      Sorry for the delay but I did not have access to my CNAF mailbox.

       

      The idea is to build a dictionnary available for all OPA developers to avoid creating attributs with differents names and public names across projects with the same functional use.

      The validation use could be a bonus but not really in our scope as we try to not use them (they are more linked to web determination which is strategicly not to be used in the future for cnaf purposes).

       

      Intermediates are important because a lot of intermediate functional attributes can be used across various projects (aka age from date of birth which is used to know if the person as legal age).

      Value list can be a serious plus and bonus to be available across project and use the sames codes and values.

      For the other forms as interrogative or negative, not really in our idea as the idea is to have the opa name across project. The way it can be displayed in the decision tree or in web determination is not linked to out need.

       

      Feel free if you need other clarification.

      KR,

      Orlando

    • Davin Fifield

      Orlando,

      It sounds like you want to use this to check the data model of a project after it is deployed.

      If you could help rule authors avoid adding them in the first - i.e. during development - would that be even more useful?

      Inclusions allow shared data model elements to be provided to more than one Policy Modeling project - are you already using them? 

      Davin.