MT AG - KASS - Keep APEX Stupid Simple

606 views
544 views

Published on

How to maintain your

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
606
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • KASS: Keep APEX Stupid Simple or "How to Create Maintainable APEX Pages"
  • Screenshot Erftverband
    Fixed headers, column
    Überschriften vertikal
    Auswahllisten zum Vorschlag (editierbar)
    Clientseitige Validierung
    Breite wird ermittelt
    Meldung falls nicht gespeichert
  • - Die Transaktionsebene in FOEX 1.2.x ist pro Komponente (Speichern Button löst pro Komponente eine Validierung/Speichern Aktion aus)
  • - Die Transaktionsebene in FOEX 1.2.x ist pro Komponente (Speichern Button löst pro Komponente eine Validierung/Speichern Aktion aus)
  • MT AG - KASS - Keep APEX Stupid Simple

    1. 1. | KASS: Keep APEX Stupid Simple or “How to create maintainable APEX pages” Niels de Bruijn, Business Unit Manager APEX Ratingen, 23/06/2014
    2. 2. | MT AG LEGAL STATUS AG (CORPORATION) HEAD OFFICE RATINGEN, GERMANY FOUNDING YEAR 1994 EMPLOYEES 190 HOLDING MT-IFS GMBH (RATINGEN), MT-IFS SARL (LUXEMBURG) business by integration BUSINESS INTELLIGENCE SOLUTIONS SOCIAL BUSINESS SOLUTIONS MOBILE SOLUTIONS APPLICATION DEVELOPMENT INTEGRATION SERVICES IT SYSTEM SERVICES
    3. 3. | About me  Niels de Bruijn, Business Unit Manager APEX  Born in 1977, married, two daughters  Started career in 2001 at Oracle in the Netherlands  Since 12/2003 employed at MT AG in Ratingen  Working with APEX since its inception back in 2004  Responsible for sales/marketing/delivery of all kinds of APEX projects - https://apex.mt-ag.com & http://www.apexsolutions.de  As DOAG representative, responsible for the APEX community in Germany  You can find me here: - Online: Skype, Xing, LinkedIn, Twitter, Facebook - Offline: DOAG Conference, DOAG Development Conference, ODTUG Kaleidoscope, Regional APEX UserGroup (Meetup) KASS: Keep APEX Stupid Simple3
    4. 4. | My first APEX app in 2004 Easy understandable, right? KASS: Keep APEX Stupid Simple4
    5. 5. | APEX Guidelines KASS: Keep APEX Stupid Simple5  How to enforce guidelines: - See presentation of Oliver Lemm - “The APEX QA Plugin” - Tue 24-JUN, 08:30 am - 09:30 am  Packaged App: Standards Tracker
    6. 6. | 1. Rapid Prototyping APEX/FOEX Wizards KASS: Keep APEX Stupid Simple6 2. Rapid Application Development APEX +(PL/)SQL +jQuery 3. Rapid Rich Internet Application Development APEX +(PL/)SQL +FOEX Plugins Classification of modules in APEX projects Complexity of module End-user time spent each day with the module b. Mockup APEX/FOEX Wizards Use Case For example “Access Replacement” Use Case For example “Forms Replacement” a. Draft Flipchart / Balsamiq Requirements Engineering For which implementation method am I going for? Implementation Phase
    7. 7. | Definition of a module  One APEX application may consist of multiple modules  A module covers certain business functionality and is used by a specific group of end users  A module normally has multiple APEX pages, for example: - The module „User Maintenance“ consists of two APEX pages (IR-page + SRU-page) und its target audience are administrators. KASS: Keep APEX Stupid Simple7
    8. 8. | How do you define „complex“?  Not easy to define, but some elements of a complex module could be: - that it writes data to multiple tables - that there is (complex) business logic to respect - that it contains client side behavior and dependencies between fields - the page layout has multiple areas - that the page can‘t be created by using APEX wizards - that it is AJAX driven KASS: Keep APEX Stupid Simple8
    9. 9. | Some remarks  The number of end users doesn‘t matter  Chosen the wrong implementation method may lead to massive maintenance costs!  For each module, rethink your implementation method KASS: Keep APEX Stupid Simple9
    10. 10. | 1. Rapid Prototyping APEX/FOEX Wizards KASS: Keep APEX Stupid Simple10 2. Rapid Application Development APEX +(PL/)SQL +jQuery 3. Rapid Rich Internet Application Development APEX +(PL/)SQL +FOEX Plugins Classification of modules in APEX projects Complexity of module End-user time spent each day with the module b. Mockup APEX/FOEX Wizards a. Draft Flipchart / Balsamiq Requirements Engineering For which implementation method am I going for? Implementation Phase
    11. 11. | Requirements Engineering: Draft Key features:  Shows how the application or page may look like  Can even be created during your conversation with the customer KASS: Keep APEX Stupid Simple11
    12. 12. | 1. Rapid Prototyping APEX/FOEX Wizards KASS: Keep APEX Stupid Simple12 2. Rapid Application Development APEX +(PL/)SQL +jQuery 3. Rapid Rich Internet Application Development APEX +(PL/)SQL +FOEX Plugins Classification of modules in APEX projects Complexity of module End-user time spent each day with the module b. Mockup APEX/FOEX Wizards a. Draft Flipchart / Balsamiq Requirements Engineering For which implementation method am I going for? Implementation Phase
    13. 13. | Requirements Engineering: Mockup Key features:  Shows how the application or page may look like  Enables end users to interact with the UI  May have selected business processes implemented  The result is thrown away - Clear focus on speed versus maintainability (1-2 PT) - Operates directly on the tables (no view-layer) KASS: Keep APEX Stupid Simple13
    14. 14. | 1. Rapid Prototyping APEX/FOEX Wizards KASS: Keep APEX Stupid Simple14 2. Rapid Application Development APEX +(PL/)SQL +jQuery 3. Rapid Rich Internet Application Development APEX +(PL/)SQL +FOEX Plugins Classification of modules in APEX projects Complexity of module End-user time spent each day with the module a. Draft Flipchart / Balsamiq Requirements Engineering For which implementation method am I going for? Implementation Phase b. Mockup APEX/FOEX Wizards
    15. 15. | 1: „Rapid Prototyping“ Key features:  Requirements are known, but not written down  Features of APEX/FOEX are unknown  Iterative development (daily alignment with the customer)  Just like with MS Access, development could be done by the business  Team: 1 developer, optionally 1 requirements engineer  Complexity: live with the standard functionality  Very Short “Time to Market“ (approx. 3 months)  Applications normally targeted for usage by a small group of end users  View/Package-layer between APEX and the tables should be established  Single combined technical/functional spec. is authored during development KASS: Keep APEX Stupid Simple15
    16. 16. | 1: „Rapid Prototyping“ KASS: Keep APEX Stupid Simple16 Items Buttons Fetch Data Process Data Dynamic Actions Redirect
    17. 17. | 1. Rapid Prototyping APEX/FOEX Wizards KASS: Keep APEX Stupid Simple17 2. Rapid Application Development APEX +(PL/)SQL +jQuery 3. Rapid Rich Internet Application Development APEX +(PL/)SQL +FOEX Plugins Classification of modules in APEX projects Complexity of module End-user time spent each day with the module b. Mockup APEX/FOEX Wizards a. Draft Flipchart / Balsamiq Requirements Engineering For which implementation method am I going for? Implementation Phase
    18. 18. | 2: „Rapid Application Development“ (RAD) Key features:  Requirements are known and mostly a functional specification is available  Development done by IT - Multiple developers are involved (“Enterprise APEX”) (architects/(different kind of) developers/QA/PL/delivery manager) - “Scrum” method with sprints during development  Complexity of a module ranges from medium to complex - The sky is the limit: „What works in the web, also works in APEX“  Shift business logic from APEX to the database  View/Package-layer between APEX and the tables  Approach valid both for desktop apps as well as mobile apps KASS: Keep APEX Stupid Simple18
    19. 19. | 2: RAD with custom fetch/save processes KASS: Keep APEX Stupid Simple19 Items Fetch Data Process Data Buttons Dynamic Actions Redirect
    20. 20. | 2: RAD – Example of a non-standard APEX page Things you can do with jQuery KASS: Keep APEX Stupid Simple20
    21. 21. | 1. Rapid Prototyping APEX/FOEX Wizards KASS: Keep APEX Stupid Simple21 2. Rapid Application Development APEX +(PL/)SQL +jQuery 3. Rapid Rich Internet Application Development APEX +(PL/)SQL +FOEX Plugins Classification of modules in APEX projects Complexity of module End-user time spent each day with the module b. Mockup APEX/FOEX Wizards a. Draft Flipchart / Balsamiq Requirements Engineering For which implementation method am I going for? Implementation Phase
    22. 22. | 3: „Rapid Rich Internet Application Development“ Key features:  Like „Rapid Application Development“ - but limited to desktop apps  Layout typically ranges from complex to extreme complex  Logically one page, technically multiple APEX pages  100% AJAX driven KASS: Keep APEX Stupid Simple22
    23. 23. | 3: „Rapid Rich Internet Application Development“ KASS: Keep APEX Stupid Simple23
    24. 24. | KASS: Keep APEX Stupid Simple 3: „Rapid Rich Internet Appl. Development“ 24 SQL Report defines meta data FOEX Plugins (AJAX) Processes No page processing anymore!
    25. 25. | Summary So, how do we keep APEX stupid simple?  Setup Development Guidelines - Use Packaged App „Standards Tracker“ - Use QA Plugin to automatically check your standards  See presentation of Oliver on Tue 24-JUN between 08:30 am - 09:30 am  For each module, decide your implementation method - Rapid Prototyping - Rapid Application Development - Rapid Rich Internet Application Development KASS: Keep APEX Stupid Simple25
    26. 26. | Q&A MT AG Balcke-Dürr-Allee 9 40882 Ratingen Telefon: +49 (0) 21 02 309 61-0 Telefax: +49 (0) 21 02 309 61-10 E-Mail: info@mt-ag.com https://apex.mt-ag.com

    ×