Upload
clyde-lyons
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Track the changes in your Apex application between releases: Yes you canPlsql based methodology to monitor the changes in your application between releases
Koen LostrieDeveloper, Curriculum DevelopmentOracle CorporationMarch 25th, [email protected]@koenlostrie
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor StatementThe 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.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Program Agenda
Introduction
Solution Architecture
Implementation
Demo
Q & A
1
2
3
4
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
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 ?
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...
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...
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 ?
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Implementation
• 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
The work. Step 1: Create Objects
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
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
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
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
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...