Professional Documents
Culture Documents
Query Zones
Query Zones
Query Zones
• All of the “look and feel” features described for info zones apply to query zones
• The major differences are:
• The filter area appears at the top of the zone
• No drag and drop is available on query zones
Query Zone
Info Zone
Application
User Group
Portal Service/
/ User
User Group
A zone’s parameters
Parameter control what data is
Parameter
Parameter
Type retrieved and how it is
displayed
These are a sample Info Zone Type Account’s Bills Zone Person’s Contacts Zone
of the parameters Filter 1
Dynamic SQL
• When you were adding your zone, you may have noticed
the “tips” that appeared in the dashboard
• When you have a moment, take the time to read the tips
as they have several interesting examples
• Warning - some of these examples might be a little advanced
Portal Preferences
Portal /
Portal /
Zone /
Zone
User
A zone can be referenced on any Users define which zones they use (and
number of portals the order they appear and …)
• Besides the “look and feel” differences described earlier, there are a
few other differences:
• Query zones execute the first SQL statement that satisfies the condition,
whereas info zones execute every SQL statement that satisfies the
conditions
– Remember the account activity info zone – it contains the results of several SQL
statements
• For query zones, the number of columns (and their headings) is dependent
on the SQL statement that is executed. This means that the columns can
be radically different depending on the SQL that is executed
– This is why drag and drop isn't available on query zones (the fields can be
completely different on the different SQL statements)
• Info zones are triggered when a portal first opens and whenever
broadcasting occurs; query zones are not triggered when a portal first
opens (the user has to press Refresh after entering search criteria)
Zone Security
Application
User Group User
Service
Application
User Group
Zone Service/
/ User
User Group
Script
The script’s
(Service) schema defines its
Schema input and output
<name/>
<driversLicense/>
• Our case study - if the user is considered "restricted" (e.g., has some
type of char that indicates they don't have complete access), only
customer names are shown as the search results
1
2 Zone Parm
Info / Query Zone: Bill History The Explorer
Zones Filter 1: Account=123212
Service
3
When info and query zones build, they invoke a service that:
1. Reads the supplied zone's parameters (this is cached for performance
reasons)
2. Splices in the supplied filter values and column order
3. Executes the zone's SQL
4. Appends any derived columns (e.g., it appends icons, FK references, business
service elements, business object elements, formula results, etc.)
5. Returns the rows and columns back to the client for display in the zone
Service
Script 2 Zone:
Filter 1:
SQL-FindAccount
Account ID
3 SQL Parm: SELECT ACCT_ID
FROM CI_ACCT
WHERE ACCT_ID = :F1
Account
=123212
The
Explorer
1 Business Service
Zone: SQL-FindAccount 4
Filter1: Account=123212
Service
You can invoke this business service from any script (BPA or service)
• You might find it easier to say that you will have one
business service for each SQL statement
• But remember that query zones support multiple mutually
exclusive SQL statements so you could adopt a technique
like:
• Create a single query zone that contains separate SQL statements
that support all the methods that you can use to retrieve an
account ID
• Create a business service for this zone
• Invoke this business service passing it different filter values (as
per the search criteria)