Using multi-search functionality from one field in any Visual Composer application

[Former Member]

Title: Using multi-search functionality from one field in any Visual Composer application 

Introduction

Have you often wondered how to let end-users search in multiple back-end fields from just one field in the user interface without having to make any code-changes in the associated BAPI. This blog shows how this can be done without BAPI coding based on a Visual Composer-based cocktail of adding fields, writing formulas and using a filter to enable the search. In my opinion, this modeling pattern gives the user a better search experience without forcing them to use a complicated UI.

Details

My basic model is a classic “Sales order” model using the BAPI (BAPI_SALESORDER_GETLIST), where I display order headers in one table and a second BAPI (BAPI_SALESORDER_GETSTATUS) to /--display order line(s). For each of the BAPIs, I added an output table. I have added an input form called “Input”.

  "  

One customer requirement was to display sales orders and to be able to search for specific sales orders via date-intervals and via a single free-text search field.

  Label: Fields available from the Search Form in Layout mode  "  Label: How the fields in the Search Form look like 

To achieve the desired functionality, I use the  following using the BAPI (BAPI_SALESORDER_GETLIST) labeled “Salesorder Getlist”.

 

1)      Assign the values to the BAPI (Customer_number, Document_date, Document_date_to, Sales_organization) with a combination of data from the “Input” form and “User data” from login in the portal (not showed above for simplicity)

2)      Create a field in the output port of the BAPI – named “Test Search”. Click “+” to add the field and then enter the formula window in “Compute”.

Label: Create field and enter formula                      

Label: Formula in the field “Test_Search”                

3) In the formula window, I enter the following text using the formulas IF and CONTAINS in combination.

 

IF(CONTAINS(@PURCH_NO, TRIM(Search_Field))

OR ISNULL(TRIM(Search_Field)), "t", IF(CONTAINS(@SD_DOC, TRIM(Search_Field))

OR ISNULL(TRIM(Search_Field)), "t", IF(CONTAINS(@MATERIAL, TRIM(Search_Field))

OR ISNULL(TRIM(Search_Field)), "t",  IF(CONTAINS(@SHORT_TEXT, TRIM(Search_Field))

OR ISNULL(TRIM(Search_Field)), "t", "f"))))

 

In this way, I create an entry for EACH record passed through the BAPI that checks to see if it meets the search criteria entered in the “Input” form. If the user enters a very broad search string (for example “2”), the search will probably return a lot of entries from the BAPI fields - SD_DOC, MATERIAL etc. On the other hand, the user can narrow the search to a specific material number like “59535001” or a description like “Jamaica T-Shirt”, and the search will return fewer hits.

4)      Last step is to filter the values when displaying the results using the Filter found in the “Compose” section.  

 

Label: Using a filter in the model

 

 

Label: Filter criteria Examples 

An example of retrieval of all orders matching the search string “23”:

  " "

"  

Label: Output when searching with string “23”

Note that the string is also found in the subsequent BAPI with the order details, where the material number contains the string “23” anywhere in the respective order lines.

A search can also be performed of course which can be demonstrated in the following small screenshot where it is the field purchase number.  For the user, the technical details of search are transparent and the search UI permits great flexibility and increased usability.

  

Conclusion

The beauty of this modeling pattern is that you can let the user search on various back-end fields without creating a confusing user interface. Furthermore, this is done entirely without any back-end configuration and ABAP programming knowledge. It might adverse effects on performance compared to restricting the data in the back-end, because you actually retrieve all data and then filter them before displaying them. For demo purposes and for smaller amounts of data, it is very useful to be able to filter the data in the front-end.

 

If you either do not have access to a BAPI developer resource or find it more useful to be able to configure the model yourself, I find this way a useful approach. On the other hand, if you have to make a custom BAPI anyway, i.e. if the BAPI you want to use does not exist or does not provide you the desired input/output fields then it will be a better approach to make the same selection/search criteria available “inside” the BAPI. By providing a useful implementation in VC, you can communicate a lot better with a developer team to show the desired functionality when “ordering” a custom BAPI. In my projects, I have tried both varieties, customizing only in VC and ordering custom BAPIs and by mixing the two strategies you have more tools to ensure a timely and low cost implementation for the customer.

 

Please do not hesitate to contact me with questions or developer issues regarding this model. I would be happy to know whether you found it useful and/or understandable.

 

Jakob Diness, Consultant Invendium A/S