In my current Project we had to deal with conditions, we had to add custom fields in the pricing field catalog and make available those fields in the Web UI.
If anyone worked before with the pricing field catalog, you should know the behavior of those fields is controlled with the BADI /SAPCND/ROLLNAME ( check values, translate the data from external to internal, search help, etc. )
In this blog I will focus on the search help. For more information about the BADI I suggest to check the BADI documentation and the interface documentation (/SAPCND/IF_EX_ROLLNAME) it’s pretty well explained, this BADI is widely internally implemented, so you can also take a look to all the classes which implements this interface via SE80 or Eclipse in order to understand better how it works.
The GAP which I found is how complex Search helps can be implemented in the Web UI. The method F4_HELP only covers complex search help in SAP GUI (using the common functions inside the method to call search helps) this method only will work for you if you want to show a list of values in the Web UI which only have two available fields (key and description), one good example is the implementation CRM_SALES_INDUST_CND which uses the class CL_IM_CRM_COUNTRY_CND, which covers both scenarios, SAP GUI y Web UI.
Now I will talk about my journey to implement a complex search help in the Web UI, where all my fun started.
If you check the component/views for conditions CRMCMP_CND/CondRecEditConfView and CRMCMP_CND/CondRecEditListView, first of all I would recommend implementing the Note 1575115 – Enhanced setter method not getting called, if you will deal with those views and the note Note 1731897 – Incorrect F4 help for date related condition field, if you deal with custom fields in the pricing catalog which are date typed.
Well, getting back to the complex search help of custom fields in the views CRMCMP_CND/CondRecEditConfView and CRMCMP_CND/CondRecEditListView, if you check the configuration, you will see is generated dynamically from the pricing fieldcatalog merging the XML so you cannot configure the views.
If you analyze further the get_config_from_fcat you can also understand why some fields are mandatory and how you can do in customizing to make them non-mandatory, But getting back( again ) to the search help topic, it is also dynamically determined in the context node class. I was really surprised to don’t see a single GET_V method implemented so I started to analyze where it came from….
Finally I found the class CL_CRM_CND_F4_CALLBACK which has the method IS_SIMPLE_F4_HELP_DENIED where are mapped the fields/domains with the events in the view, so actually the complex search help are developed in the Web UI( BADI independent).
I raised a message to SAP in order to clarify this point, but until I received the response of SAP I created a enhancement spot in the beginning of the method IS_SIMPLE_F4_HELP_DENIED to overwrite the values in the internal table with the ones provided by the standard plus my own ones (from a customizing table).
I know maybe is not the best approach but was the only way which I could assure the search helps pointing to my custom fields will work properly in the Web Client, allinged how the standard is working,
Those are my guessings how the internal table which manages this information works:
|context||Value for the context, leave cc_default_context|
|fieldname||Context node attribute name|
If is not initial, will use the list of values provided by the badi /SAPCND/IF_EX_ROLLNAME F4_HELP so the event or the implementation
of the GET_V method won’t be executed
|use_advanced_search||If is ‘X’ will triger the event as output plug doesn’t apply if you an already implemented GET_V method|
|is_date_field||You don’t need to care about this, In the case which you are using a date type search helps works without all this stuff|
|event_name||The view controller event name, In the view CRMCMP_CND/CondRecEditConfView you also need to have an Outbound plug( don’t forget to make it public 😉 ) with the same name defined, doesn’t apply if you have an already implemented GET_V method|
Voila! Everything worked fine.
Without this workaround complex searh help won’t work on conditions component( this is confirmed by SAP ), I hope SAP will deliver a BADI to solve this, until then… 😈
I recommend use allways the component searches as popup instead of converting the dictionary search helps into Web UI format (GET_V, CL_BSP_WD_VALUEHELP_F4DESCR) why? Personally I think they are more use friendly and perform faster, but more important: is the only way that will work in both types of view (single and tableview) due the tableview is very dynamic, can hold different types of condition, and each type can have more or less avaliable fields dealing with the conditions tableviews is a complete pain, because doesn’t fully relay on the Web Client contex node development princpiles.
A good example is mi next post: Enable/Disable Conditions fields in Web UI