Ah, the joy of a low-code development tool like Application Express! You point, you click, and you get beautiful, powerful websites and mobile apps. But you will also almost certainly need to write some SQL and PL/SQL to complete the functionality of that application. Sadly, there is always a tendency when writing code within a point-and-click development environment to treat that code rather casually; after all, it is not the really important (user-facing) part of the application, right? Wrong! It’s all important, and it is way too easy to create an awful mess in your otherwise elegant APEX app if you treat your SQL and PL/SQL code as “second class citizens” in terms of the attention you give to it. Not to mention bad performance or maintenance nightmares! In this session, Steven will offer some recommendations for how best to write and manage your SQL and PL/SQL in your APEX applications, as well as cover key features in PL/SQL you should be leveraging. https://apex.oracle.com https://oracle.com/plsql

1. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Application Express and PL/SQL
Make the most of a world-class combo!
Steven Feuerstein
Oracle Developer Advocate for PL/SQL
Oracle Corporation
Email: steven.feuerstein@oracle.com
Twitter: @sfonplsql
Blog: stevenfeuersteinonplsql.blogspot.com
YouTube: Practically Perfect PL/SQL
1

2. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Point and Click versus Coding
• When code is written inside that oh-so-cool UI environment,
we tend to be a bit dismissive of it.
–Irritating interruption from the usual point-and-click.
–Minimal editing capabilities.
• The custom-written source code in your APEX application will
present the biggest challenge in terms of debugging,
maintenance, support.

3. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
What's an APEX developer to do?
• Set clear rules on...
–Where all that PL/SQL code goes, and
–Where and how SQL statements are written.
• Follow Rule #1: Don't repeat anything – hide everything.
• Follow Rule #2: Hope for the best, plan for the worst.
• And remember: It only gets more complicated over time.

4. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Set Some Rules on SQL and PL/SQL Code
1. If the PL/SQL code does not contain references to UI elements, move it
out of Application Builder and into packages.
2. If the PL/SQL code contains UI elements, move as much code as possible
to packages.
– Leave behind a minimal "footprint" in APEX code.
3. The only SQL you should write inside APEX are queries to populate
tables.
– And even then you should generally query from views.
– No updates, inserts, deletes - unless generated and performed automatically by
APEX.

5. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Don't repeat anything – hide everything.
• This is the most important principle you can follow in
programming.
–Repetition = hard coding = maintenance nightmare.
–You end up with brittle, hard-to-change apps.
• Instead, aim for a Single Point of Definition (SPOD) for every
aspect of your application.
–That way, when you have to change it, you change it in just one place.
• The hard part is recognizing all the sorts of hard-codings that
can occur.

6. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Dealing with Hard Codings in APEX
• Literals can easily sneak their way into your code, all over the
place.
• WHERE clauses, validations, conditions, LOVs
• It all comes down to discipline.
–And constant review and consolidation of logic.
–Use application items
–Define as constants in packages (cannot reference directly in SQL)
How about date formats: YYYY-MM-DD HH24:MI:SS

7. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Example: List of Values
• Many LOVs reference page items.
• And often the same LOV is needed on different pages.
• It’s pretty easy to end up with
something like this:

8. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Get Rid of List of Values Repetition
• That just seemed wrong to me. Surely there was a way around
it. Let’s ask APEX!
LOVs can be based on a
dynamic query!
Common solution: Use
:app_page_id to construct
item name, or use CASE.

9. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Hide with PL/SQL Packages
• Key building block for any PL/SQL-based application.
• By using a package, you….
– Collect together related functionality
– Offer well-crafted APIs – for use in Application Builder, but also other backend code,
scheduled jobs, etc.
– Break the dependency chain: change the package body without invalidating any
program units dependent on the package (specification).
– Benefit from optimized caching of packaged code in the SGA
– More easily search APEX code for usages
– Leverage PL/Scope for stored code analysis

10. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
How to Hide with PL/SQL Packages
• Move as much code as possible into packages, avoid schema-level
functions and procedures.
• Create lots of small, narrowly focused packages.
• Build a toolbox of handy utilities.
• Here are some examples from the Dev Gym code base:
– Manage classes – dg_class_mgr
– Email management and template processing – qdb_communication_mgr and
qdb_template_mgr
– Gamification – dg_gaming_mgr

11. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Hide Your SQL (stop writing so much of it)
• We PL/SQL developers take SQL completely for granted.
It's so easy to write!
§But what do we know about SQL statements?
–Change constantly, forcing us to change code; cause most of the
performance problems; cause many runtime errors in an application.
• We should very careful about how, when and where we write
SQL statements.
–Avoid repetition.
–Assume things will get more complicated.

12. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
In the context of APEX....
• Your APEX-based, custom-written source code should never contain non-
query DML SQL statements.
– Any inserts, updates, deletes outside of automatic form processing should be done
through packaged procedures.
• Put as much validation and conditional logic inside functions.
• Constantly revisit your code and APIs to transfer logic out of Application
Builder and into packages.
• Could it really be worth the "bother"?
– It's always more complicated than it initially appears.
– And you will often need the same functionality in more than one place.

13. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Everything Gets More Complicated
• After a few years of quizzes, we decided to "gamify" the Dev Gym.
– In addition to ranking, reflect your level of activity on the site.
– Rack up points, earn some trophies!
• So what was formerly an insert is now an insert-insert, updates become
update-insert.
– And often much, much more….
• If those DML statements are “exposed” inside the application, it is much
harder to manage and upgrade that functionality.

14. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Compile Time versus Run Time
• One big advantage of putting your SQL in PL/SQL subprograms or even
views is that any errors are detected at compile time.
• If you "dump" the SQL into APEX, then you (or your users) don't see the
error until run time.
• This is especially dangerous with upgrades, and incomplete testing.
Step 1: add new columns to table X. Has same name as column in table it joins with.
Step 2: upgrade all packages to support new column. All looks OK, but....
Problem: getting "ambiguous column" errors in application – but only if and when
you actually visit that page.

15. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Manage Backend Errors Carefully
• Either through user error or bugs in code, exceptions will be raised in your
PL/SQL code.
• What should your user see when this happens?
• You don't want it to be this:

16. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Standardize and Be Consistent
• Don't allow unhandled exceptions to propagate out of your stored code
without logging the error first.
• Use standard, consistent error logging in your backend code
– If you don't have your own, check out the open source Logger at oraopensource.com.
• Use APEX_ERROR and "Error Handling Function" in App Properties to
implement a "catch-all" handler.

17. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Remember: all items are strings!
• Watch out for overloadings of string and number.
–The runtime execution path may surprise you.
• Watch out for comparisons of "date" items.
–Create Y/N items computed with real dates.
• Ordering in reports may not meet your expectations.
–With dates, at a minimum use a format that results in correct ordering as
strings, e.g., YYYY-MM-DD HH24:MI:SS.

18. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Manage Emails Carefully
• Nobody every liked to be spammed and now with GDPR there can
be real consequences.
– Besides pissing off your users big time.
• APEX_MAIL makes it easy to send emails. You need to make it less easy.
• Rules to consider putting in place:
– Never send emails to users from dev/stage/test
– Hide APEX_MAIL.SEND behind your own send procedure
– Don't always push emails into the queue (performance)

19. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
PL/SQL and APEX: a match made in Oracle
• It's not surprising that it's easy to work with PL/SQL from within APEX.
• But as with SQL, just because it's easy doesn't mean you should treat it
casually.
• Write your PL/SQL code with care.
– Move as much as possible to PL/SQL packages.
– Decide on standards for SQL construction, error management, naming
conventions.
– Avoid repetition; aim for that Single Point of Definition.

20. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Deepen Your PL/SQL and SQL Expertise
• Take advantage of our community websites.
• Oracle AskTOM – https://asktom.oracle.com
–Q&A site, Office Hours with database experts, and much more
• Oracle Dev Gym – https://devgym.oracle.com
–Quizzes, workouts and classes for an active learning experience
• Oracle LiveSQL – https://livesql.oracle.com
–24x7 access to the latest release of Oracle Database, plus a script library and
tutorials

21. 21