MVC Architecture and Sales Order Entry

Purpose of Document

This document is to explain how MVC architecture (powerform) is implemented and how to debug in hitting any issue in running a certain application which is written based on MVC architecture.

The reason is that logs (both jdedebug.log and jasdebug.log) may not describe information on controllers and wrappers (C business functions) so there may be possible difficulties in debugging. As name implies though View, Model and Controllers are written in C and executed in logic server and detail information is not to be written into call object kernel log. However how these behavior will be written well in jasdebug.log (runtime debug log).

So this document is to serve how to debug application which is written MVC (and/or power form) architecture in EnterpriseOne.

DISCLAIMER
The following is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle.

What is MVC Architecture?

Model-View-Controller (MVC) is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data. The MVC pattern hinges on a clean separation of objects into one of three categories - models for maintaining data, views for displaying all or a portion of the data, and controllers for handling events that affect the model or view(s).

• Model (data and its surrounding Business Logic)
• (Application) Controller
• View (controller)

So routine to handle business data is:
: E1 Form -> View (Controller) -> (Application) Controller -> Model (Business Logic) -> Master Business Function

Events typically cause a controller to change a model, or view, or both. Whenever a controller changes a model's data or properties, all dependent views are automatically updated. Similarly, whenever a controller changes a view, for example, by revealing areas that were previously hidden, the view gets data from the underlying model to refresh itself.

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. An E1 form typically has a one to one correspondence with a display surface and knows how to render to it.

The controller receives input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and E1 form to perform actions based on that input.

Object References:

View (Controller) Related (B4210400 to B4210899)

(Application) Controller (B4210900 - B4210999)

Model Related (Business Logic) - B4210000 to B4210399

Example of implementation:

A. Sales Order Header

• S421007A for user interface
• (View) B4210670 - S421007A_SOHeaderViewController
• (Controller) B4210900 - SalesOrderApplCtrlEX
• (Model) B4210000, B4210010 and B4210020
• which is calling B4204200 - ProcessSOHeader then eventually B4200310 - F4211FSBeginDoc gets called (which validate header information and create cache for header)

B. Sales Order Detail

• S421002C for user interface
• (View) B4210620 - S421002C_SOLineViewController
• (Controller) B4210900- SalesOrderApplCtrlEX
• (Model) B4210000, B4210030
• which is calling B4204200 - ProcessSODetail then B4200310/F4200311 - F4211FSEditLine gets called (which validate detail information and create cache for detail)

For Sales Order Entry of P42101,

A. (View for Header) B4210670 contains below 2 BSFNs:

• S421007A_InitializeSoHeader (S421007A Initialize Sales Order Header)
• S421007A_SOHeaderViewController (S421007A Sales Order Header View Controller)

A1. (View for Detail) B4210620 is made up of:

• S421002C_InitializeSODetail (S421002C Initialize Sales Order Detail)
• S421002C_SOLineViewController (S421002C Sales Order Line View Controller)
• S421002C_ValidateApprarelTemplate (S421002C Validate Apparel Template)
• S421002C_GetItemInquiryMode (S421002C Get Item Inquiry Mode)
• S421002C_SetPropertiesAndErros (S421002C Set Sales Order Line Properties and Err)
• S421002C_SetSOLineErrors (S421002C Set Sales Order Line Errors)

B. Then B4204200 is calling:

• ProcessSOHeader (Process SO Header Wrapper)
• ProcessSODetail (Process SO Detail Wrapper)
• ProcessConfigurator (Process Configurator Wrapper)
• CommitSalesOrder (Commit Sales Order Wrapper)
• ClearSOWorkFile (Clear Work File Wrapper)
• TPPostCommit (TP Post Commit Wrapper)

C. Master Business Function for Sales Order (B4200310/B4200311) is made up of:

• F4211FSBeginDoc (F4211FSBeginDocument)
• F4211FSEditLinePreProcess (F4211 Pre Process Values for Edit Line)
• F4211FSEditLine (F4211 Edit Line) which is calling B4200311 - F4211SOEInternalFunctions (F4211 Sales Order Entry Internal Functions)
• F4211FSEditDoc (F4211 Edit Doc)
• F4211FSEndDoc (F4211 End Document)
• F4211ClearWorkFile (F4211 Delete Work File)

So relationship between Model and Master Business Functions are:

• ProcessSOHeader -> F4211FSBeginDoc
• ProcessSODetail -> F4211FSEditLinePreProcess and F4211FSEditLine
• CommitSalesOrder -> F4211FSEndDoc)
• ClearSOWorkFile -> F4211ClearWorkFile
• TPPostCommit (Auto Rollback or release record reservation and so on)