MVC Architecture

The architecture of the portal UI is based on the Model-View-Control (MVC) design pattern. The MVC paradigm allows you to separate the code that handles business logic from the code that controls presentation and event handling. Each page in the portal is made up of a combination of at least one Model and View, and one or more Controls.

• Model classes store the data for a page or page section. A single page might use one or more Model classes, depending on how much of the page data can be shared by other types of pages. A Model defines how data is accessed and set for a given page, including any functions necessary for security or data validation and modification. Models encapsulate calls to the portal server API and also store UI-specific data. Data that is globally accessed by the UI is available from the ActivitySpace object (discussed on the next page). All other data should be stored in a Model.

• View classes contain HTMLElements and HTMLConstructs that describe how the data from the Model should be displayed to the user. In the portal UI design, DisplayPage objects are used to aggregate View objects to encapsulate all the information needed to render a particular page. Some Views are common throughout the portal and some are specific to certain pages. For example, the banner that makes up the majority of the portal is a common View that defines the color scheme and where the search section will be displayed. In contrast, the View used to create and modify data within a User Profile is specific to the User Profile function and is seen only on that page.

• Control are actions or sets of actions that are executed when a specific event is triggered. Multiple Controls can be defined within a page, each with its own functional specification. For example, one Control might produce a popup window that allows the user to browse for a specific object and places the selection within the View, and another could save the new data to the Model.

error: APP-AR-11221 : you must save this transaction before attempting to make it complete

Problem:     error: APP-AR-11221 : you must save this transaction before attempting to make it complete

Error: APP-AR-11221 : you must save this transaction before attempting to make it complete, user has to exist the form, re query the manual credit memo transaction to be able to save it


Symptoms:

Create AR transaction with source Manual Credit Memo and transaction type as Credit Memo

Log files:
ar.plsql.arp_ct_pkg.lock_compare_p.begin arp_ct_pkg.lock_compare_p()+
ar.plsql.arp_ct_pkg.lock_compare_p EXCEPTION: arp_ct_pkg.lock_compare_p NO_DATA_FOUND


Solution:

Trailing spaces issue:- 

Columns detected with trailing spaces / uncompiled AR% objects in APPS schema.


Please find file afchrchk.sql under $FND_TOP/sql. Please run the
same and this will create a procedure: chk_trail_space.
After successfully running this , please execute the below commands and then this will diagnose
the problematic columns (trailing spaces) and then run subsequent update scripts
and check whether the issue is resolved or not.

Usage:

"set serveroutput on " and execute the same,one by one.
execute chk_trail_space ('RA_CUSTOMER_TRX_ALL');
execute chk_trail_space ('RA_CUSTOMER_TRX_LINES_ALL');
execute chk_trail_space ('RA_CUST_TRX_LINE_GL_DIST_ALL');
execute chk_trail_space ('RA_BATCHES_ALL');

On executing a script, if you get an output for a table, then issue the update
statement below , issuing a COMMIT then.

update <table name>
set <column name> = rtrim(<column name>);

Follow Note 416878.1 to correct the trailing spaces / Compile all AR% objects in APPS schema using adadmin


References:


Note 416878.1 to correct the trailing spaces / Compile all AR% objects in APPS schema using adadmin