VIDEO: JDE Sevice Oriented Architecture (SOA)

VIDEO: Creating a Business View

VIDEO: Creating a Interactive Application

VIDEO: Creating a Simple Batch Application (Report)

VIDEO: Creating a OMW project

Project and its attributes

• A Project is made up of Objects and Owners.
• A Project consists of OneWorld objects that have been modified or created by a developer.
• A Project includes Owners who play different roles in the development process.
• All development of OneWorld Objects will be done in the context of a Project.
Default Project
• The first time a developer uses OMW a Default Project is created.
• The Default Project is named after the user’s ID.
• All development done outside of OMW is stored in the Default Project.
• Default Projects cannot be advanced to another status code.
User Roles
• User Roles define the allowed actions a specific user can perform on a project.
• The administrator assigns allowed actions to each User Role.
• You may add as many people to each User Role in a project as necessary.
Object
• Traditionally a OneWorld Object was defined as any object created in Object Librarian. : Applications, Business Functions, Business Views, UBEs, Data Structures, Tables, Media Objects
• The definition has now been expanded to include non-Object Librarian Objects: Data Dictionary Items, User Defined Codes, Workflow Items, Menus, Versions
Token
• A Token has a One-to-One relationship with the following objects: Applications, Business Functions, Business Views, UBEs, Data Structures, Tables, Media Objects and Batch Versions
• The Token is used to minimize the possibility of one user overriding another user’s changes to an object.
• When an object is checked out and is not already checked out by another user, the project receives a Token.
• A Token can be released, switched or inherited.
• The Token is released by the project when the project reaches the status designated by the administrator for release.
• A Token is not released by the project when the object is checked back in.


Queue up for token
This option is available to the developer upon realizing another project holds the token.


Inherit token
This option is also available to the developer upon realizing another project holds the token.

Release token
This option must be performed by an owner of the project that currently holds the token.

Switch token
This action can only be performed by an owner defined in the Object Management Configuration program. The recommendation is for a manager to be allowed to perform this action.

Constants
Enables the administrator to set the following general constants pertaining to OMW Projects:
• Project Status for Users' Personal Default Projects
• Project Status for All New Projects
• User Role to be Assigned to the Project's Originator
SAR System Integration
• For J.D Edwards internal development and clients using the SAR system.
• Integrates all development with the SAR System.
Logging System
• Tracks information about projects and objects.
• All actions are logged by OneWorld User ID.
• Administrators can reduce logging detail.
• A major log is created whenever:
o A project is created, copied, or deleted
o The project status is changed
o A new or existing object is added to or removed from a project
Object Action Notification
• Enables you to activate or deactivate object action notification.
• Sends you an e-mail each time an event occurs to one of your objects, such as check in or check out.
• Object action notification is enabled by default.

Notification Setup
• Sends e-mail messages to users regarding changes to objects in the system, such as when an object is checked in or checked out.
• Allows you to add, delete, and modify notification subscriptions, as well as to sort notification subscription records by criteria you select.

Activity Rules
• Object Transfer Activity Rules
• Define FROM and TO locations for each object type at each project status transition
• Define get locations for all object types
• Define check out and check in locations for Object Librarian objects

User Roles
• User Roles define the user's function within the project organization.
• When defining user roles, you specify a User Defined Code value or job title for roles that can be performed on a project.
Example:
o 01 Originator
o 02 Developer
o 03 Manager
o 04 Quality Assurance
o 05 PVC Administrator
Allowed Actions

• Rules that define the actions that may be performed by a project owner who has been assigned a certain user role.
• Rules are set up for each user role, object type, and project status
Example:
o 02 Check in
o 03 Check out
o 04 Delete
o 05 Add
o 10 Design

Save Locations
o Indicates the save-off location for Object Librarian (OL) Objects.
o The save location must be different than the check in location.
o Save-off work in development that is not ready to be checked in.

ONE WORLD EVENTS

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.