Apps To Fusion

Part II – Extend Application Module and Controller

This is the second article in the series “Custom Defaulting and Validation in iProcurement”. For the readers who jumped into this article directly, I will outline my objective. The objective of the article is to implement custom defaulting and validation in iProcurement using different approaches I learnt, and limitations of each approach. To illustrate each approach I took a sample requirement of copying a DFF attribute value called ‘Fund’ on requisition header to another DFF attribute in requisition line during checkout process.

In the first article, I used POR_CUSTOM_PKG to implement my requirement. Limitation on when por_custom_pkg is invoked during checkout process restricted me to partially achieve my objective. I could copy fund value when the requisition is first created, any change made to fund later is not copied to fund at line level as por_custom_pkg executes only for the first time requisition is created.

In this article I will use OA Framework extension of Application Module and Controller to implement my requirement. If you are not familiar with OA Framework extension, Anil’s articles on OA Framework are great places to start. Recommended readings Extending AM Part 1, Part 2, and Extending Controller.

Approach 2: Extend AM and Controller using OAF extension

The screenshot below shows fund at header level in “Checkout: Requisition Information” page. I’ve to copy fund value entered by user, to fund attribute in requisition line.

The user may go to “Edit Lines” to edit line information or “Save” requisition for later use or “Submit” requisition without bothering to edit lines, during requisition creation process. In order to execute my custom code along with seeded validations/defaulting, I’ve to override the seeded functionality built in the events ‘Save’, ‘Submit’, and ‘Edit Lines’.


How do I do it?

• Override processFormRequest method by Controller Extension to execute custom code.

• Custom code resides in a new method in extended Application Module. AM is the most logical place to do business validations and defaulting

Before I implement above high level steps, I need to find out BC4J components and Controller used in “Checkout: Requisition Information” page. ‘About this Page’ section is a good place to start.

I will follow bottom up approach to create underlying BC4J component i.e. extended AM to call it in controller. Looking closely at process flow on clicking “Edit Lines” button, I came up with how interaction happens between seeded classes.

• ‘Edit Lines’ event is captured in processFormRequest (PFR) method of controller CheckoutSummaryCO. It calls processEditLines method.

• processEditLines calls server command class CheckoutSummarySvrCmd’s method populateAttributesToVOs. This populates VOs PoRequisitionHeadersVO and PoRequisitionLinesVO for requisition header and line respectively from ReqSummaryVO.

Below illustration summarizes the interaction, please note Classes are shown in bold to differentiate them from methods.

PFR in CheckoutSummaryCO > processEditLines > CheckoutSummarySvrCmd > populateAttributes > populateAttributesToVOs
 

Implementation:

Understanding seeded process helps in planning how to write custom code for copying fund from header to line. Fund attribute in header is stored in PoRequisitionHeadersVO, which holds any changes made to fund value. ReqSummaryVO also has DFF attributes information, but Attribute15 is not reflecting the changes I made on the page. Due to this, when the last step of populating header VO from ReqSummaryVO took place new fund value entered is overwritten with old value. This part is crucial as the user is not seeing the changes they made to fund number.

The custom code will fill this gap, by fetching Attribute15 from PoRequisitionHeadersVO and set the new value to ReqSummaryVO. Later when the seeded code executes, new fund value is copied to header and line VOs which in turn stores in the database. The steps for extending application module are:

• Create XxRequisitionAM to extend oracle.apps.icx.por.req.server.RequisitionAM

• Create a new method copyFundFromHeader to set Attribute15 value from PoRequisitionHeadersVO to          ReqSummaryVO

• Substitute RequisitionAM with XxRequisitionAM in ‘Edit Business Components Project’.
• Create controller XxCheckoutSummaryCO which extends oracle.apps.icx.por.req.webui.CheckoutSummaryCO. Override PFR to call copyFundFromHeader method in extended AM, during Edit Lines, Save, and Submit events.

• Upload custom files in $JAVA_TOP or $XX_TOP (if it is CLASSPATH, jserv.properties, zone.properties). Run JPXImporter to load substitution into MDS repository and verify it with JDR_UTILS.listdocuments. Bounce Middle-Tier.

• In Checkout: Requisition Information page, Personalize page is used to substitute XxCheckoutSummaryCO.

I first reaction was blame it on any patches applied by DBAs, but I later came to know this is happening with all list of values in requisition creation process. I turned off all personalizations and removed substitutions, to realize the hard truth that it was my customization which caused this catastrophe. Putting all emotions aside, thinking rationally and referring OAF developer guide, I came to my conscience that this session state expiration is caused by extending root application module. RequisitionAM is root Application module for most pages in requisition creation process. Root Application module is the AM attached to top region of the page during design time. It maintains the session state and retention level for requests between client and server.


Extending root AM is not advisable, unless you know what you are doing. Since I extended root AM, I was loosing session state between main page and Lov region. I tried creating nested Application modules and call it from extended controller, it did not work either because I couldn't get reference to VOs. I read nested AMs are in the same transaction state as root AM, so it may have worked if I had stretched myself to research more. I will cover this in separate article, on how to use nested AMs.

After my failed attempts with nested AMs, iProcurement Architecture Overview document (Metalink Note: 313195.1) came to rescue. It has a section on extending helper classes to do custom validations in iProcurement. My third approach is based on this, which I will cover in the next article.

Update: Writing this article kept me thinking of Application Module Retention Level property. This property indicates how AM should be retained between requests until it is explicitly released. RequisitionAM has retention level as "MANAGE_STATE". I believe I have not set this property for extended application module, when I implemented the above solution. This may be the cause for Lov issue. I will retest it and share the results.

I tested it by setting retention level property for extended AM, I still face the same Lov issue. So there is genuinely something wrong with extension of root AM. If I can get nested AMs working properly, I will have another solution for my requirement.

Comments (4)

Subscribe to this comment's feed

Write comment

Name

Email

Title

Comment

smaller | bigger

Subscribe via email (Registered users only)

Write the displayed characters

Add Comment