E1: 42: MVC Architecture (Powerform) and Sales Order Entry (P42101) [ID

1212163.1]
Modified 19-MAY-2011 Type TROUBLESHOOTING Status PUBLISHED
In this Document
Purpose
Last Review Date
Instructions for the Reader
Troubleshooting Details
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.
What is MVC Architecture?
View (Controller) Related (B4210400 to B4210899)
(Application) Controller (B4210900 - B4210999)
Model Related (Business Logic) - B4210000 to B4210399
Example of implementation:
References

Applies to:
JD Edwards EnterpriseOne CRM Sales Order Entry - Version: 8.11 Base and
later [Release: 8.11Base and later ]
JD Edwards EnterpriseOne Sales Order Entry - Version: 8.11 Base and later [Release:
8.11Base and later]
JD Edwards EnterpriseOne Sales Order Management - Version: 8.11 Base and later
[Release: 8.11Base and later]
JD Edwards EnterpriseOne Sales Order Processing - Version: 8.11 Base and later
[Release: 8.11Base and later]
Information in this document applies to any platform.

Purpose
The audience for this note is someone with developer level knowledge.

Last Review Date

May 19, 2011

Instructions for the Reader

A Troubleshooting Guide is provided to assist in debugging a specific issue. When
possible, diagnostic tools are included in the document to assist in troubleshooting.

Troubleshooting Details

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)

Object
Name
P42101 Main
Application
Search and
Container
forms

Form

View
Controller (DS)

B4210450 W42101A_InitOrderInquiryEX
W42101A (D4210421A)
Manage
B4210450 Pending
V4211AC_AdaptPendingViewData
Order
(D4210420B)
B4210440 - obsolete
W42101B Confirm
N/A
Cancel
B4210420 W42101B_InitOrderInquiryEX
W42101C (D4210420A)
Manage
B4210420 Existing
V4211AC_AdaptViewData
Order
(D4210420B)
B4210410 - obsolete
(SO Create) B4210400 W42101D_CreateSalesOrder
(D4210400A)
W42101D (SO Confirm) B4210400 Enter New
W42101D_ConfirmSalesOrder
Order
(D42100400B)
(SO Submit) B4210400 SubmitSalesOrder (D4210400C)

Business
View

Others

Manage
Pending Order
Search
F4211Z1
V4211Z1A - Init is written at
Dialog Is Intialized
- Adapt is written at
Grid Record Is
Fetched event
Confirm
N/A
Cancel
Message

V4211AC

Manage
Existing Order

N/A

Enter New
Order - Main
Container
Implemented in
Button Clicked Event

P421001 Sales Order

Header

P421002 Sales Order

Detail

P421003 Line Default

Form

P421004 Line
Availability
P421005 Order
Summary

W42101E Order
N/A
N/A
Header
Revision
S421001E B4210610 Sales
S421001E_InitializeSOHeader
Order
(D4210610C)
N/A
Header
B4210610 - SOHeaderViewController
Reusable
(D4210610A)
Subform
B4210620 S421002C_InitializeSODetail
(D4210620C)
B4210620 S421002C_SOLineViewController
(D4210620A)
S421002C - B4210620 Sales
S421002C_SetSOLineErrors
Order
(D4210620A)
N/A
Detail
B4210620 Reusable S4210620_SetPropertiesAndErrors
Subform
(D4210620A)
B4210620 S421002C_GetItemInquiryMode
(D4210620D)
B4210620 S421002C_ValidateApprarelTemplate
(D4210620E)
S421003A
- Sales
B4210630 Order Line
S421003A_SetSOLineDefaults
N/A
Default
(D4210630A)
Reusable
Subform
S421004B Sales
Order
N/A
N/A
Availability B4210640 - obsolete (D4210640A)
Reusable
Subform
S421005D B4210650 N/A
- Sales
S421005D_CalculateOrderSummary
Order
(D4210650A)
Summary

Header
Revision

Button clicked or in
exiting a certain form
control these are to be
called to display data

BUTTON Initialize
Detail
and depends on user
interface each BSFN
can be called

EVENT: Notified By
Parent

No viewer for this

form.
Calling External
B4101220 CalculateAvailability
BUTTON Recalculate

Reusable
Subform
S421006A
- Free
P421006 Goods
Free Goods
Reusable
Subform
S421007A
P421007 - - Sales
Lean
Order
Header
Header
Form
Reusable
Subform
N4210430 - N/A
View
Dispatcher
it is used for
form
interconnect

B4210660 S421006A_GetFreeGoodLines
(D4210660A)

N/A

B4210670 S421007A_InitializeSOHeader
(D4210670C)
N/A
B4210670 S42007A_SOHeaderViewController
(D4210670A)
B4210440 is made up of below
N/A
functions
GetAgreementData (D4210440AJ)
GetApparelMatrixData
(D4210440AP)
GetConfiguredItemData
(D4210440D)
GetCrossReferenceItemData
(D4210440L)
GetCustomerSegmentItemData
(D4210440W)
GetDisplayBeforeAcceptData
(D4210440H)
GetFreeGoodCatalogData
(D4210440AC)
GetInventoryCommitmentData
(D4210440X)
GetKitItemData (D4210440N)
GetLocalizationData (D4210440AL)
GetOrderAddressData (D4210440AF)
GetOrderTemplatesData
(D4210440R)
GetP42101ProcessingOptions
(D4210440AO)
GetPrePaymentData (D4210440AI)
GetPriceHistoryData (D4210440J)
GetProductAllocationData
(D4210440P)
GetProductVariantsData
(D4210440AK)
GetRevisionHistoryData
(D4210440AE)

BUTTON Load Free

Good Lines

BUTTON Initialize
Header
Or exiting a certain
form controls
Client only NER so it
behavior like
interactive application

B4210440 GetSalesCommissionData
(D4210440T)
GetServiceLevelRuleData
(D4210440AS)
GetSupplyDemandData
(D4210440AD)
GetVertexGeocodeData (D4210440Z)
GetVolumeBasedUpsellingData
(D4210440U)
PostProcessRateShoppingInfo
(D4210440AN)
PreProcessRateShoppingInfo
(D4210440AM)
PreprocWorkWithShipmentsByOrder
(D4210440AA)
ProcessAgreement (D4210440AJ)
ProcessApparelMatrixData
(D4210440AQ)
ProcessCrossReferenceItems
(D4210440M)
ProcessInventoryCommitment
(D4210440Y)
ProcessOrderTemplates (D4210440S)
ProcessLinePriceHistory
(D4210440K)
B4210440 ProcessProductAllocation
(D4210440Q)
ProcessProductCatalogLines
(D4210440AB)
ProcessProductVariants
(D4210440AK)
B4210440 ProcessSOConfiguredLine
(D4210440E)
ProcessSOKitLine (D4210440O)
ProcessSupplyDemand
(D4210440AG)
ProcessVolumeBasedUpselling
(D4210440V)
UpdatePrePaymentFlag
(D4210440AI)

(Application) Controller (B4210900 - B4210999)

Object Name

Description
Sales Order Entry
B4210900
- Application
PopSalesOrderViewStackItemEx Controller.
SalesOrderApplCtrlEX
Interactive mode
SalesOrderApplCtrlStandaloneEX and standalone
mode

Comments
The Sales Order Action is defined in
the Header File (b4210900.h) as
well as default view selections
application and versions.

Model Related (Business Logic) - B4210000 to B4210399

Object Name

Scope of
Interface

B4210000 CancelSalesOrderEX
CancelSalesOrderLineEX
ClearSalesOrderEX
ClearSalesOrderLineEX
ConfirmSalesOrderEX
CreateSalesOrderEX
GetSalesOrderKeyEX
Public
GetSalesOrderLineEX
GetSalesOrderPOEX
GetSalesRelatedProcessVersionsEX
ProcessSalesOrderHeaderEX
ProcessSalesOrderLineEX
SubmitSalesOrderEX
UpdateSalesOrderLineEX
"Package" B4210010 intended for
CreateSalesOrderFunctions
Sales Order
Entry only
"Package" B4210020 intended for
ProcessSalesOrderHeaderFunctions Sales Order
Entry only
"Package" B4210030 intended for
ProcessSalesOrderLineFunctions
Sales Order
Entry only
"Package" B4210040 intended for
ConfirmSalesOrderFunctions
Sales Order
Entry only

Description

Sales Order
Entry Public Interface
and
wrappers

Order Level
interface and
implemenation
Header Level
interface
and
implementation
Line Level
interface and
implementation
Order
confirmation
interface and
implementation

Comments

This is a wrapper
function only and
there is
no business logic
implemented here

B4210050 SubmitSalesOrderFunctions

B4210060 CancelSalesOrderFunctions
B4210070 ClearSalesOrderFunctions

"Package" intended for

Sales Order
Entry only
"Package" intended for
Sales Order
Entry only
"Package" intended for
Sales Order
Entry only

"Package" B4210080
intended for
DefaultHeaderContactInformationE
Sales Order
ValidateContactIDRetrieveAlphaE
Entry only

B4210090 CRMUserReservedDataProcessing

"Package" intended for

Sales Order
Entry only

B4210100 PopulateF4201OrderTypeIndicator

"Package" intended for

Sales Order
Entry only

"Utility
Package"
B4210390 - intended for
SalesOrderModelCommonFunctions
Sales Order
Entry only

Order
submission
interface and
implementation
Order
Cancellation
interface and
implementation
Order Cleanup
interface
and
implementation
Contact
defaulting and
validation
interface and
implementation
CRM User
Reserved
fields interface
and
implementation
Order type
indicator
interface and
implementation
Sales Order
Model and
common
function for
interface and
implementation

Example of implementation:
A. Sales Order Header

S421007A for user interface

(View) B4210670 - S421007A_SOHeaderViewController
(Controller) B4210900 - SalesOrderApplCtrlEX
(Model) B4210000, B4210010 and B4210020

Master Function
is to be called by
this common
function

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)

Note:

In jdedebug.log (namely call object kernel log) does not contain information on
wrapper functions
For this example, B4210900, B4210000 and B4204200 won't be appeared
B4210000.h contains all the definition on behavior
Call object kernel may not show how parameters are handled through View,
Controller and Model

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)