Orchestrations in JDE

Creating Custom Orchestration Java Classes

Before creating we must include following JAR files

OrchestratorCustomJava.jar (For definition of the interfaces).

AIS_Client.jar 1.1.0 or higher. (For the loginEnvironment attribute and enables AIS calls to JD Edwards EnterpriseOne)

OrchestratorCustomJava.jar (For custom rule implementation by using the CustomRuleInterface class and for implementation of CustomServiceRequestInterface class )

Custom Java for the Orchestration Service Request

Custom service request Java classes should implement the com.oracle.e1.rest.orchestrator.customjava.CustomServiceRequstInterface which requires the following methods:

setLoginEnvironment(com.oracle.e1.aisclient.LoginEnvironment loginEnvironment). The method used to perform AIS calls.

process(). The method that returns javax.ws.rs.core.Response which is called automatically after all the attributes are set.

Custom Java for the Orchestration Rule

Custom rule Java classes should implement the com.oracle.e1.rest.orchestrator.customjava.CustomRuleInterface 

For following methods:

setLoginEnvironment(com.oracle.e1.aisclient.LoginEnvironment loginEnvironment). The method used to perform AIS calls.

evaluate(). The method that returns Boolean and is called automatically after all the attributes are set.

Power Forms

Power Forms

A power form is a web application form that enables users to view multiple, interrelated views of data, grids, and tab pages on one form and to pass logic among them. The tab pages can have their own business views, and these business views can communicate with each other and can update data based on selection and changes that occur in other business views on the form. Power forms are designed for advanced end users.

Advantages:-

Multiple views on a form.

Multiple grids on a form.

Multiple tab controls on a form.

Tab pages with their own business views.

Business views that communicate with each other and are updated based on selection and data changes that occur in other views on the same form.

 Power Form Types

 The types of power forms are:

 • Power Browse.

 • Power Edit.

 • Reusable Browse subform.

 • Reusable Edit subform.

Power Browse Form

 Similar to a Find/Browse form, a Power Browse form is designed  only for browsing data. Editing capabilities are not available on  this form.

  Power Edit Form

 Similar to a Headerless Detail form, a Power Edit form is  designed for browsing and manipulating data.

 Reusable Browse and Edit Subforms

 Reusable subforms are discrete objects in the system that  represent one data view. Reusable subforms are referenced through  other applications with aliases. Subforms own the data flows    between the interface and the database.

Power Form Performance

 Power forms work best when you use an object-oriented design to  create them. When you design modifications or applications, you  need to identify objects (subforms), how the objects interact  with each other (business logic or actions), and when their  attributes (variables or fields) interact or change (states).  This design is necessary to minimize the data passed between  parent and child forms.

Power Form Key Standards

 When using Power forms and subforms to create an interactive application, follow these key standards:

 • Do not implement search and edit use cases on the same form.

 • Avoid toolbars on Power forms.

 If your application includes a hierarchical layout of subforms and these subforms include push buttons, do not use the toolbar. Hide the toolbar and provide form and subform level push buttons instead. Toolbars should be avoided as much as possible in 8.12 applications

 • Follow a standard naming convention.

 For example: <Application Title> - <Verb> <Object Name> for Requisition Inquiry - Search for Requisitions.

 • Title all subforms, unless they contain tabs.

 • Name grids so that the displayed information is clearly identified, unless the grid appears alone on the form.

Power Form Types

 The Power Browse and Power Edit forms have extended functionality when subforms are embedded or referenced. Using power forms to create applications has many advantages. For example, applications are usually characterized by a sequence of forms. Typically, a user launches an entry form and then, to update information or find related data, must navigate through a series of interconnected forms. Power forms eliminate these navigations by enabling the developer to place subforms on power forms.

The general properties of Power forms are:

• All regular controls except a parent-child control can be placed on a power form.

• Multiple tab controls are permitted.

• The maximize grid feature is supported for all grids.

• Power forms contain both vertical and horizontal scroll bars.

• Only power forms can contain subforms.

• Power forms run only on the web.

Power Browse Form

The Power Browse form enables:

• View-only.

• Subforms.

Power Browse forms with a business view should always have a grid with at least one column.

Power Edit Form

 The Power Edit form enables:

 • Data modification.

 • Data browsing.

 • Subforms.

Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

 The Power Edit form enables:

 • Data modification.

 • Data browsing.

 • Subforms.

 Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

  Subform Types

 The two subform types are:

 • Standard subforms.

 • Reusable subforms

Subforms can exist as discrete objects in the system. You can place the subform itself on a power form; this action is referred to as embedding. You can also reference an existing subform on a power form with an alias; this action is referred to as reusing. Typically, you reuse subforms that are designed to appear on numerous forms, such as the display of address book information. In this way, you can more easily standardize the interface.

Reusable Subforms

 A reused subform is actually just a pointer; therefore, it is unaware of its parent and children in any given context. If you want a reused subform to communicate with its parent or children, you must do so through ER. While you cannot embed a subform within another subform, you can reuse a subform within another

subform. In other words, you can embed or reuse a subform within a reusable subform, but you cannot embed

or reuse a subform within an embedded subform. Inserting reusable subforms in a form is different from inserting an embedded subform. They exist as two different control types in the user interface. Therefore, the FDA Menu/Toolbars contain two different insert actions. If you insert an alias, you are prompted for the application. If you insert a reusable subform, you are prompted for the subform. You cannot insert a subform onto a form until the application the subform has been defined in has been saved. Reusable subforms can be written once and then reused in any other power form. They are created as their own entity within an application. The different types of reusable subforms are Browse and Edit.

  

A subform is a control designed for use on a power form or another subform. Although technically a control, subforms have some form characteristics as well. Each subform represents one data view. That is, each subform control can have a single business view (BSVW) attached to it. Power forms can contain several subforms, so a single power form with multiple subforms enables users to see multiple data views. For example, a user selecting a purchase order in a grid could see related shipping information in one subform and fulfillment information in another subform on the same power form. When the user selects a row in the grid, all of the data is updated. Most importantly, the user does not have to open a new form to see the updated data.

 Together, power forms and subforms provides you with the ability to code:

 • Multiple views on a form.

 • Multiple grids on a form.

 • Multiple tab controls on a form.

 • Tab pages with their own business view.

 • BSVWs that can communicate with each other and even react to selection and data changes that occur in other views on the form.

  

Processing Of power forms:-

Power Browse:-

 When a Power Browse form is called, runtime initializes these items in this order:

1.   Thread handling.

2.   Error handling process.

3.   Business view columns.

4.   Form controls (FC).

5.   Grid fields.

6.   Static text.

7.   Help.

8.   Event rule structures.

Events

 The Power Browse form supports these events:

 • Dialog is Initialized.

• Post Dialog is Initialized.

• End Dialog.

• Grid Record is Fetched.

• Write Grid Line-Before.

• Last Grid Record Has Been Read.

• Write Grid Line-After.

• Row is Selected.

• Notified By Child.

  

Power Edit Form

 When a Power Edit form is called, runtime initializes these items in this order:

1.   Thread handling.

2.   Error handling process.

3.   Business view columns (BC).

4.   Form controls (FC).

5.   Grid fields.

6.   Static text.

7.   Helps.

8.   Event rule (ER) structures

Events for a Form with Grid Control

 These events can occur on the Power Edit form during runtime if the form contains a grid control:

• Dialog is Initialized.

• Post Dialog is Initialized.

• Grid Record is Fetched.

• Last Grid Record Has Been Read.

• Clear Screen Before Add.

• Clear Screen After Add.

• Write Grid Line-Before.

• Write Grid Line-After.

• Post Commit.

• Notified by Child and End Dialog

Events for a Form without a Grid Control

 These events can occur on the Power Edit form during runtime if the form does not contain a grid control:

• Dialog is Initialized.

• Post Dialog is Initialized.

• Clear Screen Before Add.

• Clear Screen After Add.

• Add Record to DB - Before.

• Add Record to DB - After.

• Update Record to DB - Before.

• Update Record to DB - After.

• Post Commit.

• Notified by Child.

• End Dialog.

When you place subforms on a power form or another subform, the system treats the interactions among them as parent-child relationships. The power form or subform acts as the parent, and the subforms act as the children of the power form and as siblings to each other. This hierarchical relationship governs logical relationships. It is also represented visually in the Form Design Aid (FDA) application tree view as a hierarchy to help you understand the relationships.

Similar to a form, a subform owns the data flows between the interface view and the database, including browse, insert, update, or delete. In fact, you create a subform as if it is a form, and then you place it as a control. Do not let its appearance fool you: a subform is really a control, and the FDA interface treats it accordingly. For example, if subform B is contained in power form A, then when you select B the FDA control bar still displays the title of A. Additionally, if you view the data structure, you will see the data structure for A and not for B.

Hierarchical Structure

The two hierarchies in FDA are:

• Control hierarchy.

• Business view hierarchy.

Control Hierarchy

In this hierarchy, controls are contained within other controls.

 Business View Hierarchy

 The business view hierarchy enables you to connect business view containers (subforms) to each other. Subforms can only interact with their parent and their children. This hierarchy should be created based on relationships between business views. Data flows between parent and child in the business view hierarchy. There is no direct data flow among siblings or from the power form to the grandchild subform

Transaction Boundaries

 Power forms include the transaction property, which functions in the same way with other form types. By default, the transaction property is scoped to OK  button processing; however, the scope can be extended to business functions, table input/output (I/O), and form interconnects.Subforms are scoped to Save button processing; however, the scope can be extended to business functions, table I/O, and form interconnects. When you include all forms in the transaction boundary and the roll back data on any one form, the system rolls back the changes on all of the forms

JDE ER

JDE ER

Events

Events are points in the normal execution or flow of an interactive or batch program. In Event Rules Design, you can specify the particular event to which you want to attach an API. Examples of events are: Entering a Form, Exiting a Field using the Tab key. Events are predefined in the OneWorld toolset and cannot be changed.

Batch Application Events

Batch Application Events give you flexibility and control over how your reports are processed. For example, you can hide or show an object, hide or show a section, or generate a message.

Batch Application Events consist of the following Categories:

·        Section Level Events

·        Page Footer Section Level Events

·        Page Header Section Level Events

·        Report Footer Section Level Events

·        Report Header Section Level Events

·        Variable Events

Section Level Events consist of the following:

·        AdvanceSection

·        AfterLastObjectPrinted

·        BeforeLevelBreak

·        DoBalanceAuditor

·        DoColumnHeading

·        DoSection

·        DoTabularBreak

·        EndBrkSection

·        EndLvlBrkFooterSection

·        EndLvlBrkHeaderSection

·        EndOfReport

·        EndSection

·        EndVariable

·        InitLvlBrkFooterSection

·        InitLvlBrkHeaderSection

·        InitializeSection

·        RefreshSection

·        SupendSection

AdvanceSection: Advance Section should be used if you need to perform processing on object before a fetch. This occurs each time you do a fetch from the database. If this section does not have a business view attached, then this event is processed once.

AfterLastObjectPrinted: AfterLastObjectPrinted should be used to process information after a row has been output. This occurs after a row is printed to an output file.

BeforeLevelBreak: BeforeLevelBreak should be used to do processing after a fetch, but before any level breaks are checked.

DoBalanceAuditor: Event Rules for this event process form interconnect information and generate the Balance Auditor link information to be displayed in the PDF file.

DoColumnHeadin: DoColumnHeading event will happen once for every column header that is printed on a report. This applies to both columnar and tabular style sections. This also applies to when column headers are reprinted after a page break has occurred. Regardless of why the column headings are printing, this event will be executed.

DoSection: DoSection occurs after Advance Section after values have been assigned to print out to a printer or an output file. This event occurs before any information for the current record is written to the PDF file. This event occurs before DoCell (if Tabular cells exist) and before DoVariable/DoConstant.

DoTabularBreak: DoTabularBreak occurs when any of the business view fields set as level breaks change. This is only valid for tabular sections. Use this to do processing that requires a change of values in any of the level break fields.

EndBrkSection: Event Rules attached to this event occur after a Level Break finishes. After the event has terminated, the Level Break Header begins processing.

EndLvlBrkFooterSection: EndLvlBrkFooterSection should be used to do processing immediately after a level break footer.

EndLvlBrkHeaderSection: EndLvlBrkHeaderSection should be used to do processing immediately after a level break header.

EndOfReport: EndOfReport sends INIT_PAGE_FOOTER and INIT_REPORT_FOOTER messages.

EndSection:  EndSection occurs after a batch process has completed processing the last set of section values. Use this to do processing immediately after a section ends. This event is useful for last record and end of file procedures.

EndVariable: EndVariable occurs immediately after the object has been processed, even if the object is invisible or suppressed.

InitLvlBrkFooterSection: InitLvlBrkFooterSection is to be used to do processing immediately before a level break footer.

InitLvlBrkHeaderSection: InitLvlBrkHeaderSection should be used to do processing immediately before a level break header.

InitializeSection: InitializeSection occurs when a batch process encounters a section for the first time. Use this to do processing immediately before a section begins. This is useful for working with global variables or performing other preparatory procedures. For conditional sections, this event will be processed each time the section is called.

Refresh Section: The first time the UBE encounters a child section; it issues an initialize section event. Each subsequent time the child section is to be processed, the batch process uses Refresh Section. At this point, the internal structures and pointers for the child section have been established and the UBE is about to select a new group of records for the child section. This logic also works for the level break sections. use this to set the object values of level two sections based on the parent section. You can also use this event to reset or modify data selection and sequencing of the child section.

SuspendSection: SuspendSection processes when an overflow page break occurs. For example, if the information printed does not fit in the space available on a page. This temporarily stops the section processing. Use this to do processing when a page break occurs

Page Footer Section Level Events

InitializePageFooter: InitializePageFooter occurs at the beginning of the report after any report header logic and before the page header section processes for the first time. Use this to initialize values to be printed in the current page footer section. These assignments typically depend on information processed so far on that page.

Page Header Section Level Events

EndPageHeader : EndPageHeader after the page header finishes processing. Use this to do processing immediately after a page header.

InitializePageHeader: InitializePageHeader occurs at the beginning of a report after any report header logic and before the page header section processes for the first time. It also processes every time a page break occurs. Use this to initialize values that cannot be set until after the report header logic executes. This is similar to Init Section for a normal group, columnar, or tabular section, except that it is only processed for a page header section.

Report Footer Section Level Events

EndReportFooter: EndReportFooter occurs after the report footer processes. After processing finishes, the report terminates. Use this to do processing immediately after a report footer.

InitializeReportFooter: InitializeReportFooter occurs once at the very end of a report after everything else processes and before the report footer prints. use this to initialize values to print in the report footer.

Report Header Section Level Events

EndReportHeader: EndReportHeader occurs after the report header processes. Then the report processes the page header for a report. Use this to do processing immediately after a report header.

InitializeReportHeader:  InitializeReportHeader processes once at the very beginning of the report before anything else in the report processes. Use this to initialize values at the beginning of a report. This is similar to Init Section for a normal group, columnar, or tabular section except that it only processes for a report header section.

Variable Events

ClearSpace: ClearSpace occurs when a section reaches its end. If there is a need to process any information at the time a Section is completed, this is the event at which to attach the ER.

ColumnInclusion: ColumnInclusion occurs right after a record is fetched. 

DoVariable: DoVariable occurs just before the font and color are selected for the report object and before the value of the object is translated into a printable string of characters and output to the page. This is your last chance to manipulate the value or display attributes of the object before output.

InitializeVariable:  InitializeVariable is invoked each time a report object, or variable, is to be processed.
SkipVariable: If an object will not fit on the current page, the UBE will issue a SkipVariable, which will cause the object to be bypassed until the next page begins processing.

SuspendVariable: If an object requires multiple lines to print, such as a long text string or column heading, and if only part of the object fits onto a page, then the UBE will issue a SuspendVariable, which causes processing of the object to be halted until the next page has been started. The value of the object has already been partially processed when this event happens, so this would be a risky time for Event Rules to manipulate that value.

JD Edwards Enterprise One

Important Reports

Reports:

Purchase Order:
Purchase Order Print	R43500
Open Purchase Orders	R43632
Sales Order:
Print Pick Slips	R42520
Print Invoices	R42565
Sales Update	R42800
Batch Ship Confirmation	R42500
EDI:
EDI Inbound Purchase Order Edit/Create	R47011

Important Applications

Applications:

Address Book:
Address Book Revisions	P01012
Batch Address Book Revision	P0101Z1
Contact Information	P01111
Revise Phone Numbers	P0115
Customer Master	P03013
Vendor Master	P0401
Inventory:
Location Master	P4100
Item Master	P4101
Item Branch	P41026
Item Ledger Enquiry	P4111
Inventory Issues	P4112
Inventory Transfers	P4113
Inventory Adjustments	P4114
Cycle Count Entry	P4141
Inbound Cycle Count Enquiry	P4141Z1
Purchase Order:
Purchase Orders	P4310
Purchase Order Receipts	P4312
Voucher Match	P4314
Sales Order:
Sales Order Entry	P4210
Shipment Confirmation	P4205
EDI: (Table)
EDI Purchase Order Header Inbound	F47011
EDI Purchase Order Detail Inbound	F47012

Important Tables

Tables:

Address Book:
Address Book Master	F0101
Address Book – Who’s Who	F0111
Address Book – Contact Phone Numbers	F0115
Address Book – Electronic Address	F01151
Address Book – Address by Date	F0116
Address Organizational Structure Master	F0150(p02150)
Inventory:
Location Master	F4100
Inventory Constants	F41001
Item Units of Measure Conversion Factors	F41002
Item Master	F4101
Item Branch File	F4102
Item Location File	F41021
Item Cross Reference File	F4104
Item Cost File	F4105
Item Base Price File	F4106
Item Ledger File	F4111
Supplier Price/Catalog File	F41061
Purchase Order:
Purchase Order Header	F4301
Purchase Order Detail File	F4311
Purchase Order Receiver File	F43121
Purchase Order Detail Ledger File	F43199
Supplier Master	F0401
A/P Ledger	F0411
Customer Master by Line of Business	F0301 (F03012 in E900)
General Accounting:
General Ledger	F0911
Account Balances	F0902
Account Master	F0901
Customer Ledger	F03B11

Sales Order:
Sales Order Header	F4201
Sales Order Detail	F4211
Sales Order Detail - History	F42119
Sales Order Ledger	F42199
Invoice Print File	F42565