I posted several blogs in the past that covered how to us the filterCriterion property of a service data provider (SDP) in order to filter the results you see in a table or a list including how to use compound conditions for advance filtering. This works great with REST services that are exposed on the business objects you created in Visual Builder, but if you'll try and use this filterCriterion approach with other REST services, you'll notice it doesn't work out of the box. In this blog I'll show another approach to filtering REST services that populate a service data provider.
First, a bit of explanation on what's going on behind the scenes when using the filter criteria. If you'll monitor the REST calls used with filter criteria, you'll notice that it generates a URL parameter that will look something like ?q=dname='Marketing' . Basically the filter criteria generates a URL parameter called q and formats your conditions correctly for that parameter.The REST services we expose on business objects know how to parse and use this q parameter (read more about the q parameter and its query capability here). Filtering is done on the server side, and the records that match the condition are returned to the client.
(Important to know - REST services exposed from ADF Business Components - such as the REST services exposed by many of our SaaS apps - also support the usage of the q parameter. If you are planning on leveraging these type of services in your app, make sure to add them using the ADF Describe option in the "Service from Specification" wizard - as shown in this blog.)
But not every REST service out there knows how to parse the q parameter. In fact, most of them won't know what to do with a q parameter passed to them - they'll probably just ignore it. They will be expecting the information about what exactly you want them to return using some other URL parameters.
One approach to handle this will be for you to translate the filter criteria structure to the format they are expecting to get. You can do this by defining a service transform on your service as explained here. Such transformation can also let you support sorting and pagination with SDP based tables.
In the video below, I'm using an alternative approach to get filtering to work directly passing the expected URL parameters for filtering to the service. Note that using this approach rather than the above mentioned "transformation" approach means that some table functionality such as sorting, and pagination won't be available out of the box.
In the video I leverage a REST service from Songsterr which allow you to search their repository of song tabs. This REST service filters the results it returns by using a parameter called "pattern". You can further filter the results by adding ,a= with another value to the URL. For example, this will give you songs that have both Bob and Sheriff https://www.songsterr.com/a/ra/songs.json?pattern=Bob,a=Sheriff
As you'll see I use the Service Data Provider (SDP) uriParameters attribute to pass in an object that contains the URL parameters that will be passed to the REST end point. the uriParameres expects an object that has an entry for each of the query parameters you define on the REST end point. In my case there is only one such parameter called pattern so the format of the value I pass is:
{"pattern" : $page.variables.Artist+ ",a=" + $page.variables.Filter }
When you work with other services the URL parameter will probably be different but the concepts should still apply. So your steps would be:
- Figure out the URL format for getting filtered data
- Define the URL parameters for the service end point
- Construct the value passed to the parameters in your page event
(The browser's network tab is your friend when you need to debug what's going on while you go through the above process - see the end of the video)