How to restrict a search so it only works when filter properties are provided?

Hi Community,

maybe some of you know a solution for this scenario.

Every regular ItemType in Aras can be searched through with the Simple/Advanced/AML search in the grid.

In my case I have a couple of federated ItemTypes that links to an external data source (SQL Views).  Some of the views are pretty heavy. They connects a lot of tables with millions of datasets, for example measurement values from production test field. 

So getting results from the table is slow and performance consuming by default. But only if people search without proper filter values.

Restricting the number of returned results in one option. But even with this restriction users can still play around and trigger a lot of unnecessary searches until they get their required result.

So I am looking for a way to force users entering proper filter values by default. In my case user should always have to specify the required product and a date range.

One idea was, just to not execute a simple search when users do not provide any filter at all. But I haven´t seen an OOTB option for this idea inside Innovator.

One other idea is using a custom search mode that replaces the available Simple/Advanced/AML Search modes available for this ItemType. 

Does anyone of you have an idea for a better solution? I somehow assume that there must be a easier solution. All ideas welcomed!

Many thanks!

Angela

Parents
  • Hello Angela,

    Very primitive solutions are there which you might be already knowing although they are not full proof.

    1. There is property on Item Type called Auto Search. You can keep it unchecked so that search does not run automatically when Items grid is opened

    2. You can specify Default Search on Properties that you need like - "Required Product" and "Date Range"

    Comprehensive solution can be to write a method onBeforeGet:


    1. The method should read a flag which indicates if get is called from search grid. You need to set this flag most probably from code tree. To avoid setting up flag in code tree you can check for typical attributes in AML which are specific to Items Grid like Page Size or Max Records or Others...

    2. If the flag is set to true or if Items Grid specific attribute is available, it indicates that get is called from Items Grid, in that case you need to verify if required properties are not blank like "Required Product" and "Date Range"

    Note: You can even avoid setting up flag or checking for Itrem's Grid specific attributes but in that case action='get' even if it is called from an AML will throw an error if necessary properties are not available in AML

    Let me know if this makes sense.

    Thanks,

    Jayraj

Reply
  • Hello Angela,

    Very primitive solutions are there which you might be already knowing although they are not full proof.

    1. There is property on Item Type called Auto Search. You can keep it unchecked so that search does not run automatically when Items grid is opened

    2. You can specify Default Search on Properties that you need like - "Required Product" and "Date Range"

    Comprehensive solution can be to write a method onBeforeGet:


    1. The method should read a flag which indicates if get is called from search grid. You need to set this flag most probably from code tree. To avoid setting up flag in code tree you can check for typical attributes in AML which are specific to Items Grid like Page Size or Max Records or Others...

    2. If the flag is set to true or if Items Grid specific attribute is available, it indicates that get is called from Items Grid, in that case you need to verify if required properties are not blank like "Required Product" and "Date Range"

    Note: You can even avoid setting up flag or checking for Itrem's Grid specific attributes but in that case action='get' even if it is called from an AML will throw an error if necessary properties are not available in AML

    Let me know if this makes sense.

    Thanks,

    Jayraj

Children
  • Hi Jayraj,

    thank´s a lot! This was indeed helpful!

    I have a talent for fixing complex Aras problems, but you wouldn´t believe how often I forget basic and “primitive solutions”

    1. ‘Auto Search’ -> Yes, of course disabled
    2. ‘Default Search’ –> Thanks for the tip!!! I never have used it in all the years and never have noticed that this option exists at all
    3. onBeforeGet -> Of course! Completely forget about this option, even I have done it before

    I use an onGet for the federation. But of course I can an onBeforeGet BEFORE querying for federated data at all.

    This way I can check all kind of user settings like ‘maxResults’,’pageSize’ and their filter values. And it has the advantage that I can give direct user feedback (error message) if their search settings doesn´t match the requirements.

    I didn´t like my idea with the custom search mode, cause it would influence all other ItemTypes as well.

     @Edit: I wrote the text above before actual testing the solution. I think the above ideas work fine regular ItemTypes. 
    But in my current federated ItemType it turned out that we cannot use "onBeforeGet" when using an "onGet" Method. The "onBeforeGet" simply is not triggered. 
    I right now try to figure out how to add more restrictions to the "onGet" Method. Unfortunately this event type is a bit special. Well, I will of course give it a try! 

  • Hello Angela,

    Are you using a federated Item Type? And are you looking for all these restrictions on Search of a federated Item Type?

  • Hi Jayrajvh,

    yes, it´s a federated ItemType! 

    I have my Innovator database and in parallel a second database that contains millions of measurement values from production testing. I want to provide a way to analyze the measurement values inside Innovator.

    I use an onGet Method to connect to the second database, read the data and display them in a standard grid. 
    The standard item grid is not the best choice to work with data, but in the beginning it´s a simple way to have some kind of access to the data at all. I think I will later move to reporting options, so users don´t have general access to the data.

    So far I just use a simple restriction in the SQL query ("Select TOP(500)").

    I haven´t tested all of your ideas yet. Your idea regarding using a "flag" as indicator sounds promising!  I just still need some time to think it through. I maybe can provide a code sample later.