The Business Central “Data Search” app (under the hood)

One of the things that totally slipped by me, is the new app from Microsoft that apparently was released in the last wave called “Data Search“.

It’s a simple, but powerful concept: Search for “any” record in your data. Well, any record that you have set up to search for at least ;-).

It is explained here: Search for Specific Data – Business Central | Microsoft Learn

Yeah, I know, it’s not a lot of explanation – but then again, it doesn’t need much explanation, does it? There is a search-string, and it will search for that string in the tables that you have set up (for that role). In fact, in the tooltip/onboarding/.. It explains all you need to know.

And indeed, it exactly works like that:

By clicking Results / Show tables, you can add your own tables. You’ll notice that the functionality saves settings per rolecenter (role) – well, may be not what I would have done, but the nice thing is: it has multiple settings ;-). And – it fills those settings from code – so it comes with a pre-configured set of settings. Interesting!

But .. how is it designed?

Now, to learn, I find it always interesting to look into how things are architected and developed. Especially when it’s from Microsoft, as they come with pretty darn nice architected apps lately. And may be this is a very good example to look into, because it’s easy to predict issues with functionality like this – especially performance issues.

Let me take you along the short journey on how we can look under the hood of this little gem.

Step 1 – where to find the code

Well, I ALWAYS use the project of the long-overdue-MVP “Stefan Maron”: StefanMaron/MSDyn365BC.Code.History. I simply search for the string “Search in company data” (since that’s the label of the page, I figured I should find it somewhere in code). And look at that, it’s a separate app altogether:

Easy to verify in a container, or in an upgraded environment in the “Extension Management” page, of course.

The git history (timeline in VSCode) also shows it’s brand new from V21:

Cool! Let’s dig some more.

Step 2 – What objects do we have and what stands out

First thing that stood out to me is that it has a folder “RoleCenterExtensions”. Apparently, these are just all page extensions of the (default) RoleCenters, to add the shortcut (and action) to open the DataSearch from the rolecenter. Basically, now we have the CTRL+ALT+F available from each rolecenter.

This makes you think though: If you ever wondered “are we able to create some shortcut/action that is accessible anywhere in the app”? Well, I guess not. But then again – shouldn’t we be able to? This is the best example ever for a use case. And since we have ActionRefs now 🤷‍♀️.. seems feasible, no?

Another thing that stood out to me when I was testing the app, was the ability to show all results in some kind of generic page that could show the data from all kinds of tables. WHAT??

One page (2682) which can show any resultset from any record?

Unfortunately, there wasn’t much magic behind it. It’s just some page, based on an integer-element, with a fixed amount of fields, which are pretty much filled in OnAfterGetRecord. Well, to make this happen, there is a lot of coding going on – but I guess you get the gist: no magic.
I don’t know this is the best way to do it .. honestly. Simply creating a filtered recordset and opening the page (0) with that recordset must not have been an option, I guess. I do wonder what will happen if there is a huge resultset though 🤔.. .

For the rest, nothing really stood out to me (from looking at the files), so .. let’s try to find out some more explicit things.

Step 3 – Find out more explicit things (duh.. 🤪)

The main thing that I wanted to look into is how it would react in a big database, or on tables with loads of results. Did Microsoft do anything to be as fast as possible? Or in other words: How did Microsoft architect this to mitigate as much as possible the performance impact.

I found a few things…

Search in background

Well, first of all, it uses PageBackgroundTasks to do multiple searches at the same time. In fact, it will queue all tables and then do as many parallel searches at the same time as possible:

Since we can only have 5 PageBackgroundTasks at the same time, it will loop and manage the 5 threads accordingly, and only start a next search if a thread if available.

When done (OnPageBackgroundTaskCompleted), it will simply add the results (dictionary) to the ListPart with the results (which is based on a temptable, of course).

Only list 4 results

Next: the search-page doesn’t show all results. In fact, it will only show 3 results per table that you will search in. This means that it’s not looping all the data, but only the first 3 records and if there are more results, it will show a “more” link to open a page with all results.

As you can see at the end: it will exit when I >= 4 (3 results + a “more”-line).

One small nitpicking (?) remark could be that it would be better to use a Find(‘-‘) in stead of a FindSet, since we’re absolutely sure to not need the full set, but (far) less than the 50 records that the Find(‘-‘) would do.

Partial Records

Another performance-related addition that Microsoft thought about is the fact it uses the Partial Records.

Very important, of course, because just imagine you’d have like 27 table-extensions on the salesline, and then would use this functionality ;-). This is awesome, only the tables are hit that are actually necessary!

Probably, there are more considerations – but these three really stood out to me. Nice job!

Step 4 – Extensibility

Next – can I extend this app? Like: are there events? Or Interfaces? Or…

As you might expect of a good app, there are default settings. In fact, there is a default setup codeunit (codeunit 2681 “Data Search Defaults”) that holds the (hardcoded) settings to initiate the default setup (which is basically done when opening the page). There’s a bit more to it, but the real question is: how do I add my tables to the default setup?

Well, there is an event:

Makes absolutely sense! And yep, I can also remove stuff from the default setup! ;-).

Though – this is the ONLY event in the entire app – and no, there are no interfaces either.

So may be I would have one small remark: I might want to also be able to tap into some of the search-functionality. I don’t know. What if I want to be able to do case-sensitive searches, or do an “and” in stead of an “or”? Or may be I want to mess around (add/change/.. ) the amount of resultlines – or add results – or remove results.

Also, some of the code seemed to be somewhat hardcoded to the existing documents:

To set the Document Type? Well – what if I have my own document tables and want to add those to the search? I won’t be able to set the type for my own tables. Or do similar things on any Header/Line story on my own entities?

Well – I don’t know – it’s just a feeling, honestly .. I didn’t go too deep into it.

UPDATE!
Since this post was published, Microsoft has confirmed that in v21.2, we’ll get a lot more extensibility points. More info here: https://github.com/microsoft/ALAppExtensions/pull/20590.

Conclusion

In any case – here you go. Hope you enjoyed that short journey ;-). It’s a great app – I am impressed – our consultants that I showed it to really loved it too – now let’s see how it behaves in real life, and if Microsoft is willing to remove the “Preview” label (what the heck is that all about 😉) :-).