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) Business View Others

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)

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

BUTTON Load Free Good Lines

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 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)

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

Object Name

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 Description Comments

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

Sales Order Entry Public Interface and wrappers

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

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

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 "Package" intended for Sales Order Entry only "Package" intended for Sales Order Entry only

B4210090 CRMUserReservedDataProcessing

B4210100 PopulateF4201OrderTypeIndicator

"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

Master Function is to be called by this common function

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)

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)