Oracle Visual Builder: Applications That Outlive Their First Release · Module 6 · Connecting to Fusion
Query parameters, filtering and fields
Lesson 59 of 176 · 3 min
Asking Fusion for WHAT YOU NEED rather than for EVERYTHING. The habit that decides WHETHER MODULE 15 HAS ANYTHING TO FIX. A Fusion REST resource returns a great deal by default — every field of every row that matches, in pages. Almost every performance problem in this course is a page that accepted that default. THERE ARE THREE LEVERS AND THEY ARE ALL QUERY PARAMETERS. Filter the rows you want, name the fields you want, and set how many come back. Each is one parameter and each is usually left off, because the call works without them. FILTERING IS THE ONE WITH THE LARGEST EFFECT AND THE MOST COMMON OMISSION: FETCHING EVERYTHING AND FILTERING IN THE BROWSER. It works on the developer's test data and it means the client received every row before discarding most of them. Which is a performance problem, and also a disclosure problem — the rows…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Visual Builder: Applications That Outlive Their First Release, with a certificate on completion and a fourteen-day refund window.
In this module: Module 6 · Connecting to Fusion
- 1What a service connection is
- 2Creating one against a Fusion REST APIFree preview
- 3Authentication, and whose identity is used
- 4Why a shared service account is usually wrong
- 5Query parameters, filtering and fields
- 6Pagination, properly
- 7Writing back to Fusion
- 8When the shape changes underneath you
- 9Calling an OIC integration instead
- 10Handling a service that is down
- 11CORS and the errors it produces
- 12What breaks: four connection failures
- 13Lab briefing · Connect, over-fetch, then fix it