Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 
 

Oracle Application Express (APEX): Calling reusable pages in separate applications

Oracle Tips by Burleson Consulting

When developing large systems in APEX it is imperative that we have the ability to invoke a page (or a set of pages) within another application and return without loosing the session state of the calling routine.  Based on my research, it appears that parts of APEX pages cannot be dynamically included for reusability, but if the common component is encapsulated into a page, that page can be made reentrant, and called like a subroutine, performing a database action and returning the item values via a known interface, in a separate APEX application.

Having standard shared components (e.g. lookup a person name) simplifies the APEX application and allows subroutine-like calls from anywhere.  This ability to re-use APEX code across applications is critical for many reasons. 

  • Reduces developer effort - The ability to create reusable components reduces coding overhead and there is never any need to reinvent the wheel and re-write a common routine.
     

  • Adds screen uniformity - Shared components reduce end-user training and provide a recognizable standard for shared system functions.
     

  • Simplifies maintenance - When a change to a shared component is made, the change will be immediately available to all calling components without any code changes.

Let's take a look at how to create a cross-application reusable subroutine page in APEX.  In this example, we interface a page in another application to access and return from a shared "person lookup" APEX screen (page).

STEP 1: Setup calling page

The shared page must accept the calling application:page as variables by creating two hidden page items on the subroutine page:

Pxxx_RETURN_APP_ID Hidden
Pxxx_RETURN_PAGE Hidden

On the calling screen, we go to the page definition "Branches", and we make a branch to the shared subroutine page, passing our application number and APEX page number. 


This Branch is then associated with the button on the calling screen:

At this point, mashing the FIND_ADD_INDIVIDUAL_SPONSOR button will invoke the cross-application screen (500:20051 in this example) and setup the APEX "f?p=" URL syntax to pass the page information.

Since we are navigating to another application (and the session state is not shared between APEX applications) we need to do some setup by using page processing computations. In the "page definition" screen for the calling page, we create a page computation that sets the SEARCH session state on a condition. The value is set to EmployeeSearch (BTW: I recommend using CAPS for these names because JavaScript is case sensitive) since that is what the request is when the button is pressed.

The value of SEARCH is used by processes (Before Regions) when returning to the page so it can populate the Employee Information.

Now, let's see how we intercept and process the keys when they are passed-back from the called cross-application page.  In the main page definition for the calling page we define two "before regions" computations:

In the set person ID computation, we check the "case" when our search has completed, and pass the value from the incoming URL into the screen item's value:

The second "before regions" process takes the keys and performs the SQL to access the table and populate the screen with details:


STEP 2: Setup called subroutine page

Within the called page, we define hyperlinks in the first name and last name report columns, so that when the end-user clicks the link, the page will return to the calling page with the data that we need:

Inside the reports region for the called screen, we see that we see the inks that we have created for the last name and first name report columns:

When we click on the detail icon on the far left of the above screen, we see the URL that returns to the calling application page, passing the variables that the calling application requires:

This is the link-back to the calling screen.  The two keys (person_id and adr_id in this example) are wrapped into the URL of the column link. In the URL below, we pass-back a person_id and an address_id:

f?p=&P20551_RETURN_APP_ID.:&P20551_RETURN_PAGE.:&SESSION.::&DEBUG.::
PERSON_ID,ADDRESS_ID:#PERSON_ID#,#ADR_ID#

SEE CODE DEPOT FOR FULL SCRIPTS

While APEX does an excellent job in managing session state within an application, this technique can be used to create cross-application page calls and allow large APEX systems to be created with common, reusable pages, a critical feature for reducing duplicate coding and improving screen uniformity.

For more details on this technique, I recommend the book Easy Oracle HTML-DB Application Express .


APEX support:

For APEX development support just call to gat an Oracle Certified professional for all APEX development projects.

APEX book and code samples:

Easy Oracle HTML-DB Application Express
Create Dynamic HTML with Oracle

Includes online APEX code depot

Buy it now for 30% off - Only $27.95
 

 

 

��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational