1 / 19

Track the changes in your Apex application between releases: Yes you can

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.

emcmillan
Télécharger la présentation

Track the changes in your Apex application between releases: Yes you can

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 25th, 2015 koen.lostrie@oracle.com @koenlostrie

  2. Program Agenda Introduction Solution Architecture Implementation Demo Q & A 1 2 3 4 5

  3. Introduction How can we know what changed in our application • 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.

  4. Introduction So what doesn’t work ? • Check the export file – challenge. Big challenge. • Compare the splitted export files – same. • Version control comparison.

  5. Introduction The idea... • 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 ?

  6. Introduction I want my solution to... • 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

  7. Architecture What are the parts ? • 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 !

  8. Implementation Naming conventions • Activities: Initialize data and Log incremental changes • Transactions: Row level changes (I/U/D) • Audit Logs: Column value changes

  9. Implementation The work. Step 1: Create Objects • Create table <my_apex_view> as select * FROM <apex_view> 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

  10. Implementation The work. Step 2: Create Objects • 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)

  11. Implementation The work. Step 3: Initialize Data • 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

  12. Implementation The work. Step 4: Log Changes • 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.

  13. Implementation Quirks, open issues and unexpected results • 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)

  14. Implementation I knew you were going to ask... • 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)

  15. Demo

  16. Questions ?

More Related