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.

Autoinvoice Mater Program Does not spawn Import Program

There could be various reasons why Autoinvoice Master Program does not spawn Autoinvoice Import program, I have listed down all of them below.

1. Order number doesnt exist in ra_interface_lines_all.

2. Batch source name passed in the Autoinvoice Master Program Doesnt belong to the order you are expecting to be invoiced.

3. If the above points are ok then Check the request_id column in ra_interface_lines_All and if its not NULL then query the request_id in fnd_concurrent_Requests.

Query :-

Select * from fnd_concurrent_requests
where request_id = :p_request_id;

Check the stats of concurrent request. If its running then ok if its cancelled or terminated then you need to Nullify the request_id from ra_interface_lines_all and run the Autoinvoice master Program again.

For more about concurrent request status check this link:-
https://oracleapplicationstechfunc.blogspot.in/2017/03/status-code-and-phase-code-in.html


4. Check the parameters passed are correct in Autoinvoice Master Program.