This chapter contains the following topics:
This section discusses:
Object storage.
Object movement.
Performing backups and restoring objects.
Correlating replicated and central objects.
By industry standards, an object is a self-sufficient entity that contains data as well as the structures and functions that are used to manipulate the data. An object is also a reusable entity that is based on software specifications. A specification is a complete description of a system object. Each object has one or more of its own specifications.
The system stores objects in three formats:
Central objects are stored in a relational database format.
Objects are stored in a central location to enable deployment and development. Central objects consist of object specifications for each JD Edwards EnterpriseOne object and C components for code-generated objects. Central object specifications are stored in a relational database on a data server.
Package objects, or replicated objects, are stored in XML format in a relational database.
Package objects are created during the package build process. You can specify the database data source in which to build the shared spec repository. This shared repository usually exists on a data server. Several enterprise servers and web servers can share this repository. A set of replicated objects is also stored in a local database on each developer workstation.
Serialized objects are stored in database tables and used by web clients at runtime.
Web servers use on-demand generation to create serialized objects from the shared spec data source. The generator converts specs into Java code, which enables you to access the JD Edwards EnterpriseOne applications in HTML. The system stores the objects in a relational database and retrieves them at runtime.
When you perform any of these tasks, objects move between the central objects location and the object destination:
Check in or check out objects.
Add existing objects to a project.
Perform a get object in Oracle's JD Edwards EnterpriseOne Object Management Workbench application (P98220).
Run Oracle's JD Edwards EnterpriseOne Workstation Installation application.
During the workstation installation, all objects and the Supported Local Database, which contains replicated data, are copied from the package to the workstation. The system copies objects in only those packages for which you included specifications. If the package does not include specifications, objects are not replicated; instead, they are installed on the workstation through just-in-time installation.
Unless otherwise noted, object movement is the same when you check objects in or out, add objects to a project, or perform a get object. This table describes the objects and specifications that move when you check in, check out, add, or get each type of object:
You can back up development objects on workstations and servers as frequently as necessary.
Consider these scenarios and solutions when developing your backup strategy:
A company does not allow the developers to back up directory data to the server because of space concerns.
Developers are required to check in their development objects at specific time intervals, such as every eight hours, to avoid rework. Unless you have unlimited disk space on a file server to enable developers to back up their entire path code directory, you must use the check-in process as your backup method. If you follow the recommended development process, developers will know that they can check in unfinished or malfunctioning applications to the DEV path code.
For workstation backups, end users should not have non-replicated data on their machines.
For development server backups: At a certain company, the IT department backs up both the development file server (normally the deployment server) and necessary databases (central objects, Object Librarian, and data dictionary).
When a developer needs to restore a particular object from backups, a database administrator restores the export to a path code called Restore. The developer checks out the object from Restore, ensures that the object functions as expected, and checks the object into the normal development path code.
For deployment server backups: In most cases, you do not need to back up the entire server nightly.
However, under certain conditions, you might need to back up these directories nightly:
The DEV path code, if you are modifying objects, building new packages, or updating the database that is delivered during a workstation installation.
MEDIA OBJ, if your media objects reside on the deployment server.
Data sources in Oracle or SQL Server, if your system data or any other important data is stored on the deployment server.
For enterprise server backups:
Back up the DBMS nightly.
You should use the backup tool that your database vendor provides.
Back up objects by backing up the entire directory.
Also back up the PROD and DEV path codes and the jde.ini file.
Path codes are updated when the Version Control administrator deploys an object that was modified by developers who are authorized to access the Server Package application, and by end users who create new batch versions that will be run on the server.
This table describes the correlation between the spec data in the package build objects and the central objects that are stored in a relational database that has a binary large object (BLOB):
| Replicated Package Build Object | Central Object |
|---|---|
| F98710<package name> | The F98710 table contains one record for each table. |
| F98711<package name> | The F98711 table contains one record for each column in a table. |
| F98712<package name> | The F98712 table contains one record for each table index. |
| F98713<package name> | The F98713 table contains one record for each column in an index. |
| F98720<package name> | The F98720 table contains one record for each business view. |
| F98740<package name> | The F98740 table contains one record for each event that has event rules for applications, reports, or tables. (Named event rule links are stored in the F9862). |
| F98741<package name> | The F98741 table contains one record for each line of event rules. |
| F98743<package name> | The F98743 table contains one record for each business function, processing option, form interconnection, report interconnection data structures, and power form. |
| F98750<package name> | The F98750 table contains override text for applications. |
| F98751<package name> | The F98751 table contains one record for every column, grid line, button, hyperitem, control, and so on, in the application. |
| F98752<package name> | The F98752 table contains one record for each application. If the application has processing options, that information is also stored in the record. |
| F98753<package name> | The F98753 table contains one record for each form (and also includes references to the data structures). |
| F98760<package name> | The F98760 table contains override text for batch reports. |
| F98761<package name> | The F98761 table contains one record for each section, column, sort, constant, and so on, in Batch Reports and Versions. |
| F98762<package name> | The F98762 table contains one record for each function in BSFN. |
| F98770<package name> | The F98770 table contains only one record for each package. This table is empty in Central Objects. |
| CGTYPE | Code Generator Form Types are stored in specification format only. |
| DDDICT
DDTEXT |
One record exists for each data dictionary item that has been just-in-time installed.
This is data dictionary text. |
| GLBLTBL | This cache information from data dictionary and table specifications contains runtime table and override information. This is built dynamically the first time that a table is used. |
| SMRTTMPL | This is field information required by the data structure. |
| F9200
F9202 F9203 F9207 F9210 |
F9200
F9202 F9203 F9207 F9210 |
| NEXTID | The F98701 table contains a local record of next IDs that are assigned to each workstation. |
Types of modifications.
Objects that an upgrade preserves and replaces.
Because JD Edwards EnterpriseOne Development Tools are comprehensive and flexible, you can configure certain aspects of business solutions and applications without making custom modifications. This concept is referred to as modless modifications. Modless modifications are modifications that you can perform easily without the help of a developer. You can perform modless modifications on:
User overrides
User-defined codes (UDCs)
Menu revisions
All text
Processing options values
Data dictionary attributes
Workflow processes
This flexibility improves efficiency and provides distinct advantages, such as the ability to:
Export grid records to other applications, such as a Microsoft Excel spreadsheet.
Re-sequence a grid on a different column.
Change grid fonts and colors.
Control major system functions using processing options.
Developers may need to modify the JD Edwards EnterpriseOne software more extensively. To ensure that the modifications perform like modless modifications and to provide a seamless and predictable upgrade to the next release level, you should verify that any software modifications that you make comply with the recommended rules and standards.
To ensure a smooth upgrade, you should prepare for the upgrade before you make any custom modifications. If you plan modifications properly, you can minimize the tasks that you need to perform following an upgrade. Planning usually reduces the time that is required to upgrade your software, therefore reducing disruption to your business and the overhead cost of the upgrade.
The system tracks all custom modifications as you check them into the server. Before you perform an upgrade, you can run Oracle's JD Edwards EnterpriseOne Object Librarian Modifications report (R9840D) to see a list of the changed objects.
The system consists of control tables, such as menus, UDCs, versions, and the data dictionary, and transaction tables, such as the F0101 table. The system provides control tables, which contain data that you can modify, as well as transaction tables, which contain your business data.
During an upgrade, both sets of tables go through an automatic merge process. The system merges control tables with new data and converts transaction tables to the new specifications without changing your existing data. For the object specification merges (such as business views, tables, data structures, processing options, event rules, and applications), the system merges the specifications or replaces them, depending on the rules that are defined in the software.
Modification rules exist for these types of objects:
Interactive applications
Reports
Application text changes
Table specifications
Control tables
Business views
Event rules
Data structures
Business functions
Versions
Business services
If you require custom modifications to the software to meet your business needs, use these general definitions to ensure a smooth and predictable upgrade. These definitions describe which modifications the upgrade process preserves and which modifications it replaces:
Preserves
During an upgrade, the system automatically merges your modifications with the new applications that are shipped with the upgrade, and you do not lose your modifications. If a direct conflict exists between your specifications and system specifications, the upgrade process uses your specifications. When no direct conflict exists, then the upgrade process merges the two specifications.
Replaces
The upgrade does not merge your modifications with new applications and, therefore, the new software replaces your modifications. You must recreate your modifications after the upgrade finishes.
Run the JD Edwards EnterpriseOne Object Librarian Modifications Report (R9840D) before the upgrade process to identify the objects that you modified.
These general modification rules apply to all objects:
When adding new objects, use system codes 55–59.
The system uses its own reserved system codes that enable it to categorize different applications and vertical groups. When you use system codes 55 through 59 for your custom modifications, the system does not overlay your modifications with new applications.
Do not create custom or new version names that begin with ZJDE or XJDE.
These prefixes are reserved for standard version templates that are included with the software, and these prefixes do not preserve your custom versions in case of a naming conflict. You can copy the pristine versions to create new templates or versions.
For upgrades, build a package from the last modified central objects set and perform backups of your development server, central objects, and Object Librarian data sources so that you can access those specifications for comparison or for troubleshooting purposes.
None of the custom modifications to the JD Edwards EnterpriseOne applications are preserved during the Batch Specification Merge process. Instead, administrators must manually retrofit the modifications from a JD Edwards EnterpriseOne workstation with the help of Oracle's JD Edwards EnterpriseOne Visual ER Compare and FDA Compare tools when the upgrade is complete.
For Oracle's JD Edwards EnterpriseOne Report Design Aid specifications, do not delete objects on existing reports. Hide the objects that you do not want to appear. The system might use these objects for calculations or as variables, and deleting them could disable major system functions.
This table describes the report elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| New reports. | X | You can either create a new report or copy an existing report using the Copy feature in Report Design Aid. This feature enables you to copy all the report specifications, including event rules.
If you use the Copy feature to copy an existing report for some modifications, during an upgrade your new report does not receive any changes that might have been made to the original report. |
|
| New constants added to existing reports. | X | ||
| New alphabetical variables added to existing reports. | X | ||
| New numeric variables added to existing reports. | X | ||
| New data variables added to existing reports. | X | ||
| New runtime variables added to existing reports. | X | ||
| New database variables added to existing reports. | X | ||
| New data dictionary variables added to existing reports. | X | ||
| Style changes. | X | Style changes include fonts and colors. New controls have the standard base definitions. If you have adjusted the default style, you need to also adjust the styles for any new controls that you added to a report. | |
| Location and size changes for objects. | X | In a subsequent release of the software, a new object, such as a control, might be placed in the same location as you placed a custom object. In this case, the objects appear next to each other. This situation does not affect the event rules or the functions of the report in any way. After the upgrade, you can use Report Design Aid to rearrange the objects. | |
| Data dictionary overrides. | X | ||
| Custom sections on existing reports. | X | Instead of adding custom sections to existing reports, use Report Interconnect and connect to a new custom report that uses system codes 55 through 59. System performance is not adversely affected when you call a report through report interconnections. |
This table describes the application text that is preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| Overrides performed in JD Edwards EnterpriseOne Application Design Aid. | X | Use the JD Edwards EnterpriseOne Visual Compare tools. | |
| Overrides performed in JD Edwards EnterpriseOne Report Design Aid. | X | ||
| Overrides performed in JD Edwards EnterpriseOne Interactive Vocabulary Override. | X | Use the JD Edwards EnterpriseOne Visual Compare tools. | |
| Overrides performed in JD Edwards EnterpriseOne Batch Vocabulary Override. | X |
An upgrade merges your table specifications from one release level to the next.
This table describes the table specification elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| New Tables. | X | ||
| Custom indexes to tables. | X | ||
| Columns added to or removed from existing tables. | X | This object includes changing field length, field type, and decimal position.
Instead of adding a new column to an existing table, use a tag table with system codes 55 through 59. |
For custom tag files, be aware of data item changes in the data dictionary. In subsequent releases, JD Edwards EnterpriseOne software might contain changes to certain attributes of a data item, such as its size, that might affect data integrity and how the data is stored in the database. For this reason, you might need to use Oracle's JD Edwards EnterpriseOne Table Conversion tool to convert the tag file data to the new release level. For base files, the upgrade process automatically applies the data dictionary to the new release level. An upgrade preserves custom indexes for the custom tag files.
Control tables contain UDCs, menus, and data dictionary items. An upgrade merges your control tables from one release level to the next using the change table process, which uses your control tables, not system tables, as the basis for the data merge.
This table describes the control table elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| Data dictionary custom changes. | X | This object includes changes to row, column, and glossary text. The upgrade process uses your data dictionary as the base, and in case of a conflict with system data items, your changes override. Create new data items using system codes 55 through 59. | |
| UDCs. | X | The upgrade process merges any new, hard-coded values. (Oracle-owned values are stored in systems 90 and above, and H90 and above.) The process also reports any hard-coded values that conflict with your custom values. | |
| Menus. | X | In case of a conflict with base menus, your custom changes override. | |
| Columns added or removed from existing control tables. | X |
Do not remove columns from existing business views. Changing business views that applications use can cause unexpected results when you run the application. If you need to hide columns, do so within the application design using either JD Edwards EnterpriseOne Application Design Aid or Report Design Aid. Deleting a few columns from a business view does not significantly improve system performance.
This table describes the business view elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| New custom business views. | X | ||
| New columns, joins, or indexes that are added to existing business views. | X | ||
| Columns that are removed from business views. | X |
During the upgrade process, the system checks for custom event rules that conflict with new event rules that the software installs. If a conflict exists, the system disables the custom event rules and appends them to the end of the new event rules.
This table describes the event rule elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| Custom event rules for custom applications, reports, and tables. | X | ||
| Custom event rules for custom business functions. | X | ||
| Custom event rules on a new custom control. | X | Use the JD Edwards EnterpriseOne Visual Compare tools. | |
| Events for system applications, reports, and tables that do not have any system event rules attached to the same event. | X | ||
| Events for system business functions that do not have any system event rules attached to the same event. | X | ||
| Events for system applications, reports, and tables that have existing event rules attached to the same event. | X | Use the JD Edwards EnterpriseOne Visual Compare tools. | |
| Events for system business functions that have event rules attached to the same event. | X | Use the JD Edwards EnterpriseOne Visual Compare tools. |
To restore your custom event rules to system objects, highlight and drag the event rules back to the proper place in the event and enable them. Prior to an upgrade, perform these tasks:
Run the JD Edwards EnterpriseOne Object Librarian Modifications report to identify modified applications.
Print the event rules for the modified application so that you can see the logic for the event when you restore custom event rules.
This table describes the data structure elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced |
|---|---|---|
| Custom forms' data structures. | X | |
| Custom processing options' data structures. | X | |
| Custom reports' data structures. | X | |
| Custom business functions' data structures. | X | |
| Custom generic text's data structures. | X | |
| Modifications to existing system forms' data structures. | X | |
| Modifications to existing system processing options' data structures. | X | |
| Modifications to existing system reports' data structures. | X | |
| Modifications to existing system business functions' data structures. | X | |
| Modifications to existing system generic text's data structures. | X |
To bring forward to the next release level the custom modifications that you made to system data structures, run the JD Edwards EnterpriseOne Object Librarian Modifications report (R9840D) to list all of the modified data structures. Use this report as a guide when you manually enter data structure changes.
For any new custom business functions (BSFNs), create a new custom parent DLL to store your custom modifications. Always use the standard application program interface (API), jdeCallObject, to call other business functions from within a business function.
To bring your custom changes forward to the next release level, run the JD Edwards EnterpriseOne Object Librarian Modifications report (R9840D) to list all of the modified business functions. Use this report as a guide when you manually enter the business function changes.
To determine whether the source code of existing base business functions has been modified, use a third-party source-compare tool, such as Microsoft WinDiff. To determine modifications to APIs within business functions, see the online help feature for the most current information about APIs.
This table describes the business function elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| New custom business function objects. | X | ||
| Modifications made to existing system business function objects. | X | Named event rule (NER) BSFNs can be modified. |
For new custom versions, create a new version with a name that does not begin with XJDE or ZJDE.
This table describes the versions elements that are preserved or replaced during an upgrade:
| Object | Preserved | Replaced |
|---|---|---|
| Non-Oracle versions. | X | |
| Version specifications. | X | |
| Processing option data. | X | |
| All ZJDE and XJDE version specifications. | X | |
| All processing option data for XJDE versions. | X |
In addition, processing option data is copied but not converted for non-Oracle versions that use processing option templates. A warning is issued at runtime, and some data might be lost.
Also, event rule modifications for custom versions of JD Edwards EnterpriseOne templates are not reconciled with the parent template.
This table describes the business services elements that are preserved or replaced during an upgrade.
| Object | Preserved | Replaced | Comments |
|---|---|---|---|
| New custom business service | X | n/a | Custom objects are always preserved. |
| New object within an existing JD Edwards EnterpriseOne business service | n/a | X | JD Edwards EnterpriseOne objects are always replaced. |
| Changed object within an existing JD Edwards EnterpriseOne business service | n/a | X | JD Edwards EnterpriseOne objects are always replaced. |
| Business services selected as web services | X | n/a | Within P9603, you select which business services will be exposed as web services. This selection is preserved. |