2. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Track the changes in your Apex application between releases: Yes you can Plsql based methodology to monitor the changes in your application between releases Koen Lostrie Developer, Curriculum Development Oracle Corporation March 25 th, 2015 koen.lostrie@oracle.com @koenlostrie

3. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

4. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Program Agenda Introduction Solution Architecture Implementation Demo Q & A 1 2 3 4 5

5. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Introduction Good tracking system (team dev/ packaged app/ Jira) where developers document changes. Works really well for tracking features/enh req/bugs. NOT for knowing exactly what changed. Apex apps are easy to change. There is always the “ah here is a bug let me quickly fix that. No need to document that”. Audit columns in the apex views give us who and when but not what and old value/new value. How can we know what changed in our application

6. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Introduction Check the export file – challenge. Big challenge. Compare the splitted export files – same. Version control comparison. So what doesn’t work ?

7. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Introduction How else can we track changes ? – DBMS_COMPARISON. – Oracle Total Recall. – Other Tools (eg COMPARE_SYNC) But I would like to track changes in the apex views. – That is a view, can’t create a trigger on that So how about – replicating the apex view data and then auditing changes ? The idea...

8. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Introduction Be available to all oracle customers (no EE functionality) Not needing any special system/sys access Be supported by Oracle – no messing with apex objects or apex schema Survive upgrades Be easy to maintain, debug, change I want my solution to...

9. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Architecture Generate a table for every view we want to track Generate a trigger on each of those tables For every column that we want to track, log old/new value in case of change. Merge the view data into our tables and we’re flying ! What are the parts ?

10. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation Activities: Initialize data and Log incremental changes Transactions: Row level changes (I/U/D) Audit Logs: Column value changes Naming conventions

11. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation Create table as select * FROM were 1 = 2 Challenges: – Which views ? APEX_DICTIONARY – Fails for APEX_APPLICATION_LISTS with ORA-1723 – Some Bugs in APEX_DICTIONARY Solution: Create helper table CTA_VIEW_ATTRIBUTES The work. Step 1: Create Objects

12. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation Create trigger on each table INS/UPD/DELETE for each row. Trigger calls procedure to store old/new values if there is a change (asktom). Challenges: – Oh no ! PAGE_NAME seems to be everywhere ?? – Do I track all columns (even COMPONENT_SIGNATURE ?) – How do I uniquely define a row (some documented, some not documented, some not available and skipped) Solution: Create helper table CTA_VIEW_EXCL_COLUMNS to store columns to exclude for table and child table (based on apex_dictionary hierarchy) The work. Step 2: Create Objects

13. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation Copy the current application view data into our newly created tables. Disable triggers for this operation. Merge statement (see later) on unique key from CTA_VIEW_ATTRIBUTES The work. Step 3: Initialize Data

14. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation Merge the current apex view data into CTA tables (Merge + Delete) Challenges: – After a Log Changes operation, the data in our CTA tables is now identical what if more changes come up. Solution: restore old version and Initialize Data Better solution: parameter INCREMENT_VIEW_DATA. Use AUTONOMOUS TRANSACTION to store delta and roll back transaction. The work. Step 4: Log Changes

15. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation You learn how internals work and not everything is what it seems: – eg: do anything on IR and CT_APPLICATION_PAGE_IR_RPT gets updated – Eg: CT_APPLICATION_PAGES.PAGE_FUNCTION only set after builder is run Control characters trigger a change (this is not logged as change) Quirks, open issues and unexpected results

16. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Implementation Can I copy from another app id ? Can I get my hands on this ? This is more than just a working prototype right ? And it is fully supported by Oracle ? Apex 5 (Yes, if...) ? Warning ! (hint... Security) I knew you were going to ask...

17. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Demo

18. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Questions ?