Developing Commercial APEXApplications               Doug Gault & Scott Spendolini                                     Enk...
WELCOME          2
Doug Gault doug.gault@enkitec.com Using Oracle since 1988  Versions 5.1b, 6, 7, 8, 9, 10, 11 Focused on Web Technologi...
Scott Spendolini scott.spendolini@enkitec.com @sspendol Ex-Oracle Employee of 10 years  Senior Product Manager for Ora...
About Enkitec Oracle Platinum Partner  Established in 2004  Headquartered in Dallas, TX  Locations throughout the US &...
Agenda Overview Design Infrastructure Testing Deployment Summary                   6
OVERVIEW           7
Disclaimer Almost 100% of the content in this session are  applicable to any type of APEX project -  commercial software ...
Passion for APEX Combined 25 years of APEX experience Wanted to produce a product with APEX Knew that a subject matter ...
eSERT Origins Given the declarative nature of APEX, many  security vulnerabilities could be exposed by  inspecting the me...
Benefits Can adopt the APEX footprint No additional software or hardware Same database and operating system versions T...
eSert Info This is not an eSert  presentation For more info on eSert, be  sure to stop by our booth in  Moscone South or...
DESIGN         13
Design Hands down the most important phase  Need to spend ample time here and work out problems on   paper not in code ...
User Interface Mockups Balsamic mockups is invaluable  Issues with UI can be flushed out early and quickly  Easier to g...
User Interface Keep it simple Keep dependencies similar to that of APEX  You have no control over when APEX will be upg...
Dealing with IE Initially tried to have a single CSS file for all  browsers  Quickly realized that was a bad idea Thus,...
PL/SQL All code of any length goes in a package  Even a simple RETURN FALSE Benefits of this approach  Centralized  E...
Tables & Views All tables accessed via views  Allows for security and manageability  Easier to patch                   ...
Page Zero Used as much as possible  However, need to keep an eye on the number of   components placed here              ...
Shared Components Use as much as possible  All computations and processes referenced package calls                      ...
Shared Components Images, JS and CSS have to be shared components  Easier to install and manage  Cant assume file syste...
Supporting Objects Decided to have a split installation  DB objects installed via SQL Plus as SYS  Images, JS and CSS d...
Versions Multiple Apex versions presents a challenge  Initially thought few customers were using Apex 4.0    “Your idea...
Database Support Piggyback on APEX-supported versions  10g R2+  Exception was Oracle XE                                ...
INFRASTRUCTURE                 26
Infrastructure Choices Source Code Control Shared Development Automated Builds Licensing                         27
Source Code Control                      28
Source Code Control We were comfortable with subversion                                        28
Source Code Control We were comfortable with subversion  Fear of change? Nahhh!                                        28
Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own          ...
Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of...
Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of...
Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of...
Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of...
CodeSpaces             29
CodeSpaces           TO        U S       C         M      29
CodeSpaces Custom “Small Team” Plan  Fewer Users (6)  Less Storage (1Gb)  Unlimited Projects  Unlimited Repositories ...
SubVersion Clients                     31
SubVersion Clients Versions                     31
SubVersion Clients Versions Cornerstone 2                     31
SubVersion Clients Versions Cornerstone 2 Both were  Simple easy to use interface  Allows “experts” to do what   they...
SubVersion Structure                  TRUNK                   All development happens                    here           ...
SubVersion Structure                  Branches                   Reserved for Branches in the                    source ...
SubVersion Structure                  Releases                   Only created after building                    and test...
Shared Development We faced a number of challenges  Needed a platform we could share and use to develop   collaborativel...
Shared Development Amazon Web Services  Inexpensive  Easy to stand up   AMI’s already existed with OEL and Oracle Data...
Shared Development Database Version Choice  Needed to make sure what we developed would work   across all versions  Loo...
Automated Builds Needed a way to create a “Release” of the  software  Install testing, functional testing, actual releas...
Automated Builds Created an ANT build.xml script allowing us to  Dynamically create the working directory  Check the mo...
Automated Builds Final Build Script had 3 main targets  RELEASE   Create a final wrapped and zipped release  NOWRAP  ...
Product Licensing Licensing requirements were unique  We understood that product licensing can almost always   be subver...
Product Licensing Licensing consists of a Customer Key and a  License Key  Customer Key - Hashes information about the s...
Product Licensing Two sets of code  Application Side   Creates and encode Customer Key   Receives, interprets and vali...
Application Side                   44
Product Owner Side                     45
Product Licensing Benefits Allows us to  scale product use to the need of the end user  quickly create “Trial” keys tha...
TESTING          47
Product Testing Testing is hard and no one likes to do it It covers way more than you might think  Functional Testing ...
Product Testing We chose to use Virtual Machines as our testing  platform  Self Contained “Sandbox”  Easy to copy a ful...
Product Testing Identified and mitigated several potential  problems by having the wide variety of platforms  available. ...
DEPLOYMENT             51
Deployment Decided early on to mirror the APEX install & upgrade  scheme  Allows users to upgrade SAFELY in place  Allo...
Deployment Database Schemas and Objects  Modeled on the APEX install Scripts  SQL Script run as SYS   Checks pre-requi...
Deployment APEX Application  Per Workspace   Associate the SV_SERT_APEX schema as a Parse As Schema for a    workspace ...
Deployment Used Supporting Objects quite heavily for images,  JavaScripts, CSS  Didn’t want customers to have to manuall...
SUMMARY          56
Summary Developing for APEX is not too unique - but there  are a number of unique benefits  Shorter development cycles ...
Download This and all other Enkitec presentations can be  downloaded for free from: http://enkitec.com/presentations     ...
http://www.enkitec.com                         59
Upcoming SlideShare
Loading in …5
×

Developing Commercial APEX Applications

2,369 views

Published on

Oracle Application Express has proven itself as a powerful development platform for internal development needs in countless organizations worldwide. One of the new frontiers it is starting to conquer is building commercial applications. This session covers what it takes to use Oracle Application Express as a platform for building commercial applications. It looks at all facets of the software development lifecycle and discusses different infrastructures, deployments, processes, and tools used to make development with Oracle Application Express as streamlined and cost-effective as possible. Real-world examples are given throughout the session. Much of what is discussed in this session can also be applied to medium to large Oracle Application Express projects.

Published in: Technology
  • Be the first to comment

Developing Commercial APEX Applications

  1. 1. Developing Commercial APEXApplications Doug Gault & Scott Spendolini Enkitec 1
  2. 2. WELCOME 2
  3. 3. Doug Gault doug.gault@enkitec.com Using Oracle since 1988  Versions 5.1b, 6, 7, 8, 9, 10, 11 Focused on Web Technologies OWA, ‘PSP’, Web DB, HTML-DB, APEX Hotsos Product Development Director Co-Founded Sumneva Now part of Enkitec  APEX PRACTICE DIRECTOR  Focused on Providing World Class APEX Products, Education and Services 3
  4. 4. Scott Spendolini scott.spendolini@enkitec.com @sspendol Ex-Oracle Employee of 10 years  Senior Product Manager for Oracle APEX from 2002 through 2005 Founded Sumner Technologies in October 2005 Co-Founded Sumneva in January 2010 Joined Enkitec in June 2012 Oracle Ace Director Co-Author, Pro Oracle Application Express Author, Secure APEX Development Best Practices “Scott” on OTN Forums 4
  5. 5. About Enkitec Oracle Platinum Partner  Established in 2004  Headquartered in Dallas, TX  Locations throughout the US & EMEA Specialties include  Exadata Implementations  Development Services  PL/SQL / Java / APEX  DBA/Data Warehouse/RAC  Business Intelligence 5
  6. 6. Agenda Overview Design Infrastructure Testing Deployment Summary 6
  7. 7. OVERVIEW 7
  8. 8. Disclaimer Almost 100% of the content in this session are applicable to any type of APEX project - commercial software or internal 8
  9. 9. Passion for APEX Combined 25 years of APEX experience Wanted to produce a product with APEX Knew that a subject matter expert was needed to succeed A tool for APEX developers solved this problem 9
  10. 10. eSERT Origins Given the declarative nature of APEX, many security vulnerabilities could be exposed by inspecting the metadata Why not build an APEX application to evaluate the security of other APEX applications? 10
  11. 11. Benefits Can adopt the APEX footprint No additional software or hardware Same database and operating system versions Tight integration with APEX Ease of distribution 11
  12. 12. eSert Info This is not an eSert presentation For more info on eSert, be sure to stop by our booth in Moscone South or Jillians on Wednesday at 2pm 12
  13. 13. DESIGN 13
  14. 14. Design Hands down the most important phase  Need to spend ample time here and work out problems on paper not in code Conceptual and feature design is just as important as visual design  Version 1 vs Version 2  Core Functionality  Asynchronous Execution & Collections  APEX_ADMINISTRATOR_ROLE Role 14
  15. 15. User Interface Mockups Balsamic mockups is invaluable  Issues with UI can be flushed out early and quickly  Easier to get user feedback as you can send as PDF or image versus installing software 15
  16. 16. User Interface Keep it simple Keep dependencies similar to that of APEX  You have no control over when APEX will be upgraded If it cant be installed easily, its not worth including Test in all target browsers early and often  IE will add days to project timeline and subtract years from your life if you wait until the end 16
  17. 17. Dealing with IE Initially tried to have a single CSS file for all browsers  Quickly realized that was a bad idea Thus, created a specific CSS for IE  A little extra work on our side to synchronize the two, but ultimately a better approach 17
  18. 18. PL/SQL All code of any length goes in a package  Even a simple RETURN FALSE Benefits of this approach  Centralized  Easier to patch  Single SQL script vs. entire APEX application  Wrappable  Upgrade from 4.1 -> 4.0 18
  19. 19. Tables & Views All tables accessed via views  Allows for security and manageability  Easier to patch 19
  20. 20. Page Zero Used as much as possible  However, need to keep an eye on the number of components placed here 20
  21. 21. Shared Components Use as much as possible  All computations and processes referenced package calls 21
  22. 22. Shared Components Images, JS and CSS have to be shared components  Easier to install and manage  Cant assume file system access  Helpful to include version in file names  Prevents browser cache issues after upgrades 22
  23. 23. Supporting Objects Decided to have a split installation  DB objects installed via SQL Plus as SYS  Images, JS and CSS delivered as Apex supporting objects  Gotcha: supporting object definitions need to be updated if their corresponding shared component is changed 23
  24. 24. Versions Multiple Apex versions presents a challenge  Initially thought few customers were using Apex 4.0  “Your idea, although interesting, is irrelevant”  “The answer to your question is not in the building”  Survey proved otherwise Ideally this can be mitigated by having common database objects 24
  25. 25. Database Support Piggyback on APEX-supported versions  10g R2+  Exception was Oracle XE 25
  26. 26. INFRASTRUCTURE 26
  27. 27. Infrastructure Choices Source Code Control Shared Development Automated Builds Licensing 27
  28. 28. Source Code Control 28
  29. 29. Source Code Control We were comfortable with subversion 28
  30. 30. Source Code Control We were comfortable with subversion  Fear of change? Nahhh! 28
  31. 31. Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own 28
  32. 32. Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of commitment? Nahhh! 28
  33. 33. Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of commitment? Nahhh! Looked for hosted version control 28
  34. 34. Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of commitment? Nahhh! Looked for hosted version control  Several out there, but one caught our eye 28
  35. 35. Source Code Control We were comfortable with subversion  Fear of change? Nahhh! Didn’t want to manage our own  Fear of commitment? Nahhh! Looked for hosted version control  Several out there, but one caught our eye  WWW.CODESPACES.COM 28
  36. 36. CodeSpaces 29
  37. 37. CodeSpaces TO U S C M 29
  38. 38. CodeSpaces Custom “Small Team” Plan  Fewer Users (6)  Less Storage (1Gb)  Unlimited Projects  Unlimited Repositories  $200 per year ($16 per Month) Flexibility was a big selling point. 30
  39. 39. SubVersion Clients 31
  40. 40. SubVersion Clients Versions 31
  41. 41. SubVersion Clients Versions Cornerstone 2 31
  42. 42. SubVersion Clients Versions Cornerstone 2 Both were  Simple easy to use interface  Allows “experts” to do what they need to do  Friendly to SVN Newbies  Recommended 31
  43. 43. SubVersion Structure  TRUNK  All development happens here  Sub-directories created for each type of object  Included objects that were to be loaded into the app as Supporting Object scripts  Application was exported and checked in as a single object. 32
  44. 44. SubVersion Structure  Branches  Reserved for Branches in the source code line  When you need to change the code based on changing underlying requirements  We needed a code branch when we worked with both APEX 4.0 & 4.1 33
  45. 45. SubVersion Structure  Releases  Only created after building and testing a release  Takes a snapshot of all source that was released  Would allow us to  Recreate the release if necessary  Create a Branch / Create a Patch 34
  46. 46. Shared Development We faced a number of challenges  Needed a platform we could share and use to develop collaboratively  Disparate Locations (Texas & Virginia)  No hosting capability of our own  Small company, so cost was important  Traditional APEX Hosting companies weren’t a good fit  No access to Internal workspace  No access to SYS/SYSTEM users 35
  47. 47. Shared Development Amazon Web Services  Inexpensive  Easy to stand up  AMI’s already existed with OEL and Oracle Database  Full control of the machine  DB Version  APEX Version  All the right access  Safe from ourselves  Available from everywhere  Create our own AMI’s 36
  48. 48. Shared Development Database Version Choice  Needed to make sure what we developed would work across all versions  Looked at XE  Found issues on 10XE with some of the SQL syntax that we were using  Settled on Oracle 10g SE as base development platform  Lowest common denominator  Lowest cost to the customer  What we wrote here would work on Enterprise Edition  Fairly confident that things would port seamlessly to 11+ 37
  49. 49. Automated Builds Needed a way to create a “Release” of the software  Install testing, functional testing, actual release Manual method would get very tedious very quickly Knew from previous experience that Apache ANT could automate this type of thing 38
  50. 50. Automated Builds Created an ANT build.xml script allowing us to  Dynamically create the working directory  Check the most recent version of code out of SVN  Replace @VERSION@ variables in code with a dynamic versions number passed on the command line  Choose to WRAP Oracle PL/SQL code  (or not for dev builds)  Zip the files into a “Release”  Clean up the working directory 39
  51. 51. Automated Builds Final Build Script had 3 main targets  RELEASE  Create a final wrapped and zipped release  NOWRAP  Create a full release with unwrapped PL/SQL  CLONE  Create a Development version that doesn’t replace the @VERSION@ Tags ant <Target> -D sv_version=020100 40
  52. 52. Product Licensing Licensing requirements were unique  We understood that product licensing can almost always be subverted. It’s there to keep honest people honest.  Multiple license types  SITE  WORKSPACE  APPLICATION  Loads of licensing software out there, but nothing that would really work for APEX  Ended up having to rolling our own in PL/SQL 41
  53. 53. Product Licensing Licensing consists of a Customer Key and a License Key  Customer Key - Hashes information about the server, GUID of the product and other info based on the license type  License Key - Hashes information that matches the Customer Key as well as Expiration Date and Licensed Company 42
  54. 54. Product Licensing Two sets of code  Application Side  Creates and encode Customer Key  Receives, interprets and validates License Key  Product Owner Side  Receives and validates Customer Key  Matches Customer Key to a valid license in our back end system  Created and encodes License Key, saves it and presents to user 43
  55. 55. Application Side 44
  56. 56. Product Owner Side 45
  57. 57. Product Licensing Benefits Allows us to  scale product use to the need of the end user  quickly create “Trial” keys that expire after a given amount of time  limit the use of the product to a specific licensed server regardless of the level of license purchased 46
  58. 58. TESTING 47
  59. 59. Product Testing Testing is hard and no one likes to do it It covers way more than you might think  Functional Testing  Installation Testing  Upgrade Testing  Platform Testing Do everything you can to make it  Easy  Repeatable  Full Coverage 48
  60. 60. Product Testing We chose to use Virtual Machines as our testing platform  Self Contained “Sandbox”  Easy to copy a fully set up system  Easy access to multiple platforms (OS, DB, etc)  Snapshots  Makes rollbacks as easy as a button click  Snapshots of successful installs/upgrades provide the basis for the next generation  Allows you to setup and test “edge-cases” and keep those around for future tests. 49
  61. 61. Product Testing Identified and mitigated several potential problems by having the wide variety of platforms available.  Issue with install script on Windows based SQL*PLUS  Issue with 10g and positional parameters in a function when used in a SQL Query  Lack of support for certain functionality in Oracle XE 50
  62. 62. DEPLOYMENT 51
  63. 63. Deployment Decided early on to mirror the APEX install & upgrade scheme  Allows users to upgrade SAFELY in place  Allows rollback in the odd case of a failed installation Multi Part Install  Database Schemas and Objects  SV_SERT_XXXXXX  SV_SERT_APEX  SV_SERT_APEX_ALL  APEX Application  Application per Workspace  Application Cross Workspace 52
  64. 64. Deployment Database Schemas and Objects  Modeled on the APEX install Scripts  SQL Script run as SYS  Checks pre-requisites  Creates users  Creates Objects  Allows DBA’s to choose underlying tablespace(s) and features/grants to install  Future versions will  Migrate data from previous working schema to new working schema 53
  65. 65. Deployment APEX Application  Per Workspace  Associate the SV_SERT_APEX schema as a Parse As Schema for a workspace  Install the eSERT APEX Application in the workspace where the Apps to be evaluated are  Cross Workspace (4.1+ only)  Requires APEX_ADMINISTRATOR_ROLE to be granted to parse as schema  Associate the SV_SERT_APEX_ALL schema as a Parse As Schema for a workspace  Install the eSERT APEX Application in the workspace  Ability to evaluate all applications across all workspaces 54
  66. 66. Deployment Used Supporting Objects quite heavily for images, JavaScripts, CSS  Didn’t want customers to have to manually copy these items to their web server  Couldn’t adequately script this as everyone’s install bay be different However it was a bit of a challenge  No “Relationship” between shared components and supporting objects  Had to keep deleting & Re-creating them 55
  67. 67. SUMMARY 56
  68. 68. Summary Developing for APEX is not too unique - but there are a number of unique benefits  Shorter development cycles  Ability to use built-in components to save time  Charts, IRs, User Interface Code is easy to write; difficult to maintain  Thus, less is more “The answer to your question is not in the building”  Customer feedback is critical 57
  69. 69. Download This and all other Enkitec presentations can be downloaded for free from: http://enkitec.com/presentations 58
  70. 70. http://www.enkitec.com 59

×