Kendra Barton - JDE Source | Oracle JD Edwards ... Introduction • 11 years with EnterpriseOne –...

Kendra Barton Principal Software Engineer

JD Edwards EnterpriseOne

Developing Powerform-Based

JD Edwards EnterpriseOne

Applications

Agenda • Speaker Introduction

• Assumptions

• Web Development Client Architecture

• Powerforms & Subforms • Problem Space & Terms

• Powerforms – properties/features

• Reusable & Embedded Subforms – properties/features

• Best Practices

• “Converting” Existing Forms

• Portlets & Wizard Forms

• Summary

• Questions

Speaker Introduction

• 11 years with EnterpriseOne – Runtime

• Three companies

• Six product names

• Tools perspective

• Customer is Application Development

• Business knowledge = none

• Hands On will be simple

• Usability Engineering knowledge = little

• All recommendations are from UE group

Assumptions

• Familiarity with E1 Windows Platform

• Familiarity with E1 Windows Development

• Object Management Workbench

• Design Objects – Data Dictionary, Tables,

Business Views, Forms

• Design Tools – Forms Design Aid

• Familiarity with E1 Form Types

Web Development Client

Architecture

App

Specs

Serialized

Specs

Web Development Client Architecture

EnterpriseOne Windows Client

Local Web

OMW

Solution

Explorer

Design

Tools

Local

Business

Function

Execution

Local Application Server

Web Runtime Engine

HTML Browser(s)

App

Specs

Serialized

Specs

Web Development Client Architecture

EnterpriseOne Windows Client

Local Web

OMW

Solution

Explorer

Design

Tools

Local

Business

Function

Execution

Local Application Server

Web Runtime Engine

HTML Browser(s)

Dynamic

Generation

Lab Machines

• Web Development Client plus

• Enterprise Server

• Security Server

• Database Server

• Deployment Server

• Same image Sales uses for Customer

demonstrations

• Application release 8.11, Tools release 8.94

Powerforms & Subforms

Problem Space • Previous EnterpriseOne Form Types

• Find Browse, Parent/Child Browse, Search Select, Message

• Fix/Inspect, Headerless Detail, Header Detail

• These form types are good for: • Ease of creation

• Working on one data view (2 for header detail)

• Predictable Workflow: Browse first, Edit later.

• These form types are not intended for: • Working on multiple, interrelated data views on one screen.

• Need to use form interconnects for related tasks.

• Powerforms • Powerforms enable a user to work on multiple, interrelated

data views on one screen.

Problem Space

• No good answer for the complex use case

• Separate forms had to be created when an app

needed

• Multiple views of interrelated data

• Multiple grids

• Multiple tab controls

• Tab pages with their own business view

• Business views that communicate, and even react to user

actions that occur in other views

• Existing form types too rigid

Supporting the Complex Case

• A new Web-only form type to solve all the

issues in the problem space – Powerform

• Powerform itself is not complex

• Power Browse – similar to Find Browse

• Power Edit

• With grid – similar to Headerless Detail

• Without grid – similar to Fix Inspect

• Supports the complex cases because only

Powerforms can contain Subforms

Subforms

• A new control/form hybrid

• Form-like

• Associated with a business view

• Owns the data flow between the UI and the database –

fetch, insert, update, delete

• Defined data structure to pass values in/out

• Can contain any control types

• Control-like

• Contained by a form

• Takes up real estate

• System functions to dynamically modify attributes/actions

A Powerform example – SOE

Lab – Approach

• A simple example

• Address and Phone records

• Build a Powerform and Subforms feature by

feature

• Powerform – browse Address Book grid

• Subform – Address Book (update fields)

• Buttons, Structured communication, Functions,

Layout, Transaction boundaries, and more

• Reusable Subform – Phones (update grid)

Lab – Create App

• Run Solution Explorer (activconsole.exe)

• Log in as PSFT/PSFT on lab machines

• Fast path to OMW

• Add

• Interactive Application - OK

• Object name – P55PWRFM

• Product Code/Product System Code – 55

• OK

• Design Tools tab

• Start Forms Design Aid

• OK

Lab – PowerEdit form

• Form > Create > PowerEdit

• Description – Address Book PowerEdit

• Business View – V0101JB Address Book Master

F0101/Address by Date F0116

• Enable In-Your-Face-Errors

• Form > Menu/Toolbar Exits

• Add Find

• Remove OK

Lab – PowerEdit grid columns

• Insert > Grid

• Add grid columns • F0101.AN8 – Address Number

• F0101.ALPH – Alpha Name

• F0116.CTY1 – City

• F0116.ADDS – State

• Set grid property to disable (read only)

• Set grid property for „No adds on update grid‟

• Disable Form property „Update on Grid Business View‟

Lab – Embedded Subform

• Insert > Subform

• Description – Address Book Detail

• Business View – V0101JB Address Book Master

F0101/Address by Date F0116

• Create the Subform Data Structure with

• AN8 – Address Number

• CTY1 – City

• ADDS - State

Lab – Embedded Subform fields

• Add text fields

• F0101.AN8 – Address Number

• Disable Next Numbers

• F0101.ALPH – Alpha Name

• F01161.ADD1 – AddressLine1

• F01161.ADD2 – AddressLine2

• F01161.CTY1 – City

• F01161.ADDS – State

• F01161.ADDZ – Zip Code

Lab – Subform buttons

• Insert > Button

• Open the button properties to make this Find

• Repeat for Save

• Set tab sequence

Subform buttons

• Subforms have buttons, no toolbar

• There is a Button substitute for each standard toolbar

item

• Buttons can be „standard‟ AKA „default‟

• Save (think OK)

• Find

• Delete

• Clear

• Each Subform has at most one of each standard type

• Available types differs for Browse and Edit

Interrelated Data

• There is a hierarchical relationship between

Powerform and the Subforms it contains

• Powerforms have children Subforms

• A Subform has a parent and may have siblings

and children (grandchildren)

• All communication is up or down the hierarchy

• Hierarchical (logical) and physical relationship

are not necessarily identical

Mapping Link

• Mapping link is the data communication channel

between parent and child.

• Each parent/child pair has one mapping link defined.

• Mapping link contains items defined in the child form‟s

data structure.

• Parent (left) side – any ER object can be mapped

• Child (right) side – Subform‟s data structure referred to in

ER as “SI” (Subform Interconnect)

• Three Directions: Parent to Child, Child to Parent, or both.

• Similar to a Form Interconnect

Lab – Hierarchy & Mapping Link

• Open Subform properties to see the default

assignment of its parent

• On the Powerform properties‟ Mapping Link

tab connect as follows

Lab – ER to Execute Mapping Link

• On the Powerform grid Row is Selected event

• On the Subform Find Button Clicked event


• On the Subform Save Button Clicked event

Powerform Communication

Powerform

Child Subform

City Add Num State


Powerform

Child Subform

Row is Selected ER

{

Trigger Default Child Action(child, Find)

}

City Add Num State


Powerform

Child Subform

Row is Selected ER

{


}

City Add Num=1 State


Powerform

Child Subform

Row is Selected ER

{


}


Find Button Clicked

{

BC Address Num = SI Address Num

}

Powerform


Child Subform

Add Num City State

Powerform


Child Subform

Add Num

Save Button Clicked

{

SI City = FC City

SI State = FC State

Update Parent

}

City State

Powerform


Child Subform

Add Num

Save Button Clicked

{

SI City = FC City

SI State = FC State

Update Parent

}

State = CO City = Den

ER to Execute Mapping Link

• Parent to child (down) just before • Trigger Default Action for standard buttons

• Notify Child System Function triggers “Notified by Parent” event on the child

• Subform Functions

• Child to parent (up) • Update Parent System Function

• Often used just prior to Notify Parent System Function which triggers “Notified by Child” event on the parent

Lab – Reusable Subform

• Form > Create > Reusable Edit Subform

• Description – Phones

• Business View – V0115A Phone Number Update

• Create the Subform Data Structure with

• AN8 – Address Number

Lab – Reusable Subform fields

• Insert > Grid

• Add grid columns

• F0115.AN8 – Address Number

• Disable Next Numbers

• F0115.IDLN – LineNumberID

• F0115.PHTP – PhoneNumberType

• F0115.AR1 – PhoneAreaCode1

• F0115.PH1 – PhoneNumber

• Add Address Book equals filter field

Lab – Subform buttons

• Insert > Button

• Open the button properties to make this Find

• Repeat for Save

Lab – Insert Subform Alias

• Insert > Subform Alias • Search for lab application P55PWRFM

• Open Subform Alias properties • Change the parent to be the Address Book Detail

Subform

• On the Address Book Detail‟s Mapping Link tab

• FC Address Number > mnAddress Number

• Note that some properties are set on the Alias, and some are set on the Subform itself


• On the AB Detail Find Post Button Clicked

event

• On the Phones Find Button Clicked event

Powerform Communication Powerform

Child Subform

City Add Num State

Grandchild Subform

Add Num


Child Subform

Row is Selected ER

{ Trigger Default Child Action(child, Find) }

City Add Num State

Grandchild Subform

Add Num


Child Subform

Row is Selected ER



Grandchild Subform

Add Num


Child Subform

Row is Selected ER


Find Button Clicked

{ BC Address Num = SI Address Num }


Grandchild Subform

Add Num


Child Subform

Row is Selected ER


Find Button Clicked



Find Post Button Clicked


Grandchild Subform

Add Num


Child Subform

Row is Selected ER


Find Button Clicked





Grandchild Subform

Add Num=1


Child Subform

Row is Selected ER


Find Button Clicked



Grandchild Subform

Add Num=1

Find Button Clicked

{ FC Address Num = SI Address Num }



Lab - Subform Functions

• Part of a Subform‟s “interface”

• With the Reusable Subform highlighted

• Form > Create > Function

• Add ER from the tree on the left hand side

• From an event on the Embedded Subform

• Add the „Call Function‟ system function

Reusable Subforms as Parents

• This lab has a Reusable Subform as a child

• When a Reusable Subform is the logical parent but not the physical parent:

• ER cannot reference children by name

• Trigger Default Child Action can only broadcast messages to <All Children>

• Call Function cannot introspect to the child‟s functions

• When a Reusable Subform is both the logical and physical parent:

• ER can reference children by name

Transaction Processing (TP)

• Enabling Powerform TP

• Creates and commits/rolls back a Manual

Commit transaction during OK processing

• The TP boundary can be extended to include

specific ER lines

• The TP boundary can be extended to include

subforms

Transaction Processing (TP)

• Enabling Subform TP

• Subforms can create their own TP boundary

• Subforms can inherit their parent‟s TP boundary,

if any

Lab – Transaction Processing

• On the Address Book Detail Subform set the

subform only option

• On the Phones Subform set the Include in

Parent Transaction option

• From the Address Book Detail Save Post

Button Clicked event

Lab – Checking Subform Errors

• Only errors on the current Form/Subform will cause

Save processing to halt

• To make errors from a child Subform halt the current

Form/Subform Save process, use system function

„Get Error Count‟

Powerform

Child Subform 1


Child Subform 2

Powerform

Child Subform 1


Child Subform 2

Trigger Default Child Action – i.e. Find, Save

Find Find

Powerform

Child Subform 1


Child Subform 2

Call Function (child, functionName)

Powerform

Child Subform 1


Child Subform 2

Call Function (child, doSomeWork)

doSomeWork

{

}

Powerform

Child Subform 1


Child Subform 2

Notify Child (child(ren))

Powerform

Child Subform 1


Child Subform 2

Notified by Parent

{

}

Notify Child (child(ren))

Notified by Parent

{

}

Powerform

Child Subform 1


Child Subform 2

Powerform

Child Subform 1


Child Subform 2

Assign to SI

Powerform

Child Subform 1


Child Subform 2

Assign to SI

Update Parent

Powerform

Child Subform 1


Child Subform 2

Notified by Child

{

Call Function (child2, doSomeWork)

}

Assign to SI

Update Parent

Notify Parent

Powerform

Child Subform 1


Child Subform 2

Notified by Child

{

Call Function (child2, doSomeWork)

}

Assign to SI

Update Parent

Notify Parent

doSomeWork

{

}

Lab – Controlling UI

• Open Address Book Detail Subform

properties

• Check Collapsible

• Open Phones Subform (Alias) properties

• Uncheck Show Subform Header

• Open Powerform grid‟s properties

• Check Reclaim Whitespace

Powerform/Subform Grids

• For Powerforms/Subforms the size at Design

time is a maximum size

• For all other form types the size at Design

time is a minimum size

• Only Powerform/Subform grids can „reclaim

whitespace‟

• Reclaiming whitespace effects both the

container‟s size and all controls below the grid

Best Practices

Powerform Layout

Powerform (Level 0)

Child Subform (Level 1)

<Header> and/or <Detail>

(Level 0)

Powerform (Level 0)


Powerform Layout


(Level 0)

Grandchild Subform (Level 2)

Powerform (Level 0)

Child Subform 1 (Level 1)

Powerform Layout


(Level 0)

Child Subform 2 (Level 1)

Powerform (Level 0)


Powerform Layout


(Level 0)

Grandchild

Subform 1 (Level 2)

Grandchild

Subform 2 (Level 2)

Powerform Layout

• The most important information should visually

precede the less important information

• Presentation of information should follow the

sequence in which the user needs it - it should relate

to the user‟s mental model for the task

• Common information should be in consistent locations

across the UI

• Frequently needed or referred to information should

be in the most prominent locations across the UI

Toolbars

• Applications with a hierarchical layout of

subforms that have push buttons should not

use the toolbar

• Hide the toolbar and provide form and

subform level push buttons instead

• Do not use a combination of toolbar actions

and repeated buttons together

Form/Row Exits

• All “Form Exits” should be placed within the

form/subform boundary above all form content

• All “Row exits” should be placed below the

grid within the form/subform boundary

• When there are more than 4 Form/Row exits,

place them in a drop down menu.

Required Fields

• Users need to know that certain fields are

mandatory to complete a task and to avoid

errors

• Turn on the “Required Entry” option in the edit

field property in FDA

• Connect the static text to the edit field

Grids

• Do not display more than three grids on a page

• Place grids in the order the user will view and interact

with the information

• If more than one grid is displayed, limit the number of

visible rows to five on each grid

• Limit the number of grid columns on the page

• If a grid requires more columns than can fit, prioritize

and create grid formats

• Try to limit the number of grid columns to eight

• Display the most critical, frequently used columns first

Command Buttons

• Users need consistent command buttons

when working with a multiple grid page

Button Behavior

Save Changes Saves changes and keeps form open

Save and Continue Save and go on to the next step

Save and Add New Save and add another record

Save and Close Save changes and close the form

Cancel Discards changes and closes the form

Close Closes the form

Undo Changes Reverts to the state of the last save

“Converting” Existing Forms

“Converting” Existing Forms

• There is no magic. No silver bullets.

• Examine Form and Row Exits for Subform

conversion candidates

• Prioritize the user tasks each form provides

• A Subform should replace the most important

and most frequently used tasks

• Strive for simplicity in subforms – retain

Form/Row Exits for remaining tasks

Portlets and Wizards

Wizards

• A new form type, built on the backbone of Powerforms

• Collection of subforms, arranged in sequence

• Tool provides

• Navigation buttons

• Left hand navigation/task list

• Progress bar

• Transaction processing to commit all subforms together

• Application developer specifies

• Task sequence – can be dynamically changed

• Partial save logic – when wizard has not completed

Wizards

Portlets

• Portal Content produced from Forms Design Aid

• JSR 168 Compliant • Java Specification Request 168

• To enable interoperability between Portlets and Portals, this specification will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security.

• Structurally similar to Subforms

Portlets

Summary

Summary

• Web Development Client Architecture

• Local Web Server

• Local Business Function Execution

• On the fly generation

Summary

• Powerforms

• New web-only form type that can house subforms

• Browse or Edit

• Reusable & Embedded Subforms

• Control/form hybrid

• Contract with Parent (and children)

• Data structure

• Size

• Functions/Standard buttons

• Parent notification

Summary

• Best Practices

• Powerform Layout

• Toolbars

• Form/Row Exits

• Command buttons

• Multiple grid guidelines

• “Converting” Existing Forms

• Portlets & Wizard Forms

Q U E S T I O N S

A N S W E R S

Kendra Barton - JDE Source | Oracle JD Edwards ... Introduction • 11 years with EnterpriseOne –...

Documents

Transcript of Kendra Barton - JDE Source | Oracle JD Edwards ... Introduction • 11 years with EnterpriseOne –...