Hi Everybody,
Not long ago I've asked carsten.ziegler.
Refactor tool for used expression, i.e. to edit all the BRFplus objects which are using/referring expression A to refer to expression B instead (with the same result type, of course).
For example, replacing formula expression 'Max Limit' (which is being used in many other expressions/rules) with new decision table expression.
Option for Quick search of component (name) while Structure object is displayed.
Currently, there isn't any find component and you have to scroll down and search the component manually, even if the structure is consists of hundreds of components (elements).
When you create two structure data objects with same data type, all their elements are created with the same texts (and name).
As a result, when you use one of these elements and other BRFplus expression/rules, it is hard to tell which structure they are referring to.
My solution was to enter for each and every used element and rename it by adding some prefix.
It would be to have an option to add prefix for all the structure elements in the structure level.
a. Option to define local variables in loop expressions.
Sometimes you have to make some complex calculations during loop expression. These might require some internal variables which aren't relevant to the external context nor expression result.
b. Initialization block before loop for internal initialization of variables/result before loop is processed.
Currently it requires preliminary handling in external rule.
Additional function in all "Select Expression" context-relevant menus for quick selection of Constant expressions, restricted by the element/date type.
I like to use Constants expression for better readability, maintainability and tractability (where-used). However, using them might be a little pain in the *** since you have to search them manually each and every time via "Select expression". Quick search of relevant-only constants would make the life much easier.
New simulation mode which allow you to find the matching percentage of decision table (How many columns has matched their condition) in order to find the nearest/best nominate for complete match. In this mode all table columns would be processed regardless if column condition was met or not.
This might be really useful during QA phase for analysis of decision tables with many columns and tens/hundreds of rows. In case that no match was found due to some error it is really hard (almost impossible) to find out what is the reason behind it since you cannot tell which rows have nearest match.
Option for setting the whole table in editable mode (only for direct values?).
Currently, edit is possible only in cell or row level, but sometimes you are required to make some quick changes for multiple rows. The best option for now is using the Export/Import from Excel, but it also spent some time.
Allowing quick drag and drop of cell value of one row to cell of the same cell (of the same column).
Newer WDA table controls provide a Search / Find component automatically, plus a lot more (sorting, Excel export, fixed columns, client-side scrolling, dynamic data loading, ...).
Thanks to jrgen.lukasczyk for suggesting this point.
Currently, When decision table with expressions in cell values is exported to Excel, the expressions are evaluated as object ID. It is impossible to understand what lies behind these IDs out of BRFplus (Excel in this case).
It would be nice if the expression description will be added to the cell value as comment, for documentation purpose only. e.g. 005056B500281EE395BD44D3095C2BC2 (Customer Rank).
When the Excel will be re-imported, these comments will be ignored.
Values tables (Code + description) are really useful in SAP in general and in BRFplus in particular.
When the business user is the one who is responsible to maintain these values (and BRFplus is being used), the most natural "maintenance view" would be BRFplus decision table.
However, many times these values should be used both in BRFplus and in the outer world. The problem is the fact that BRFplus objects aren't exposed to DDIC (in a simple manner, at least), so "native" ABAP objects/program cannot make use of them easily.
Therefore, the only/simplest option in such cases is maintaining the values in standard DDIC table (probably via maintenance view).
It will be nice if BRFplus -> DDIC integration can be achieved somehow (currently only DDIC -> BRFplus is supported).
One option I may suggest is creation of a new dedicated/naive BRFplus decision table (only with direct values/constants) which generates automatically a mirror DDIC DB table.
What do you think?
Would you like to share any of your own ideas?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |