Application Deployment and Application Management - … ·...

APEX 4.2 – Application Deployment and Application

ManagementDenes Kubicek

APEX 4.2 - Application Deployment and Application ManagementDenes Kubicek Page 1

About Denes Kubicek

∗ Dipl. -Oec. Denes Kubicek, independent Oracle and Oracle APEX consultant

∗ 5 years of experience as deparment manager for logistics and order processing

∗ 7 years of experience as IT manager∗ 12 years of experience with Oracle – since 2007

working on APEX and Oracle projects only∗ Working as a freelancer since May 2007

∗ „Oracle APEX und XE in der Praxis“∗ Published end of 2009

∗ Authors: ∗ Denes Kubicek∗ Jens-Christian Pokolm∗ Dietmar Aust


About Denes Kubicek

∗ „Expert Oracle Application Express“∗ Published in May 2011∗ Charity Project for Carl Backstrom und Scott Spadafore

∗ Authors: ∗ Dietmar Aust∗ Denes Kubicek∗ Doug Gault∗ Dimitri Gielis∗ Roel Hartman∗ Michael Hichwa∗ Sharon Kennedy…


About Denes Kubicek


About Denes Kubicek∗ Oracle Apex Developer of the Year 2008∗ Own Blog – http://deneskubicek.blogspot.com∗ Frequent postings in the Oracle APEX Forum -

https://community.oracle.com/community/developer/english/oracle_database/application_express

http://deneskubicek.blogspot.com

https://community.oracle.com/community/developer/


About Denes Kubicek∗ Well known for „My Demo Application“ at

apex.oracle.com -https://apex.oracle.com/pls/apex/f?p=31517:1

http://apex.oracle.com

https://apex.oracle.com/pls/apex/f?p=31517:1


About Denes Kubicek

∗ Oracle ACE Director


About Denes Kubicek

∗ APEX Advisory Board Member∗ https://apex.oracle.com/pls/apex/f?p=55447:1

https://apex.oracle.com/pls/apex/f?p=55447:1


About Denes Kubicek

∗ APEX and Oracle PL/SQL Projects ∗ APEX & eBusiness Suite 11i at Synventive GmbH – first APEX

project∗ Interseroh AG and ALBA Berlin – application for quote-

management∗ Siemens AG – internal applications∗ T-Systems SAP and Apex – multiple projects∗ T-Shop (German Telecom) – applications for shop management∗ BASF – multiple applications∗ Postbank – multiple applications∗ Customers outside of Germany (Australia, USA and Luxemburg)∗ Trainings (Oracle und Apex) together with my colleague and

friend Dietmar Aust


About Denes Kubicek

∗ You can reach me under the following addresses:

∗ [email protected]

∗ [email protected]

mailto:[email protected]



Agenda

∗ Application Programming – Best Practices

∗ Application Deployment – Development / Test / Production

∗ Application Deployment – Translated Applications

∗ Application Security – New Features in APEX 4.1 and 4.2

∗ Add-On Management – Best Practices


Application Programming – Best Practices

∗ APEX is a great tool for application development.

∗ Using APEX you can build and deploy applications within a short amount of time.

∗ APEX has a lot of features out of the box.

∗ You can easily specify many behaviours for an application without having to write any code.



∗ APEX combines PL/SQL with HTML, CSS and Javascript.

∗ APEX is a true RAD (Rapid Application Development) environment.

∗ APEX is flexible and comfortable – it gives you a lot of possibilities in terms on where you can place your code…

∗ … and this is where the problem starts.



∗ As long as you create small applications, programmed and maintained by yourself, there are no questions and doubts – you can use the APEX builder the way you want and choose any of the options available.

∗ Programming larger applications – hundreds of application pages or even programming a group of applications in a team – will force you to think about setting up some programming rules.



∗ These rules are important in terms of:

∗ keeping the advantages of RAD

∗ producing high quality applications

∗ keeping the productivity and maintainability



∗ Application coding is one of the most important things when it comes to the questions of productivity and maintainability.

∗ If a framework like APEX can do a lot of work for you, you will want to solve the problems using that framework.

∗ You will write some code here.

∗ You will write some more code there.

∗ You will copy some code from here to there.

∗ You don‘t even need to write BEGIN and END while using PL/SQL code.



∗ If you are building really big and complex applications, you will soon be faced with a lot of redundant code:

∗ writing the same query in multiple places

∗ writing the same rules for multiple conditions

∗ Any changes in the data model or even data content will cause bugs and an increase in time you need for debugging.

∗ You will be faced with performance issues.

∗ You will probably not be able to ensure a bug free deployment and soon you will be lost in your own application.



∗ In APEX, you can put your code almost everywhere:

∗ APEX Item has at least five different options for inserting PL/SQL code:

∗ Source value or expression (many different types)

∗ Post Calculation Computation

∗ Default value (three different types)

∗ Condition

∗ Read Only Condition



∗ Some code will be compiled while trying to save the changes.

∗ Some code will not be compiled and the errors are visible at runtime only or if you use APEX Advisor prior to deployment.

∗ If you don‘t use advisor your applications, once deployed to test and production, will not work properly.



∗ Example:

∗ Edit an item in your application and for the Default Value Type select PL/SQL Function Body

∗ Enter there the following code:

∗ See what happens.

BEGINRETURN x;

END;



∗ There are two problems if you decide to use all the options APEX provides you with:

∗ Your application may not run and it may be to late once you notice it – your code is in production.

∗ Your code is not visible but hidden. It could even be that the code compiles an the functionality may just depend on the content.

∗ The solution in this particular case is to use page computations or single page processes – on load.



∗ My recommendations regarding application coding:

∗ Your goals should be that the only statements you write are SQL statements required for reports.

∗ If the complexity of those SQL statements are high, you should move them to views or pipelined functions.

∗ Never write anonymous PL/SQL blocks like in the following example:




∗ Move your code to PL/SQL packages – functions, procedures and constants (for application literals).

∗ Call your packages from your page processes like in the following example:




∗ Using PL/SQL packages you will avoid repetition of code and this is one of the most important rules not only for APEX programming.

∗ Use application item values as input and output variables to functions and procedures (:P1_ITEM).

∗ Avoid using v ('P1_ITEM') syntax to read the session state of your items in a package function or procedure – parse it as an input parameter:

∗ If using v ('P1_ITEM') syntax in the packages, your item ID‘s may change and the code may compile but it will not work.

∗ This way your code will run faster since this function adds some overhad and could cause problems if you use multiple applications and share the same session.




∗ If you need to write a PL/SQL block, always use BEGIN and END – even if APEX is taking care of it. You can read and understand it much better.

∗ Which code is more readable?

Is this a PL/SQL Expression?




∗ Combine this with code formatting – use one formating standard and force the use of it (SQL Developer, TOAD).

∗ Never let developers format their code by hand – this way you will never reach one standard and this will require additional time spent on placing commas and indenting lines of code. Imagine formatting a package with 15.000 lines of code by hand.




∗ Make sure you use the same approach for all of your applications and accross all developers in your team. This way, you will speed up your development even more.

∗ Never create standalone functions or procedures. Use packages only.

∗ Your applications will probably have different functional areas. Split the application logic in separate packages to make it more manageable.

∗ The packages should be named in the way the names reflect their purpose.



∗ The advantages of this approach are:

∗ Your code will not be redundant and will be easier to debug.

∗ Your code will be reusable.

∗ It will be easier to maintain – no one needs to know where you use a particular condition in a complex PL/SQL block. If using a function or a procedure it can be located using simple application search.

∗ Your applications will be much faster.

∗ You will be able to change the way your applications work by simply changing packages – no need to always install (deploy) both – code and the application.



RAD²∗ This way you will reach the next level of application

development – RAD with the power of two:



∗ In the March issue of the Oracle Magazine, Steven Feuerstein recommends the same approach:

∗ http://www.oraclemagazine-digital.com/oraclemagazine/march_april_2014?sub_id=CiysxBJPq7YE2&folio=53#pg56

http://www.oraclemagazine-


Application Deployment –Development / Test / Production

∗ For a developer application deployment is the last step in application development.

∗ Application deployment is important and it requires a good setup in order to save time and insure a fast feedback in case of errors and bugs.



APEX Development APEX Test Environment APEX Production

APEX Integration Test

This is how it should be…



APEX Development / Test and Integration

EnvironmentAPEX Production

…and this is how it is in reality…



…or even worse...

APEX Development / Test and Integration

Environment

Schema A

APEX Production

Schema B



∗ I recommend using script based deployment from development through integration, test and production.

∗ The scripts should include:

∗ DML and DDL scripts,

∗ Application scripts,

∗ Recompiling scripts,

∗ Instructions for the DBA like README.txt or other similar documents.



∗ The advantages of such approach are:

∗ Your DBA doesn‘t need to know much about APEX –eventually how to provision workspace or add space to workspaces.

∗ You can do the installation using one user – SYS or SYSTEM.

∗ You can test the scripts in the integration environment.

∗ You can use the integration for quick patches while still developing in the developement environment.

∗ This approach saves time since there are no surprises once you are live.

∗ Good for the case where there is a continuous development and multiple rollouts (sprints).



∗ This is how a such a script looks like:



∗ Deployment-Skript – readme.txtImportant: Set NLS_LANG to GERMAN_GERMANY.AL32UTF8 prior to the installation.

Depending on the OS you should us one of the following:

Bourne or Korn shell:NLS_LANG=GERMAN_GERMANY.AL32UTF8export NLS_LANG

C shell:setenv NLS_LANG GERMAN_GERMANY.AL32UTF8

Windows:set NLS_LANG=GERMAN_GERMANY.AL32UTF8

After that you should:

1. Start sqlplus and login as sys,2. Run @install.sql,3. Send the log file with the name

apex_deployment_01.logto the following email address:[email protected]

mailto:@install.sql




∗ Deployment-Skript – install.sqlset define '&'

spool install_apex_deployment_01.log

set verify off

promptpromptpromptprompt Change User to DKUBICEK

ALTER SESSION SET CURRENT_SCHEMA = DKUBICEK;

promptpromptpromptprompt Install dkubicek_ddl_1.sql

@dkubicek_ddl_1.sql;

set verify off

mailto:@dkubicek_ddl_1.sql;



∗ Deployment-Skript – install.sqlprompt Change User to SYS

ALTER SESSION SET CURRENT_SCHEMA = SYS;

set define '&'

@set_workspace_credentials.sql;

prompt Install application 103

@f103.sql;

set define '&'

prompt recompile Schema

@?/rdbms/admin/utlrp

prompt Finish the Installation

spool off

mailto:@set_workspace_credentials.sql;

mailto:@f103.sql;



∗ Deployment-Skript – set_workspace_credentials.sqlDECLARE

v_workspace_id NUMBER;BEGIN

SELECT workspace_idINTO v_workspace_idFROM apex_workspacesWHERE workspace = 'DKUBICEK';

--apex_application_install.set_workspace_id (v_workspace_id);apex_application_install.generate_offset;apex_application_install.set_application_alias

( 'F'|| apex_application_install.get_application_id);

END;/



∗ Deployment-Skript – install_apex_deployment_01.logChange User to DKUBICEKSession altered.Install dkubicek_ddl_1.sqlView created.Change User to SYSSession altered.Set Workspace CredentialsPL/SQL procedure successfully completed.

Install application 103APPLICATION 103 - Sample ProcessingSet Credentials...Check Compatibility...Set Application ID......ui types...user interfaces...plug-in settings...authorization schemes...navigation bar entries...application processes



∗ The advantages of such approach are:

∗ If properly testet (Development > Integration) installing the scripts on Test and Production is just a formality.

∗ There is no need to expect problems during the installation.


Application Deployment –Translated Applications

∗ As of the APEX Version 4.2.3 you can use the new (undocumented) API for installing translated applications via SQL scripts.

∗ APEX_LANG package has new procedures to help you seeding and publishing translated applications:

∗ create_language_mapping

∗ update_language_mapping

∗ delete_language_mapping

∗ seed_translations

∗ publish_application

∗ update_message

∗ update_translated_string


Application Deployment –Translated Applications

∗ Installing translated applications is not a problem any more.

∗ There is no need to export those and no need to transfer xlif-Files.

∗ publish_translation.sql shows how to use these procedures to install and publish translated applications in a target environment.



∗ Don‘t forget to include translations on export:



∗ Deployment-Skript – delete_translation.sql

∗ Delete existing translations so no orphan applications appear in the application builder – APEX will pick an application number from the pool for the translated application.

BEGINapex_util.set_security_group_id

(apex_util.find_security_group_id ('DKUBICEK'));

apex_lang.delete_language_mapping (p_application_id => 103,p_language => 'de');

COMMIT;END;/



∗ Deployment-Skript – publish_translation.sql

∗ Full example and related scripts are included in this presentation.

BEGINapex_util.set_security_group_id

(apex_util.find_security_group_id ('DKUBICEK'));

apex_lang.publish_application (p_application_id => 103,p_language => 'de');

COMMIT;END;/


Application Security – New Features in APEX 4.1 and 4.2

∗ The biggest changes in APEX 4.1 and APEX 4.2 are related to seccurity issues.

∗ There are many improvements in security in 4.1 and 4.2.

∗ Security improvements are no highlights – people like fancy stuff.

∗ However, security is one of the most important issues if we talk about APEX – APEX is used to create applications which take care of your data.



∗ My recommendations regarding security:

∗ Activate session state protection for the application links.

∗ Never secure your application using jQuery and Javascript.

∗ Never just hide application elements without securing the depending processes.

∗ Be careful with dynamic actions. The code is visible on the page.



∗ My recommendations regarding security:

∗ Use Authorization functions as much as possible – those are cached and therfore faster. You can use it instead of conditional display functions.

∗ Remember that the more fancy stuff you have in your application it is more likely you will have security issues.



∗ Have a look at the newest security features in 4.1 and 4.2 and you will be surprised:

∗ Display and Read-Only Item security improvments

∗ Read-Only Region and Read-Only Page

∗ Global Application Item

∗ Control over „Embedding in Frames“

∗ Option to define session timeout per Application

∗ Delay after failed login attempts

∗ Deep Linking control in Security Attributes and in Authentication Schema

∗ Restricted Characters in Session State (4.2)

∗ Session State Encryption (4.2)


Add-On Management – Best Practices

∗ Plugins (and Dynamic Actions) were introduced in version 4.0.

∗ The most of the plugins are a mixture of PL/SQL code and jQuery sources.

∗ The goal was to reduce the need for repeated custom coding.



∗ Suddenly, there are a lots of plugins we can use in our applications. This is basically a good thing.

∗ There is a central plugin page at:

∗ http://www.apex-plugin.com/

∗ There are also a couple of consulting companies having their own pool of plugins:

∗ http://www.enkitec.com/products/plugins

∗ http://skillbuilders.com/Oracle-APEX/APEX-Consulting-Training.cfm?category=apex-plug-ins&tab=free-plugin-download

http://www.apex-plugin.com/

http://www.enkitec.com/products/plugins

http://skillbuilders.com/Oracle-APEX/APEX-Consulting-



∗ If you intend to use plugins, you will need a good strategy.

∗ There are a lots of plugins but not all of them satisfy basic quality standards.

∗ There is no commitee for testing and releasing plugins –basically anyone can create a plugin.

∗ Potentially, a plugin could be malicious and do cross-site scripting.

∗ Not all of the plugins work with all APEX versions.

∗ And at the end, your upgrade problems could become a Plugin-problem.



∗ My recommendations regarding plugins:

∗ The best plugins are those developed by the people you know from the community and well established companies – you can be sure that in a case of an APEX upgrade, you will get a new and working version delivered.

∗ Not all of the plugins will work together. Some of the plugins will use different versions of the same library and this may cause problems. Therefore, you should be very carefull and invest some time in testing of the plugins you use in your aplication.



∗ My recommendations regarding plugins:

∗ Never use to many plugins in your application.

∗ Sometimes you can solve a problem without using a plugin.

∗ Use a selective approach in choosing plugins.


Management von Plugins in den APEX-Anwendungen

∗ „Good“ Plugins tested and solid:

∗ Clob Load Plugin:

∗ http://www.enkitec.com/products/plugins/clob-load

∗ Modal Page Plugin:

∗ http://skillbuilders.com/Oracle-APEX/APEX-Consulting-Training.cfm?category=apex-plug-ins&tab=free-plugin-downloads

http://www.enkitec.com/products/plugins/clob-load

http://skillbuilders.com/Oracle-APEX/APEX-Consulting-


Questions?

Application Deployment and Application Management - … ·...

Documents

Transcript of Application Deployment and Application Management - … ·...