Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
HorstSchaude
Product and Topic Expert
Product and Topic Expert

Hello,

I am not sure if everybody understands the concept of the different queries which are supported in PDI and when to use which.

Let me shed some light on this.

Three Kinds of Queries

PDI is supporting three different kinds of queries.

  1. QueryByElement
    • I am quite sure everybody knows these queries which are generated for every node by the framework automagically.
    • These queries support only the elements of the own node, for the selection parameter as well as for the result.
    • As they access direct the database table there is no optimization for this query access.
      This means a shot execution can only happen if the key fields are part of the selection conditions. These are
      • Node ID (which you will probably never use in a search)
      • Alternative Key annotated elements.
    • Furthermore this is only true if the operator for the selection is the equal comparison. :shock:
    • This makes theses queries not the preferred ones if your selection criteria do not match these conditions.
      Especially if there are many entries in the database table.
    • If you get more than 1000 hits you will see a message in the UI which informs you that you are using the wrong type of query for such a big result list.
  2. QueryBuilder
    • You define a (technical name) Query Response Transformation Node (QRTN) which can make use of any element which can be reached from the node to this query is attached. :cool:
    • The implementation is based on the Fast Search Infrastructure (FSI) so you can expect
      • A fast execution
      • Support of any comparison operator
    • This query will give you a quick access to the search data in many places.

  3. SADL based Queries
    • These queries are defined direct in the UI (typically OWLs) and grasp direct to the data avoiding any framework overload.
    • This access is not only dedicated for key access but also for query, so you can also expect
      • A fast execution
      • Support of any comparison operator
    • As there is no further propagation of the query definition it can only be used in the the UI in which it is defined. :???:
      No reuse.

Trigger a query

Imagine where you want to trigger a query:

  • Studio (SDK)
    • Just right-click on the BO and choose "Execute Query" and you can choose any query from any node, either the generated QueryByElement or the ones from the QueryBuilder.
    • You can provide all the selection criteria, follow in the result list the available associations.
    • It is even possible to generate the resp. ABSL statement which can be copied to your code snippet
    • Due to security reasons this is not availabe in a production tenant! :!:
  • Coding (ABSL)
    • If the SDK generates code for you it is clear that you can use it anywhere in any ABSL code snippet.
    • But also the QueryBuilder queries are available.
    • But please follow the "SAP Cloud Application Studio Performance Best Practices":
      • First the query and later the modify part.
      • Do not mixed that. :!:
    • If you do not povide any selection criteria you will get a warning message in the ABSL editor. ℹ
  • User Interface
    • All kind of queries can be used here
    • For filling the selection parameters you can even use Transformation Definitions.
    • This can be standard ones as well as Customer Reuse Library functions which are marked to be used by the UI Designer.

I hope your decision about "Which query shall I use for my case?" can now be answered more easily.

That's all, folks,

Horst

13 Comments