E 24256
E 24256
E 24256
April 2013
JD Edwards EnterpriseOne Tools Package Management Guide, Release 9.1.x E24256-06 Copyright 2011, 2013, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
Contents
Preface ............................................................................................................................................................... xiii
Audience..................................................................................................................................................... Documentation Accessibility ................................................................................................................... ...................................................................................................................................................................... Related Documents ................................................................................................................................... Conventions ............................................................................................................................................... xiii xiii xiii xiii xiv
iii
Cumulative and Noncumulative Update Packages .................................................... Comparing Deployment Methods ................................................................................. Deploying Various Types of Modifications .................................................................. Just-in-Time Installation .................................................................................................. Recommendations for Sites Using Full Packages with JITI........................................ Disabling JITI..................................................................................................................... Package Implementation ........................................................................................................
3 Understanding Objects
3.1 Objects .......................................................................................................................................... 3-1 3.1.1 Object Storage....................................................................................................................... 3-1 3.1.2 Object Movement................................................................................................................. 3-2 3.1.3 Performing Backups and Restoring Objects .................................................................... 3-4 3.1.4 Correlating Replicated and Central Objects .................................................................... 3-5 3.2 Modification Rules...................................................................................................................... 3-6 3.2.1 Types of Modifications........................................................................................................ 3-6 3.2.2 Objects That an Upgrade Preserves and Replaces .......................................................... 3-7 3.2.2.1 General Rules for Modification .................................................................................. 3-8 3.2.2.2 Interactive Applications .............................................................................................. 3-8 3.2.2.3 Reports ........................................................................................................................ 3-10 3.2.2.4 Application Text Changes ........................................................................................ 3-11 3.2.2.5 Table Specifications ................................................................................................... 3-11 3.2.2.6 Control Tables ............................................................................................................ 3-12 3.2.2.7 Business Views........................................................................................................... 3-12 3.2.2.8 Event Rules ................................................................................................................. 3-13 3.2.2.9 Data Structures........................................................................................................... 3-14 3.2.2.10 Business Functions .................................................................................................... 3-14 3.2.2.11 Versions....................................................................................................................... 3-15 3.2.2.12 Business Services ....................................................................................................... 3-15
4 Assembling Packages
4.1 4.1.1 4.1.2 4.2 4.2.1 4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.4 4.4.1 4.4.2
iv
Understanding the Package Assembly Process...................................................................... 4-1 Package Assembly Director................................................................................................ 4-1 Accepting Default Values ................................................................................................... 4-3 Verifying a Path Code for Package Assembly ........................................................................ 4-3 Understanding the Process to Verify a Path Code.......................................................... 4-3 Form Used to Verify a Path Code for Package Assembly ............................................. 4-4 Verifying a Path Code for Package Assembly................................................................. 4-4 Assembling a Package Using Director Mode ......................................................................... 4-4 Using Director Mode to Assemble a New Package ........................................................ 4-5 Adding a New Foundation Location ................................................................................ 4-7 Adding a Database Location .............................................................................................. 4-7 Adding Features to a Package ........................................................................................... 4-8 Reviewing the Package Assembly Selections .................................................................. 4-9 Assembling a Package Using Express Mode ....................................................................... 4-10 Understanding Express Mode ........................................................................................ 4-10 Forms Used to Assemble a Package Using Express Mode ......................................... 4-11
Revising an Existing Package................................................................................................. Understanding the Package Revision Process.............................................................. Prerequisite ........................................................................................................................ Form Used to Revise an Existing Package .................................................................... Revising an Existing Package.......................................................................................... Activating an Assembled Package ........................................................................................ Understanding the Activation Process .......................................................................... Form Used to Activate an Assembled Package............................................................
5.4.3.1 Files Created by a Business Function Build........................................................... 5.4.3.2 Where Business Functions Are Stored ................................................................... 5.4.3.3 Specification Files ...................................................................................................... 5.4.4 Windows Server Build ..................................................................................................... 5.4.4.1 Files Created by a Business Function Build........................................................... 5.4.4.2 Where Business Functions Are Stored ................................................................... 5.4.4.3 Specification Files ...................................................................................................... 5.4.5 IBM i Server Build............................................................................................................. 5.4.5.1 Files Created by a Business Function Build........................................................... 5.4.5.2 Where Business Function Source Members Are Stored....................................... 5.4.5.3 Specification Files ...................................................................................................... 5.5 Features ..................................................................................................................................... 5.5.1 Defining Features.............................................................................................................. 5.5.2 Feature INF Files............................................................................................................... 5.5.2.1 [Header] ...................................................................................................................... 5.5.2.2 [Registry]..................................................................................................................... 5.5.2.3 [INI] ............................................................................................................................. 5.5.2.4 [FileSets] ...................................................................................................................... 5.5.2.5 [Shortcut] .................................................................................................................... 5.5.2.6 [ThirdPartyApps] ...................................................................................................... 5.5.2.7 [ODBCDataSources]..................................................................................................
5-17 5-17 5-18 5-18 5-18 5-19 5-19 5-20 5-20 5-20 5-21 5-21 5-22 5-22 5-22 5-23 5-23 5-24 5-24 5-25 5-25
6 Building Packages
6.1 Understanding the Package Build Process.............................................................................. 6-1 6.1.1 Directory Structure for Packages....................................................................................... 6-1 6.1.1.1 Example: JD Edwards EnterpriseOne E900 Directory Structure........................... 6-1 6.1.2 Package Build Tasks ............................................................................................................ 6-2 6.1.3 Package Build Definition Director..................................................................................... 6-3 6.1.3.1 Viewing Package Build History and Resubmitting Builds .................................... 6-4 6.1.4 Business Function Builds During Package Build............................................................ 6-4 6.1.5 Package Compression ......................................................................................................... 6-5 6.1.5.1 Compressing Server Packages .................................................................................... 6-5 6.1.5.2 Compressing Server Update Packages...................................................................... 6-5 6.1.5.3 Compressing Client Packages..................................................................................... 6-6 6.1.6 Verification of a Package Build.......................................................................................... 6-6 6.2 Building a Package...................................................................................................................... 6-6 6.2.1 Prerequisites ......................................................................................................................... 6-6 6.2.2 Forms Used to Build a Package ......................................................................................... 6-7 6.2.3 Setting Processing Options for the Package Build Definition Director (P9621) ......... 6-8 6.2.3.1 Processing Tab .............................................................................................................. 6-8 6.2.4 Defining a Package Build.................................................................................................... 6-8 6.2.5 Reviewing Package Build Selections.............................................................................. 6-12 6.2.6 Building a Package ........................................................................................................... 6-13 6.3 Incorporating Features into Packages................................................................................... 6-13 6.3.1 Understanding the Feature Build and Deployment Process...................................... 6-14 6.3.1.1 Feature Definition...................................................................................................... 6-15 6.3.1.2 Feature Selection During Package Assembly ........................................................ 6-15
vi
6.3.1.3 Feature Configuration During Package Build Definition.................................... 6.3.1.4 Package Deployment ................................................................................................ 6.3.1.5 Workstation Installation and Deployment Server Installation ........................... 6.3.1.6 Feature Entries in the Package.inf File ................................................................... 6.3.1.7 Installation of Packages Containing Features ....................................................... 6.3.2 Understanding the Feature Based Deployment Director ........................................... 6.3.2.1 Copying a Feature Definition .................................................................................. 6.3.3 Forms Used to Incorporate Features into Packages..................................................... 6.3.4 Creating a Feature............................................................................................................. 6.3.5 Defining a File Set ............................................................................................................. 6.3.6 Defining a Registry Setting.............................................................................................. 6.3.7 Defining a Shortcut........................................................................................................... 6.3.7.1 Entering a Simple Shortcut Definition.................................................................... 6.3.7.2 Entering Advanced Shortcut Options .................................................................... 6.3.8 Defining Additional Package Build Processes ............................................................. 6.3.9 Defining Additional Install Processes............................................................................ 6.3.10 Defining an Initialization File ......................................................................................... 6.3.11 Defining a New ODBC Data Source .............................................................................. 6.3.12 Importing an Existing ODBC Data Source.................................................................... 6.3.13 Reviewing Feature Components .................................................................................... 6.3.14 Copying Features.............................................................................................................. 6.3.15 Adding a Feature to a Package ....................................................................................... 6.3.16 Configuring Features During the Package Build Definition ...................................... 6.3.17 Configuring Features for an Existing Package Build Definition ............................... 6.4 Viewing Package Build Records and Resubmitting Builds ............................................... 6.4.1 Understanding Package Build History.......................................................................... 6.4.1.1 F96225 Table ............................................................................................................... 6.4.1.2 Logs.............................................................................................................................. 6.4.1.3 Where to Find the Error Logs .................................................................................. 6.4.1.4 Package Statistics Log ............................................................................................... 6.4.1.5 Client Package Build Log ......................................................................................... 6.4.1.6 Server Package Build Log......................................................................................... 6.4.1.7 Business Functions Errors Log ................................................................................ 6.4.1.8 Missing Business Function Source Errors Log ...................................................... 6.4.1.9 Server Logs ................................................................................................................. 6.4.2 Understanding the Build Status ..................................................................................... 6.4.3 Forms Used to View Package Build History and Logs ............................................... 6.4.4 Viewing the Package Build History ............................................................................... 6.4.5 Viewing Log Files ............................................................................................................. 6.4.6 Resubmitting a Package Build ........................................................................................ 6.4.7 Changing the Build Status............................................................................................... 6.4.8 Resetting the Specification Build and Package Build Statuses...................................
6-15 6-15 6-16 6-16 6-16 6-16 6-16 6-17 6-19 6-21 6-22 6-23 6-23 6-24 6-25 6-26 6-27 6-29 6-29 6-30 6-31 6-33 6-34 6-35 6-35 6-36 6-36 6-36 6-37 6-37 6-37 6-37 6-37 6-38 6-38 6-38 6-38 6-39 6-40 6-41 6-42 6-42
7 Deploying Packages
7.1 7.1.1 7.1.2 Understanding Package Deployment ...................................................................................... 7-1 Deploying to Workstations Without JD Edwards EnterpriseOne................................ 7-2 Deploying to Workstations with JD Edwards EnterpriseOne Already Installed ...... 7-2
vii
7.1.3 7.1.4 7.1.5 7.2 7.2.1 7.2.1.1 7.2.1.2 7.2.2 7.2.3 7.2.4 7.2.4.1 7.2.4.2 7.2.4.3 7.2.4.4 7.2.4.5 7.2.4.6 7.2.5 7.2.6 7.2.7 7.3 7.3.1 7.3.1.1 7.3.1.2 7.3.1.3 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.5 7.5.1 7.5.1.1 7.5.1.2 7.5.1.3 7.5.2 7.5.3 7.5.3.1 7.5.4 7.5.5 7.5.6
Deploying to Servers ........................................................................................................... 7-2 Deploying to Tiered Locations........................................................................................... 7-3 Deploying to Workstations from CD................................................................................ 7-3 Defining Deployment Parameters ............................................................................................ 7-3 Understanding Deployment Parameters ......................................................................... 7-4 Locations ........................................................................................................................ 7-4 Deployment Groups..................................................................................................... 7-5 Prerequisites ......................................................................................................................... 7-5 Forms Used to Define Deployment Parameters.............................................................. 7-6 Defining Machines............................................................................................................... 7-6 Workstation ................................................................................................................... 7-7 Deployment Server....................................................................................................... 7-7 Enterprise Server .......................................................................................................... 7-7 Data Server .................................................................................................................... 7-8 HTML Server................................................................................................................. 7-8 Business Services Server .............................................................................................. 7-8 Defining Locations............................................................................................................... 7-8 Defining Package Deployment Groups............................................................................ 7-9 Revising Package Deployment Groups ......................................................................... 7-10 Working with Package Deployment ..................................................................................... 7-11 Understanding the Deployment Director ..................................................................... 7-11 Using the Deployment Director .............................................................................. 7-13 Activating Scheduled Packages............................................................................... 7-14 Installing a Scheduled Package ............................................................................... 7-14 Forms Used to Work with Package Deployment......................................................... 7-15 Scheduling a Package for Deployment.......................................................................... 7-16 Revising Deployment Options........................................................................................ 7-19 Activating the Scheduled Package ................................................................................. 7-20 Installing a Scheduled Package ...................................................................................... 7-21 Deploying a Server Package................................................................................................... 7-22 Understanding Server Package Deployment ............................................................... 7-22 Understanding Deployment to Web Servers................................................................ 7-24 Prerequisites ...................................................................................................................... 7-25 Forms Used to Deploy Server Packages........................................................................ 7-25 Deploying a Server Package............................................................................................ 7-26 Monitoring Package Deployment .................................................................................. 7-26 Using Push Installation ........................................................................................................... 7-27 Understanding Push Installation.................................................................................... 7-28 Push Installation Process .......................................................................................... 7-28 Installing the JD Edwards EnterpriseOne Listener .............................................. 7-29 Installing the Listener Using Silent Installation .................................................... 7-30 Forms Used to Use Push Installation............................................................................. 7-30 Preparing the Enterprise Server for Push Installation ................................................ 7-30 UNIX and IBM i Considerations ............................................................................. 7-31 Preparing Workstations for Push Installation .............................................................. 7-31 Installing the Listener....................................................................................................... 7-31 Installing the Listener Using Silent Installation ........................................................... 7-32
viii
7.5.7 Stopping and Uninstalling the Listener......................................................................... 7.5.8 Scheduling a Package for Push Installation .................................................................. 7.5.9 Scheduling the JD Edwards EnterpriseOne Push Installation Batch Application .. 7.5.10 Running the Package Installation Results Report........................................................ 7.6 Installing Workstations from CD........................................................................................... 7.6.1 Understanding How to Install Workstations from CD............................................... 7.6.2 Prerequisite ........................................................................................................................ 7.6.3 Forms Used to Install Workstations from CD .............................................................. 7.6.4 Defining the CD Writer Location ................................................................................... 7.6.5 Deploying a Package to the CD Writer Location ......................................................... 7.6.6 Creating the Installation CD ...........................................................................................
7-33 7-34 7-34 7-36 7-37 7-37 7-37 7-38 7-38 7-39 7-40
9 Harvesting Published Business Services into the Oracle Enterprise Repository Server
9.1 9.2 9.3 9.3.1 Overview...................................................................................................................................... Prerequisites ................................................................................................................................ Generating Business Service Asset Definition XML Files/Artifacts .................................. Understanding the LocationURL Element in the Asset Definition XML File............. 9-1 9-1 9-2 9-4
ix
Harvesting the Business Service Asset Definition XML Files/Artifacts into the Oracle Enterprise Repository Server .................................................................................................... Configuring Java Doc Location in Oracle Enterprise Repository for the Published Business Services......................................................................................................................... Troubleshooting the Business Services Package Build and Deployment Process for Harvesting Published Business Services Artifacts ................................................................. Turn on Logging for Business Services Package Build .................................................. Business Service Asset Definition XML Files Not Generated ......................................
Glossary Index
xi
xii
Preface
Welcome to the JD Edwards EnterpriseOne Tools Package Management Guide.
Note:
This guide has been updated for JD Edwards EnterpriseOne Tools 9.1 Update 2 and 9.1 Update 3 releases. For details on documentation updates, refer to the JD Edwards EnterpriseOne Tools Net Change Guide.
Audience
This guide is intended for system administrators and technical consultants who are responsible for assembling, building, and deploying packages.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc. Access to Oracle Support Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Related Documents
You can access related documents from the JD Edwards EnterpriseOne Release Documentation Overview pages on My Oracle Support. Access the main documentation overview page by searching for the document ID, which is 876932.1, or by using this link: https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=876932.1 To navigate to this page from the My Oracle Support home page, click the Knowledge tab, and then click the Tools and Training menu, JD Edwards EnterpriseOne, Welcome Center, Release Information Overview.
xiii
This guide contains references to server configuration settings that JD Edwards EnterpriseOne stores in configuration files (such as jde.ini, jas.ini, jdbj.ini, jdelog.properties, and so on). Beginning with the JD Edwards EnterpriseOne Tools Release 8.97, it is highly recommended that you only access and manage these settings for the supported server types using the Server Manager program. See the Server Manager Guide.
Conventions
The following text conventions are used in this document:
Convention Bold Italics Monospace Meaning Indicates field values. Indicates emphasis and JD Edwards EnterpriseOne or other book-length publication titles. Indicates a JD Edwards EnterpriseOne program, other code example, or URL.
xiv
1
Introduction to JD Edwards EnterpriseOne Package Management
1
JD Edwards EnterpriseOne Package Management Overview JD Edwards EnterpriseOne Package Management Implementation
1-1
2
Understanding Package Management
2
Section 2.1, "Customer and Consultant Roles" Section 2.2, "Packages" Section 2.3, "Types of Packages" Section 2.4, "Object Change Tracking" Section 2.5, "The Integrity of the Production Environment" Section 2.6, "Deployment Methods" Section 2.7, "Package Implementation"
CNC consultant. Custom solution consultant. Application consultant. Hardware, network, and third-party software consultant.
CNC administrator. Application developer. Application project leader. Hardware, network, and third-party software administrator.
After the implementation, the consultants typically have fewer responsibilities. Therefore, customers must receive adequate training for the roles that they fill.
2-1
Packages
2.2 Packages
The purpose of a package is to group software modifications so that they can be deployed to workstations, web servers, and enterprise servers. A package defines and contains the components to deploy. A package can contain everything that is needed to run the software (as in an initial installation for a new workstation), or only updates or changes to existing applications.
You want to set up a workstation for a new user or role. You need to deploy custom solutions to all users or only to selected users. You have created a new path code for development purposes, and you need to deploy it. You need to rapidly deploy a software fix to a selected group of affected users.
Types of Packages
Disk space is getting low on some of the workstations, and you need to create a minimum configuration. You need to update the servers with custom modifications that you have developed using the toolset.
JD Edwards EnterpriseOne provides solutions to meet all of these needs. First, the system enables you to create a package that defines and contains the location of the components that need to be distributed to the workstations. To deploy these components, you must define and build a package.
The server package does not include client-specific business functions. During the package build process, you can select to build only the runtime system code on a server package. The administrator cannot select a different system code.
2-3
Types of Packages
During the package build process, you can specify the database data source in which to build the spec repository. This repository can be shared by several enterprise and web servers. The specs are built in a platform-independent XML format. The spec repository is portable across dissimilar servers.
The jde.ini file on the client includes a setting called UpdateParentPackage that determines whether the parent is updated. If this setting is not present or set to Y, the parent package is updated by the update package. If this setting is N, the parent is not updated.
Note:
Specs are always in XML format. However, they are stored in a TAM file for update packages and in an RDBMS for a full package. Hence, full package specs are in XML/RDBMS format and update package specs are in XML/TAM format.
Business function objects in the update package are linked to the corresponding objects in the parent package, and new DLLs are created. Similarly, specs from the update package are merged into the specs in the parent package.
The parent package concept applies to both workstations and servers. Parent packages for workstations reside on the deployment server, while server parent packages are kept in the build area for the enterprise server.
Update server packages include only the objects that were described previously for full server packages. When you are building an update server package, enterprise servers are automatically selected based on the parent package. Update packages can be deployed only to the enterprise and web servers that have the parent package deployed. Update packages must be parented to live full packages for them to be deployed. Specs are built only on the deployment server. They are merged directly into the spec repository at deployment time only.
One manager to oversee coordination within the department. One supervisor to coordinate the package builds, coordinate object transfers, and troubleshoot problems. Two server specialists to build server packages. Four technical specialists to build workstation packages, perform object transfers, and run automated testing before releasing the package to Quality Assurance. One night operator to build workstation packages, build server packages, and clear build errors.
2-5
The path code that you use for routine development. After successfully testing the objects that you develop, transfer them to the PY900 path code using the Object Transfer application, and distribute them to the users using the package build and deployment process.
PY900
A path code that contains a practice set of objects that you test during the conference room pilot before you transfer objects to production. Use this path code to deploy quick corrections or make minor modifications to objects that you will transfer to production. You also can use this path code to test modifications that were made in the development path code before you transfer the objects to the production path code.
PD900
The production path code from which just-in-time installations and production server objects are deployed. After you test software changes in PY900, transfer them to PD900, and then deploy the changes to the enterprise servers and workstations.
PS900
The set of pristine objects that is included with the software. You should not make changes to this path code other than to apply documented Oracle changes. Use this path code to compare standard software to any custom software that you have implemented in other path codes. You should keep a copy of this path code so that you have an unchanged copy of JD Edwards EnterpriseOne in case you need to undo any of the changes. All path codes share the same Object Librarian tables, the same system data source, and usually, the same data dictionary. The only tables that are distinct for each path code are the central objects and specifications tables (tables that begin with F987), the F983051 table, the F98306 table, and the F98950 table.
Update packages might be named with the path code followed by "UA" or "UB" as shown:
Update Package Name PD900UA PD900UB PD900UA PD900UB Description Production Update Package 1 Production Update Package 2 Production Update Package 3 Production Update Package 4
A deployed server package cannot be revised, rebuilt, or deleted. It must be replaced with another package first. For this reason, you must have at least two server packages available so that you can alternate between them.
See Also:
"Understanding Security Workbench" in the JD Edwards EnterpriseOne Tools Security Administration Guide.
Note:
When a user is set up for just-in-time installation (JITI), the system automatically deploys the object to the user's workstation the first time that the user attempts to access the object.
Note:
JITI affects users who received an update package containing an application without specs.
When you build an update package that includes a business function build for that package, the system builds the business function and then globally links it with all other business functions in the parent package.
To ensure that the modifications that you transfer to the production path code are not immediately available to end users, avoid using update packages that contain applications with no specs. Also, do not transfer business functions into the production path code until you are ready to deploy because, during a package build, a global build of business functions automatically includes the new functions. When you transfer changes into the production path code, they will not be available to users until you build a full or update package.
2-7
Build the package. Test the modifications. Deploy server objects to the CRP path code on the enterprise server, and then test the objects. Schedule the package. Transfer the objects to PD900.
Build the package. Schedule the package. Deploy the server objects to the PD900 path code on the enterprise server, and then test the objects.
Check out the objects from the DV900 path code, modify them, test them, and check them back in. Use an incident-tracking system or any numbering system to track changes. Always use an incident number when you check in the objects.
3. 4. 5.
If the objects need to reside on the logic server, transfer them to the DV900 path code on that server. Test the objects by comparing them to the objects on the server. Use an incident number with Object Transfer to transfer the objects to the PY900 path code. Use the checkout log to confirm the transfer (optional). The objects are not in production, but they are now available for you to build a test package in the PY900 path code.
6. 7.
Build a full or update package. Test the newly built, unreleased package in the PY900 path code. You test the package only by comparing it to workstation processes, not to server processes. Although the name of this package will probably be PY900U1 (update package number 1 for the CRP path code), it is a test package because you have not released it to the users.
Deployment Methods
8. 9.
Schedule the update package to deploy to a test machine and test it in an environment that contains CRP objects with CRP data. Deploy server objects to the PY900 path code on the enterprise server and test them. If you prefer, you can build the server package and schedule the deployment at the same time that you build and schedule the workstation package. Building these packages simultaneously can save you time, although this method puts a greater load on the server.
10. Schedule the new package to deploy to CRP users. 11. Use an incident number with Object Transfer to transfer the object to the PD900
path code. Use the checkout log to confirm the transfer (optional). The objects are now in the production environment and are available for you to build a package in the PD900 path code.
Note:
12. Build a full or update package for client workstations. 13. Perform a server package build.
You can transfer the server package now or wait until it has been tested on a workstation.
14. Schedule the new package to deploy to end-user workstations. 15. Deploy the server objects to the PD900 path code on the enterprise server and test
them. If you prefer, you can build the server package and schedule the deployment at the same time that you build and schedule the workstation package.
2-9
Deployment Methods
Package deployment. Multitier deployment. Cumulative and noncumulative update packages. Comparing deployment methods. Deploying various types of modifications. Just-In-Time Installation. Recommendations for sites using full packages with JITI. Disabling just-in-time installation.
Change the package assembly status to Inactive. Go to the Package Revisions form. Add the changed or new objects to the package. Rebuild the package. Redeploy the package.
When you use a noncumulative update strategy, you create and deploy a different package each time you add or change an object. For example, if you deploy one modification a week for 10 weeks, you would have 10 different packages, each containing only the software change for that week.
Deployment Methods
A new user loading a new machine should use the Install Manager to load a full package, plus any update packages that you have instructed users to load since the last package build. Therefore, you need a manual tracking system to track which update packages must be applied after installing a particular package.
All update packages must use the JD Edwards EnterpriseOne Deployment Director application to be scheduled to workstations unless you are using the Push Installation feature. Full packages can also use JD Edwards EnterpriseOne Deployment Director if JD Edwards EnterpriseOne is already loaded on a machine. You can use Oracle's JD Edwards EnterpriseOne Push Installation feature to deploy to a machine that does not have JD Edwards EnterpriseOne installed.
Use Oracle's JD Edwards EnterpriseOne Silent Installation application to submit a workstation installation request through command line arguments. Do not use this application for an initial installation.
Use Oracle's JD Edwards EnterpriseOne Multitier Deployment process to install from more than one deployment location. You should consider this method if you have more than 50 workstations performing software installations per day or if you have users on a WAN.
Use the JD Edwards EnterpriseOne Deployment Director application when you need to push objects in a server package to enterprise servers.
Modification Applications
Full Package
Imbedded event rules X Vocabulary overrides (FDA text) Data structure Processing options (report) Business Functions X X X
X X X X
Deployment Methods
Modification
Full Package
Update Package with Specs, Business Functions, and Named Event Rules (NERs) X
C Language X source/include/object (if a compiler exists) Consolidated business X function DLLs Data structure Table event rules Named event rules Batch Applications Report X X X X
X X X X
X X
X X X X X X
Imbedded event rules X in a report Report data structure Report vocabulary overrides Report processing options Versions and processing option values (depends on processing options) X X X X
Imbedded event rules X in versions Processing option templates Business Views Added or changed fields Tables Structure (specifications) Indexes Joins Generic text data structure Data dictionary items Foundation code X (required for full packages, optional for update packages) Foreign languages X X X X X X X
X X
X X X X
Deployment Methods
Modification
Full Package
Update Package with Specs, Business Functions, and Named Event Rules (NERs) X
Non-Oracle objects X (custom items must be defined in the JD Edwards EnterpriseOne Central Objects database, and can be deployed through any package type) Replicated local data X (required for full packages, optional for update packages) New icons X
Applications. Imbedded ER. Vocabulary overrides (FDA text). Data structure. Processing options (report). Batch applications. Report. Imbedded ER in a report. Report data structure. Report vocabulary overrides. Report processing options. Versions and processing option values (depends on processing options). Imbedded ER in versions. Business Views. Added or changed fields. Miscellaneous. Foundation code (required for full packages, optional for update packages). Foreign languages. Non-Oracle objects (custom items can be deployed through any package type). Replicated local data (required for full packages, optional for update packages).
Deployment Methods
from the menu. Loading happens only once; the next time that you select the same application, it is still loaded on the workstation. JITI applies only to applications. Business functions cannot be installed through JITI. JITI works when the workstation receives an update package that does not contain specs. Update packages that contain specs do not require the JITI process. When you receive an update package that contains a changed application without the new specs, the system first determines whether specs for the application reside on the workstation. If so, it deletes from the workstation old versions of that application. Then, the next time that you select that application from the menu, the system loads the new version of that application. JITI can be used in remote locations that are using multitier deployment to install packages. However, you might find that performance time for the JITI is unacceptable. In this case, you can initially install full packages and use update packages to deploy software changes. When a package includes applications without specifications, at the time of execution only these related objects are deployed:
Interactive or batch application specifications. Embedded event rules for the application. Processing option templates, data structures, and related business views.
The listed objects are not deployed and, therefore, must be included in the package if they have been modified:
Business functions and their data structures. Generic text data structures. Table event rules, which are included with tables. Named event rules. New icons.
Use Oracle's JD Edwards EnterpriseOne Work with Environments application (P0094) to disable JITI for the environment.
Package Implementation
When JITI is disabled, users who sign on to that environment can access only those applications for which they have specifications. You should use this method during the cumulative installation process when you update the production central objects with new changes.
Use application security to disable JITI for a particular application, for an end user, or for a role profile. When a user accesses an application for which the specifications do not reside on the user's workstation, the system first reviews P0094 to determine whether JITI is disabled for the entire environment. If JITI is on for the environment, the system determines whether application security prevents the user from using JITI. Application security has a field called not allowed to install.
Although you can disable JITI for an environment, the system still uses JITI to copy data dictionary items to the global tables and data dictionary tables. The structure of the data dictionary prevents you from disabling JITI for it.
Assemble the package. During this step, you specify the type of package that you are building and provide a name, path code, and package description. Next, you assemble the package by specifying the objects, data, foundation, features, and so on that you want to include in the package. If you are building an update package, you can specify individual objects to include. To simplify the process of assembling a package, Oracle's JD Edwards EnterpriseOne Package Assembly application (P9601) includes the Package Assembly Director, which displays a series of forms that guide you through the steps of naming the package and adding the objects that you want to include in the package.
2.
Define the package build. After you assemble the package, you must define the build before you can deploy the package to the workstations and servers. In this step, you specify: Build options. Build specification options. Business functions build options. Compression options. Build features options. You also need to specify whether the package is for a workstation, a server, or both. If the package is for servers, you must specify the servers for which the package should be built and select the spec database data source. To simplify the build process, Oracle's JD Edwards EnterpriseOne Package Build Director application (P9621) includes the Package Build Definition Director, which displays a series of forms that guide you through the steps of specifying where to build the package, whether to include specifications, whether to compress or build business functions, and so on.
3.
Package Implementation
During the actual build process, the system takes the information that you provided when you assembled and defined the package and copies and converts central objects to the package. It also globally builds the business functions that are included in the package and then compresses the package.
4.
Schedule the package for deployment. After you have defined and built the package, it is ready for distribution. Depending on the package type, you can deploy packages through JD Edwards EnterpriseOne Client Workstation Installation application or Deployment Director application. JD Edwards EnterpriseOne Deployment Director enables you to specify the workstations and servers that receive the package, as well as when the package is made available. Packages can be deployed to all computers within the enterprise, a select group of computers, or individual computers. When you schedule the package, you can indicate whether package installation is mandatory or optional.
5.
Deploy the package to deployment, enterprise, and web servers. Use the JD Edwards EnterpriseOne Deployment Director application to move any changed objects to the enterprise server. If you specify a server during the package build definition process, the system automatically creates a corresponding server package in the correct format. If you do not specify a server and define only a workstation package, you should create a corresponding server package. The process is nearly identical to creating a workstation package. Web servers automatically retrieve the package information from their configured business function logic servers. See Understanding Deployment to Web Servers.
3
Understanding Objects
3
3.1 Objects
This section discusses:
Object storage. Object movement. Performing backups and restoring objects. Correlating replicated and central objects.
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
Understanding Objects
3-1
Objects
to access the JD Edwards EnterpriseOne applications in HTML. The system stores the objects in a relational database and retrieves them at runtime.
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:
Object Type Table (object type TBLE) Movement These objects move:
Table specs Table event rule specifications (If the tables have event rules) Source files (*.c) Table header files (*.h) Object files (*.obj) (If the objects have event rules) Table event rule include files (*.hxx) (If the tables have event rules)
The table header is not the same as the actual table that resides in a database. The table itself is created through Table Design Aid when you generate it. The JD Edwards EnterpriseOne Workstation Installation program copies this table to the workstation if the table is stored in the Supported Local Database. Business view (object type BSVW) These objects move:
Objects
Specifications Source files (*.c) Header files (*.h) Object files (*.obj)
Business function event rules (object type BSFN) can be checked out. When business function event rules are checked out, the .h file moves to the include directory, the .c file moves to the source directory, the .obj moves to the obj directory, and the local specifications are updated. These objects move:
Business function data structure (object type DSTR) Embedded event rules
Specifications move. You cannot check out embedded event rules. Embedded event rules move when you check out the object in which the event rule is embedded. For example, if embedded event rules are attached to a table, interactive application, or batch application, when you move the table or application, the specifications for the embedded event rules move with it. Data structure specifications move. These specifications move:
Media object data structure (object type GT) Interactive application (object type APPL)
Report and event rule specifications (check in and check out the version separately from the report) .h file (if generated by the developer)
Understanding Objects
3-3
Objects
Object Type Business Services (object type BSFN, source language Java) These objects are type BSFN except for:
Movement These objects can be checked out and checked back in. The IDE for development of business services objects is JDeveloper. When they are checked out, the <F9860.SIOBNM>.zip file is copied from the path code check-in location on the deployment server (<path code>/java/sbfjars) to the <EnterpriseOne client install>/<path code>/java/source/<F9860.SIOBNM> folder on the Microsoft WIN32 client, and the contents are extracted. When they are checked in, the contents of the <EnterpriseOne client install>/<path code>/java/source/<F9860.SIOBNM> folder are compressed to a <F9860.SIOBNM>.zip file and the file is copied to the path code check-in location.
See Also:
" JD Edwards EnterpriseOne OMW Overview" in the JD Edwards EnterpriseOne Tools Object Management Workbench Guide
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.
Objects
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.
See Also:
"Backing Up JD Edwards EnterpriseOne Tables Servers" in the JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide.
Understanding Objects
3-5
Modification Rules
Central Object The F98752 table contains one record for each application. If the application has processing options, that information is also stored in the record. The F98753 table contains one record for each form (and also includes references to the data structures). The F98760 table contains override text for batch reports. The F98761 table contains one record for each section, column, sort, constant, and so on, in Batch Reports and Versions. The F98762 table contains one record for each function in BSFN. The F98770 table contains only one record for each package. This table is empty in Central Objects. Code Generator Form Types are stored in specification format only. One record exists for each data dictionary item that has been just-in-time installed. This is data dictionary text.
F98753<package name>
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. This is field information required by the data structure. F9200 F9202 F9203 F9207 F9210 The F98701 table contains a local record of next IDs that are assigned to each workstation.
Modification Rules
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.
Interactive applications Reports Application text changes Table specifications Control tables
Understanding Objects 3-7
Modification Rules
Business views Event rules Data structures Business functions Versions Business services
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 5559. 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.
Modification Rules
Preserved X
Replaced Comments You can either create a new application, or copy an existing application using the Copy feature in Application Design Aid. This feature enables you to copy all of the application specifications, including event rules. If you use the Copy feature to copy an existing application for some modifications, during an upgrade your new application does not receive any changes that the system might have made to the original application.
New hyper items added to existing forms. New controls added to existing forms. New grid columns added to existing forms. Style changes.
Style changes include fonts and colors. New controls have the standard base definitions. If you adjust the style, you need to also adjust the styles for any new controls that you added to an application.
X X X In a subsequent release of the software, a new control might be placed in the same location that you have placed a custom control. In this case, the new control appears on top of your custom control. This situation does not affect the event rules or the functions of the application. After the upgrade, you can use Application Design Aid to rearrange the controls. The upgrade process adds new controls to the end of your custom tab sequence. You can review the tab sequence after an upgrade. Instead of adding custom forms to existing applications, create a custom application using system codes 55 through 59, and then place the custom form on that custom application. You can then add to existing applications Form exits and Row exits that call your custom forms within your custom applications. System performance is not adversely affected when you call an external application from a row exit instead of from a form within the application.
Understanding Objects
3-9
Modification Rules
Note: 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.
3.2.2.3 Reports
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 New reports. Preserved X Replaced Comments 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. New alphabetical variables added to existing reports. New numeric variables added to existing reports. New data variables added to existing reports. New runtime variables added to existing reports. X
Modification Rules
Object New database variables added to existing reports. New data dictionary variables added to existing reports. Style changes.
Preserved X
Replaced
Comments
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. 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.
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.
Modification Rules
This table describes the table specification elements that are preserved or replaced during an upgrade:
Object New Tables. Custom indexes to tables. Columns added to or removed from existing tables. Preserved X X 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. Replaced Comments
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.
UDCs.
Modification Rules
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 New custom business views. New columns, joins, or indexes that are added to existing business views. Columns that are removed from business views. Preserved X X X Replaced Comments
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:
Modification Rules
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.
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.
Modification Rules
Preserved
Replaced X
3.2.2.11 Versions
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 Non-Oracle versions. Version specifications. Processing option data. All ZJDE and XJDE version specifications. All processing option data for XJDE versions. Preserved X X X X X Replaced
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.
New custom business service X New object within an existing n/a JD Edwards EnterpriseOne business service Changed object within an existing JD Edwards EnterpriseOne business service Business services selected as web services n/a
n/a
Within P9603, you select which business services will be exposed as web services. This selection is preserved.
Modification Rules
4
Assembling Packages
4
Section 4.1, "Understanding the Package Assembly Process" Section 4.2, "Verifying a Path Code for Package Assembly" Section 4.3, "Assembling a Package Using Director Mode" Section 4.4, "Assembling a Package Using Express Mode" Section 4.5, "Revising an Existing Package" Section 4.6, "Activating an Assembled Package"
When you finish adding the selected components to a package, those components appear on the specific form for that component, the Package Component Revision form, and the Work with Packages form of the Package Assembly Director. This table summarizes the function of each form in the Package Assembly Director:
Form Function
Package Assembly Directory form Use this form to review introductory information about the Package Assembly Director. Package Information form Package Type Selection form Use this form to enter the package name, description, and corresponding path code. Use this form to indicate whether you are creating a full or update package. When you create an update package, you must also indicate the parent package on which the update package is based. For example, if you were creating a package to update your original package called APPL_B, you would enter APPL_B as the parent package for your update package. Foundation Component form Use this form to enter the location of the foundation. A foundation is the code that is required to run all applications. It is required for all full packages. If you do not specify a foundation path for full packages, the system uses the default foundation path. Update packages use the foundation for the parent package unless you specify another foundation. Use this form to specify the location of the database to be included in the package. For full packages, if you do not specify a database location, the system uses the default database path. Update packages do not require a database. Use this form to verify the deployment data source. When you build a full package, the system retrieves the objects that are included in the package from the deployment data source that is associated with the path code that you specified for the package. Use this form to specify the individual objects that you want to include in the package. You can add any of these objects:
Interactive or batch applications Business functions Business views Data structures Media object data structures Table definitions
Use this form to include features in your package. A feature is a set of files or configuration options, such as registry settings, that must be copied to a workstation or server to support an application or another feature. Use this form to include in your package language specifications for a language other than English. Use this form to review the information that you entered on the previous forms. You can modify any or all of your selections on this form.
Foundation The default foundation location is the server share path under the path code for the package.
Database The default database location is the server share path under the path code for the package.
Objects The default location for full packages is the deployment data source.
On forms that have a default value, even if you change or clear the field you can always restore the original default value by clicking the Default button. The Form menu of the Package Component Revisions form also has a Set Default option that restores default values. If you are building a full package and do not need to specify the objects in that package, the fastest way to define the package is to accept the default locations for the foundation, database, and language. This method applies only to full packages. For an update package, if you accept the defaults but do not include any objects, the system creates an empty package. As you view the forms in the Package Assembly Director, you can accept the default selections by clicking Next. If necessary, you can always make changes at the final Package Component Revisions form.
Disk space is adequate. Central objects and package build tables are accessible. User has permissions to create directories on the deployment server and enterprise server.
Assembling Packages 4-3
Required service pack is installed. Required Microsoft Data Access Components (MDAC) are installed. Machine tables are set up. Required compiler version is installed. Enterprise Server port is accessible. Debug levels of the jde.ini files are adequate for the client and enterprise server.
Select a version and click Select. On Version Prompting, click Submit. Complete the Processing Options fields, and click OK. On Printer Selection, select the desired printer, and click OK.
Assembling a package in Express mode, rather than Director mode, is recommended in order to simplify and speed up the assembly process. Director mode can be used if you are unfamiliar with the process and would like to walk through each form consecutively. However, Express mode is the default mode for the Package Assembly application. This default behavior can be changed with a processing option.
Use Director mode to assemble a new package. Add a new foundation location. Add a database location.
On the Work with Packages form, click Add, and then on the Package Assembly Director form, click Next. On the Package Information form, complete the Package Name, Description, and Path Code fields.
Note:
You can build a single foundation package to deploy to all path codes by entering *ALL in the Path Code field. This option enables you to create an update package for service packs that can be installed to any path code. If you enter *ALL in the Path Code field, the application does not enable you to select, build, or deploy any objects (such as specs, business functions, and so on) in the package; you can only deploy a foundation. The package is built to a directory called all_packages, which is located under the release path (for example, e900/all_packages). This package can be deployed to any path code.
Note:
Before you can use this option, you must define the *ALL path code in the Path Code Master application. See "Setting Up Path Codes" in the JD Edwards EnterpriseOne Tools Configurable Network Computing Implementation Guide.
3. 4.
Select the Director option, and click Next. On Package Type Selection, complete these fields, and click Next:
Description Select to create a full package that contains all specifications and foundation code. Select to create an update package with specific items that can be deployed to specific users. If you are building a foundation package to the *ALL path code, the application automatically selects an update package. Indicate the parent package that the update package is based on or related to. This information is used by the system to determine how to build business functions.
Parent Package
5.
On the Foundation Component form, perform one of these actions: For full packages, accept the default location by clicking Next, or click Browse to specify another foundation location.
For an update, click Clear unless the package includes a foundation, and then click Next. See Adding a New Foundation Location.
6.
On the Database Component form, perform one of these actions: For full packages, accept the default location, or click Browse to specify another database location. For an update, click Clear unless the package includes a foundation. See Adding a Database Location.
7.
Complete one of these actions: If you are assembling a full package, click Next. For a full package, the system builds your package from the deployment data source that is associated with the default object path. Verify that the correct location appears on the form, and proceed to the next step. If you are assembling an update package, click Next on the Database Component form, and then proceed to the next step.
8.
On the Object Component form, to add an object, click Browse. The Object Component form only appears when you are assembling an update package. If you are assembling a full package, the Default Object Component form appears and you cannot add objects.
9.
On the Object Component Selection form, locate and select the objects that you want to include in your update package, and then click Close to return to the Object Component form. When you revise a previously assembled package, objects that you added earlier also appear on the Object Component Selection form.
10. On the Object Component form or Default Object Component form, click Next.
The Features Component form appears, on which you can specify the features that you want to include in your package. When you revise a previously assembled package, the system displays the features that you added earlier.
11. To add a feature, click Browse. 12. On the Feature Component Selection form, click Find to display a list of features,
select one or more features, and then click Select to add the features that you want to include in your package. To select multiple features, press the Ctrl or Shift key while clicking features, and then click Select.
13. Click Close to return to the Features Component form.
row header in the detail area, and click Next. If you add a language to your package, only that language will be included. For example, if you add French, English will not be included even though it is the
default language. To include two languages (such as French and English), you must select the detail records for both languages.
17. Continue with the task Reviewing the Package Assembly Selections.
Enter a foundation ID in the Foundation Name field. This is the code that is required to run all applications. A foundation ID is required for all full packages. For full packages, if you do not select a foundation, the default foundation is used. The default foundation is determined through the release that is associated with the path code for the package. This is normally the system directory at the same directory level as your path code. The foundation must be compressed when built.
2.
Enter a service pack number in the Service Pack Number field, if appropriate. A service pack is an update to the foundation code that is delivered between major releases and cumulative releases of the software.
3. 4. 5. 6. 7. 8. 9.
Enter the release number with which this foundation is associated in the Release field. Enter the host machine type in the Platform Type field. Enter the compiler configuration to use for the software build in the Build Type field. Enter the current status of the build process for foundation in the Foundation Build Status field. Enter the date that the software build finished in the Date Built field. Enter the time at which the software build finished in the Time of Build field. Enter the name of the deployment server where your custom foundation resides in the Foundation Machine Key field. field. All files in the last directory that is specified will be included in the package. Source Machine Key and Source are used together to define the item's location.
10. Enter the exact path from which this item should be copied in the Foundation Path
1. 2. 3. 4.
Click Add to add a new database component. Enter the name of the database component in the Database Name field. Enter the name of the machine on the network (server or workstation) in the Source Machine Key field. Enter the shared directory for this path code in the Server Share Path field.
Note:
For full packages, if you do not specify a database location, the system uses the default database path (\pathcode\Packages\Data). Update packages do not require a database.
1.
Find and select the existing features that you want to include in the package, and then click Select. To select multiple features, press the Ctrl or Shift key.
2.
If the feature that you want to include has not been defined, you can create the feature definition by clicking Add. Oracle's JD Edwards EnterpriseOne Feature Based Deployment Director launches. You can use this director to create the new feature. See Incorporating Features into Packages.
3. 4.
Repeat steps 1 and 2 until you have finished adding features to your package. When you are finished, click Close to return to the form from which you accessed the Feature Component Selection form.
1. 2.
Review the current foundation, database locations, objects, features, languages, and business services that exist for your package. To change any of the package components, click the button for the component that you want to change. The form for that package component appears.
3. 4.
When you are finished assembling the package, click End to quit the Package Assembly Director. Continue with the task Activating an Assembled Package.
W9601H
Click the Foundation Add an existing button on the Package foundation location to Component Revisions your package. form. Locate the existing foundation location that you want to use in the package, and click Select. Click Add on the Foundation Component Selection form. Add a new foundation location to the package.
W9883D
W9601N
Click the Database Add an existing button on the Package database location to Component Revisions the package. form. Locate the existing database location that you want to use in the package and click Select. Click Add on the Database Component Selection form. Add a new database location to the package.
W9883K
W9601D
Click the Objects Add an object to the button on the Package package. Component Revisions form. Click Browse. Click the Features Add a feature to the button on the Package package. Component Revisions form. Click Browse.
W9601AB
4.5.2 Prerequisite
Verify that the status of the package is In Definition. If you try to revise a package that has a status of Assembly-Definition Complete, the system displays an error message. To change the status of a package, select Active/Inactive from the Row menu on the Work with Packages form. You cannot revise or delete a package that has already been deployed.
Make any necessary changes to the package components. When you are finished revising the package definition, click OK to return to the Work with Packages form. If any build information exists for the package, the system warns you that the changes will delete the existing build information.
3.
Click one of these buttons: OK Accept the revisions and delete the existing build information. If you accept the revisions, you should update the build information so that it reflects the changes that you made. Cancel Delete the revisions and save the existing build information.
5
Understanding the Package Build Process
5
Section 5.1, "How the System Builds Packages" Section 5.2, "Server Packages" Section 5.3, "Workstation Packages" Section 5.4, "Files Created by the Build Process" Section 5.5, "Features"
How the JD Edwards EnterpriseOne system builds a full client package. How the JD Edwards EnterpriseOne system builds an update client package. How the JD Edwards EnterpriseOne system builds a full server package. How the JD Edwards EnterpriseOne system builds an update server package.
Creates the package build directories. Creates the INF file. Copies these directories and files from the check-in location to the package name directory: res source (.c files) include (.h files) work make bin32 lib32 obj
5-1
If you select to build business functions with the package build, the system does not copy bin32, lib32, and object (.obj) files because Oracle's JD Edwards EnterpriseOne BusBuild program creates them.
4. 5. 6.
Creates an OEE or SSE database with all the central objects tables. Copies all the central objects data into the created database. Runs the JD Edwards EnterpriseOne BusBuild program to compile and link the business functions that create the DLLs in the bin32 directory, the objects in the obj directory, and the libraries in the lib32 directory. Copies the files from the include, source, bin32, lib32, and obj folders of the package to the path code check in location. Compresses the directories.
7. 8.
Creates the package build directories. Creates the INF file. For each object in the Package Build History table (F96225), retrieves the information from the relational database and adds it to the TAM specification files. Copies the associated .c, .h, and .hxx files for the selected objects from the check-in location to the package build area. Runs the JD Edwards EnterpriseOne BusBuild program to update the DLLs in the bin32 directory, the objects in the obj directory, and the libraries in the lib32 directory. Copies the specs and files in the include, source, bin32, lib32, and obj folders of the update to the parent package.
6.
Creates the package build directories. Creates the INF file. Copies these directories and files from the check-in location to the package name directory: res source (.c files) include (.h files)
Server Packages
If you select to build business functions with the package build, the system does not copy bin32, lib32, and object (.obj) files because the JD Edwards EnterpriseOne BusBuild program creates them.
4. 5. 6. 7. 8. 9.
Builds the local spec repository based on the central objects. Generates named event rules (NERs) using the JD Edwards EnterpriseOne BusBuild program. Creates package build directories on the enterprise server. Copies all necessary source and include files from the package location to the enterprise server. Compiles business functions on the server to generate .dll, .so, .sl, or .SRVPGM files. Creates the spec repository in the specified server spec data source.
10. Copies specs from the build machine/deployment server to the spec data source. 11. Compresses the .dll, .so, .sl, and .SRVPGM files. 12. Copies the compressed files from the enterprise server to the deployment server.
A description of server packages. The server package build process. Jde.ini settings for server package builds. Spec.ini settings. Source code for Solaris servers.
5-3
Server Packages
A server package does not include a Supported Local Database. Foundation code is not deployed as part of a server package. All specs are built directly into the specified spec data source. The specs are copied from the database on the build machine to the spec database data source.
Some business functions (such as client only business functions) are not built on the server, and therefore are not included in a server package.
All application development takes place on workstations. Object-related files are stored on a single deployment server, and specs are stored in the central objects database on the database server. The application development life cycle is managed by Oracle's JD Edwards EnterpriseOne Object Management Workbench. This configuration enables you to partition business applications to an enterprise server. To ensure that modifications and enhancements that are developed on the workstation are reflected on the server, you must build a server package that contains those modifications and enhancements. You use Oracle's JD Edwards EnterpriseOne Package Assembly (P9601) and Package Build Director (P9621) applications to assemble, define, build, and deploy server packages. After defining and building a server package, you can deploy it to an enterprise, logic, or application server by using Oracle's JD Edwards EnterpriseOne Deployment Director program (P9631).
Provides complete integration with client workstation packages. Builds a package on multiple servers simultaneously. Builds individual package components simultaneously on the server. Builds a package on one enterprise server and deploys to another server of the same type. Creates history records to enable monitoring and to provide restart capabilities for packages that do not deploy successfully. Creates compressed files and loads them onto the deployment server for easier mastering to a CD, or for deploying to another server of the same type. Supports both full and update packages. Provides the capability to specify a central spec repository for all enterprise and web application (WAS) servers to share.
Because server packages are assembled and defined in the same way as client workstation packages, you can assemble a server package using the JD Edwards
Server Packages
EnterpriseOne Package Assembly program (P9601), and build the server package using the JD Edwards EnterpriseOne Package Build program (P9621), at the same time that you assemble and build client workstation packages. After you assemble the server package and define the package build, these events occur:
1.
The system starts a batch application that copies the central objects from the RDBMS to the spec repository on the build machine. The created repository is then copied to the deployment server. On the build machine, the system starts another batch application for the server package. This batch application calls a business function, which in turn calls the server package build engine. The build engine uses the records that the Package Assembly and Package Build Director programs create to: Transfer all business function source and header files to the server. At this time, the build engine reads the Object Librarian Master table (F9860) to determine the DLL to which each module belongs. For the JDBTRIG library, a special function is called to direct the trigger library to which the module belongs. In this case, the system does not use the Object Librarian Master table. Start a build master process on the server when the source files for all business functions are transferred. This build master starts one or several individual build processes simultaneously. Each DLL has its own build process. The jde.ini file indicates the number of processes that can run simultaneously on a non-IBM i platform. This function is performed by the QBATCH subsystem on an IBM i platform. Move the process to another server if one was specified during the package build process. The process transfers and builds all components on that server. Create the spec repository in the spec database data source and copy the spec files from the build machine to the spec repository. Check the status of each build piece on each server after the build process has begun on all servers. History records are updated as the statuses change. Compress the package components and transfer the compressed files back to the deployment server when the building is complete. This happens only if you specify that the system compress the files when it builds the package. This process is repeated for all servers.
2. 3. 4.
5-5
Server Packages
Value
Purpose
/usr/jdedwards/E900/packa Indicates the location on the ges server where the package will be built. +02 (default for HP-UX) -02 (default for AIX and Solaris) Varies, depending on the platform. The system uses these compile flags to build business functions in Release mode. You should not change these flags. Varies, depending on the platform. The system uses these compile flags to build business functions in Debug mode. You should not change these flags.
Optimization Flags
DebugFlags
-g -D_DEBUG _DJDEDEBUG (default for HP-UX) -g -qfulpath -qdbextra -D_ DEBUG -DJDEDEBUG (default for AIX) -g -D_DEBUG -DJDEDEBUG (default for Solaris)
InliningFlags
blank (default)
Indicates whether the IBM i uses inlining. Enter Yes to select inlining on the IBM i. Enter No to turn it off. This flag is blank or ignored for non-IBM i servers. Indicates the Kernel Production Version of the source for HP-UX, AIX, and Solaris.
DefineFlags
-DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT -D_HPUX-SOURCE (default for HP-UX) -DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT (default for AIX) -DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT -D_SUN-SOURCE (default for Solaris)
CompilerFlags
-Aa +w1 +z -c (default for HP-UX) -qalign=natural -qflag=I:I -c (default for AIX) -qspill=1024 -misalign -KPIC (default for Solaris)
Varies, depending on the platform. The spill flag sets the stack space when business functions are compiled. Typically, 1024 is adequate space to compile the delivered business functions. Indicates the release level for which you are compiling the package. You should not change these flags.
OSReleaseLevel
Server Packages
Setting LinkFlags
Purpose
Varies, depending on the platform. The system uses -bl:/<your system these flags to link business directory>/bin32/functlist.im functions. You should not p -bM:SRE -bexpall -brtl -lc change these flags. -bnentry -L. L/usr/<your system directory>/lib -ljdelib -ljdekrnl -ljdenet -bloadmap:loadmap (default for AIX) -G -L$(ORACLE_HOME)/lib (default for Solaris) shared -z muldefs -melf_i386 -L/JDEdwards/e900/system/ lib -ljdesaw (Linix-64 bit)
LinkLibraries
blank (default)
Indicates the libraries to which business functions are linked. (Applies to Windows and IBM i servers only.) Indicates the number of DLLs that can be built at a time. Zero means that all will be built simultaneously. Applies to IBM i only. Specify a queue name if you want the jobs for building dlls to go to a queue other than the default queue. Indicates the compiler level to use for builds. For more information on the supported versions of Visual Studio, see the Visual Studio Requirements for Microsoft Windows-based Enterprise Servers section in the JD Edwards EnterpriseOne Server Manager Guide. Indicates the number of minutes to wait for an update or full package to deploy.
SimultaneousBuilds
Qname
queue name
<compiler values>
Any compilers installed on the system will be retrieved from the registry and shown in a pull-down list. (Microsoft Windows platform)
DeployWaitInMinutes
5-7
Workstation Packages
Workstation installation. Building specifications and business functions. Defining the compiler level. Verifying UNICODE settings. Package INF files.
A Y means that business functions are built after all the specs are complete. The system builds the specifications and business functions sequentially instead of simultaneously.
Workstation Packages
An N means that specs and business functions are built simultaneously, which can speed up the build process.
Use the first setting if you are using the Microsoft Visual C++ 2010 compiler and the second setting if you are using the Microsoft Visual C++ 2008 compiler. If more than one supported compilers have been installed on the computer that you use to build packages and the VisualStudioVersion is not defined in the jde.ini, the highest level compiler will be used to perform the build. For more information on how to update this setting using Server Manager, as well as the supported versions of Visual Studio, please see the Visual Studio Requirements for Microsoft Windows-based Enterprise Servers
In this setting, code_page_value is a valid value for the code page of the language-enabled application that contains NERs. For example, for Korean language the value would be:
Unicode Conversion Codepage=ksc-5601
Note:
If you are a language customer but have never added NERs to your applications, then you are not required to have this setting. Also note that LocalCodeSet=<value> is no longer used in releases subsequent to Xe.
5-9
Workstation Packages
Here is a typical INF file for package DV900FA, which is full package A for the DV900 path code. This INF file includes these sections:
[SrcDirs] [DestDirs] [FileSets] [FileSetsDescription] [Components] [Typical] [Compact] [Attributes] [Oracle Databases] [Start] [Desktop] [Environment] [Fonts] [Feature] [Language]
5.3.5.1 [SrcDirs]
The JD Edwards EnterpriseOne Workstation Installation program uses these settings to determine the source path from which information is copied. JD Edwards EnterpriseOne Package Build compresses these directories. JD Edwards EnterpriseOne Workstation Installation copies the compressed directories to workstations.
Item Purpose
SPathcode=\\MachineName\E900\PACKAG Indicates the location of the package that the E\ DV900FA package builds for workstation installation. The default value for this path is the path code directory over which you built the package. You can change this setting if you want to use a different package. SSYS=\\MachineName\E900\SYSTEM Indicates the location of the system directory that the package builds for workstation installation. The default value for this path is the system directory that is associated with the path code over which you built the package. Normally, this directory is subordinate to the release share name (E900). This item appears only when included in the package. Indicates the location of the Supported Local Database that the package builds for workstation installation. The default value for this path is the data directory that is subordinate to the path code over which you built the package. This item appears only when included in the package.
SPathcodeDATA=\\MachineName\E900\ DV900\PACKAGE\DATA
Workstation Packages
5.3.5.2 [DestDirs]
The JD Edwards EnterpriseOne Workstation Installation program uses these settings to determine the destination paths on the workstation. The process replaces %INSTALL with the user's computer configuration, which is set up in the User Display Preferences table (F00921) and the User Defined Codes Language Status table (F00051).
Item DPathcode=%INSTALL\path code DSYS=%INSTALL\system Purpose Indicates the destination directory for the package. Indicates the destination directory for system files. This item appears only when included in the package. Indicates the destination directory for the database. This item appears only when included in the package.
DPathcodeDATA=%INSTALL\path code\data
5.3.5.3 [Filesets]
These settings list the various source and destination directories that are subordinate to the path code for the package. Y equals compressed, and N equals not compressed. The source and destination directory names are preceded by an S and D, respectively.
Item Pathcode1=Y, $Spathcode\bin32, $Dpathcode\bin32 Pathcode2=Y, $Spathcode\spec, $Dpathcode\spec Pathcode3=Y, $Spathcode\include, $Dpathcode\include Pathcode4=Y, $Spathcode\lib32, $Dpathcode\lib32 Pathcode5=Y, $Spathcode\obj, $Dpathcode\obj Pathcode6=Y, $Spathcode\source, $Dpathcode\source Pathcode7=Y, $Spathcode\work, $Dpathcode\work Pathcode8=Y, $Spathcode\make, $Dpathcode\make Pathcode9=Y, $Spathcode\res, $Dpathcode\res Pathcode10=Y,$Spathcode\sbf.cab, $Dpathcode\java SYS=Y,$SSYS\System.cab, $DSYS PathcodeDATA=Y, $SpathcodeDATA\data.CAB, $DpathcodeDATA Purpose Indicates the bin32 directory that is subordinate to the path code. Indicates the spec directory that is subordinate to the path code. Indicates the include directory that is subordinate to the path code. Indicates the lib directory that is subordinate to the path code. Indicates the obj directory that is subordinate to the path code. Indicates the source directory that is subordinate to the path code. Indicates the work directory that is subordinate to the path code. Indicates the make directory that is subordinate to the path code. Indicates the res directory that is subordinate to the path code. Indicates the java directory that is subordinate to the path code. Indicates the compressed system database that the package build generates. Indicates the compressed data database that the package build generates.
Workstation Packages
5.3.5.4 [FileSetsDescription]
This section provides a text description for each fileset as shown in this example:
[FileSetsDescription] DV9001=Business Function DLL Files DV9002=Specification Files DV9003=Include Files DV9004=Library Files DV9005=Object Files DV9006=Source Files DV9007=Work Files DV9008=Make Files DV9009=Resource Files DV90010=SBF Source Files SYS=Foundation Files DV900DATA=Data Files
5.3.5.5 [Components]
These settings indicate the location of the foundation, production, and development objects, as well as the database files.
Item Production Objects=APPL_PKG1, APPL_ PKG2, APPL_PKG3 Development Objects=APPL_PKG4, APPL_ PKG5, APPL_PKG6, APPL_PKG7, APPL_ PKG8, APPL_PKG9 Foundation=SYS Data=pathcode DATA Purpose Indicates the location of production objects. Indicates the location of development objects.
5.3.5.6 [Typical]
This section describes the setting for a typical development user.
Item Name=Development Description=Install the development objects Components=ProdObj, DevObj, Foundation, Data Purpose Indicates that the package is for a development user. Indicates the package description. Indicates that the package should contain both production and development objects, as well as the database and foundation.
5.3.5.7 [Compact]
This section describes settings for a typical production user.
Item Name=Production Description=Install the production objects only Purpose Indicates that the package is for a production user. Indicates the package description.
Workstation Packages
Item
Purpose
Components=Production Objects, Foundation, Indicates that the package should contain only Data production objects, as well as the database and foundation.
5.3.5.8 [Attributes]
This section contains information about the current release, global tables, specification and help files, and the jde.ini file.
Item PackageName=DV900FA PathCode=DV900 Built=Build Completed Successfully Purpose Indicates the name of the package. Indicates the path code for which the package is being built. Indicates the package status. A status of 50 or 70 means that the package is ready for installation. Indicates the package type: full or update. Indicates the format for the specifications. Indicates the current release, which determines the setup.inf file to use in building the jde.ini for the workstation. The release is also used to determine paths for system and helps. Indicates the current base release. Indicates the type of build: DEBUG or RELEASE. This option is retrieved from owver.dll. Indicates the version of the MFC compiler. Indicates that specification files are available to merge or copy. This option is always set to Y for full packages. For update packages, this option is set to Y only if objects are included in the package. Indicates whether to delete global tables when installing. This option is set to Y for full packages. For update packages, this option is set to Y only if the objects include a table object. Indicates whether to delete the existing jde.ini file when installing, and then create a new one. This option is set to Y for full packages. For update packages, the user must specify during package build definition whether to replace the jde.ini file. Indicates the date and time when the package was built. Full packages always have this date. This option is blank when no objects are included in the package.
BaseRelease=B9 SystemBuildType=RELEASE
MFCVersion=6 SpecFilesAvailable=Y
DelGlbTbl=Y
ReplaceIni=Y
Workstation Packages
Purpose Indicates the date and time when the foundation was built.The date is retrieved from owver.dll. Full packages always have this date. This option is blank when no foundation location is specified in the package. Indicates the date and time when the database file was built. Full packages always have this date. This option is blank when no database location is specified in the package. Indicates the name of the deployment server. Indicates the location of the deployment server. Indicates the package deployment status. Indicates the package description. Describes the desktop icon. Indicates the default environment. Indicates that a package for *ALL path codes exists when set to Y. Indicates the format of the specifications with these values:
DeploymentServerName=DENMLSAN222 Location=DENVER DeploymentStatus=Approved PackageDescription=Development full package A Icon Description=JDEdwards Default Environment=DV900 AllPathCodes=Y Spec=
XML_RDBMS Use this setting when XML specs are in an RDBMS (full package).
XML_TAM Use this setting when XML specs are in TAM format (update package).
Language
Lists the languages in the package using language codes and separated by commas.
Each of the databases listed, has its own section in the INF file as shown in this example:
[JDELocal_DV900] SourceTableSpace=JDELocal Server=127.0.0.1 UserID=SYSTEM DataFileDestDir=$DDV900DATA\JDELocal_DV900.dbf DumpFileDestDir=$DDV900DATA\JDELocal_DV900.dmp [SPEC_DV900FA] SourceTableSpace=MASTER 5-14 JD Edwards EnterpriseOne Tools Package Management Guide
Workstation Packages
5.3.5.10 [START]
This section contains startup information:
[START] ProgramGroupName=JDEdwards Item1=System\Bin32\activConsole.exe, JDEdwards Solution Explorer, appl_ pgf\res\One World.ico
5.3.5.11 [Desktop]
This section contains desktop information:
[Desktop] Item1=System\Bin32\activConsole.exe, JDEdwards Solution Explorer, appl_pgf, res \OneWorld.ico
5.3.5.12 [Environment]
This section contains environment information:
PathDV900=%INSTALL\DV900\bin32; PathSys=%INSTALL\system\bin32;
5.3.5.13 [Fonts]
This section contains font information:
[Fonts] Arial=Font\arial.ttf
5.3.5.14 [Feature]
This section describes information for any features that are included in the package. A feature is a set of files or configuration options that is included in a package for deployment to a workstation or server. This example provides an example of some features that might be included:
[Feature] WEBDEVELF=\\DENMLSAN246\E900\Package_inf\Feature_inf\WEBDEVELF_1.INF WEBDEVOC4J=\\DENMLSAN246\E900\Package_inf\Feature_inf\WEBDEVOC4J_1.INF WORKFLOWF=\\DENMLSAN246\E900\Package_inf\Feature_inf\WORKFLOWF_1.INF
5.3.5.15 [Language]
This section describes information for all of the languages that were included in the package. This example includes simplified Chinese and German:
[Language] LANGUAGE=CS,G
[Language] LANGUAGE=
Workstation package build Server package build UNIX server build Windows server build IBM i server build
You must use the jdecallobject API to call a business function from a business function. These files are created for NER business functions:
either full or update packages during package assembly. After you have assembled the package, you must select the server option during package definition, and select the relevant servers from the list of available servers in the screen that follows. When package definition is complete and the package has been activated, highlight the package and select Submit Build from the Row menu to start the server package build. When the server package build has finished successfully, you can deploy the server package. To assemble a server package, use the foundation, database, and object information in package assembly to generate build information, specification files, and business function source for .c, .h, and .hxx files. After the server package build has generated these objects and placed them in the staging area, the system transfers the objects to each of the servers that is specified in the package definition. The system then directs the servers to compile the business function source code and generate the corresponding business function DLLs.
NER business functions. Table event rules. C business function event rules.
When you are building business functions, these file types are supplied to the build process:
When building business functions, the build process creates these file types:
Object files (.o) Make files (.mak) Shared libraries (.sl, .so)
Shared libraries for business functions, which are equivalent to a DLL for a Windows workstation, are consolidated. Therefore, one shared library is created for each parent DLL in the Object Librarian - Status Detail table (F9861). If you are creating custom business functions, use a custom parent DLL instead of one of the parent DLLs that JD Edwards EnterpriseOne software provides.
Subordinate to the package directory (PD900FA) is a source directory. This source directory contains subdirectories for each shared library that is created on the enterprise server. The directory structure looks like this example where the top directory represents the package name: PD900FA source CAEC CALLBSFN CCORE CDESIGN CDIST CFIN CHRM CMFG JDBTRIG Each subdirectory contains the business function source files that belong to the shared library. All shared libraries are installed in the PD900/bin32 directory. The naming convention for the shared libraries is lib, followed by the name of the shared library subdirectory, followed by .sl (for HP-UX) or .so (for AIX). An example is libccore.sl.
Business function event rules. Table event rules. C business function event rules.
When you are building business functions, these file types are supplied to the build process:
When building business functions, the build process creates these file types:
Business function DLLs are consolidated, just as they are on the UNIX platform or workstation. Therefore, one shared library is created for each parent DLL in the Object Librarian - Status Detail table (F9861). If you are creating custom business functions, use a custom parent DLL instead of one of the parent DLLs that JD Edwards EnterpriseOne software provides.
*MODULES - Object files. *USRSPC - User spaces hold information about which .c files each business function DLL contains. *SRVPGM - Server programs are the DLLs on the IBM i. *FILE - Contains only logs about compiled business functions.
Features
Directory PD900\include
Description This is the location where .h and .hxx source files are located. These objects are taken from the server and built on. This folder is no longer used but is created for backwards compatibility. This directory contains subdirectories that include the business function DLL names. Each subdirectory contains .c source for the business functions that are compiled and linked into the DLL. This folder is no longer used but is created for backwards compatibility. This directory contains build text, status files and log files (.txt, .sts, .log) for business function DLLs and specification files. The text files contain information that is needed for the server package build. The text files also contain build directives for creating business function DLLs. The status files for specification files indicate whether a server package build was successful in converting pack files into spec files. The status files for business function DLLs indicate which .c source files were successfully compiled and linked. The log files created exclusively for business function DLLs contain the compiler commands used to build and link business functions. For the Microsoft Windows platform, the beginning of this file identifies the compiler used to perform the build.
PD900\pack PD900\source
PD900\spec PD900\text
Note:
After an upgrade, existing IBM i server path codes must be rebuilt with the server package build to avoid problems building server package updates and manually re-linking business functions using the LINKBSFN program.
5.5 Features
This section discusses:
Features
This is a typical Feature INF file for which the sections contain specifications for each feature component.
5.5.2.1 [Header]
The header section contains general information about the feature and specifies the installation options for the feature.
Item Feature= FeatureType= Description= Required= InitialChoice= Purpose Name of the feature. Type of feature. Text description of the feature. A setting that indicates whether installation of the feature is required. A setting that specifies the default selections for features that the user can install.
The Required and InitialChoice entries are set using the three Feature Installation option settings (Required, Selected, Deselected) on the Feature Information form.
Features
When you select one of these three options, the system writes these values into the Required and InitialChoice entries in the feature INF file.
Feature Installation Option Required Selected Deselected Required Y N N InitialChoice Both Both Custom
5.5.2.2 [Registry]
This section contains information about how the feature affects the Windows registry. The settings for this section are displayed in this order: Registry_no.=Root[value],Key,[prefix]Name,[prefix]Value The following table contains a description of each variable:
Item Root Purpose Describes the root in the registry with these values:
0 means root 1 means current user 2 means local machine location 3 means users
Key Name
Indicates the key for the registry value. The registry value name. Name prefixes are:
+ means that the name is created (if it does not already exist) when the feature is installed means that the name is deleted with all subkeys when the feature is uninstalled * means that the name is created (if it does not already exist) when the feature is installed, and it is removed with all subkeys when the feature is uninstalled
Value
#x means that the value is stored as a hexadecimal value #% means that the value is stored as an expandable string # means that the value is stored as an integer #$ means that the value is stored as a string
5.5.2.3 [INI]
This section contains information about how the feature affects the jde.ini file. The settings for this section are displayed in this order: Ini_no.=FileName,Directory,Section,Key,Value,Action The following table contains a description of each variable:
Item FileName Directory Purpose The name of the destination INI file. The location of the destination INI file.
Features
Purpose The name of the section in the destination file. The name of the key within the section of the destination file. The value to be written to the key of the destination file. The action to take regarding the INI entry:
0 means create the INI entry. 1 means create the INI entry only if it does not already exist. 3 means create the INI entry or append to the existing entry.
5.5.2.4 [FileSets]
This section contains information about additional files that must be installed for the feature to function correctly. The settings for this section are displayed in this order: Fileset_no.=Compression,SourceDirectory,FileName,TargetDirectory The following table contains a description of each variable:
Item Compression Source Directory FileName Target Directory Purpose An option that indicates whether the fileset is compressed. The source location of the fileset. The name of the CAB file for the fileset. The target location into which the fileset will be placed.
5.5.2.5 [Shortcut]
This section contains information about shortcuts that appear on the Windows desktop as part of the feature installation. The settings for this section are displayed in this order: Shortcut_ no.=Directory,Name,Target,Arguments,Description,HotKey,Icon,IconIndex,ShowCm d,WKDir The following table contains a description of each variable:
Item Directory Name Target Arguments Description HotKey Icon IconIndex Purpose The directory where the shortcut is created. The name of the link file for the shortcut. The name of the executable file for the shortcut. Any command line arguments for the shortcut. A description of the shortcut. A hot key that launches the shortcut. The shortcut icon and location. An index of the icon if the icon is inside an image list.
Features
Item ShowCmd
Purpose A command for the application window, with these value options:
0 means show the window normal-sized. 3 means show the window maximized. 7 means show the window minimized; not active.
WkDir
5.5.2.6 [ThirdPartyApps]
This section contains information about third-party products that are installed with the feature. The settings for this section are displayed in this order: ThirdPartyApp_no.=Source Directory,Description,Synchronous/Asynchronous,Execute Before/After,FileName The following table contains a description of each variable:
Item Source Directory Description Synchronous/Asynchronous Purpose Source location of the executable for running the third-party application. Description of the third-party application. An option that indicates whether the third-party application can be installed in parallel (synchronous) or must be installed serially (asynchronous). An option that indicates whether the third-party application installation is run before or after JD Edwards EnterpriseOne is installed. The name of the file that launches the third-party application.
Execute Before/After
FileName
5.5.2.7 [ODBCDataSources]
This section contains information about ODBC data sources that are installed with the feature. ODBC data sources have two sections in the feature.inf. One section contains header information and the other contains the detail information. The feature.inf contains one header section listing all data source components that are included in the feature. For each data source that is listed in the header, a corresponding detail section exists. Only the header section is described in this table. For information about the detail section, see the documentation for the selected ODBC Driver. The settings for this section are displayed in this order: DataSourceName=DataSourceDriver
Item DataSource Name DataSource Driver Purpose The name of the ODBC data source. The driver that is used for the data source.
Features
6
Building Packages
6
Section 6.1, "Understanding the Package Build Process" Section 6.2, "Building a Package" Section 6.3, "Incorporating Features into Packages" Section 6.4, "Viewing Package Build Records and Resubmitting Builds"
Directory structure for packages. Package build tasks. JD Edwards EnterpriseOne Package Build Definition Director. Business function builds during package build. Package compression. Verification of a package build.
include java lib32 make obj res source spec work pkgspec bin32 include java lib32 make obj res source work When you build a package, the directories under the package name are populated. Files for the source and include directories are copied from the path code check in location on the deployment server to the corresponding package folder. Information for all other directories comes from central objects. The bin32, lib32, and obj directories are populated with the output of the business function build process.
Transfer objects. Ensure that all of the objects that you want to include in the build have been transferred to the appropriate path code.
Ensure that the database for the package has the most current replicated data. Build a package. Build a package using the path code to which objects were transferred.
(Optional) Perform a cross-reference build. Perform a cross-reference build to verify that the cross-reference information reflects the changed objects. This process takes up to 15 hours to complete. You can deploy the package before the cross-reference build has finished.
Compression Options
Description Use this form to enter file set and compression information for features that you added to the package. A feature is a set of files or configuration options, such as registry settings, that must be copied to a workstation or server to support an application or other function. Use this form to review or change any of the options that you have specified for the package.
You can access the Package Build Definition Director (Director) from either the Package Assembly menu selection or the Package Build menu selection. The advantage of accessing the Director from the Package Assembly menu selection is that the system automatically enters the package name and other information. If you access the Director from the Work With Package Build Definition form, you must manually specify the name of the package that you want to build. Before you launch the Package Build Definition Director, you can use the Work with Package Build Definition form to review information about any previously designed packages. For example, you can review the properties, build options, business function options, and compression options for the package. As on any other parent/child form, you can click the plus (+) symbol to view more information about the package or click the minus (-) symbol to view less information about the package.
When building business functions, use the path code that you defined in the package. The foundation is either the same as the foundation that is included in the package or, for an update package, it is the foundation for the parent package.
Build output is directed to the bin32, obj, and lib32 directories of the package itself. When building a full package, or when building an update package that includes a business function, always build business functions; otherwise, the consolidated DLLs included in the package will not be current. For update packages, the system builds each business function individually. After it builds an individual business function, the system performs a global link for that object and all other objects that are in the same consolidated DLL. The global link affects all objects in the check-in location for the path code of that package.
This setting compresses packages that you built on the server and deploys them to other servers of the same type, such as all AIX UNIX servers or NT servers. If you plan to deploy a package to an enterprise server, you must build the package on the same type of server, with compression selected. The directories are compressed into file types that are compatible with the type of enterprise server that you are using. For NT servers, the file extension is .cab, for UNIX the file extension is .z, and for IBM i, the file has no extension. When the server builds a compressed package, it stores the compressed files in subdirectories, such as \bin32, that are subordinate to this path on the deployment server: \package\package name\server type\, where package name is the name of the package and server type is the type of server for which the package is compressed. The program also creates .cab files in the package name directory, although these files are not used when you deploy to a client workstation. The compression process creates a new file called compressed.inf in the server type directory. This file includes the information that the system needs to deploy the compressed files. This table shows the type of compressed file that the process creates for each type of server:
NT .cab UNIX .z IBM i SAVF
When you deploy the package to another enterprise server, the system reads the compress.inf file and uses this information to copy the compressed files from the package directory on the deployment server to the enterprise server. Specs are no longer compressed. They are deployed either by being copied directly from the database on the deployment server or by setting the spec.ini file setting.
Building a Package
This option displays a field to compress an update package when defining that package. When you select this option and build the package, the program creates a compressed file in the package name\server type\bin32 directory. Specifications are not compressed. They are copied directly from the deployment server to the specification database data source during package deployment.
Disk space is adequate. Central objects and package build tables are accessible. User has permissions to create directories on the deployment server and enterprise server. Required service pack is installed. Required Microsoft Data Access Components (MDAC) are installed. Machine tables are set up. Required compiler version is installed. Server port is accessible. Debug levels of the jde.ini files are adequate for the client and enterprise server.
Note:
You cannot verify the specification database data source. Only enterprise servers and clients can be verified.
Set processing options for the Package Build Definition Director. Define a package build. Review package build selections. Build a package.
6.2.1 Prerequisites
Before you complete the tasks in this section:
Verify that the User ID that is used to perform the package build has drop table and create table rights.
Building a Package
If you are using a Oracle, SQL, or IBM DB2 for LUW (Linux, UNIX, Windows), and you are running with security server turned on, you must add a security override so that the package build process can create the metadata repository table in central objects. See Adding a Security Override for Package Build.
For customers adopting Microsoft Visual C++: All JD Edwards EnterpriseOne Windows machines receiving application foundation packages built with Microsoft Visual C++ require the corresponding runtime libraries to be installed.
Assemble the package and verify that the status of the assembled package is Assembly-Definition Complete. Verify that Oracle's JD Edwards EnterpriseOne Object Configuration Manager (OCM) mappings are correctly set for the JD Edwards EnterpriseOne Package Build (R9621) and Server Package Build (R9622) programs, which the system generates as part of the package build process. For example, if you want the programs to run locally, ensure that the OCM mappings point to Local for the environment in which the package build is running.
Verify that logging is turned off during the package build. When the jdeproperties.log file is set for logging in the \system\classes folder and a package build is submitted, the build process is slowed down.
See Also:
"Working with Object Configuration Manager" in the JD Edwards EnterpriseOne Tools Configurable Network Computing Implementation Guide.
Building a Package
FormID W9621L
6.2.3 Setting Processing Options for the Package Build Definition Director (P9621)
Processing options enable you to specify the default processing for programs and reports. For programs, you can specify options such as the default values for specific transactions, whether fields appear on a form, and the version of the program that you want to run. For reports, processing options enable you to specify the information that appears on reports. For example, you set a processing option to include the fiscal year or the number of aging days on a report. Do not modify JD Edwards EnterpriseOne demo versions, which are identified by ZJDE or XJDE prefixes. Copy these versions or create new versions to change any values, including the version number, version title, prompting options, security, and processing options.
Enter a value to determine how changes will occur. <Blank> means that changes will only be allowed at the package level and will apply to all servers selected. Enter 1 to enable changes to the build definitions by individual server.
2. Mastering
Mark this processing option with a 1 if this process is for Mastering purposes. If the process is for all users, mark this processing option with <Blank>.
3. Build Verification
Mark this processing option with a 1 if the Build Verification UBE is to be run prior to building all packages. If the build verification fails, the package build UBE will not be run. Leave this processing option <Blank> if you do not want to run Build Verification.
4. Director or Express Mode
Use this processing option to switch between Director and Express modes.
Building a Package
1. 2.
Find and select the defined package that you want to build. If the package definition has a status of In Definition, you must change the status to Assembly-Definition Complete before you build the package. To change the status, select the package and select Activate from the Row menu. On the Package Selection form, in the Express Option pane, select one of these options:
Description Select this option if you want to configure the package build. Director enables you to navigate the package build definition forms. Select this option if you want to accept the default build parameters. Express enables you to accept the default options for the package build and skip the package build definition forms.
3.
Option Director
Express
4. 5.
If you selected the Express option, skip to the Reviewing Package Selections task. If you selected the Director option, continue with the next task. On the Package Build Location form, select one or both of these options:
Description Select to indicate that the package is being built for installation on client workstations.
Option Client
Building a Package
Option Server(s)
Description Select to indicate that the package is being built for installation on one or more servers.
6. 7.
If you are building a package for client workstations only, click Next and proceed to step 10. If you are building a server package, you can specify the Shared Location for the shared spec database and click Next.
Note:
The default shared spec database is always the central objects data source for the package path code.
8.
To select a server on the Server Selection form, and then double-click the row header for the server. A check mark indicates your selection. You can select multiple servers.
Note:
Servers are automatically selected for an update package. They are selected based on the server selection of the parent package.
9.
Click Next. definition and copy and convert objects from the central data source to the replicated format used by workstations.
10. On the Build Specification Options form, select Build Options to take the package
11. Complete these fields and click Next: Field All Specification Tables Individual Specification Tables Description Select this option if you want to build all specification tables into the package. Select this option if you would like to select individual tables to include in the package. All of the tables listed on the Individual Specifications Selection form will be included in the package. Indicate the point at which the system should stop the build. You can continue building on all errors, stop building on specification errors, stop building on business function errors, or avoid compressing when errors exist. For update packages, indicate if you want a new jde.ini file delivered with the package. Leave this unchecked unless the jde.ini file has changed. For example, the jde.ini may change when you perform upgrades or when you re-configure in release master.
Replace jde.ini
12. If you chose to build individual specification tables, the Individual Specification
Building a Package
For a full package or for an update package that includes business functions or tables with table event rules, the Business Function Options form appears.
15. Complete these fields and click Next: Field Build Mode Stop-Build Option Build BSFN Documentation Clear Output Destination First Description Specify the build mode, such as debug or optimize. Specify what action to take if errors occur while building business functions. Specify whether you want to build the documentation for the functions. Indicate if you want the destination directory for the functions to be cleared before the build.
16. On the Compression Options form, select the Compress Package option.
Select this option to compress the applications included in the package, and to specify options for the compression process. If the package that you are building will be deployed to a server, you should select Compress Options only under these circumstances:
You are building the same package for both the workstation and server, and you want to create compressed files for the workstation package. You plan to build the package on one enterprise server and deploy it to another enterprise server.
17. If you are compressing the package, select from these options: Option All Directories Individual Directories Compress Data Description Select to compress all of the directories listed on the Individual Directory Selection form. Select to compress only certain directories which you specify. Indicate whether to compress the data in a package after the package is created. Compress Data compresses the Supported Local Database that is associated with this package. Indicate whether to compress the foundation files in the package after the package is created. Compress Foundation compresses the foundation that is associated with the package.
Compress Foundation
Note:
Verify that the DoCompression setting is set to 1 to enable compression. If this setting is not set to 1, the system does not compress the server package.
This selection compresses the client and server packages. The system compresses the client package to the deployment server. It compresses the server package on the enterprise servers and copies the files to the deployment server.
Building Packages 6-11
Building a Package
If you chose to compress individual directories, the Individual Directory Selection form appears.
20. On the Individual Directory Selection form, indicate that you want to compress a
directory by clicking its option to select it and click Next. You can select multiple options.
21. If the package does not include features, skip to the next task. 22. On the Build Features form, if you want to build a feature.inf file with the
package, select the Build Feature INFs option. When you select this option, the Compress and Build options become available. See Configuring Features During the Package Build Definition.
23. Click Next. 24. Review the package build selections and click End.
1. 2.
Review current build options, business function options, compression options, and feature options that you specified for the package. Click the tab for the type of option that you want to change, and make any changes. Only tabs for options that you selected appear on this form. See Defining a Package Build.
3.
When you are finished reviewing or changing the build options, click End to exit the Package Build Definition Director, or click OK to accept changes to an existing package. On Work With Package Build Definition, activate the package by choosing Active/Inactive from the Row menu. After you enter the build options for a package, you can easily revise any of those options using the Package Build Revision form. You do not need to go through all of the forms in the Package Build Definition Director to revise build options.
4.
Select Active/Inactive from the Row menu to activate the package. Select Submit Build from the Row menu when you are ready to initiate the package build. Select one of these options and click OK. On Screen To Printer The form closes and the system begins building the package. Build time varies, depending on the number and size of the items in the package. A build could take five minutes for a small package, or several hours for a full package that contains all applications. When the build finishes, the report either appears on the screen or prints, depending on the destination that you specified.
4.
Review the report to make sure that all components in the package were built successfully. If the report indicates any errors, review the error logs for more detail. If the package build finishes successfully, you can schedule the package for deployment.
Create a feature. Define a file set. Define a registry setting. Define a shortcut. Define additional package build processes.
Building Packages 6-13
Define additional install processes. Define an initialization file. Define a new open database connectivity (ODBC) data source. Import an existing ODBC data source. Review feature components. Copy features. Add a feature to a package. Configure features during the package build definition. Configure features for an existing package build definition.
Oracle's JD Edwards EnterpriseOne web development clients require a specific feature component to develop web-based objects.
See Development Client Installation and Configuration Guide for Tools Release 9.1.
Note:
Oracle's JD Edwards EnterpriseOne machines that run Microsoft Windows, use business functions built with a Microsoft Visual C++ 2008 or higher level compiler, and do not have the same level Microsoft Visual C++ compiler installed locally, require a specific feature that installs the appropriate Microsoft Visual C++ Compiler runtime libraries.
See "Appendix: Using the Microsoft Visual C++ Compiler" in the JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide You might also want to include any of these features when you build a package:
ActiveX controls. The Application Design Aid tool enables you to include ActiveX controls in applications. If ActiveX controls are delivered with the software, you need a way to copy these controls to the workstation.
Open Data Access (ODA) data sources. ODA requires that additional ODBC data sources be created on any workstation or server that uses ODA.
Sales Force Automation databases. The Sales Force Automation feature requires that you install a separate Supported Local Database on the workstation so that it can be disconnected from the network during offline operation. You must also write a registry setting that indicates that the machine is used offline.
Each of these products and interfaces requires additional components on the workstation and server in order to function. As functionality expands to support additional third-party products and interfaces, these products will each have their own set of supporting files. For software releases prior to JD Edwards EnterpriseOne 8.10, custom programming was required to add feature components to the workstation and server. You can now use familiar tools such as the JD Edwards EnterpriseOne Package Assembly Director and Package Build Definition Director to create a package that contains the feature, and then you can deploy it using the JD Edwards EnterpriseOne Package Deployment Director or multitier deployment. Because feature components are not objects, the process for incorporating feature components into a package is slightly different from the normal package build process. Specifically, you must first define the feature before you can add it to a package.
Create a file set. Define registry settings. Define a Microsoft Windows shortcut. Enter initialization file information. Add ODBC data sources. Specify the feature build sequence. Enter information for third-party products.
Features. Adding Features to a Package. Workstation Packages. JD Edwards EnterpriseOne Application Release 9.0 Installation Guide.
Shortcut Definition
W9326G
From the Feature Information form, select Shortcut and click Next until the Shortcut Definition form appears.
W9326P
From the Shortcut Enter advanced Definition form, select shortcut options. Advanced from the Form menu. From the Feature Information form, select Additional Package Build Processes and click Next until the Additional Package Build Processes form appears. Specify a batch application or executable program to run either before or after the package that contains the feature is installed.
W9326H
FormID W9326K
Navigation From the Feature Information form, select Additional Install Processes and click Next until the Additional Install Processes form appears. From the Feature Information form, select Initialization Files (INI) and click Next until the Initialization File (INI) Definition form appears. From the Feature Information form, select ODBC Data Sources and click Next until the ODBC Data Source Definition form appears. On ODBC Data Source Definition, select Import from the Form menu. From the Feature Information form, click Next and add the each feature component. After you add all the components, the wizard displays the Features Summary form.
Usage Enter information about third-party applications that should be run when the package is installed.
Enter information that should be written to an initialization file (such as jde.ini) as part of the feature installation. The INI file is automatically updated when the package is installed. Enter information for any ODBC data sources that must be added to support the feature.
W9326N
W9326O
Select previously created data sources that reside locally on your machine. Review and modify information that you entered on any of the Feature Based Deployments forms.
Features Summary
W9326L
Feature Copy
W9326M
Copy an existing feature and rename it as a new feature. This function is useful if you want to create a Select Features from feature definition that the Form menu. closely matches an Select the feature from existing feature definition. which to copy the definition, and click Copy.
FormID W9601AB
Navigation Package and Deployment Tools (GH9083), Package Assembly Click Add to create a new package. Enter the forms in the Package Assembly Directory until the Features Component form appears. Click Browse. Package and Deployment Tools (GH9083), Package Assembly Select a package and then select Package Revisions from the Row menu. On Package Component Revisions, click the Features button. To add a feature, click Browse.
Usage Add defined features to a new package. Add defined features to an existing package that is open for revision.
Build Features
W9621B
Package and Deployment Tools (GH9083), Package Build Click Add to launch the Package Build Definition Director. Click Next and complete the screens until you come to the Build Features form. Package and Deployment Tools menu (GH9083), Package Build Find and select the package that contains features. Select Build Revisions from the Row menu. Click the Build Features tab.
Enables you to specify whether the system builds feature INF files for the features in the package. If you defined a fileset component in the feature, you can select to compress it. If any additional package build processes are included in the feature, you must click Build Processes and select them before they will run during package build.
Feature
Select this option if the installation of this feature is mandatory for both Compact/Production and Typical/Development installs. Inclusion of this feature cannot be overridden when the package is installed.
Not Required
Select this option if the installation of this feature is optional. Whether the feature is installed depends on the options that you select (Compact/Production and Typical/Development). Inclusion of the feature can be overridden when the package is installed.
Compact/Production
Select this option if this feature is to be included in a Compact/Production install by default. This option can be overridden when the package is installed if Not Required is also selected.
Typical/Development
Select this option if this feature is to be included in a Typical/Development install by default. This option can be overridden when the package is installed if Not Required is also selected.
File Set
Registry
Select this option if the feature is an additional process to be performed during the package build.
Additional Install Processes
Select this option if the feature is an additional process to be performed during the install process.
Initialization Files (INI)
File Set
Enter the path that identifies the source location of the file set.
Compress
Enter a path to identify the target location of the file set. The source path tells the system where to find the file set to be copied into the package, and the target path indicates the location to which the file set should be copied when the package is installed. Although a feature can have an unlimited number of file sets, each file set can have only one target path.
Note:
You can also use this form to modify or delete any previously defined file sets. Existing file sets appear in the tree structure on the right side of the form. To modify a file set, select the file set on the tree structure and modify any of the fields for the file set. To delete a file set, select the file set and click Delete.
Always select Save Node from the Form menu when you are finished adding file set information.
Registry
Name
Enter the data type in which the value is stored in the registry.
Note:
You can also use this form to modify or delete any previous registry definitions. Existing registry definitions appear in the tree structure on the right side of the form. To modify a registry definition, select the item on the tree structure and modify any of the fields for the registry definition. To delete a registry definition, select the item and click Delete.
Always select Save Node from the Form menu when you are finished entering registry information.
Shortcut
Name
Arguments
Enter the parameters that are entered at the command line for the shortcut.
Description
Enter a key sequence that, when pressed, automatically launches the shortcut.
Icon
Enter the path and name of the icon file, based on a relative target path.
Icon Index
Specify the size of the window after the shortcut is launched. For example, the window might be minimized or maximized.
Work Directory
Enter the identifier of the directory path or the working directory of a shortcut.
Process Name
Enter a number to identify the order in which the process will be run relative to the other processes that run during the package build.
Synchronous Execution
Select this option to indicate whether the package build job waits for the process to finish before it continues.
Batch Application or Executable
Enter the name of the batch application. Only applies if batch application was selected.
UBE Version
Enter the version of the batch application. Only applies if batch application was selected.
Machine Name
Enter the name of the server or workstation on which the batch application will run. Only applies if batch application was selected.
Executable Name
Enter the name of the executable program that the system launches to install the third-party software. Only applies if executable program was selected.
Target Path
Enter the path and file name of a target file. Only applies if executable program was selected.
Parameters
Enter the executable parameters that the setup program uses to install the third-party software. Only applies if executable program was selected.
Note:
You can also use this form to modify or delete any previously defined processes. Existing processes appear in the tree structure on the right side of the form. To modify a process definition, select the item on the tree structure and modify any of the fields for the definition. To delete a process definition, select the item and then select Delete or Delete Node After from the Form menu, depending on whether you want to delete a process that is executed before or after the feature is installed. You can run the process either before or after the feature is built. When you are finished adding process information, select either Save or Save Node After from the Form menu, depending on when you want the process to run.
Third Party
Enter a number to identify the order in which this process will run relative to the other additional install processes.
Synchronous and Execute After Install
Clear the Simultaneous Execution option and select the Execute After Install option. The third-party process waits for the JD Edwards EnterpriseOne client install to finish before running.
Synchronous and Execute Before Install
Clear the Simultaneous Execution option and select the Execute Before Install option. The JD Edwards EnterpriseOne client install will run the third-party process and wait until it finishes before installing the client.
Asynchronous and Execute After Install
Select the Simultaneous Execution option and the Execute After Install option. The JD Edwards EnterpriseOne client install finishes, and then starts the third-party process. Neither process waits for the other to finish before proceeding.
Asynchronous and Execute Before Install
Select the Simultaneous Execution option and the Execute Before Install option. The JD Edwards EnterpriseOne client install begins, and then immediately starts the third-party process and resumes the client install without waiting for the third-party process to finish.
Executable Name
Enter the name of the program that launches the third-party software.
Target Path
Enter the path to the executable file. Do not include the name of the file.
Parameters
Enter the executable parameters that the system passes to the third-party program.
Note:
Select Save from the Form menu when you finish adding third-party product information.
Figure 610
Initialization INI
Enter the option that identifies the action associated with the key in the initialization file.
Note:
You can use this form to modify or delete any previous initialization file definitions. Existing definitions appear in the tree structure on the right side of the form. To modify an initialization file definition, select the item in the tree structure and modify any of the fields for the definition. To delete an initialization file definition, select the item and click Delete.
When you finish adding initialization information, select Save Node from the Form menu.
When you select Save Node from the Form menu, the system activates the Microsoft Windows control panel applet that displays the ODBC Data Source forms where you can enter the data source information.
Figure 612
1.
Press the Ctrl or Shift key to select one or several data sources, and click Select to add the data sources to the feature. The ODBC Data Source Definition form reappears.
2. 3. 4.
When you are finished adding data source information, select Save Node from the Form menu. Click Next. To modify existing data sources, enter the data source name and then select Modify from the Form menu. The ODBC Data Source Revisions form appears. Use this form to make changes to the data source. When you are finished, click OK to return to the ODBC Data Source Definition form.
5.
Figure 613
1. 2. 3. 4.
Select a component in the right pane and click the Revise button to review the information for that component. If needed, change the field values for the selected component and click Save. Repeat the previous steps to modify other components. When you are finished defining the feature, click End.
See Also:
Figure 614
1.
2.
Option Required
Not Required
3.
Select one or both of the options that follow. If you chose Required, both of these options are automatically selected. Compact/Production When selected, this feature is included in a Compact/Production install by default. This option can be overridden when the package is installed if Not Required is also selected. Typical/Development
When selected, this feature is included in a Typical/Development install by default. This option can be overridden when the package is installed if Not Required is also selected.
4. 5.
Click OK. To revise the new feature definition, select the feature and select Revise Feature from the Form menu.
1.
Before a feature is available for inclusion in the package, you must first define the feature.
2.
Use one of these methods to select one or more features to include in the package:
Select a feature and click the Select button. (Press the Ctrl or Shift key to select multiple features.)
3. 4.
When you are finished adding features, click Close to return to the Features Component form. The selected features appear. Click Next and complete the remaining forms to finish assembling the package.
Note:
To delete a feature that was previously included in the package, on the Features Component form select the feature and then click Delete.
1.
If you want to build a feature.inf file with the package, select Build Feature INFs. When you select this option, the Compress and Build fields become available if file sets or additional package build process components are included in the package.
2.
Continue with one or both of these tasks: To compress file sets To build processes
1. 2. 3. 4. 5. 6. 7. 8.
Select Compress, and then select Compress File Sets from the Form menu. On the File Set Selection form, select each feature that you want to include by choosing a file set and clicking Select. When you are finished selecting file sets, click Close. Continue either by performing the next steps, or by clicking Next and completing the remaining forms to finish defining the package build. To build processes, select Build, and then click Select Build Processes. On the Build Processes Selection form, select each process that you want to build by choosing a process and clicking Select. When you are finished selecting processes to build, click Close. From the Form menu, select Build Processes and manually select each process to run during the package build. You must complete this step or none of the processes will run, even though they are included in the feature.
9.
Click Next and complete the remaining forms to finish defining the package build.
Modify or add to any of these existing build feature settings: Build Feature INFs Compress Build
2. 3. 4. 5. 6.
If you select Compress, select Revise File Sets from the Form menu to modify file sets. When you are finished modifying file sets, click Close. If you chose Build, click Revise Processes to modify processes. When you are finished modifying processes, click Close. If you selected Build, from the Form menu, select Build Processes and manually select each process to run during package build. You must complete this step or none of the processes will run, even though they are included in the feature.
7.
View the package build history. View log files. Resubmit a package build. Change the build status.
Package name. Path code. Date and time built. Name of the server for which the package was built. Current build status and status description. Current status of selected specification tables. Number of specifications written. Package records written and read.
The View Logs option on the Form menu enables you to view four logs that contain additional information about the build process. Refer to these logs in the event that the build does not finish successfully and you need to review the errors that occurred during the build. If a build does not finish successfully, you can use the Resubmit Build option to resume the build from the point at which the process stopped. Only the business functions and objects that did not build successfully will be built; the entire package will not be rebuilt. In some cases, if a build is interrupted or otherwise unable to finish, you might need to reset the build status from Build Started to Build Definition Complete. Unlike the Resume Build feature, which continues the build from the point at which it failed, resetting the status enables you to start the build process from the beginning.
6.4.1.2 Logs
After you build the package, you can view logs that list any errors that occurred during the build process. In particular, you can view these logs:
Package build log. Business function errors log. Missing business function source errors log.
Each log contains a header, which includes the package name, date, build machine, and path code.
Package statistics: \PD900FA\work\buildreport.log Client package build log: \PD900FA\clientpkgbuild.log Server package build log: \PD900FA\svrpkgbuild.log Business function errors log: \PD900FA\work\buildlog.txt Missing business function source log: \PD900FA\work\NoSource.txt
View Logs
W9622B
FormID W9621L
W9622C
From Work with Package Build History, find the package for which you want to reset the statuses, expand the package, and select an individual item. Select Reset Status from the Row menu.
Reset the spec status and pack status for a package to the statuses that you specify.
1.
Select CLIENT or the server or the spec data source to display information about the current build status for those computers. You can also expand the tree to view this information: Build specification options Compression options
Building Packages 6-39
Business function options Objects These options and objects are those that you specified when you created the build definition for the package. For example, if you chose to build only selected specifications, you can determine the status for each specification, as well as other pertinent information.
Note:
2.
When you are finished viewing build history information, click Close.
Package Statistics
Select this option to be able to view count and size statistics for the package directories that were built.
Select this option to be able to view errors that may have occurred during a package build. These errors could have occurred while building the specification files or the objects for the package.
Business Function Errors
Select this option to be able to view the results of the business function build for this package. Both errors and warnings display in this report. A summary appears at the end of the report that indicates how many errors and warnings occurred for each dll. Use this information to determine if a rebuild is necessary.
Missing Business Function Source
Select this option to see a list of all source members that were not available when the business function was created. The program attempted to find these members because each had a record in the F9860 table. However, a matching source could not be found in the source directory. To resolve these errors, either delete the Object Librarian record or provide a source member.
Business Services Build Log
Select this option to be able to view the results of the business services build for this package.
Select one of these options to find the package you want to resubmit: Select a specific server to resubmit only the builds for that server. Select the CLIENT heading to resubmit only the workstation builds.
2.
Select Resubmit Build from the Row menu. If you generated NERs when you initially submitted the build, the system displays a window that asks whether you want to regenerate the NERs.
3.
If you do not want to regenerate NERs, you can prevent this window from appearing by entering 2 in the Generate NER processing option for the Package Build History program.
4.
Select one of these destinations for the build report, and click OK: On Screen To Printer The form closes, and the system begins to build the package. Build time varies, depending on the number and size of the items in the package. When the build is finished, the report either appears on the screen or prints, depending on the destination you specified.
5.
Review the report to verify that the system successfully generated all components in the package. If the report indicates any errors, review the error logs for more detail.
See Also:
Deploying Packages.
Find the package for which you want to reset the status. Below the package name, select the server or servers and client workstation for which you want to build the package.
2. 3. 4. 5. 6.
From the Row menu, select Advanced. On the Advanced Revisions form, click Reset to change the status of the package build from Build Started to Build Definition Complete. Click OK. If desired, select the package name and select Submit Build from the Row menu. The program asks whether you want to delete the current build or to continue without deleting it; select one.
Enter the desired statuses in the Spec Build Status and Pack Build Status fields. Both of these fields have a visual assist feature to help you determine the available statuses.
Note:
The values of these two fields are dependent on each other. If you change one value, be sure you understand the dependency on the other value.
2. 3.
7
Deploying Packages
7
Section 7.1, "Understanding Package Deployment" Section 7.2, "Defining Deployment Parameters" Section 7.3, "Working with Package Deployment" Section 7.4, "Deploying a Server Package" Section 7.5, "Using Push Installation" Section 7.6, "Installing Workstations from CD"
See "Appendix: Using the Microsoft Visual C++ Compiler" in the JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide This section discusses:
Deploying to workstations without JD Edwards EnterpriseOne. Deploying to workstations with JD Edwards EnterpriseOne already installed. Deploying to servers. Deploying to tiered locations. Deploying to workstations from CD.
JD Edwards EnterpriseOne Workstation Installation (for full packages). Oracle's JD Edwards EnterpriseOne Deployment Director (P9631) (for full and update packages).
After you assemble and build a package, use JD Edwards EnterpriseOne Deployment Director to schedule the package for deployment to individual workstations or to selected groups. On the specified deployment date, when the users who are scheduled to receive the package sign in, they are given the opportunity to load the package. Unless you are using the Push Installation feature, JD Edwards EnterpriseOne Deployment Director requires that JD Edwards EnterpriseOne be already loaded on the workstation. You can schedule a new full package to replace the existing package, or an update package to be merged with the existing package on the workstation. Both deployment methods have advantages. JD Edwards EnterpriseOne Workstation Installation is a good method to use when you want to install a package immediately or soon after it is built, without having to schedule the package. Alternatively, JD Edwards EnterpriseOne Deployment Director is useful if you need to control when the package becomes available, if you want to make the package installation mandatory, or if you want to deploy the package to servers as well as to workstations.
the package, you use the JD Edwards EnterpriseOne Deployment Director application (P9631), which uses the same scheduling mechanism to deploy packages to workstations. In fact, you can easily schedule deployment to both client workstations and servers on the same form. You cannot use the Push Installation feature to deploy to servers. If you are deploying a package that contains only UBEs, otherwise known as batch applications, the system marks the package as a "UBE only" package. The system deploys a UBE-only package immediately, rather than waiting for the EnterpriseOne HTML server and waiting for all UBEs to finish. When the package is deployed, the system checks to see if the UBE in the package is currently being processed. If so, a lock is placed on that individual UBE so that the deployment can update the specifications. If not, the package deployment moves forward. This happens automatically and provides a faster deployment time for packages that contain only UBEs. If you are deploying a package that contains only APPs (interactive applications), the system marks the package as an "APP-only" package. The system deploys the APP-only package, waits for the EnterpriseOne HTML server (for one minute), and then deploys it immediately without waiting for any UBEs to finish. If you are deploying a package that contains only UBEs and APPs, the system marks the package as a "UBE/APPs only" package. In this case, the system waits for the EnterpriseOne HTML server (for one minute), and then follows the same logic as the UBE-only deployment. All three of these scenarios happen automatically and provide a faster deployment time for packages that contain only UBEs, only APPS, or only UBEs and APPs.
Define machines. Define locations. Define package deployment groups. Revise package deployment groups.
An HTML server can be defined only as an HTML server, not as a data server, enterprise server, and so on. A deployment server should not be used as a workstation. A deployment server can be used as a data server. A deployment server should not be used as an enterprise server for tuning and performance reasons.
7.2.1.1 Locations
In some cases, an enterprise might span several buildings, cities, or countries. In these situations, you might deploy a package to a location rather than to individual workstations and servers. Then, a secondary deployment server at each location can deploy the package to the workstations and servers at that location. The larger your enterprise, the more you can benefit from creating and deploying to locations. If you use multitier deployment to deploy packages to remote locations, the concept of locations is crucial. In JD Edwards EnterpriseOne, a location is essentially a user-defined group of machines, databases, and environments. In some cases, the location is an actual physical location that is connected by a WAN, such as when you have remote offices that are geographically separate from your main office. For example, a location might be a floor in your office building, a separate building on the corporate campus, a branch office across town, or a facility in another city. After you create a new location, you can add workstations and servers for that location by defining the machine names that are associated with that location.
The topmost location that appears when you launch the JD Edwards EnterpriseOne Deployment Locations Application program (P9654A) is the base location. You cannot change or remove this base location, but you can create or revise locations that are subordinate to it. When you create a location that is subordinate to another location, the original location is the parent location, and its subordinate location is the child location. For example, if you have a location called Seattle and then create a location called Redmond that is subordinate to Seattle, Seattle is the parent location and Redmond is the child location.
7.2.2 Prerequisites
Before you use the JD Edwards EnterpriseOne Deployment Director to deploy a package to individual client workstations, verify that each machine that will receive the package has a record in the Machine Master table (F9650). Select one of these ways to populate the F9650 table:
Manually For a machine that no user has ever used to sign in to JD Edwards EnterpriseOne, use the JD Edwards EnterpriseOne Deployment Locations application (P9654A) to manually enter a record in the F9650 table.
Automatically The system automatically creates a record in the F9650 table when a user on a new machine signs in to JD Edwards EnterpriseOne for the first time. (The system also automatically updates existing records in the F9650 table each time a user signs in to the workstation.)
The simplest way to populate the F9650 table is to have all users on new machines sign in. In cases in which you need to deploy a package before the users can sign in, you must manually enter machine information. The JD Edwards EnterpriseOne Deployment Locations application enables you to perform this task.
In addition to defining workstations, you can also use the JD Edwards EnterpriseOne Deployment Locations application to enter or revise definitions for these machines:
Deployment Server Enterprise Server Data Server Java Application Server Windows Terminal Server Business Services Server
You can enter or revise definitions for these machines in multiple locations, including remote locations.
Highlight the type of machine you would like to create. You can choose from:
Workstations Deployment Server Enterprise Server Data Server HTML Server Business Services Server
2. 3.
Click Add. Enter the appropriate values for the type of machine you are creating.
7.2.4.1 Workstation
Deployment Server Name
Enter the name of the specific server that is being used for deployment. When you define a secondary deployment server, options on the Form menu enable you to select path codes, data items, foundation modules, and help items. (These options are not available for the primary deployment server.)
Specify whether a deployment server is the primary deployment server for a specific location. If you have set up a primary deployment server, you cannot access the Primary Deployment Server field when you define a new deployment server. You can change the value in this field only when you revise the primary deployment server definition or when you change the primary deployment server to a secondary server. In this case, you can specify a different server as the primary deployment server.
Server Share Path
Enter the shared directory for this path code. The objects that are stored on a file server will be found in this path.
Identify the port for a given instance of JD Edwards EnterpriseOne. Because the jde.ini file controls the port to which a workstation will connect, for workstations this port number is for reference only.
Logical Machine Name
Enter the logical machine name that is assigned to this unique machine and port. A machine can be a workstation. Because you can have more than one instance of JD Edwards EnterpriseOne running on a given machine, you must assign a logical machine name that identifies the unique physical machine name and port where this instance runs. The logical machine name should represent the release and purpose of the machine, such as Financial Data Server-E900 or Distribution Logic Server-E900.
Database Type
Enter the name of the specific server that is being used for deployment. When you define a secondary deployment server, options on the Form menu enable you to select path codes, data items, foundation modules, and help items. (These options are not available for the primary deployment server.)
Server Availability
This field is visible only in Update mode. Use this field to reset the enterprise server status if a package deployment failed.
Enter the name of the specific server that is being used for deployment.
Location
Enter a profile to use to classify users into groups for system security purposes.
Deployment Group Name
Enter a profile to use to classify users into groups for system security purposes. You use group profiles to give the members of a group access to specific programs. Some rules for creating a profile for a user class or group are:
The name of the user class or group must begin with an asterisk (*) so that it does not conflict with any system profiles. The User Class/Group field must be blank when you enter a new group profile.
When you revise an existing group, you cannot change the group name, but you can change the description.
1. 2.
To add to the group, select the last row (the empty one) and enter the name of the workstation or deployment group to which you want to add members. Type the name in the Workstation field or the Deployment Group field, or use the search button for those fields. When you use the search button for the Workstation field, the Machine Select form appears. When you use the search button for the Deployment Group field, the Deployment Group Search form appears.
Schedule a package for deployment. Revise deployment options. Activate a scheduled package. Install a scheduled package.
You can deploy a package either to specific workstations and servers, or you can schedule the deployment based on deployment groups or location. You cannot do both; you must select one of these methods. You can make the package mandatory, which means that users cannot access the software until they have installed the package. If the package is optional, users will be given the option of installing the package every time that they sign in until they either install or decline the package. In addition, you can specify a push installation, which means that the package can be deployed from the deployment server to the workstations that you specify, without requiring any interaction from the user.
Deploying Packages 7-11
Note:
Mandatory and Push Installation options are applicable to client packages only.
The JD Edwards EnterpriseOne Deployment Director requires that JD Edwards EnterpriseOne already be loaded on the workstation, unless you are using push installation. You can schedule a new full package to replace the existing package, or an update package to be merged with the existing package on the workstation. The JD Edwards EnterpriseOne Deployment Director uses these tables:
F9650 F9651 F9652 F9653 F9654 F98825 F988251 F98826 F9603 F96031 F98826H F988259
This table summarizes the function of each form in the JD Edwards EnterpriseOne Deployment Director:
Form Name Package Deployment Director form Package Selection form Package Deployment Targets form Form Usage View this form for a description of the JD Edwards EnterpriseOne Deployment Director. Use this form to find and select the package that you want to deploy. Use this form to specify the destination for the package. You can select individual client workstations, deployment servers, and enterprise servers, or you can deploy the package to a deployment group or location. Use this form to enter the date and time that you want to deploy the package. Also specify whether the package is mandatory (that is, it must be installed by every package recipient) and whether you want to use push installation to deploy the package. Use this form to select each of the client workstations that will receive the package. Use this form to select each of the deployment servers that will receive the package. Use this form to select each of the enterprise servers that will receive the package.
Deployment Client Workstation Selection form Deployment Server Selection form Enterprise Server Selection form
Form Name Deployment Location Selection form Deployment Groups Selection form Build Selection form
Form Usage Use this form to specify the deployment location that will receive the package. Use this form to specify the deployment groups whose members will receive the package. For multitier deployment, use this form to specify the server or client package that you want to deploy to the destination deployment server. Use this form to review and revise the locations and package recipients that you entered through the JD Edwards EnterpriseOne Deployment Director.
Machines Level One: Client Workstation, Deployment Server, Enterprise Server, and Business Service Application Server headings. Level Two: Specific machines under each of these three headings. Level Three: Specific packages that are deployed to the machine, if any.
Deployment Groups Level One: Specific groups. Level Two: Members of those groups. Level Three: Specific packages that are deployed to the group member.
Locations Level One: Specific locations. Level Two: Client Workstation, Deployment Server, Enterprise Server, Business Service Application Server, and Remote Locations headings.
Deploying Packages 7-13
Level Three: Specific machines under the Client Workstation, Deployment Server, and Enterprise Server headings. Level Three under Remote Locations only: Defined remote locations. Level Four: Specific packages that are deployed to each machine, if any. Level Four under Remote Locations only: Client Workstation, Deployment Server, and Enterprise Server headings. Level Five under Remote Locations only: Specific machines under the Client Workstation, Deployment Server, and Enterprise Server headings. Level Six under Remote Locations only: Specific packages that are deployed to each machine, if any.
Packages Level One: Package names. Level Two: Client Workstation, Deployment Server, Enterprise Server, and Business Service Application Server headings. Level Three: Package deployment dates and times for each heading. Level Four: Specific machines that have deployed that package for that date and time.
Package Selection
W9631C
W9631D
W9631F
W9631G
Build Selection
W9631N
Select the server package build to deploy to the destination deployment server. Select the Enterprise Servers to which the package will be deployed.
W9631E
FormID W9631M
Navigation Package and Deployment Tools (GH9083), Package Deployment. Select Machines, and click Find to display information according to machine name. Find and select the deployed package for which you want to modify the options, and then select Properties from the Row menu.
1. 2.
Select the package that you want to deploy, and then click Next. On the Package Deployment Targets form, select any of these options to indicate the type of machines to which you want to deploy the package, and then click Next: Client Workstation Deployment Server Enterprise Server Business Services Server See Chapter 8, "Working with Packages for Business Services". Deployment Group
3.
Locations
On Package Deployment Attributes, complete these fields: Mandatory Installation Enable Push Installation Date/Time
4.
If you want to deploy the package using push installation, which pushes the package to workstations from the deployment server, select the Enable Push Installation option, and then click Next. If you are deploying to workstations, the Deployment Client Workstation Selection form appears. If you are not deploying to workstations, bypass the next step.
5.
Find and select the workstations to which you want to deploy the package, and then click Next. Select a workstation by double-clicking in its row header. A check mark appears in the row header for each workstation that you select. If you are deploying to a deployment server, the Deployment Server Selection form appears. If you are not deploying to a deployment server, bypass the next step.
6.
Find and select the deployment server to which you want to deploy the package, and then click Next. Select a server by double-clicking in its row header. A check mark appears next to each server that you select.
7. 8.
On the Build Selection form, select the server package build that you want to deploy to the destination deployment server, and then click Close. Click Next. If you are deploying to an enterprise server, the Enterprise Server Selection form appears. If you are not deploying to an enterprise server, bypass the next step.
9.
Find and select the enterprise server to which you want to deploy the package, specify the number of deployment attempts and minutes to wait between retries, and then click Next. Select a server by double-clicking in its row header.
Note:
You can deploy an update package only to servers that have the full parent package deployed.
10. On Work with Package Deployment, review your deployment selections. 11. To change any of the selections, click Prev to return to the appropriate previous
form.
12. When you are finished reviewing and changing the deployment selections, click
End.
13. If you are deploying a server package, find and select the server package on the
Work with Package Deployment form, and then select Deploy from the Row menu.
After you schedule the package for deployment, at the specified time on the date that you specified, the package deploys to workstations. This package becomes available to the user when the user signs in. If you are using push installation, the package automatically installs at the time that you specify in Oracle's JD Edwards EnterpriseOne Schedule Jobs program (P91300). To schedule a package for deployment to a deployment group or location:
1. 2. 3.
On the Package Selection form, select the package that you want to deploy, and then click Next. On the Package Deployment Targets form, select either Deployment Group or Locations, and then click Next. On the Package Deployment Attributes form, complete these fields: Mandatory Installation Enable Push Installation Date/Time
4.
If you want to deploy the package using push installation, which pushes the package to workstations from the deployment server, select the Enable Push Installation option. Click Next. If you are deploying to a deployment group, the Deployment Groups Selection form appears. If you are deploying to a location, bypass the next step.
5.
6.
Find and select the deployment group that you want to receive the package, and then click Next. Select a group by double-clicking its row header.
7. 8.
If you are deploying to a location, the Deployment Location Selection form appears. Bypass the next step if you are deploying to a deployment group. Find and select the deployment location that you want to receive the package, and then click Next. To select a location, double-click the row header.
9.
On the Work with Package Deployment form, review the deployment selections. form.
10. To change any of the selections, click Prev to return to the appropriate previous 11. When you are finished reviewing or changing the deployment selections, click
End.
12. If you are deploying a server package, find and select the server package on the
Work with Package Deployment form, and then select Deploy from the Row menu. After you schedule the package for deployment, at the specified time on the date that you specified, the package deploys to workstations. This package becomes available to the user when the user signs in. If you are using push installation, the package automatically installs at the time that you specify in the JD Edwards EnterpriseOne Schedule Jobs program (P91300).
See Also:
Scheduling the JD Edwards EnterpriseOne Push Installation Batch Application. Scheduling a Package for Push Installation. Understanding the Deployment Director.
Package Name
Enter a name for the package. A package describes the location on the server where components that you want to deploy to workstations or servers reside. Two package types are available: Full: Contains the full suite of applications (all specifications). Update: Objects contained in this type of package are loaded after the workstation or server receives the package and the user signs in to the system. If the update package includes just-in-time applications, old versions of the application are deleted from the workstation and replaced by the current version the first time the user accesses that
application. Update packages are always deployed on the date and time that are specified by the system administrator. With the exception of just-in-time applications that are included in an Update package, all packages are a snapshot at a point in time of the central objects for a particular path code. Just-in-time applications are dynamic, not built.
Path Code
Enter the path code. The path code is a pointer to a set of objects and is used to keep track of sets of objects and their locations.
Deploy Attempts
Enter the number of times to retry the deployment if it fails. This applies to enterprise servers only. If deployment fails on any of the enterprise servers, the application will re-run R98825D. The default value is 1. Valid values are 1 through 10.
Retry Wait
Enter the number of minutes to wait between retries for a failed deployment attempt. This applies to enterprise servers only. If deployment fails on any of the enterprise servers, the application will wait before re-running R98825D. Valid values are 1 through 30.
Mandatory Installation
Indicate whether the package is mandatory or optional. Valid choices are: Y: The deployment is mandatory. The user must install the package. N: The deployment is optional to the user.
Enable Push Installation
Select this option to enable the package to be installed through push installation.
Date
1. 2.
Click Find. Select from the list the packages that you want to activate or inactivate. Alternatively, you can enter the package name in the Package field.
3.
Sign in to JD Edwards EnterpriseOne. When you are scheduled to receive a package, Oracle's JD Edwards EnterpriseOne Just-In-Time Installation program launches and the Scheduled Packages form appears.
2.
Perform one of these steps: To load the package immediately, bypass to step 3. To decline the package permanently, select Decline from the Row menu. To list all items in the package, select Package Detail from the Row menu. To load the package at another time, click Close. If the package is mandatory, you will be unable to access the system until you load the package.
3.
To load the package, select one or more packages that you want to install and click Select. The JD Edwards EnterpriseOne Workstation Installation program loads the package. If you selected more than one package, the program installs them sequentially. When the installation is complete, the software launches.
You can deploy UBE-only, APP-only, or UBE/APP-only packages at any time. Their deployment does not affect any UBEs that are currently running or those that are submitted.
All other types of server packages should be deployed only when necessary, because the enterprise server is not available to process business applications and batch processes during the installation process. The enterprise server does not actually shut down during package installation. Instead, the system queues any jobs that are submitted to the enterprise server and runs them as soon as the installation finishes. For this reason, you should schedule these server packages to be deployed after hours in order to minimize impact on users. Before you deploy a package to an enterprise server, verify that the services have been started and that no UBEs are active. To further minimize impact on the network and users, if the development environment is on the same enterprise server as the production environment, consider preventing developers from moving their own objects through server packages. Instead, require that an administrator perform this function. To deploy a server package, select Deploy from the Row menu on the Work with Package Deployment form. This is the same function that you use to deploy packages to deployment servers during multitier deployment. The system determines which of the batch programs to call, based on what is currently selected on the Work with Package Deployment form when you select Deploy from the Row menu:
If a specific deployment server is selected, the system launches the Multi Tier Deployment batch program (R98825C). If the deployment server folder is selected, the system launches the Multi Tier Deployment batch program for every deployment server that has a package scheduled. If a specific enterprise server is selected, the system launches the Enterprise Server Deployment batch program (R98825D).
If the Enterprise Server folder is selected, the system launches the Enterprise Server Deployment batch program for every enterprise server that has a package scheduled. If a specific package is selected, the system launches the Multi Tier Deployment batch program, and then the Enterprise Server Deployment batch program for the selected package. If you sort by packages and the Deployment folder is selected, the system launches both the Multi Tier Deployment batch program and Enterprise Server Deployment batch programs for all packages. If a specific workstation or the Workstations folder is selected, the Deploy option is unavailable.
When the system launches a batch program for all servers or all packages, deployment does not occur unless the package has been previously scheduled for a specific server. A full package can be deployed to all servers. However, an update package can be deployed only to servers that already have the parent package deployed. Also, update packages cannot be deployed if the parent package is an inactive or not-deployed full package. When the system launches the batch program to deploy a UBE-only, APP-only, or UBE/APP-only package to an enterprise server, the batch process:
1. 2.
Verifies that the enterprise server deployment location is the same as the Windows client submitting the package. Changes the enterprise server status to Pre Deploy. This is done by changing the MDMCHRCDNM column to 50 in the F9651 table.
3. 4. 5.
If this is an APP-only or UBE/APP-only package, then it waits one minute for the HTML server to find the deployment record. Sends lock messages to the metadata kernel for the UBEs in the package on each selected enterprise server. Once the package is being deployed, the UBEs in the package cannot be submitted. This is done by changing the MDMCHRCDNM column to 10 in the F9651 table.
6. 7. 8.
Updates the specifications in the database. Sends unlock messages to all the enterprise servers to unlock the UBEs that were in the package. Marks the servers as available. This is done by changing the MDMCHRCDNM column to 30 in the F9651 table.
9.
Updates the F96511 table with the new package and spec data source information. This information is used by the web servers.
Note: A deployed package can be deployed multiple times to the same or different servers.
When the system launches the batch program to deploy all other packages to an enterprise server, the batch process:
1. 2.
Verifies that the enterprise server deployment location is the same as the Microsoft Windows client submitting the package. Changes the enterprise server status to Pre Deploy. This is done by changing the MDMCHRCDNM column to 50 in the F9651 table.
3. 4. 5.
Waits for five minutes. Sends lock messages to all the selected enterprise servers. Once the servers are locked, the batch process marks them as unavailable. This is done by changing the MDMCHRCDNM column to 10 in the F9651 table.
6. 7. 8. 9.
Copies the BSFN executables from the package location to the live path code location. Sets the spec.ini file to the new package and spec data source. Sends unlock messages to all the enterprise servers. Marks the servers as available. This is done by changing the MDMCHRCDNM column to 30 in the F9651 table.
10. Updates the F96511 table with the new package and spec data source information.
A server package with the specs built in a shared mode can be deployed to a web server. This process of deploying to the web server is automatic and does not require any end user intervention. The web servers pool the package information from the JD Edwards EnterpriseOne logic server. It compares the package manifest from the spec tables to the one in its serialized database and makes the necessary updates. During server package deployment, the business function (BSFN) dll's, SRVPGMs, .so objects, or .sl objects of the live package are replaced by the objects from the built package. However, if a deployment fails, you may have a mismatched set of BSFNs and specs. With 8.96 JD Edwards EnterpriseOne clients, you can back up the existing BSFN objects. If the deployment fails, you can restore the BSFN objects. The option to back up the live BSFN objects before deployment can be enabled through the Build Settings within Server Manager. For IBM i, the BSFN objects in PY900 are copied into the $PY900 library. For Microsoft Windows and UNIX, the BSFN and spec objects in PY900 are copied to the PY900_ BACK folder. Clients can restore BSFN objects by copying the objects from the backup location to the live folder. They can restore the specs by changing the package name to the previous package in the spec.ini file.
A package manifest is a spec record that is created by the package build process. The manifest describes the package and its contents. The serialized object generator compares the manifest from the deployed package on the enterprise server to one that is created during the generation process and makes the appropriate changes. The process for deploying packages to web servers is:
1. 2. 3. 4.
The web servers check the F9651 and F96511 tables every minute for any change in the package. The five minute interval is changed to five seconds once the enterprise server is in a Pre Deploy state. All JD Edwards EnterpriseOne users are prevented from running any applications once the enterprise server is in a Locked state. The web server compares the package manifest in the F98770 on the enterprise server with the one in its serialized object database after the package is deployed and the enterprise server is in an Available state. The web server synchronizes the serialized object database with the deployed package. The contents of the serialized object database are deleted for a new full package deployment. Only the objects in the update package are deleted for an update package deployment.
Note:
5.
Deploying server packages to web servers is supported only in shared spec server packages.
You can have only one path code and one package per Java node. Serialized objects should not be shared with nodes running dissimilar packages and path codes.
7.4.3 Prerequisites
Before you complete the tasks in this section:
Assemble the server package. Define the server package. Build the server package. Schedule the package for deployment to the appropriate server.
FormID W9632A
Navigation Package and Deployment Tools (GH9083), Deployment Monitoring. Click Find or enter the Package Name or Path Code and click Find to display package deployment records. Find and select the deployed package that you want to review, and then select either Display PDF or Display Logs from the Row menu.
Usage Monitor the status of a package deployment while it is running or retrieve the R98825D pdf and deployment logs after completion.
Locate the server package that you want to deploy. Alternatively, select the enterprise server or, if the package is scheduled to deploy to more than one server, the Enterprise Server folder.
2. 3. 4.
Select Deploy from the Row menu. On Report Output Destination, select On Screen. Click OK.
1. 2.
Click Find. Open the tree structure to view individual deployment records. If the server package deployment is still processing, a status of Processing or Waiting for Locks will appear next to the server. If the server package deployment failed, the deployment error will appear next to the server that failed.
3.
Select the package deployment record that you want to monitor. Alternatively, you can enter the package name in the Package Name field.
4. 5.
Select Display PDF from the Row menu to view the deployment report. Select Display Logs from the Row menu to view the build and deploy logs. You can view the ClientPkgBld.log and the SvrPkgBuild.log from the deployment server, and the SvrPkgBuild.log from the enterprise server. The log from the enterprise server will include the server name at the beginning of its filename. For example, den60158jems_SvrPkgBuild.log
Prepare the enterprise server for push installation. Prepare workstations for push installation. Install the JD Edwards EnterpriseOne Listener. Install the JD Edwards EnterpriseOne Listener using silent installation.
Stop and uninstall the JD Edwards EnterpriseOne Listener. Schedule a package for push installation. Schedule the JD Edwards EnterpriseOne Push Installation batch application. Run the JD Edwards EnterpriseOne Package Installation Results report.
Install a push installation JD Edwards EnterpriseOne Listener program on each workstation that will receive pushed packages. Oracle's JD Edwards EnterpriseOne Listener monitors the progress of Oracle's JD Edwards EnterpriseOne Push Package Installation batch program (R98825) that runs on the server and performs functions such as monitoring installation status. The JD Edwards EnterpriseOne Listener can run as either a local service or a network service.
2.
Schedule the package using the JD Edwards EnterpriseOne Deployment Director program (P9631).
The JD Edwards EnterpriseOne Push Package Installation batch program reads the scheduling table and sends a message to the JD Edwards EnterpriseOne Listener on all workstations for which a package has been scheduled.
3.
Use the JD Edwards EnterpriseOne Schedule Jobs program (P91300) to launch the batch program on the enterprise server. This program enables you to specify the job name, version, start date, start time, and recurrence.
4.
At the specified start time, the JD Edwards EnterpriseOne Schedule Jobs program launches the JD Edwards EnterpriseOne Push Package Installation batch program (R98825), which initiates the package installation process from the deployment server. The JD Edwards EnterpriseOne Listener and the batch program interact during the process until installation is complete. Codes are passed from the JD Edwards EnterpriseOne Listener to the batch program to indicate the installation status (such as failed, successful, in progress, and so on).
5.
When the installation finishes, the system sends an email message to the primary user of the workstation. This message indicates whether the installation was successful. Email notification works only if the package recipient is listed in the Machine Master table (F9650) and has an email address in the profile.
6.
If the push installation fails for some reason (such as when the package recipient neglects to leave the workstation turned on), the installation status changes to Failed. If you want to reschedule the installation, you must first delete the row with the failed job, and then schedule the job again.
If the push installation is not successful, when the user signs on, the standard scheduling screen appears. At this point, the user can either accept the mandatory package or quit the program.
You can select from one of these ways to install the JD Edwards EnterpriseOne Listener on a workstation:
Use a third-party software distribution system, such as the Tivoli Management Environment (TME10) Software Distribution System or the Microsoft System Management Server (SMS) software. Distribute an executable installation program (a setup.exe file) and the accompanying ancillary files using an intranet website or the World Wide Web. Use Windows logon scripts (a .bat file) to call a C program. Install from the World Wide Web.
Important:
If the JD Edwards EnterpriseOne Listener is not installed and running on the workstation (or if the workstation is turned off), the push installation cannot occur. After you schedule a package, remind package recipients to leave their workstations on and the JD Edwards EnterpriseOne Listener service running, even during off-hours. If you set up the JD Edwards EnterpriseOne Listener to run as a local service, also remind users to remain signed in.
DNS by clicking the Network button in the Control Panel, then selecting the Services tab, and then adding Microsoft DNS Server. After you add Microsoft DNS, you must configure the DNS by specifying the domain name and servers.
From the host server on which the JD Edwards EnterpriseOne Push Installation batch program (R98825) runs, a business function attempts to retrieve the machine host address from the DNS server. Because the DNS server does not contain IP addresses, it retrieves the address from the WINS server. The WINS server returns the address to the DNS server. The DNS server returns the address to the host server. The host server finds the JD Edwards EnterpriseOne Listener on the client workstation and sends workstation installation information. The workstation installation process starts.
2. 3. 4. 5. 6.
If you have a previous version of the JD Edwards EnterpriseOne Listener already installed, the installation program removes the previous version before copying the new version to the workstation. Before you begin this task, close any applications that are currently open, and verify that the destination directory where you will be installing the JD Edwards EnterpriseOne Listener has sufficient disk space. You need approximately 2 MB of free disk space to install all of the Listener files and components. To install the JD Edwards EnterpriseOne Listener on workstations:
1. 2. 3. 4. 5. 6. 7. 8. 9.
Launch the installation program by double-clicking setup.exe. On the first Client Listener Setup form, click Next. On the second Client Listener Setup form, enter the release that you want to install through push installation in the Release field. For the release that you selected, enter the full path name on the deployment server from which to initiate the installation in the Path name field. Specify the drive on which you want to install the specified release in the Installation drive field. Select the Uninstall option to uninstall existing versions of the software before installing a new full package. Select the Autostart option to automatically start the JD Edwards EnterpriseOne Listener service whenever the workstation starts up. Click Next to proceed to the next installation form. Select one of these options: Local Network Unless the system administrator tells you to install the JD Edwards EnterpriseOne Listener on the network, click Local to install the JD Edwards EnterpriseOne Listener on the local workstation.
10. In the Folder field, specify the destination drive and folder in which the Listener
After you have successfully installed the JD Edwards EnterpriseOne Listener on the workstation, a small ear icon appears on the Windows taskbar, indicating that the JD Edwards EnterpriseOne Listener has been loaded. By right-clicking this icon, you can start or stop the JD Edwards EnterpriseOne Listener, or change the default parameter settings.
Edit these settings in the listen_silent_setup.inf file that is included on the software CD:
Description Enter Local or Network, depending on where you want to run the JD Edwards EnterpriseOne Listener service. Enter the location on the workstation where you want to install the JD Edwards EnterpriseOne Listener program and related files. For example, C:\Program Files\JDEdwards EnterpriseOne Client Listener. Enter the base release. Do not enter a cumulative update release. Enter the location on the workstation where the software is installed. For example, D:\E900. Enter the deployment server name and the location from which the JD Edwards EnterpriseOne Client Workstation Installation program runs. For example, \\server name\b9\OneWorld Client Install\setup.exe. Enter 1 to automatically start the JD Edwards EnterpriseOne Listener service when the workstation starts up. Enter 0 if you do not want to enable Autostart. Enter 1 if you want to automatically uninstall previous versions before installing a new full package. Enter 0 if you do not want to enable automatic uninstall.
AutoStart
UninstallPackage
2.
Create or modify a batch file to include the silent installation parameter /s for the ListenSetup.exe program. The batch file must reside in the same location as the ListenSetup.exe program. For example, your batch file might contain this line:
start \\servername\E900\client\misc\ListenSetup.exe /s listen_silent_setup.inf
3.
Distribute the INF file and the batch file to workstation users. You can distribute these files or place them on a network server where workstation users can copy the files to their workstations.
4.
Instruct users to restart their workstations to run the batch file and load the JD Edwards EnterpriseOne Listener using silent installation.
After workstation users have successfully installed the JD Edwards EnterpriseOne Listener, the Listener icon appears on the Windows taskbar. Users can click this icon to start and stop the JD Edwards EnterpriseOne Listener or change Listener settings.
Important: You cannot change the name of the Listener silent
installation file that is shipped with the software. The file name must be listen_silent_setup.inf.
1. 2. 3. 4.
Open the Control Panel. Select Services. Select JD Edwards EnterpriseOne Client Listener. Click Stop.
Open the Control Panel. Select Add/Remove Programs. Select JD Edwards EnterpriseOne Client Listener. Click Remove All Components.
Remind package recipients to leave their workstations turned on, even after hours. Remind users who are using a local service that they must be signed in. Remind package recipients to verify that the JD Edwards EnterpriseOne Listener is running.
1. 2.
Enter a name that uniquely identifies a scheduled job in the Scheduled Job Name field. Enter the current status of the scheduled job in the Scheduled Job Status field. As long as the status is active, the JD Edwards EnterpriseOne Scheduler determines whether the job should be submitted to the server for processing. When the scheduled end date for the job has been reached, the status changes to Not Active. To stop the JD Edwards EnterpriseOne Scheduler from considering the job for submission, you can change the status to Not Active (or suspended) at any time prior to the end date. You can reactivate the job if you want the JD Edwards EnterpriseOne Scheduler to include the job again, but you can reactivate a job only if the end date is in the future.
3. 4.
Enter the object name of the report that the Schedule submits to the server in the Scheduled Batch Application field. Enter the version of the report to run in the Scheduled Version field. This is the version of the report scheduled to run. A version identifies a specific set of data selections and sequencing settings that the batch job uses.
5.
In the Scheduled Start Date/Time field, enter the next date on which the JD Edwards EnterpriseOne Scheduler submits the scheduled job to the server for processing. To set the job recurrence (that is, to specify how frequently the job runs) select Recurrence from the Form menu. If you do not specify a recurrence by completing the fields on this form, the job runs only one time. For the JD Edwards EnterpriseOne Push Installation batch program, you should set recurrence to run every 30 minutes.
6.
7. 8. 9.
On the Recurring Scheduling Information Revisions form, click OK. On the Scheduling Information form, to enter any overrides, resubmissions, or expiration options, select Advanced Options from the Form menu. Click the tab that corresponds to the information that you want to enter or revise: Launch Overrides Job Expiration Job Resubmission Batch Application Overrides
After scheduling the job, you can use the JD Edwards EnterpriseOne Object Configuration Manager (P986110) to verify that the server on which the JD Edwards EnterpriseOne Push Installation batch program is running points to the same F98825 and F9650 tables that the JD Edwards EnterpriseOne Deployment Director program uses.
See Also:
"Working with the Job Scheduler" in the JD Edwards EnterpriseOne Tools System Administration Guide.
Machine key. Package name and path code. User class or group. Package status and status description. Install status. Package installation description. Mandatory install (yes or no).
This table lists the status codes and descriptions that the JD Edwards EnterpriseOne Push Package Installation program (R98825) uses. Codes that are marked with an asterisk indicate conditions in which the JD Edwards EnterpriseOne Push Package Installation program continues to attempt the installation the next time that the JD Edwards EnterpriseOne Push Package Installation program runs.
Status Code 200* 210* 220 230 Description Scheduled In Progress Successful Install Install Failed
Status Code 240* 250* 260* 270 280 290 300 310
Description Install Running JD Edwards EnterpriseOne Running Listener Not Started/Installed General Error Already Installed Invalid Package Install Attempted Machine Down
Define the CD Writer location. Deploy a package to the CD Writer location. Create the installation CD.
7.6.2 Prerequisite
Assemble, define, and build the package that you want to write to the CD.
1. 2.
Enter the name of the machine on the network in the Machine Name field. Enter the release number as defined in the Release Master in the Release field.
3. 4. 5.
Enter the primary user for the listed machine in the Primary User field. Enter the shared directory for the path code in the Server Share Path field. If you want to specify a location for data, a foundation, or help files, do so by choosing Data, Foundation, or Helps from the Form menu. If you do not specify a location for data, foundation, or helps, the system uses the default locations.
6. 7. 8. 9.
Click OK. Click Close to quit the Work with Locations and Machines form. In Windows Explorer, locate the folder named Client Install. Copy this folder by dragging the folder to the CD writer location. The location is the server share path that you entered on the Deployment Server Revisions form.
Deploy to the CD writer location the package that you want to write to the CD. Modify the Install.inf and Package.inf files in preparation for writing the package contents to the CD.
Click Add. Complete the forms in the JD Edwards EnterpriseOne Deployment Director in the same way as you would for any other package. From the Work with Package Deployment form, find and select the package that you just scheduled for deployment, and then select Deploy from the Row menu to deploy the package.
After you deploy the package to the CD writer location, the directory structure for that location will look similar to this example:
Multitier\package_inf\Appl_B.inf Multitier\systemcomp\system.cab Multitier\datacomp\data.cab Multitier\helpscomp\helps.cab Multitier\Appl_pgf\Package\Appl_B Multitier\package_inf\Appl_B.inf
In the previous example, Multitier is the name of the server share path. Appl_B is the package name.
Note:
The server share path name is not included when you copy folders to the CD. In the previous example, the items that are copied to the CD are \package_inf\Appl_B.inf, \systemcomp\system.cab, and so on.
In Windows Explorer, find the CD writer location and open the folder that contains the package that you deployed. This folder has the name that you entered in the Server Share Path field on the Deployment Server Revisions form when you defined the CD writer location. In the previous example, the server share path name is Multitier.
2.
Open the Client Installation folder, and then open the file Install.inf. That is, double-click the icon for the file to launch the Microsoft Notepad application.
3.
In the section [FileLocations], modify the line so that two periods and a backslash (\) precede the package_inf entry. The line should look like this example after you modify it:
[FileLocations] PackageInfs=..\package_inf
4.
Similarly, open the Package_inf folder and open the package name.inf file. In the previous example, this file is named Appl_b.inf.
5.
In the section [SrcDirs], modify each of the lines so that two periods and a backslash (\) precede each entry. After modification, the [SrcDirs] section should look similar to this example:
[SrcDirs] SAPPL_PGF=..\APPL_PGF\package\APPL_B SSYS=..\systemcomp SAPPL_PGFDATA=..\datacomp SHELP=..\helpscomp
When you are finished copying the directories to the CD, the CD should contain these directories:
Appl_pgf (contains package information). datacomp (contains the database cabinet file). helpscomp (contains the helps cabinet file). systemcomp (contains the foundation cabinet file). package_inf (contains the package.inf file). Client Install (contains the JD Edwards EnterpriseOne Workstation Installation program).
Note:
Actual names might not be the same as those listed because each system might be different.
8
Working with Packages for Business Services
8
Section 8.1, "Understanding Packages for Business Services" Section 8.2, "Assembling JD Edwards EnterpriseOne Business Services" Section 8.3, "Assembling a Package that Contains Published Business Services" Section 8.4, "Building a Package with Published Business Services" Section 8.5, "Deploying the Package to the Business Services Server"
JAX-RPC package for WLS with JDeveloper 11g. JAX-RPC package for WAS with JDeveloper 10g and RAD. JAX-RPC package for WLS with JDeveloper 10g, 11g, and the Migration Utility enabled. JAX-RPC package for WAS and WLS with JDeveloper 10g, 11g, RAD, and the Migration Utility enabled.
Note:
To build for WAS, you must specify the JDeveloper 10g install path in the JDeveloper Install Path field and also specify the location where IBM Rational Application Developer for WebSphere (RAD) is installed in the RAD Install Path field.
To build for WLS by running the migration process, you must specify the JDeveloper 10g install path in the JDeveloper Install Path field, check the option to Migrate OAS to WebLogic, and specify the location for the JDeveloper 11g install path in the JDeveloper 11g Home field. You may also migrate the business services that were built for OAS to WLS. The migration process:
Converts the OAS business service WSDLs to WLS-compatible WSDLs so that the business services running on WLS can be invoked with a SOAP request similar to the one used with OAS. Converts the OC4J-based proxies (i.e. business service consumer projects) to WLS-compatible proxies so that the existing OC4J-based proxies (for example, JRH90I30) can run on WLS.
See Also:
Assembling JAX-RPC Based Business Services for Package Build in this document for detailed steps. "Configuring Business Services Server Security" in the JD Edwards EnterpriseOne Tools Business Services Server Reference Guide for more information on configuration and security of the Business Services Server.
JAX-WS-Based Business Service Packages (Release 9.1 Update 2) Java API for XML-based web services (JAX-WS) is an API for building standards-based web services and clients that are message oriented. JAX-WS supports transmission of SOAP messages over HTTP. JAX-WS delegates data binding-related tasks to the Java API for XML Binding (JAXB). JAXB provides support for Java to XML mapping, additional support for less used XML schema constructs, and also provides bidirectional customization of Java and XML data binding. JD Edwards EnterpriseOne Tools Release 9.1.2 and later releases support building the following combinations of JAX-WS based business services packages:
JAX-WS package for WLS with JDeveloper 11g. JAX-WS package for WAS with JDeveloper 11g.
The JAX-WS business services package includes the JAX-WS based WSDL artifacts for the published business services and the newly developed JAX-WS business service consumer proxies. Existing JAX-RPC based business services consumer proxies are not be included in this package. If you want to use existing JAX-RPC based business services consumer proxies, then you need to build JAX-RPC based business services packages.
Note: Only JDeveloper 11g is required for building JAX-WS business services packages for both WLS and WAS. IBM RAD is not required for building JAX-WS business services packages for WAS.
You can build JAX-WS business services packages for both WLS and WAS at the same time by selecting both the WLS and WAS options in the Business Services Assembly Application.
See Also:
Assembling JAX-WS Based Business Services for Package Build (Release 9.1 Update 2) in this document for detailed steps. "Configuring Business Services Server Security for JAX-WS Based Business Services" in the JD Edwards EnterpriseOne Tools Business Services Server Reference Guide for more information about configuration and security of the Business Services Server.
JD Edwards EnterpriseOne deployment server installed on a Microsoft Windows Server 2008 R2 64-bit operating system. JD Edwards EnterpriseOne development client installed on a Microsoft Windows 7 operating system.
The supported version of RAD software is RAD 7.5.5 and above. It is necessary to have RAD 7.5.5 or above installed because support for Microsoft Windows Server 2008 R2 and Microsoft Windows 7 starts with this version. You must install the following packages via IBM Installation Manager. The order of installation of the packages is not important because this is handled by the Installation Manager:
IBM RAD for WebSphere Software 7.5.5 (or higher). IBM RAD Assembly and Deployment Features 7.5.5 (or higher). IBM WAS Version 6.1 Test Environment 6.1.0.19 (comes with the default installation). Apply the latest supported WebSphere Fix Pack listed in the certifications (Minimum Technical Requirements). See document 745831.1 (JD Edwards EnterpriseOne Minimum Technical Requirements Reference) on My Oracle Support: https://support.oracle.com/epmos/faces/DocumentDisplay?id=745831.1
7.3 Giga Bytes (GB) for extracting the CDs. 130 Mega Bytes (MB) for IBM Installation Manager during the installation and approximately 20 MB for user data and downloads.
10.5 GB of disk space for IBM RAD 7.5, WebSphere 6.1 Test Environment, WebSphere 7 Test Environment, and shared folders.
Configure H4A/OH4A to properly work on the deployment server. Copy jde.ini entries specific to H4A/OH4A from the client jde.ini (or modify and copy the entries below):
[LOCALWEB] # Installation flag, if it is 0, no HTML testing setup, disable all HTML testing AppServerInstalled=1 # Name of local web server, localhost is default but may not be valid always. webhostname=localhost webport=8888 webserverstart=C:\JDEdwards\E900\system\oc4j\startOC4J.bat webserverstop=C:\JDEdwards\E900\system\oc4j\stopOC4J.bat webserverstartarg= webserverstoparg= # start web server on demand, or immediately # valid values : ONDEMAND (web server will be started on the first HTTP request) , MANUAL (web server has to be started manually by user on port specified), IMME (web server starts as soon as ActivConsole starts) StartAppServer=ONDEMAND # delay time between starting web server and launching browser window # default value is 60 (60 secs) WebDelay=60
Ensure that the EnterpriseOne Menu option is accessible from the Tools menu in JD Edwards Solution Explorer.
8.1.2 Using IBM Rational Application Developer 8.5 (Release 9.1 Update 2.3)
With JD Edwards EnterpriseOne Tools Releases 8.98.4.11, 9.1.2.3, and 9.1.3, you can build business services packages for a business services server running on IBM WebSphere 8.5 with IBM's Rational Application Developer (RAD) 8.5 64 bit. You can build business services packages from these machines using RAD 8.5:
JD Edwards EnterpriseOne deployment server installed on a Microsoft Windows Server 2008 R2 64-bit operating system. JD Edwards EnterpriseOne development client installed on a Microsoft Windows 7 operating system.
You must install the following packages via IBM Installation Manager:
1. 2.
IBM Rational Application Developer for WebSphere Software Version 8.5 (8.5.0.RADO85-I20120529_2348). IBM WebSphere Application Server V7 (64-bit) Test Environment Version 7.0.0.23 (2.0.13.WTE70-6470023-I20120517_1723). You have to download this package separately as this is not included with the default package. You must first install RAD 8.5 and then install WAS v7 TE7.0.0.23 (64 bit) on top of RAD 8.5.
Important!:
Approximately 11 GB for extracting the CDs (including the test environment). 150 MB for IBM Installation Manager during the installation and approximately 20 MB for user data and downloads. Approximately 8 GB of disk space for IBM RAD 8.5, WebSphere 7.0.0.23 Test Environment (64 bit), and shared folders.
While installing WAS version 7.0 Test Environment 7.0.0.23 (64 Bit) on top of RAD 8.5, create the default WAS profile with the default profile name. If you are building the business services package on the deployment server and using RAD 8.5:
Configure H4A/OH4A to properly work on the deployment server. Copy jde.ini entries specific to H4A/OH4A from the client jde.ini (or modify and copy the entries below):
[LOCALWEB] # Installation flag, if it is 0, no HTML testing setup, disable all HTML testing AppServerInstalled=1 # Name of local web server, localhost is default but may not be valid always. webhostname=localhost webport=8888 webserverstart=C:\JDEdwards\E900\system\oc4j\startOC4J.bat webserverstop=C:\JDEdwards\E900\system\oc4j\stopOC4J.bat webserverstartarg= webserverstoparg= # start web server on demand, or immediately # valid values : ONDEMAND (web server will be started on the first HTTP request) , MANUAL (web server has to be started manually by user on port specified), IMME (web server starts as soon as ActivConsole starts) StartAppServer=ONDEMAND # delay time between starting web server and launching browser window # default value is 60 (60 secs) WebDelay=60
3.
4.
Ensure that the EnterpriseOne Menu option is accessible from the Tools menu in JD Edwards Solution Explorer.
Assemble JAX-RPC based business services for package build. Assemble JAX-WS based business services for package build. (Release 9.1 Update 2)
8.2.1 Prerequisites
Before you complete the tasks in this section:
Use Server Manager to create J2EE business service container(s) for the Business Services Server. Use Server Manager to set up Server Manager users. In order to deploy the package successfully, the JD Edwards EnterpriseOne user must be a valid Server Manager user. The user cannot deploy the package if the JD Edwards EnterpriseOne user's credentials are not valid for Server Manager. See the JD Edwards EnterpriseOne Tools Server Manager Guide.
If you have multiple security servers, you must set up JD Edwards EnterpriseOne Trusted Nodes for a successful deployment of business services. See "Setting Up a Trusted Node Configuration" in the JD Edwards EnterpriseOne Tools Security Administration Guide.
If you are building a business services package for WebLogic Server with JDeveloper 11g, JDeveloper 11.1.1.5 needs to be installed on the JD Edwards EnterpriseOne client that you are using to build the business services package. If you are running the Migration Utility during the business services package build, you must install both JDeveloper 10.1.3.5 and JDeveloper 11.1.1.5 on the JD Edwards EnterpriseOne client that you are using to build the business services package. If you are running the Migration Utility during the business services package build, ensure that you have read the Release Notes for 8.98.3.0 and installed the ESUs for the existing business services proxy objects so that the Migration Utility will run successfully. In the jde.ini, set the JDeveloperVersion: To 10.1.3 if you are assembling a business services package for WAS or assembling a business service package with the Migration Utility. To 11.1.1 if you are assembling a business services package for WLS.
If you are building a business services package for WAS or if you are running the Migration Utility during the business services package build, you must do the
following before kicking of the business services package build process so that it completes successfully. On the business services package build machine, upgrade the JDK that comes with JDeveloper 10g to JDK 1.6. To upgrade the JDK that comes with JDeveloper 10g:
1. 2.
Log out of J.D. Edwards EnterpriseOne if you are logged in. Make a backup of the jdk directory in the Jdeveloper10g installation location (JDEV_10g_Install_Path\jdk) by copying the entire folder to some other location on the machine. Delete the jdk directory present in the Jdeveloper10g installation location (the jdk folder under JDEV_10g_Install_Path). Download and install the JDK 1.6. Copy the entire JDK 1.6 Install directory into the Jdeveloper10g installation location (for example, to JDEV_10g_Install_Path) Verify that the JDK 1.6 folder under the Jdeveloper10g installation location is named "jdk" (for example, JDEV_10g_Install_Path\jdk). This jdk folder should contain the JDK 1.6 contents. On the BSSV Package build machine, set the JAVA_HOME environment variable to point to the JDK 1.6 path under JDeveloper 10g. For example, set the JAVA_HOME environment variable to JDEV_10g_Install_Path\jdk where the jdk folder has the JDK 1.6 contents.
3. 4. 5. 6.
7.
These additional prerequisites are required if you are building a JAX-WS based business services package for WLS, WAS, or both WLS and WAS: (Release 9.1 Update 2)
Apply the latest Planner ESU for EnterpriseOne 9.1 or 9.0, depending on your JD Edwards EnterpriseOne Applications release. Ensure that you have JDeveloper 11.1.1.5 installed on the JD Edwards EnterpriseOne client or deployment server machine that you are using to build the business services package. Set JDeveloperVersion to 11.1.1 in the jde.ini file.
1.
On the Assemble Business Services form, in the Pathcode field, enter the path code of the package that you plan to build and tab to the next field.
Note:
At this point, the application retrieves all the available business services from F98602 and F98603. If you have used this application before, the application also retrieves the values for the JDeveloper Install Path and Rational Application Developer Install Path fields from the JDE.INI file.
2.
If this is your first time in the application, you must manually complete the JDeveloper Install Path and Rational Application Developer Install Path fields. Enter the following values, depending on whether you are assembling your business services to build a package for WAS or WLS:
a.
To build for WAS, enter the location where RAD is installed in the RAD Install Path field & enter the location for the JDeveloper 10g install path in the JDeveloper Install Path field.
b.
To build for only WLS, enter the location for the JDeveloper 11g install path in the JDeveloper Install Path field. The JDeveloper 11g install path should include the root folder of the JDeveloper 11g installation and not the JDeveloper folder (for example, C:\Oracle\Middleware).
3.
When you enter the install path, P9603 verifies the actual location and version. If this path is correct, the P9603 adds the information to the jde.ini:
[MTR VALIDATION] JDeveloperInstallPath=<Install path specified by P9603> JDeveloperVersion=10.1.3 WebSphereInstallPath=<Install path specified by P9603> WebSphereVersion=6.1
Note:
If the path or version is incorrect, an error appears; the Close button is disabled until you enter the correct path.
4.
If the location that you enter in the JDeveloper Install Path field points to an Oracle JDeveloper 10g release, the Migrate to WebLogic option appears. If you select this option, the system migrates your business services. The migration process: Converts the OAS business service WSDLs to WLS-compatible WSDLs, so that the business services running on WLS can be invoked with a SOAP request similar to the one used with OAS. Converts the OC4J-based proxies (i.e. business service consumer projects) to WLS-compatible proxies so that the existing OC4J-based proxies, like JRH90I30, can run on WLS.
5.
If you want to run the migration process during the business services package build:
a. b.
Check the option to Migrate OAS to WebLogic. Enter the location for the JDeveloper 11g install path in the JDeveloper 11g Home field. The path to JDeveloper 11g should include the root folder of the JDeveloper 11g installation and not the JDeveloper folder (for example, C:\Oracle\Middleware).
Note:
When you build a business services package with the migration process, an OAS .ear is generated first and then the migration process converts the OAS .ear to a WLS-compatible .ear file.
6.
In the grid, select the business services that you want to expose as a web service and click the Select button. You can also double-click the row headings of the business services that you want to expose. A check mark appears by each business service that is selected.
7. 8.
Click Select again or double-click the row header to unexpose the web service. Click Close to close the application.
Working with Packages for Business Services 8-9
8.2.3 Assembling JAX-WS Based Business Services for Package Build (Release 9.1 Update 2)
Enter P9603 in the Fast Path.
Figure 82 Assemble Business Services form for JAX-WS
1.
On the Assemble Business Services form, select the JAX-WS option. The WLS and WAS options are enabled.
2.
Select the WLS option to build for WLS. Select the WAS option to build for WAS. Select both options to build for WLS and WAS at the same time. The JAX-WS EAR for WLS is built first, and then the JAX-WS based EAR for WAS is built.
3.
In the Pathcode field, enter the path code of the package that you plan to build and tab to the next field.
Note:
At this point, the application retrieves all the available business services from F98602 and F98603. If you have used this application before, the application also retrieves the values for the JDeveloper Install Path field from the JDE.INI file.
4.
If this is your first time in the application, you must manually enter the JDeveloper install path (on the package build machine) in the JDeveloper Install Path field.
The JDeveloper 11g install path should include the root folder of the JDeveloper 11g installation (for example, C:\Oracle\Middleware), and not the JDeveloper folder.
5.
When you enter the install path, P9603 verifies the actual location and version. If this path is correct, P9603 adds this information to the jde.ini:
[MTR VALIDATION] JDeveloperInstallPath=<Install path specified by P9603>
Note:
If the path or version is incorrect, an error appears; the Close button is disabled until you enter the correct path.
6. 7.
The RAD Install Path field is disabled because RAD is not required for building JAX-WS business services packages for WAS. The Migrate OAS to WebLogic option and JDeveloper 11g Home Path field are disabled because building a JAX-WS based business service OAS EAR is not supported, therefore, migration fro OAS to WLS also is not supported. In the grid, select the business services that you want to expose as a web service and click the Select button. You can also double-click the row headings of the business services that you want to expose. A check mark appears by each business service that is selected.
8.
9.
Click Select again or double-click the row header to hide the web service.
Understanding the Assemble Business Services Form (Release 9.1 Update 2) After you install the latest Planner ESU for EnterpriseOne 9.1/9.0 and you set the JDeveloperVersion to 11.1.1 in the jde.ini file, the Assemble Business Services form shows the JAX-RPC and JAX-WS options. You use this version of the form to build JAX-WS based business services packages for WLS, WAS, or both WLS and WAS. You can use this version of the form to build JAX-RPC based business services packages for WLS. To assemble a JAX-RPC based business services package for WLS, first select the JAX-RPC option, and then enter the location for the JDeveloper 11g install path in the JDeveloper Install Path field, as illustrated here:
If you want to build a JAX-RPC based business services package for WAS or for a Migration based business services package for WLS, do the following:
1. 2. 3.
Close the P9603 application. Set the JDeveloper Version to 10.1.3 in the jde.ini file. Type P9603 in the Fast Path.
The Assemble Business Services form from JD Edwards EnterpriseOne Tools Release 9.1 and earlier releases appears without the JAX-RPC and JAX-WS options. This version of the form is illustrated in Assembling JAX-RPC Based Business Services for Package Build along with information for assembling your business services to build a JAX-RPC based package for WAS or Migration.
1. 2. 3.
Set the processing option entitled Business Services to 1. This processing option is blank by default. Select OK. On the Work with Packages form, begin the assembly process. See Chapter 4, "Assembling Packages".
Define a package build with published business services. Resubmit the package build.
8.4.1 Understanding the Build Process for a JAX-RPC Based Business Service Package
This section provides overviews of how the JD Edwards EnterpriseOne system builds a package that contains business services:
Creates the \\work\sbf\sbfbuild.ini, which defines the paths to the exposed methods. Creates the Ant scripts logtimestamp.xml and build.xml in the \\work\sbf directory. Runs the build.xml Ant script to extract source. When the extract occurs, Unjar_BusinessService.log is generated in the \\work\sbf directory.
4.
Creates service interface files. An interface file is created for each published business service. The selected methods are listed in the created published business service.
5. 6.
Creates the Web Service Inspection Language (WSIL) file, which is used for Business Process Execution Language (BPEL). Creates Ant scripts for OAS. These scripts are named build.properties and build.xml. They are created within the \\work\sbf\OAS directory.
7.
Creates Ant scripts for WAS. These scripts are created within the \\work\sbf\WAS directory.
8.
Runs the OAS build.xml Ant script. The build.xml Ant script:
a. b. c.
Creates javadoc. Compiles java source files. Assembles the business services' source into an .ear file that is OAS-compatible.
9.
Runs the WAS build.xml Ant script. The build.xml script creates an .ear file that is WAS-compatible.
10. Compresses the java folder for deployment of the client sbf.cab.
Note:
Review the oas_BusinessService.log or was_ BusinessService.log to verify that the build was successful. If the build is successful, "Build Successful" appears at the bottom of the log. If the build failed, "Build Failed" appears at the bottom of the log.
Creates the \\work\sbf\sbfbuild.ini, which defines the paths to the exposed methods. Creates the Ant scripts, logtimestamp.xml and build.xml in the \\work\sbf directory. Runs the build.xml Ant script to extract source. When the extract occurs, the Unjar_BusinessService.log is generated in the \\work\sbf directory.
4.
Creates the Java Web Service (JWS) files. A JWS file is created for each published business service. The selected methods are listed in the created published business service. Creates the WSIL file, which is used for BPEL. Creates Ant scripts for WLS. These scripts are named build.properties and build.xml. They are created within the \\work\sbf\wls directory. Runs the WLS build.xml Ant script. The build.xml Ant script:
a. b. c.
5. 6. 7.
Creates javadoc. Compiles java source files. Assembles the business services' source into an .ear file that is WLS-compatible.
8.
Review the wls_buildservices.log in \\work\sbf\wls to verify that the build was successful. If the build is successful, "Build Successful" appears at the bottom of the log. If the build failed, "Build Failed" appears at the bottom of the log.
The OAS business services .ear file is created as indicated by the existing process. The business services package build process invokes the migration utility. The migration utility creates the migrated WLS .ear file in the \\<Pathcode>\Package\<Package_name> folder.
Note:
Review the create_ear.out file on the business services package build machine in the \\<Pathcode>\Package\<Package_ name>\MOAS location to verify that the migrated WLS .ear file was built successfully. If the build is successful, "Build Successful" appears at the bottom of the log.
8.4.2 Understanding the Build Process for a JAX-WS Based Business Service Package (Release 9.1 Update 2)
This section provides overviews of how the JD Edwards EnterpriseOne system builds a package that contains JAX-WS based business services for WLS & WAS. For building a JAX-WS based business services package for WLS & WAS, the JD Edwards EnterpriseOne System:
1. 2. 3.
Creates the \\work\sbf\sbfbuild.ini, which defines the paths to the exposed methods. Creates the Ant scripts, logtimestamp.xml and build.xml, in the \\work\sbf directory. Runs the build.xml Ant script to extract source. When the extract occurs, Unjar_BusinessService.log is generated in the \\work\sbf directory.
Working with Packages for Business Services 8-15
4.
Creates Java Web Service (JWS) files. The JWS files are created on the EnterpriseOne Deployment Server in the E1_ Install_Path\Pathcode\Package\PackageName\java\sbf\sbfjaxwswls directory for WLS and at E1_Install_ Path\Pathcode\Package\PackageName\java\sbf\sbfjaxwswas directory for WAS. A JWS file is created for each published business service, and it has annotations that describe the published business service. The selected methods are listed in the created published business service. The JWS files are required to create the WSDL artifacts for the published business services, and they should not be edited manually.
5. 6.
Creates the Web Service Inspection Language (WSIL) file, which is used for Business Process Execution Language (BPEL). Creates Ant scripts for WLS and WAS. These scripts are named build.compile.xml, build.xml, and sbfwebservices.xml. They are created within the \\work\sbf\wls directory for WLS and within the \\work\sbf\was directory for WAS.
7.
Creates javadoc. Compiles the business services java source files. Invokes the sbfwebservices.xml Ant script to run the wsgen Ant task Invokes the sbfwebservices.xml Ant script to run the wsgen Ant task to create the web services artifacts (such as the WSDL file).
d.
Generates the required deployment descriptors, and assembles the business services classes into an .ear file that is compatible with WLS and WAS.
When the build process finishes, an E1Services-Pathcode-wls.ear file is created for WLS, and an E1Services-Pathcode-was.ear file is created for WAS on the EnterpriseOne Deployment Server within the E1_Install_ Path\Pathcode\Package\PackageName directory.
Note:
For WLS, review the wls_BusinessService.log in the \\work\sbf\wls directory and for WAS, review the was_ BusinessService.log in the \\work\sbf\wls directory to verify that the build was successful. If the build is successful, Build Successful appears at the bottom of the log. If the build failed, Build Failed appears at the bottom of the log.
8.4.3 Prerequisites
Before building the package, verify that logging is turned off. When the jdeproperties.log file is set for logging in the \system\classes folder and a package build is submitted, the build process is slowed down. It is not recommended to have logging turned on during package builds.
1. 2. 3.
Enter P9621 in the Fast Path or go to the Package and Deployment Tools menu and select Package Build. Use the Package Build application to define build properties for the package. On the Package Build Location form, select Client as the Build Location.
Note:
The JVM's virtual memory is set to a maximum of 512 MB. You can change this using the following jde.ini settings: [PACKAGE BUILD] JavacMaxMemorySize= 512 MB JavadocMaxMemorySize= 512 MB
1.
On the Work with Package Build History form, enter your package in the Package Name field and select Find.
2. 3. 4. 5.
In the tree structure, expand your package name and CLIENT. Click Business Services and select your business service. Select Reset Status from the Row menu to reset the status of your business services. Select Resubmit Build from the Row menu.
If you are deploying the package to both the enterprise server and the business services server, you select the enterprise server and click Deploy. R98825D deploys the package to the enterprise server and then calls R98825F to deploy the package to the business services server.
2. 3.
The R98825F creates the scfjar folder. The scf_manifest.xml is created in the scfjar folder. This xml contains information that the package deployment process uses to communicate with the Server Manager.
4. 5.
The WAS .ear files are copied to the scfjar folder. The contents of the scfjar folder are combined to form the bssv_timestamp.jar file.
Note:
If errors occur, they are logged to the jas.log or jasdebug.log files that are configured through the jdelog.properties file in the E1_ Install_Path\system\classes path. Errors are also logged in the Server Manager EnterpriseOne Agent logs on the machine on which WAS is installed and under which the business service instance is created. (Release 9.1 Update 2)
6.
The jar file is uploaded to Server Manager and both the file and the scfjar folder are deleted from the deployment server.
Note:
If you are deploying the package to both the enterprise server and the business services server, you select the enterprise server and click Deploy. R98825D deploys the package to the enterprise server and then calls R98825F to deploy the package to the business services server.
2. 3.
The R98825F creates the scfjar folder. The scf_manifest.xml is created in the scfjar folder. This xml contains information that the package deployment process uses to communicate with the Server Manager.
4.
E1BSSVAuthenticator.jar is copied to the scfjar folder. E1BSSVAuthenticator.jar is a custom authenticator jar that is required to secure business services on Oracle WebLogic Server.
5. 6.
The WLS .ear file is copied to the scfjar folder. The contents of the scfjar folder are combined to form the bssv_timestamp.jar file.
Note: If errors occur, they are logged to the jas.log or jasdebug.log files that are configured through the jdelog.properties file in the E1_ Install_Path\system\classes path. Errors are also logged in the Server Manager EnterpriseOne Agent logs on the machine on which WAS is installed and under which the business service instance is created. (Release 9.1 Update 2)
7.
The jar file is uploaded to Server Manager and both the file and the scfjar folder are deleted from the deployment server.
If you are deploying JAX-WS business services to WAS v8.5, ensure that the IFIX 8.5.0.0-WS-WASProd-IFPM62535 Version 8.5.0.20120907_1136 (8.5.0.20120907_1136) for WAS v8.5 is installed on the WAS under which the business service instance is created.
1. 2.
On the Work with Package Deployment form, click the Add button. On the Package Selection form, select the business services package to deploy and click Next.
Note:
In order to deploy a business services package for WLS, you must select a server with a Server Type of owl_1031.
3.
On the Package Deployment Targets form, select Business Services Server as the Deployment Target.
Note:
The check box for Business Services Server is disabled if the selected package does not contain business services.
4.
On the Package Deployment Attributes form, enter the Management Server URL and click Next. Server Manager returns a list of eligible business services servers to which the user can deploy the business services.
Note:
In order to deploy the package successfully, the JD Edwards EnterpriseOne user must be a valid Server Manager user. The user cannot deploy the package if the JD Edwards EnterpriseOne user's credentials are not valid for Server Manager. The user also cannot deploy the package if there is no valid business services server defined in Server Manager.
See the JD Edwards EnterpriseOne Tools Server Manager Guide for information about setting up Server Manager users.
5. 6. 7. 8.
Select the appropriate servers and click Next. On the Business Services Package Deployment Properties Revisions form, click End. On Work with Package Deployment, open your package name and then Business Service Application Server in the tree structure. Select the date/time stamp and select Deploy from the Row menu.
Note:
You cannot deploy to an individual business services server. Business services are deployed to all servers under the selected date/time stamp.
9
Harvesting Published Business Services into the Oracle Enterprise Repository Server
9
The information in this chapter applies only to customers using JD Edwards EnterpriseOne business services and Oracle Enterprise Repository. This chapter contains the following topics:
Section 9.1, "Overview" Section 9.2, "Prerequisites" Section 9.3, "Generating Business Service Asset Definition XML Files/Artifacts" Section 9.4, "Harvesting the Business Service Asset Definition XML Files/Artifacts into the Oracle Enterprise Repository Server" Section 9.5, "Configuring Java Doc Location in Oracle Enterprise Repository for the Published Business Services" Section 9.6, "Troubleshooting the Business Services Package Build and Deployment Process for Harvesting Published Business Services Artifacts"
9.1 Overview
JD Edwards EnterpriseOne provides the ability to harvest information about published business services to the Oracle Enterprise Repository. Oracle Enterprise Repository is a metadata repository that serves as a single source of truth for information about Oracle Service-Oriented Architecture (SOA) assets and their dependencies. Oracle Enterprise Repository is a searchable repository that manages assets and relationships between assets.
9.2 Prerequisites
Before harvesting JD Edwards EnterpriseOne published business services into the Oracle Enterprise Repository server, perform the following prerequisites:
Set up the Oracle Enterprise Repository server. For information about the installation and setup of the Oracle Enterprise Repository server, see Oracle Fusion Middleware Installation Guide for Oracle Enterprise Repository 11g Release 1 (11.1.1).
Configure the Harvester tool. The Harvester is used to harvest JD Edwards EnterpriseOne published business services artifacts into the Oracle Enterprise Repository server.
Harvesting Published Business Services into the Oracle Enterprise Repository Server 9-1
The Harvester is included in the Oracle Enterprise Repository 11g installation in the 11.1.1.3.0-OER-Harvester.zip file. The .zip file is located in the following Oracle Enterprise Repository installation directory:
<ORACLE_HOME>/repositoryXXX/core/tools/solutions/11.1.1.3.0-OER-Harvester.zip
The following steps are general and should work with most configurations. For detailed instructions on configuring the Harvester, see "Configuring and Using Automated Harvesting in Design-time and Runtime Environments" in the Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository 11g Release 1 (11.1.1).
1. 2. 3. 4.
Extract the 11.1.1.3.0-OER-Harvester.zip to a <Harvester Home> directory. Set the JAVA_HOME environment variable to the JDK 1.6 home. In the Harvester subfolder, open the HarvesterSettings.xml file. In the HarvesterSettings.xml file, under the repository section, complete the following elements: <uri>. Enter the URL to the Oracle Enterprise Repository server. <user> (in the credentials section). Enter the Oracle Enterprise Repository admin user. <password> (in the credentials section). Enter the Oracle Enterprise Repository admin password.
5.
Access encryptRun encrypt.bat to encrypt the password stored in the HarvesterSettings.xml file. The encrypt.bat is located in the Harvester subfolder.
6.
Note: By default, the GenerateAssetXml flag is not present in the JD Edwards EnterpriseOne Windows client jde.ini file. Therefore, the asset definition XML files are not generated by default during the business services package build process.
The following example shows an asset definition .xml file generated for the RI_ CustomerManager published business service:
<?xml version="1.0" encoding="UTF-8"?> <AssetDef xmlns="http://xml.oracle.com/AIA/CAR/V1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml.oracle.com/AIA/CAR/V1 auasset.xsd"> <Instance> <Core> <UID> <AssetType>JDEdwardsE1: Business Service</AssetType> <TargetNameSpace>http://xml.oracle.com/JDEdward/EnterpriseOne</TargetNameSpace> <Name>JPR01020.RI_CustomerManager</Name> <Version>E812</Version></UID> <Description>RI_CustomerManager</Description> <LocationURL>Actual WSDL URL of PBSSV to be set here after BSSV Package Deploy</LocationURL> <Dynamic> <Name>getCustomerCreditInfo</Name> <Value>Published method for getCustomerCreditInfo retrieves credit information for Customer using provided entity id. Acts as wrapper method, passing null context and null connection, will call protected getCustomerCreditInfo. This is a reference implementation for getting customer credit information, it should not be used in Production. </Value> </Dynamic> <Category> <ApplicationName>JD Edwards EnterpriseOne</ApplicationName> <Keywords/></Category></Core> <Extend> <Category> <Name/> <Value/></Category> <Attribute> <Name>Application Release</Name> <Value>E812</Value></Attribute> <Attribute> <Name>Production Code</Name> <Value>H95</Value></Attribute> <Attribute> <Name>Production Code Description</Name> <Value>Object and Environment Tech</Value></Attribute> <Attribute> <Name>Published Business Service Class</Name> <Value>oracle.e1.bssv.JPR01020.RI_CustomerManager</Value></Attribute> <Attribute> <Name>Java Doc Location</Name> <Value>rep://JDEdwardsE1: Business Service:DV812_JAVA_ DOC/oracle/e1/bssv/JPR01020/RI_CustomerManager.html</Value></Attribute> <Attribute> <Name>Java Doc URL</Name> <Value>click here for Java Doc for RI_CustomerManager</Value>
Harvesting Published Business Services into the Oracle Enterprise Repository Server 9-3
Harvesting the Business Service Asset Definition XML Files/Artifacts into the Oracle Enterprise Repository Server
When the business services package build process completes successfully, the generated asset definition XML files are placed on the deployment server at:
DEP_SERVER\APP_RELEASE\PATHCODE\PACKAGE\PACKAGENAME\ASSETDEFNFILES
9.3.1 Understanding the LocationURL Element in the Asset Definition XML File
After the business services package build process completes successfully and the asset definition xml files are generated, the business services package must be deployed to a valid business services server instance. After a successful business services package deployment, the LocationURL element in each of the business service asset definition xml files is automatically updated with the actual WSDL URL of the deployed published business service. For business services deployed to WebSphere Application Server (WAS), the WSDL URL is an http-based URL. For example, the LocationURL element for the RI_ CustomerManager published business service that is deployed to WAS is set as:
<LocationURL>http://MachineName:HTTPPortNo /DV812_WEB/services/RI_ AddressBookManagerHttpPort/wsdl/RI_AddressBookManager?WSDL</LocationURL>
For business services deployed to Oracle WebLogic Server, the WSDL URL is specified as an https-based URL. For example, the LocationURL element for the RI_ CustomerManager published business service deployed to WebLogic Server is set as:
<LocationURL>https://MachineName:SSLPortNo /DV812/RI_ CustomerManager?WSDL</LocationURL>
When the business services package is deployed to the WebLogic Server, SSL is enabled and the SSL Listen Port is set as the HTTP Listen Port of the Business Services Server instance on WebLogic Server plus 1. For example, when the Business Services Server instance is created on WebLogic Server, if the HTTP listen port for the instance is 7771, then during the deploy process the SSL Listen Port is set to 7772. This same value is set in the LocationURL element of the asset definition xml file for the published business service.
Note:
If you manually change the SSL Listen port of the Business Services Server instance on WebLogic Server after the business services package is deployed, then you must re-deploy the business services package to the same instance in order for this new SSL Listen port to be reflected in the LocationURL element of the asset definition xml files for the published business services.
9.4 Harvesting the Business Service Asset Definition XML Files/Artifacts into the Oracle Enterprise Repository Server
To harvest the business service assets into the Oracle Enterprise Repository server:
1.
In the Harvester, specify the Harvester configuration file and the folder where the generated business service asset definition xml files are located.
Configuring Java Doc Location in Oracle Enterprise Repository for the Published Business Services
2.
Enter the following command to direct the Harvester to harvest the business service assets to the Oracle Enterprise Repository server:
CARHarvest -settings .\Harvester\HarvesterSettings.xml -input c:\bssv_xml
Note:
HarvesterSettings.xml is the Harvester configuration file that has already been configured.
As an input, you must provide the folder where the generated business service asset definition XML files are located. In the preceding command, c:\bssv_xml is the folder that contains all of the JD Edwards EnterpriseOne published business service asset definition xml files.
9.5 Configuring Java Doc Location in Oracle Enterprise Repository for the Published Business Services
Each JD Edwards EnterpriseOne business service asset has a link to the Java Doc of its Java published business service class. After a business services package build is complete, you can obtain the Java Doc for the published business service classes from the following location:
dep_server\app_release\pathcode\package\package_name\java\sbf\javadoc
The Java Doc can also be extracted from the sbf.cab file which is generated during the full business services package build process. Using an Oracle Enterprise Repository supported transport protocol, such as HTTP or FTP, configure the Java Doc location in the Oracle Enterprise Repository server to point to the actual Java Doc location of the Java published business service class. To do so, perform the following steps:
1. 2.
Make the Java Doc html files for the published business services available on the web through an HTTP server or FTP server. To configure the Java Doc server mapping in Oracle Enterprise Repository to point to the HTTP or FTP server that hosts the Java Doc html files, log in to Oracle Enterprise Repository server. Click the Edit/Manage Assets link to open the Asset Editor window. From the Actions menu, click Configure Artifact Stores. Click Add to add a new Artifact Store.
3. 4. 5.
Harvesting Published Business Services into the Oracle Enterprise Repository Server 9-5
Troubleshooting the Business Services Package Build and Deployment Process for Harvesting Published Business Services
6.
Name Enter the name for the artifact store. For example:
JDEDWARDSE1: BUSINESS_SERVICE:DV812_JAVA_DOC
Hostname Enter the server name and port, for example: dnshravindvm1.mlab.jdedwards.com:80.
7.
Click OK to add the Java Doc server mapping. A link to the Java Doc is established for every business service asset in the Oracle Enterprise Repository server.
9.6 Troubleshooting the Business Services Package Build and Deployment Process for Harvesting Published Business Services Artifacts
This section provides troubleshooting tips for harvesting published business services artifacts into the Oracle Enterprise Repository server.
Troubleshooting the Business Services Package Build and Deployment Process for Harvesting Published Business Services
Harvesting Published Business Services into the Oracle Enterprise Repository Server 9-7
Troubleshooting the Business Services Package Build and Deployment Process for Harvesting Published Business Services
10
Setting Up Multitier Deployment
01
Section 10.1, "Understanding Multitier Deployment" Section 10.2, "Defining Deployment Servers" Section 10.3, "Distributing Software to Deployment Locations" Section 10.4, "Deploying Server Packages in a Multitier Network"
Overview of multitier deployment. Multitier deployment terminology. Multitier deployment features. Multitier implementation. Multitier deployment case study.
which acts as a second deployment tier. Multitier deployment means deploying from more than one deployment tier. For example, you might have one deployment server at the main location and a second deployment server for a remote location. Because the server at the remote location is responsible for deploying to workstations and servers at that location, you do not need to deploy packages from the main deployment server across a WAN, as you would in a single-tier deployment configuration. Workgroup servers can also be used as second-tier deployment locations in a local area network (LAN) environment, where large numbers of workstations need to install software concurrently. It is recommended that you implement multitier deployment if your site has more than 50 workstations receiving multiple installations per day. The primary function of multitier deployment is to reduce network traffic (and the delays that result from heavy traffic) by enabling enterprises with more than one geographic location to deploy from a secondary deployment server at the remote site. Instead of installing packages across the WAN from the deployment server to workstations at a remote location, you can copy the package and the package.inf file from the deployment server at the primary location to the deployment server at the remote location. The server at the remote location can then deploy the package to the workstations and servers at that location. Consider implementing a multitier deployment configuration when either of these situations applies:
Too many workstations are installing packages from the same location, causing server and network performance to suffer. Workstations are remotely connected to the deployment server over a WAN, which requires unacceptably long installation times.
Normally, you decide whether to implement multitier deployment during Configurable Network Computing (CNC) implementation. Although you can enable this function at any time, you typically set it up after you have installed the software and are preparing the production sites to go live. To set up multitier deployment, you must define the machines (and their associated path codes) that are used for deployment. In addition, you can use a scheduler function to define when software should be pushed to the tiered deployment location. You must also define individual user characteristics for multitier deployment. Normally, you do this by modifying the user profiles to indicate the deployment location from which a user pulls a package.
Description Tier deployment locations (also known as remote or secondary locations) have one or more deployment servers that enable you to install the software on the workstations at that location. These servers receive their packages from the deployment server at the primary or base location. Machines at the tier deployment locations cannot use Object Librarian functions such as object check-in and check-out. These machines are designed for deployment use only and are not designed to be used for remote development. The number of tiered locations that you can have depends on the network and server capacity. Tier workstations are workstations that connect to a tier deployment location for software installation. The number of workstations per deployment location depends on the network and machine load. All tiered workstations must also have a Microsoft Windows domain connection that enables them to connect to, read, and copy files from the shared drives of their respective deployment locations.
Tier Workstations
See Also:
You can deploy workstations from any number of deployment servers. You can easily add deployment locations, and the deployment machine does not need to be a server; it can be a Microsoft Windows workstation. Setup and administration are straightforward tasks. You maintain central control over files and data that are transferred to remote deployment locations. You can easily schedule software for deployment to remote sites. Multitier deployment is integrated into Oracle's JD Edwards EnterpriseOne Deployment Director, so the process for deploying is essentially the same as the process for deploying in a single-tiered setup.
Tier 1 Workstation
Tier 1 Workstation
WAN connections
LAN connections
Tier 2 Workstation
Tier 2 Workstation
Define deployment locations. You must define each physical location to which you want to deploy. For example, if the main office is in Denver and you want to deploy to the branch office in Seattle, you must define the Seattle deployment location.
2.
Create deployment server definitions. You must define the deployment server at each remote location.
Note:
This step is not necessary if you used Oracle's JD Edwards EnterpriseOne Remote Location Workbench to create deployment server definitions when you installed the software.
3.
Schedule the package. Use the JD Edwards EnterpriseOne Deployment Director program (P9631) to schedule the package for deployment. The process of scheduling a package for multitier deployment is identical to the process for scheduling any other package.
4.
Deploy the package to workstations. After you deploy the package to the deployment server at the remote location, that server can deploy to the workstations at that location.
LAN connections
Geographic location: Physical machine name: Path code Prototype: Production: Shared drive connection
LAN connections
15 CRP Workstations
WAN connections Tier Deployment Location Geographic location: Physical machine name: Path code: Atlanta ATLSVR1 PD900 Tier 2 Deployment Location Geographic location: Physical machine name: Path code Prototype: Production: LAN connections 15 production Workstations 15 CRP Workstations Chicago CHISVR1 PY900 PD900
LAN connections
15 production Workstations
This table describes the assumptions used by the Tier 1 Denver location in this case study:
Characteristic Enterprise server name Deployment server name Setting HOME1 Denver: DENSVR1 Atlanta: ATLSVR1 Chicago: CHISVR1 Prototype workstations Denver: 15 Atlanta: 0 Chicago: 15 Production workstations Denver: 0 Atlanta: 15 Chicago: 15 JD Edwards EnterpriseOne release Deployment tier E900 Denver: 1 Atlanta: 2 Chicago: 2 Path codes Denver: PD900, PY900 Atlanta: PD900 Chicago: PD900, PY900
Define the deployment locations. Define the deployment locations on the deployment server (DENSVR1 in this example). Use Oracle's JD Edwards EnterpriseOne Deployment Locations Application program (P9654A) to define all deployment locations. For this case study, complete these fields to define three locations, one for each deployment location in Denver, Atlanta, and Chicago:
Field Location
Value Enter the name of the deployment location. In this case study, you assign these names for each physical deployment location: Denver, Atlanta, and Chicago.
Description
Enter a description (any value up to 30 characters) for each deployment location; for example: Denver: Denver - Tier 1 Atlanta: Atlanta - Tier 2 Chicago: Chicago - Tier 2
Location Code
Value Enter the name of the parent location for the location that you are adding; for example, Corporate.
2.
Create deployment server definitions. Use the JD Edwards EnterpriseOne Deployment Locations Application program (P9654A) to create a definition for each deployment server at the deployment locations that you created. For this case study, you need to define a deployment server for Atlanta and Chicago. The deployment server in Denver is already defined because it is the primary (tier 1) server. For this case study, complete the fields on the Deployment Server Revisions form as described in this table:
Value Enter the name of the physical machine. In this case study, enter these values: Denver: DENSVR1 Atlanta: ATLSVR1 Chicago: CHISVR1
Description
Enter a description (any value up to 30 characters). For example, Multitier Deployment - Denver.
Release
Enter the primary user for the machine that you entered. Enter the name of the shared directory for the path code in which system files and other files reside. For example, \E900.
3.
Schedule the package. Schedule the package to be deployed from the tier 1 deployment server to the tier 2 deployment servers through the JD Edwards EnterpriseOne Deployment Director program (P9631) or Multi Tier Deployment batch program (R98825C).
See Also:
definition. When you add a new deployment server definition, the system creates a record in the F9654 table for each deployment location. Each server at each deployment location must be defined. Typically, the table contains one record for the primary deployment server and one record per deployment location for each release. If you have multiple releases, you must create multiple records for the servers at each deployment location. If you used Oracle's JD Edwards EnterpriseOne Remote Location Workbench to create deployment server definitions when you installed the software, you do not need to define deployment servers again. In many situations, you might need to modify the definition for a deployment server that you already defined. For example, you would need to change the definition if the server share path or release changes, or if you want to designate a different server as the primary deployment server. The process for revising an existing deployment server definition is similar to the process for adding a new definition.
See Also:
Working with Installation Workbench in the JD Edwards EnterpriseOne Application Release 9.0 Installation Guide.
10.2.2 Prerequisites
Before you complete the tasks in this section:
Ensure that you understand the CNC concepts that enable you to define and implement packages, workstation installations, path codes, central objects, replicated objects, and user profiles. Ensure that adequate disk space exists on the disk drive for the machine that you will be using as a tier deployment location. Each full package that you deploy adds approximately 1.4 GB. The amount of required disk space varies, depending on the amount of data that you replicate to a Supported Local Database.
If you are adding a new definition for a deployment server at a remote location, you first need to define that location.
Note:
It is recommended that you do not define deployment locations with a DEV path code. The DEV path code is normally associated with developers who are not located at remote locations.
Enter the name of the machine on the network in the Machine Name field. Because you are entering a definition for a server other than the primary deployment server, the Primary Deployment Server field is not available. You can enter this field only if you first delete the definition for the current primary deployment server.
2. 3. 4.
Enter the release number as defined in the release master in the Release field. Enter the primary user for the listed machine in the Primary User field. Enter the shared directory for the path code in the Server Share Path field. The objects that are stored on a file server will be found in this path.
5. 6.
Select Path Code from the Form menu. On the Machine Path Code Revisions form, enter the path code for the primary or base location from which the secondary location will receive the package. When you enter the path code, the server share path will use the base server share path as the default for that machine.
Note:
You must specify the path code for each deployment server at all secondary locations. If you do not indicate the path code, multitier deployment may not work.
7. 8.
If the package includes a user-defined foundation or data, specify those items by selecting Foundation or Data from the Form menu. On the Deployment Server Revisions form, click OK.
Modify any of these fields: Description Release Primary User Server Share Path Primary Deployment Server If you are modifying the primary deployment server, you can also change the primary deployment server. For any other server, you cannot change the value in this field. Enter 1 to indicate that the deployment server is the primary deployment server. You can have only one primary deployment server.
2. 3.
Select Path Code from the Form menu. On the Machine Path Code Revisions form, enter the path code for the primary or base location from which the secondary location receives the package. When you enter the path code, the system displays the default server share path, which is the base server share path for that machine.
Note:
You must specify the path code for each deployment server at all secondary locations. If you do not indicate the path code, multitier deployment might not work.
4. 5.
If the package includes a user-defined foundation or data, specify those items by selecting Foundation or Data from the Form menu. On the Deployment Server Revisions form, click OK.
See Also:
Distribute software through package deployment. Schedule packages for multitier deployment. Distribute software through the multitier deployment batch process. Copy workstation installation programs to deployment locations.
Multi Tier Deployment batch application to distribute the software to deployment locations. Whether you push or pull the software depends on the machine on which you run the deployment function or batch program for the scheduling program. You push the software if you run the program or report on the primary deployment server or from a workstation. Conversely, you pull the software if you run the program from a workstation at the tier deployment location. In either case, execute the application on the primary deployment server machine for push installation or the destination deployment location for pull installation.
Important: If you push the software, you must have full read and
write privileges for both deployment servers (that is, the primary deployment server and the tier deployment location or destination machine), even if you do not run the batch application. If you do not have read and write authority on both servers, the deployment will fail. After the package software is distributed through the JD Edwards EnterpriseOne Deployment Director program or Multi Tier Deployment batch program, you must manually copy the workstation installation programs from the primary deployment server to the tier deployment location. These programs are located in the client portion of the base installation directory.
Select the Machines option, and then click Find. Select the deployment server to which you want to deploy. If you have scheduled to deploy packages to more than one deployment server, you can select the Deployment Server folder to deploy to all applicable servers rather than deploying to each individual server.
3.
Select the deployment server name to deploy all packages that are listed under the server name. Alternatively, select only the package that you want to deploy.
4.
From the Row menu, select Deploy. This option launches Oracle's JD Edwards EnterpriseOne Multi Tier Deployment batch program (R98825C), which enables you to deploy to deployment servers. You can also use this option to launch a batch application that deploys enterprise server packages. Therefore, if you select an enterprise server name or the Enterprise Server folder on the Work With Package Deployment form, Oracle's JD Edwards EnterpriseOne Enterprise Server Deployment batch program (R98825D)not the Multi Tier Deployment batch programlaunches. When you select a workstation, the Deploy option is not available.
When you create a distribution schedule, remember that you cannot schedule multiple packages to deploy at the same time.
Enter R98825C in the Batch Application field and click Find. Select the Multi Tier Deployment version that you want to use. On Version Prompting, click Submit. On Report Output Destination, select one of these options and click OK: On Screen Printer
1.
Connect to each deployment location and use Microsoft Windows Explorer to drag this client directory to the tier 2 workstation:
\\Tier1DeploymentServerName\E900\OneWorld Client Install
2.
Open the package.inf file and locate the [FileLocations] section. Change the PackageInfs line to reflect the machine name of the deployment server and the environment at the deployment location; for example:
PackageInfs=\\machine name\environment\ENVIRON\Evapps\appl_pgf\package_inf
3. 4.
Save your changes by selecting Save from the File menu. Select Exit from the File menu.
In the case of multitier deployment, the client installation program resides on the tier deployment location in the client subdirectory that is subordinate to the base installation directory. The workstation that is attached to the deployment location must have read access to this directory on the deployment location to install the workstation package.
See Also:
Installing the Workstations for Developers and System Administrators in the JD Edwards EnterpriseOne Application Release 9.0 Installation Guide.
Foundation and data. Subdirectories of the package name directory: bin32 include lib32
ServerPackage.inf file in the server build directories: The package.inf file. The pack directory that is subordinate to the package name directory.
When server-only builds are deployed without client builds, only the pack subdirectory is copied. This table describes where major package components are copied from and to during the deployment process; the server share path is derived from the F9651 table:
Package Component Package Copied From The path indicated in the SrcDirs section of the package.inf file. The path indicated in the SrcDirs section of the package.inf file. Copied To <server share path>\<path code>\<package name> on the destination deployment server. <server share path>\systemcomp on the destination deployment server if the default location is selected.
Package.inf file
The path indicated in the <server share path>\package_inf F00942 table if the source on the destination deployment deployment server is the server. primary deployment server in the base location. Otherwise, the path to the package.inf file in the F9651 table.
SrcDirs Attributes
DeploymentServerName Location
The package.inf file is not copied when you deploy to a deployment server in the base location.
10.4.2 Prerequisite
Assemble and build the server package.
Select the Deployment Server option. On the Package Deployment Attributes form, enter the deployment date and time, and select deployment options. On the Deployment Server Selection form, enter the machine name to which you want to deploy the server package. Select the machine by double-clicking the row header.
4.
On the Build Selection form, select the build (or version) of the package that you want to deploy by double-clicking the row header. Because of the Smart Deployment feature, the system enables you to select only the package builds that match the configuration at the destination location. For example, if package builds exist for an IBM i and a Solaris but the destination location has only a Solaris, you cannot select the IBM i build.
5. 6.
Click Close to exit the Build Selection form. On the Work With Package Deployment form, click End to finish the server package scheduling process.
See Also:
A
A
Section A.1, "Understanding Security Overrides for Package Build" Section A.2, "Adding a System User for the Owner of the Central Objects Data Source" Section A.3, "Creating a Role for Package Build" Section A.4, "Adding a Security Override for the Package Build Role" Section A.5, "Adding the Package Build Role to the User Running the Package Builds"
The database that you are using is Oracle, SQL, or IBM DB2 for LUW (Linux, UNIX, Windows). The security server is enabled.
A security override is required so that the package build process can create the metadata repository tables in central objects. To add a security override, a security administrator must first add a system user for the owner of the central objects data source, create a role for package build, add a security override for the package build role, and finally, add the package build role to the user who will be doing package builds.
A.2 Adding a System User for the Owner of the Central Objects Data Source
To add a system user for the owner of the central objects data source: In JD Edwards EnterpriseOne Solution Explorer, enter P98OWSEC in the Fast Path.
1. 2. 3. 4.
On Work with User Security, from the Form menu, select Add System User. On Work with System Users, in the System User field, enter the appropriate data source owner, for example DV900. Click the Find button. If no values are returned, add the data source owner as a system user:
a.
b. c. 5.
On System User Revisions, complete these fields: System User, Data Source, Password, and Password Verify. Click OK and then click the Cancel button.
Click the Close button to return to the Work with User Security form.
On the Work with User/Role Profiles form, select Add Role from the Form menu. Enter a value in the Role field, such as PKGBLD, and the description field, and save the new role record.
On Work with User Security, enter the role you just created for running package build, such as PKGBLD, and then click the Find button. From the Form menu, select Add Data Source. On Add Data Source, complete these fields: Role Data Source System User
A.5 Adding the Package Build Role to the User Running the Package Builds
To add the package build role to the user running the package builds:
1. 2. 3.
Open the Role Relationships (P95921) application. Search for the JD Edwards EnterpriseOne user who will be running the package builds. Add the new package build role, such as PKGBLD, to his assigned roles.
Note:
For IBM i, either sign in as a user who has rights to create tables in the central objects library, or follow the steps to set up a security override for the JD Edwards EnterpriseOne user. When the JD Edwards EnterpriseOne user connects to the data source, the user connects as a system user (IBM i user profile) who has update rights to the library.
Glossary
Build Configuration File Configurable settings in a text file that are used by a build program to generate ANT scripts. ANT is a software tool used for automating build processes. These scripts build published business services. check-in repository A repository for developers to check in and check out business service artifacts. There are multiple check-in repositories. Each can be used for a different purpose (for example, development, production, testing, and so on). control tables merge A process that blends a customer's modifications to the control tables with the data that accompanies a new release. embedded event rule An event rule that is specific to a particular table or application. Examples include form-to-form calls, hiding a field based on a processing option value, and calling a business function. Contrast with the business function event rule. Location Workbench An application that, during the Installation Workbench process, copies all locations that are defined in the installation plan from the Location Master table in the Planner data source to the system data source. Object Librarian Merge A process that blends any modifications to the Object Librarian in a previous release into the Object Librarian in a new release. Package Workbench An application that, during the Installation Workbench process, transfers the package information tables from the Planner data source to the system-release number data source. It also updates the Package Plan detail record to reflect completion. serialize The process of converting an object or data into a format for storage or transmission across a network connection link with the ability to reconstruct the original data or objects when needed.
Glossary-1
Specification merge
Specification merge A merge that comprises three merges: Object Librarian merge, Versions List merge, and Central Objects merge. The merges blend customer modifications with data that accompanies a new release. Versions List merge The Versions List merge preserves any non-XJDE and non-ZJDE version specifications for objects that are valid in the new release, as well as their processing options data. vocabulary override An alternate description for a data dictionary item that appears on a specific JD Edwards EnterpriseOne form or report. workgroup server A server that usually contains subsets of data replicated from a master network server. A workgroup server does not perform application or batch processing.
Glossary-2
Index
A
activating a scheduled package, 7-20 activating packages, 4-12 Assemble Business Services form JAX-RPC, 8-7 JAX-WS, 8-10 assembling packages adding a database, 4-7 adding a new foundation location, 4-7 adding features to a package, 4-8 assembling a new package, 4-5 reviewing package assembly selections, 4-9 understanding the process, 4-1 using the Package Assembly Director, 4-1 verifying a path code, 4-3 with business services, 8-12
C
Client Package Build Log, 6-37
D
Database Component Selection form, 4-7 defining a package build, 6-6 defining machines, 7-5 deployment APP-only packages, 7-3 groups, 7-9 locations, 7-3, 10-7, 10-8, 10-10, 10-11 multitier, 10-1, 10-2, 10-4 multitiered locations, 7-3 multitierfeatures, 10-3 parameters, 7-4 revising options, 7-19 scheduling, 7-16 to business services server, 8-18 to servers, 7-2 to workstations from CD, 7-3 two tier, 10-3 two-tier strategy, 10-3 UBE-only packages, 7-3 understanding, 7-1 workstations with JD Edwards EnterpriseOne, 7-2 workstations without JD Edwards EnterpriseOne, 7-2 Deployment Client Workstation Selection form, Deployment Director understanding, 7-11 using, 7-13 Deployment Group Revisions form, 7-9 Deployment Groups Selection form, 7-18 Deployment Location Selection form, 7-18 deployment methods comparing deployment methods, 2-11 cumulative and noncumulative update packages, 2-10 deploying various object types, 2-11 multitier deployment, 2-10 package deployment, 2-10 using Just-in-Time Installation (JITI), 2-13 deployment server, 10-2
B
batch application, scheduling the push installation batch application, 7-34 build changing status, 6-38 history, 6-4 options, 6-12 Build Selection form, 7-17 build verification, processing options, 6-8 building business functions, 6-4 BusBuild, 6-4 Business Function Errors Log, 6-38 business functions, buildspackage builds,servers, iSeries server build, 5-20 business functions, buildspackage builds,servers, UNIX server build, 5-17 business functions, buildspackage builds,servers, Windows server build, 5-18 business services, 8-1 assembling a package with, 8-12 assembling for package build JAX-RPC, 8-7 JAX-WS, 8-10 building a package JAX-RPC, 8-13 JAX-WS, 8-15 deploying a package with, 8-18
7-17
Index-1
Deployment Server Revisions form, 10-9 development process defining a typical development process, 2-8 developing short-term changes, 2-9 working with the normal development process, 2-8 distributing software through the scheduling application, 10-11 distributing software to deployment locations, 10-11
multitier deployment case study, 10-5 features, 10-3 implementation, 10-3 terminology, 10-2 understanding, 10-1
O
objects backing up and restoring objects, 3-4 correlating replicated and central objects, 3-5 moving objects, 3-2 batch applications (UBE), 3-3 business services, 3-4 business views (BSVW), 3-2 C business function (BSFN), 3-3 data structures (DSTR), 3-3 embedded event rules, 3-3 interactive applications (APPL), 3-3 media objects (GT), 3-3 NER business functions, 3-3 tables (TBLE), 3-2 preserved after an upgrade, 3-7 replaced after an upgrade, 3-7 understanding objects, 3-1
E
Enterprise Server Selection form, 7-17
F
Feature Component Selection form, 4-8 features, 5-21 Foundation Component Selection form, 4-7 Foundation Item Revisions form, 4-7 foundation location, 4-7
I
installing a scheduled package, 7-14, 7-21
J
jde.ini, 5-5
P
package activating a scheduled package, 7-14, 7-20 build definition, 6-6 build history, 6-4, 6-36 build process overview, 6-2 build processing options, 6-8 build resubmissions, 6-4, 6-41 deploying, 7-26 deployment groups, 7-9 installing a scheduled package, 7-14, 7-21 package activation, 4-12 Package Build Director, 6-9 package build history, 6-36 package builds building a client update package, 5-2 building a full client package, 5-1 building a full server package, 5-2 understanding the build process, 6-1 package builds, files created business function builds, 5-16 workstation builds, 5-16 package builds, servers iSeries server build, 5-20 understanding, 5-16 UNIX server build, 5-17 Windows server build, 5-18 package builds, workstations, 5-8 Package Deployment Attributes form, 7-16 Package Deployment Targets form, 7-16 package INF files, 5-9 package management
L
listener definition, 7-28 installing, 7-29 installing using silent installation, 7-30, 7-32 stopping, 7-33 Location Revisions form, 7-8 logs Business Function Errors, 6-38 Missing Business Function Source Errors, 6-38 Package Build, 6-37 Package Statistics, 6-37
M
machines, defining, 7-5 Missing Business Function Source Errors Log, 6-38 modification rules application text, 3-11 business functions, 3-14 business views, 3-12 control tables, 3-12 data structures, 3-14 event rules, 3-13 interactive applications, 3-8 reports, 3-10 table specifications, 3-11 types of modifications, 3-6 versions, 3-15 Monitor Deployment form, 7-26
Index-2
defining roles, 2-1 managing processes, 1-1 object change tracking, 2-5 understanding packages, 2-2 package naming conventions, 2-6 package revisions, 4-11 Package Selection form, 6-9, 7-16 Package Statistics Log, 6-37 package types full client packages, 2-3 full server packages, 2-3 update client packages, 2-4 update server packages, 2-5 packages business services, 8-1 path codes creating recommended path codes, 2-6 using in the development process, 2-8 using in the production environment, 2-7 production environment, integrity, 2-7 push installation preparing the enterprise server, 7-30 preparing workstations, 7-29, 7-30, 7-31, 7-32, 7-33 scheduling a package, 7-34 scheduling the push installation batch application, 7-34 status codes, 7-36
T
tier deployment location, 10-2 tier workstations, 10-2 two tier deployment, example, 10-3
V
Version Prompting form, 10-12 viewing logs, 6-36, 6-40
W
Work With Package Build Definition form, 6-9 Work with Package Deployment form, 7-18, 7-20 workstation installation, objects moved, 3-2 workstation packages building specifications and business functions, 5-8 installing on a workstation, 5-8
R
Report Output Destination form, 10-12 resubmitting builds, 6-4, 6-41 revising a deployment group, 7-10 revising a package, 4-11 revising a package's build options, 6-12
S
scheduling application, distribution, 10-11 Server Package Deployment Properties Revisions form, 7-19 server packages deploying, 7-26 deploying to web servers, 7-24 deployment, 7-22 deployment monitoring, 7-26 describing server packages, 5-4 server package build process, 5-4 settings in jde.ini, 5-5 source code for Sun servers, 5-8 spec.ini, 5-7 software distributing, 10-11 distributing to deployment locations, 10-11 spec.ini, 5-7 status codes, push installation, 7-36 Sun platform, 5-8
Index-3
Index-4