5 Understanding the Package Build Process

This chapter contains the following topics:

How the System Builds Packages
Server Packages
Workstation Packages
Files Created by the Build Process
Features

How the System Builds Packages

This section discusses:

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 mobile package.
How the JD Edwards EnterpriseOne system builds an update mobile package.
How the JD Edwards EnterpriseOne system builds a full server package.
How the JD Edwards EnterpriseOne system builds an update server package.

How the System Builds a Full Client Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full package. The JD Edwards EnterpriseOne system:

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
- mobileDB
- pack
- spec
- mobilespec
- pkgspec
Note:
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.
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.

How the System Builds an Update Client Package

This is an overview of how the JD Edwards EnterpriseOne system builds an update package. The JD Edwards EnterpriseOne system:

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.

How the System Builds a Full Mobile Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full mobile package. The first five steps are the same as a full client package. The JD Edwards EnterpriseOne system:

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
- mobileDB
- pack
- java
- spec
- mobile spec
- pkg spec
Note:
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.
Builds the local spec repository based on the central objects.
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.
Builds the mobile specs.
Builds the mobile DB (databases).
Builds the mobile.inf file.
Compresses the package.

How the System Builds an Update Mobile Package

The process for creating a mobile update package is similar to creating a regular update package. A mobile update package is created automatically based on the parent package. If the selected parent package was marked as mobile, a mobile update package is automatically built for every update package.

How the System Builds a Full Server Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full server package. The JD Edwards EnterpriseOne system:

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
- mobileDB
- pack
- spec
- mobile spec
- pkg spec
Note:
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.
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.
Copies specs from the build machine/deployment server to the spec data source.
Compresses the .dll, .so, .sl, and .SRVPGM files.
Copies the compressed files from the enterprise server to the deployment server.

How the System Builds an Update Server Package

The steps for a server update package are the same as the first five steps for building a full server package. However, specs for a server update package are merged directly with the live package during package deployment.

Server Packages

This section discusses:

A description of server packages.
The server package build process.
Jde.ini settings for server package builds.
Spec.ini settings.
Source code for Sun servers.

A Description of Server Packages

A server package is a group of specification records, source files, header files, and compiled objects that are created on the enterprise servers. A server package is essentially the same as a client workstation package, with these exceptions:

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).

The Server Package Build Process

Although creating a server package is identical to creating a client workstation package, you create each for different purposes. Server packages are necessary to transfer specifications and business functions to the enterprise servers.

Oracle's JD Edwards EnterpriseOne Package Build program (P9621) provides these benefits for building server package builds:

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 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:

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-iSeries platform. This function is performed by the QBATCH subsystem on an iSeries 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.

Jde.ini Settings for Server Package Builds

If the server package includes business functions, the Build Settings within Server Manager apply to the package. This table describes various build settings:

Setting	Value	Purpose
Build Area	/usr/jdedwards/E900/packages	Indicates the location on the server where the package will be built.
Optimization Flags	+02 (default for HP 9000) -02 (default for RS/6000 and ;Sun)	Varies, depending on the platform. The system uses these compile flags to build business functions in Release mode. You should not change these flags.
DebugFlags	-g -D_DEBUG _DJDEDEBUG (default for HP 9000) -g -qfulpath -qdbextra -D_DEBUG -DJDEDEBUG (default for RS/6000) -g -D_DEBUG -DJDEDEBUG (default for Sun)	Varies, depending on the platform. The system uses these compile flags to build business functions in Debug mode. You should not change these flags.
InliningFlags	blank (default)	Indicates whether the iSeries uses inlining. Enter Yes to select inlining on the iSeries. Enter No to turn it off. This flag is blank or ignored for non-iSeries servers.
DefineFlags	-DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT -D_HPUX-SOURCE (default for HP 9000) -DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT (default for RS/6000) -DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT -D_SUN-SOURCE (default for Sun)	Indicates the Kernel Production Version of the source for HP, RS, and SUN.
CompilerFlags	-Aa +w1 +z -c (default for HP 9000) -qalign=natural -qflag=I:I -c (default for RS/6000) -qspill=1024 -misalign -KPIC (default for Sun)	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.
OSReleaseLevel	+DAportable -q32 (for AIX)	Indicates the release level for which you are compiling the package. You should not change these flags.
LinkFlags	-b -z (default for HP 9000) -bl:/<your system directory>/bin32/functlist.imp -bM:SRE -bexpall -brtl -lc -bnentry -L. L/usr/<your system directory>/lib -ljdelib -ljdekrnl -ljdenet -bloadmap:loadmap (default for RS/6000) -G -L$(ORACLE_HOME)/lib (default for Sun)	Varies, depending on the platform. The system uses these flags to link business functions. You should not change these flags.
LinkLibraries	blank (default)	Indicates the libraries to which business functions are linked. (Applies to Windows and iSeries servers only.)
SimultaneousBuilds	0 (unlimited) (default) any integer (number of simultaneous builds)	Indicates the number of DLLs that can be built at a time. Zero means that all will be built simultaneously.
Qname	queue name	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.
<compiler values>	Any compilers installed on the system will be retrieved from the registry and shown in a pull-down list. (Microsoft Windows platform)	Indicates the compiler level to use for builds. With Tools Release 8.98, the JD Edwards EnterpriseOne application release supports one of two Microsoft Visual C++ compilers. For example, JD Edwards EnterpriseOne 8.12, 8.11_SP1, and 8.11 support both Microsoft Visual C++ 2003 v7.1 and 2005 v8.0 compilers.

Spec.ini Settings

All JD Edwards EnterpriseOne servers and WIN32 clients require a spec.ini file to retrieve the package and spec data source information. This file is created by the Package Build process. It resides in the spec directory.

This table describes the settings within the SPEC LOCATIONS section of the spec.ini file:

Setting	Value
path code_Package	Indicates the name of the package.
path code_DataSource	Indicates the database data source that is used to retrieve the spec information.

Source Code for Sun Servers

The Sun Solaris compiler expects a newline character at the end of every source code file that it compiles. If the compiler does not find this newline character, it rejects the line and displays a warning message. In some cases, this line rejection and message might cause the package build to fail.

If you develop custom modifications on Sun servers that use the Solaris operating system, you must ensure that this newline character is present in the compiled source code before you assemble, define, and build packages that contain the modifications. This step helps ensure that the package build process finishes successfully.

In some cases, the system automatically adds the newline character, and you do not need to add it manually. If you edit source code in the UNIX environment using an editor such as VI or emacs, these editors automatically add the newline character. Also, all of the source code files for business functions include the newline character.

However, editors that are included with PC workstations typically do not add the newline character. Therefore, if you edit source code on a PC workstation and then transfer the file to the server for compiling, verify that the newline character exists in the source code.

Workstation Packages

This section discusses:

Workstation installation.
Building specifications and business functions.
Defining the compiler level.
Verifying UNICODE settings.
Package INF files.

Workstation Installation

A typical full workstation installation takes more than 1.4 GB of disk space and can take 10 to 30 minutes to install, depending on network traffic. A workstation configuration contains the full suite of applications, including those that the user rarely or never uses, but all applications are available immediately.

Building Specifications and Business Functions

If you build a full client package that includes both business functions and specifications, add the following setting to the [INSTALL] section of the workstation jde.ini file on the computer that you use to build the packages:

WaitForBusbuild=Y/N

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.

An N means that specs and business functions are built simultaneously, which can speed up the build process.

Defining the Compiler Level

If you have more than one version of Microsoft Visual C++ on your machine, add one of the following settings to the [JDE_CG] section of the workstation jde.ini file on the computer that you use to build the packages:

VisualStudioVersion=6

VisualStudioVersion=7

VisualStudioVersion=8

Use the first setting if you are using the Microsoft Visual C++ v6.0 compiler, the second setting if you are using the Microsoft Visual C++ 2003 v7.1 compiler, and the third setting if you are using the Microsoft Visual C++ 2005 v8.0 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.

Verifying UNICODE Settings

If you are upgrading from Xe and you have modified any interactive or batch applications that contain NERs and that are language-enabled, you must ensure that the following setting is in the [INSTALL] section of the workstation jde.ini on the computer that you use to build the packages:

Unicode Conversion Codepage=<code_page_value>

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.

Package INF Files

The Package INF file is essentially the interface between the package build and Oracle's JD Edwards EnterpriseOne Workstation Installation program. The INF file defines the components that are included in the package, the source and destination paths for those components, and the attributes that are needed to install the package.

The INF file is created during the package build process and is stored in its own package_inf directory, based on the release master directory. JD Edwards EnterpriseOne Workstation Installation reads the INF file for the package that it is installing to determine which components are loaded to a workstation, as well as their locations.

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]

[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\PACKAGE\ DV900FA	Indicates the location of the package that the 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.
SPathcodeDATA=\\MachineName\E900\ DV900\PACKAGE\DATA	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.

[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	Purpose
DPathcode=%INSTALL\path code	Indicates the destination directory for the package.
DSYS=%INSTALL\system	Indicates the destination directory for system files. This item appears only when included in the package.
DPathcodeDATA=%INSTALL\path code\data	Indicates the destination directory for the database. This item appears only when included in the package.

[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	Purpose
Pathcode1=Y, $Spathcode\bin32, $Dpathcode\bin32	Indicates the bin32 directory that is subordinate to the path code.
Pathcode2=Y, $Spathcode\spec, $Dpathcode\spec or Pathcode2=Y,$Spathcode\mobilespec, $Dpathcode\mobilespec	Indicates the spec directory that is subordinate to the path code. Indicates the mobile spec directory that is subordinate to the path code.
Pathcode3=Y, $Spathcode\include, $Dpathcode\include	Indicates the include directory that is subordinate to the path code.
Pathcode4=Y, $Spathcode\lib32, $Dpathcode\lib32	Indicates the lib directory that is subordinate to the path code.
Pathcode5=Y, $Spathcode\obj, $Dpathcode\obj	Indicates the obj directory that is subordinate to the path code.
Pathcode6=Y, $Spathcode\source, $Dpathcode\source	Indicates the source directory that is subordinate to the path code.
Pathcode7=Y, $Spathcode\work, $Dpathcode\work	Indicates the work directory that is subordinate to the path code.
Pathcode8=Y, $Spathcode\make, $Dpathcode\make	Indicates the make directory that is subordinate to the path code.
Pathcode9=Y, $Spathcode\res, $Dpathcode\res	Indicates the res directory that is subordinate to the path code.
Pathcode10=Y,$Spathcode\sbf.cab, $Dpathcode\java	Indicates the java directory that is subordinate to the path code.
SYS=Y,$SSYS\System.cab, $DSYS	Indicates the compressed system database that the package build generates.
PathcodeDATA=Y, $SpathcodeDATA\data.CAB, $DpathcodeDATA	Indicates the compressed data database that the package build generates.

[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

[Components]

These settings indicate the location of the foundation, production, and development objects, as well as the database files.

Item	Purpose
Production Objects=APPL_PKG1, APPL_PKG2, APPL_PKG3	Indicates the location of production objects.
Development Objects=APPL_PKG4, APPL_PKG5, APPL_PKG6, APPL_PKG7, APPL_PKG8, APPL_PKG9	Indicates the location of development objects.
Foundation=SYS	Indicates the foundation location.
Data=pathcode DATA	Indicates the database location.

[Typical]

This section describes the setting for a typical development user.

Item	Purpose
Name=Development	Indicates that the package is for a development user.
Description=Install the development objects	Indicates the package description.
Components=ProdObj, DevObj, Foundation, Data	Indicates that the package should contain both production and development objects, as well as the database and foundation.

[Compact]

This section describes settings for a typical production user.

Item	Purpose
Name=Production	Indicates that the package is for a production user.
Description=Install the production objects only	Indicates the package description.
Components=Production Objects, Foundation, Data	Indicates that the package should contain only production objects, as well as the database and foundation.

[Attributes]

This section contains information about the current release, global tables, specification and help files, and the jde.ini file.

Item	Purpose
PackageName=DV900FA	Indicates the name of the package.
PathCode=DV900	Indicates the path code for which the package is being built.
Built=Build Completed Successfully	Indicates the package status. A status of 50 or 70 means that the package is ready for installation.
PackageType=Full	Indicates the package type: full or update.
SPEC_FORMAT=XML	Indicates the format for the specifications.
Release=E900	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.
BaseRelease=B9	Indicates the current base release.
SystemBuildType=RELEASE	Indicates the type of build: DEBUG or RELEASE. This option is retrieved from owver.dll.
MFCVersion=6	Indicates the version of the MFC compiler.
SpecFilesAvailable=Y	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.
DelGlbTbl=Y	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.
ReplaceIni=Y	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.
AppBuildDate=Mon Jul 20 11:22:22 2008	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.
FoundationBuildDate=Wed Jun 03 15:08:34 2008	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.
DataBuildDate=Wed Jun 03 15:08:34 2008	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.
DeploymentServerName=DENMLSAN222	Indicates the name of the deployment server.
Location=DENVER	Indicates the location of the deployment server.
DeploymentStatus=Approved	Indicates the package deployment status.
PackageDescription=Development full package A	Indicates the package description.
Icon Description=JDEdwards	Describes the desktop icon.
Default Environment=DV900	Indicates the default environment.
AllPathCodes=Y	Indicates that a package for *ALL path codes exists when set to Y.
Mobile=	Indicates whether the INF file is for a mobile package . This option is set to Y when the INF is for a mobile package.
Spec=	Indicates the format of the specifications with these values: 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).

[Oracle Databases]

This section contains information about the Oracle databases.

Item	Purpose
JDELocal_DV900=ORACLE	Indicates the local Oracle database.
SPEC_DV900FA=ORACLE	Indicates the Oracle database.

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
Server=127.0.0.1
DataFileDestDir=$DDV900\Spec\SPEC_DV900FA.dbf
DumpFileDestDir=$DDV900\Spec\SPEC_DV900FA.dmp

[START]

This section contains startup information:

[START]
ProgramGroupName=JDEdwards
Item1=System\Bin32\activConsole.exe, JDEdwards Solution Explorer, appl_pgf\res\One⇒
World.ico

[Desktop]

This section contains desktop information:

[Desktop]
Item1=System\Bin32\activConsole.exe, JDEdwards Solution Explorer, appl_pgf, res⇒⇒
\OneWorld.ico

[Environment]

This section contains environment information:

PathDV900=%INSTALL\DV900\bin32;
PathSys=%INSTALL\system\bin32;

[Fonts]

This section contains font information:

[Fonts]
Arial=Font\arial.ttf

[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

Files Created by the Build Process

This section discusses:

Workstation package build
Server package build
UNIX server build
Windows server build
iSeries server build

Workstation Package Build

Business function dynamic linked libraries (DLLs) on workstations are grouped by related business functions. This grouping limits the size and number of procedures that are contained in each DLL. Grouping prevents memory allocation errors and avoids the platform limitations that can occur when you export too many procedures from the same DLL.

The production environment PD900/bin32 directory contains the DLLs that are created on the workstation. All of the business function source files are in the PD900/source directory.

Files Created by a Business Function Build

When you build a single business function through Oracle's JD Edwards EnterpriseOne Object Librarian, the Business Function Builder program uses the make (*.mak) file that is generated at runtime, and creates or copies these files and builds the business functions into their respective DLLs:

Source file (*.c)
Header file (*.h)
Object file (*.obj)

You must use the jdecallobject API to call a business function from a business function.

These files are created for NER business functions:

OBJNAME.c
OBJNAME.h
OBJNAME.obj

These files are created for table event rules:

OBJNAME.c
OBJNAME.hxx
OBJNAME.obj

Server Package Build

Server package builds are used to move path code objects from the deployment server to enterprise server platforms. Server package builds are initiated when you create 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.

UNIX Server Build

This topic describes the files that the system creates when it builds business functions on a UNIX server.

Files Created by a Business Function Build

When you are building business functions, these groups of source files are actually compiled:

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:

Source files (.c)
Header files (.h, .hxx)

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.

Where Business Functions Are Stored

On a UNIX platform, related business functions are grouped into shared libraries. This grouping limits the size and number of procedures that are contained in each shared library. Grouping prevents memory allocation errors and avoids platform-specific limitations in the number of procedures that you can export per shared library.

The exact location of the package is determined by the Build Settings within Server Manager.

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 HPUX) or .so (for AIX). An example is libccore.sl.

Specification Files

JD Edwards EnterpriseOne specifications are stored in an RDBMS. The database data source for this database is specified in the spec.ini file or is selected by the package build administrator during the server package build definition process. Package Build copies the specs directly from the build machine to the specified spec database. However, local cache (GLBLTBL, DDDICT, and DDTEXT) specification files are still created in TAM format. The contents in these files are destroyed when a new package is deployed.

Windows Server Build

This topic describes the files that the system creates when it builds business functions on a Windows server.

Files Created by a Business Function Build

When you are building business functions, these groups of source files are actually compiled:

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:

Source files (.c)
Header files (.h, .hxx)

When building business functions, the build process creates these file types:

Object files (.o)
Make files (.mak)
DLLs (.dll)

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.

Where Business Functions Are Stored

On Windows platforms, business functions are grouped into parent DLLs for related business functions. This grouping limits the size and number of procedures that are contained in each DLL. Grouping also prevents memory allocation errors and avoids platform-specific limits of exported procedures per DLL.

The exact location of the package is determined by the Build Settings within Server Manager.

Subordinate to the package directory (PD900FA) is a source directory. This source directory contains subdirectories for each DLL that is created on the enterprise server.

The directory structure looks like this example where the top directory is the package name:

PD900

source

CAEC

CALLBSFN

CCORE

CDESIGN

CDIST

CFIN

CHRM

CMFG

JDBTRIG

Each subdirectory contains all of the business function source files that belong to the DLL. All DLLs are installed in the PD900\bin32 directory. They have the same name as the DLL subdirectories, except that they have the .dll suffix.

Specification Files

iSeries Server Build

This topic describes the files that the system creates when it builds business functions on an iSeries server.

Files Created by a Business Function Build

When building business functions, the server package build creates these file types in a library with the package name in the QSYS file system:

*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 iSeries.
*FILE - Contains only logs about compiled business functions.

Where Business Function Source Members Are Stored

iSeries business function source and headers are now transferred to the Integrated File System (IFS). Server package build transfers objects to these subdirectories under the server package directory in the IFS for the iSeries.

The exact location of the package is determined by the Build Settings within Server Manager.

Subordinate to the package directory (PD900FA) is a source directory. This source directory contains subdirectories for each DLL that is created on the enterprise server.

The directory structure looks like this example where the top directory is the package name:

PD900FA

include

pack

source

CAEC

CALLBSFN

CCORE

CDESIGN

CDIST

CFIN

CHRM

CMFG

JDBTRIG

spec

text

This table describes the files that are found in the directories:

Directory	Description
`PD900\include`	This is the location where .h and .hxx source files are located. These objects are taken from the server and built on.
`PD900\pack`	This folder is no longer used but is created for backwards compatibility.
`PD900\source`	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.
`PD900\spec`	This folder is no longer used but is created for backwards compatibility.
`PD900\text`	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 (for example, "Using Microsoft Visual Studio Version 8").

Note:

After an upgrade, existing iSeries 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.

Specification Files

Features

This section discusses:

Defining features
Feature INF files

Defining Features

In addition to objects, you can also add a feature to a package. A feature is a set of files or configuration options that must be copied to a workstation or server to support an application or another function. Like objects, features are included in a package and deployed to the workstations and servers that require the feature components.

For example, you might need to add these items to a package: ActiveX controls, a Supported Local Database for the Sales Force Automation feature, ODBC data sources for use with Open Data Access, or Microsoft Windows registry settings.

You define a feature by using the JD Edwards EnterpriseOne Package Assembly program (P9601). You can then add the feature to a package by using the JD Edwards EnterpriseOne Package Assembly program (P9601) and Package Build Director program (P9621).

Feature INF Files

When a package contains features, a section called [Features] in the Package INF file includes both the feature name and a pointer to the Feature INF file that is created for each feature in the package. These Feature INF files provide specifications that tell the installation program the actions to perform during the installation.

The Feature INF file can include these sections:

[Header]
[Registry]
[INI]
[FileSets]
[Shortcut]
[ThirdPartyApps]
[ODBCDataSources]

This is a typical Feature INF file for which the sections contain specifications for each feature component.

[Header]

The header section contains general information about the feature and specifies the installation options for the feature.

Item	Purpose
Feature=	Name of the feature.
FeatureType=	Type of feature.
Description=	Text description of the feature.
Required=	A setting that indicates whether installation of the feature is required.
InitialChoice=	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. 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	InitialChoice
Required	Y	Both
Selected	N	Both
Deselected	N	Custom