Legacy Business Object v3.x to v6.5 introduced the @prompt variable to parameterize the universe and reports. This design gave rise to reporting flexibility. Many users built very creative reporting solutions with the use of the @Prompt variable across declarative reporting templates. This variable code can look very confusing at first but over time it will be easy to read. An example would look like
report_country = @Prompt(‘enter Country’,’A’,’Location/Country’, Multi, Free)
The general format of the original prompt is
@Prompt(‘Parm1′,’parm2′,’parm3’, parm4, parm5)
Parm1 = ‘Prompt Text: Enter the text that will be displayed for the end user when prompted
Parm2 = ‘Prompt Type‘ (i.e. A,N,D,U)
A= Character, N= Number, D= Date, U= Unit.
Parm3 = ‘Class Name/ Object Name‘ or {‘static value1′,’static value2’ }
Parm4 = ‘Multi/ Mono‘
Multi allows user to select Multiple: Example year IN (2018,2005,2000)
Mono allows the user to make one selection ( Example year = 2020)
Parm5 = Free/Constrain
The user is allowed to Type a value OR the user must select value in LOV
The user will be able to select one or multiple value instead of entering them manually.
Today you can use the prompt wizard that has some extended prompt features.
Keep Last Value selected: Will keep the last value entered by the end user selected.
Select only from list: end user will not be able to enter any data manually and he will just forced to select from the list of values. of course this option will be enabled only of we selected the prompt with list of values option.
Optional prompt: If this option is selected the end use will be able to skip this prompt. the value will be considered only if the end user selected a value for this prompt.
Advanced Side Notes:
- Universe Design Tool (UDT) or AKA legacy BO designer will work best with the 5 main parameters. If you do not use these extra parameters in the designer that will parse OK. Infact sometimes it might not recognize all the 8 parameters so it is best to stick to the main 5 at the universe level but it will work fine with all 8 Parameters.
Example @Prompt(‘1) Enter Country Name’,’A’,’Country Dimension\Country Name’,multi,free,[Not_Persistent],[<{default_value(s)or leave_blank}>],[User:#])
Prompt Persistence: Default value is “Persistent”; however, the value “Not_Persistent” is needed on the prompt value for any Personally Identifying Information (PII). WebI report writers want to use this syntax but the designer might fault this as a parameter issue in UDT or Designer. Using “Not_Persistent” removes the last prompted value in the report parameter. It force purges the value. This can be very important for security and regulatory reasons. Leaving values especially if it is personal data can open up possible General Data Protection Regulation (GDPR) issues.
Default Value(s): If left blank no default value used. If a value or values is desired then the set should be surrounded by { } characters and separated by commas (much like hard-coded LOV values earlier in the @Prompt parameters). This optional parameter can serve as a manual override to the values coming from the database and short list the values to do so row level security or simplification in your Web Intelligence report prompt. Some Report Developers find that using this option with the “Not_Persistent” option provides business value in the workflow of the webi reports.
User:#: This is very useful when you have more than 1 prompt that appears when the refresh is invoked. It allows the business objects universe developer to define the relative order of the prompt. If two prompts have the same “User:#” value then they are sorted alphabetically. This is typically coded at the report level since the UDT might complain about the prompt values depending on which part of the SQL predicate the prompt parameters is being evaluated.
- As of BO v4.1.x usage of LOV parameter ie Parm3 if used in a derived table will not parse. I suspect the SQL regeneration will parse the @Prompt in the FROM clause instead of the WHERE predicate. While it can do so without error if the LOV (parm3) is blank or with static default values, it will fail while trying to parse a valid LOV ‘class/object’ in the derived table.
