Oracle Utilities Software Development Kit V4.4.0.2.x Installation Guide
Oracle Utilities Software Development Kit V4.4.0.2.x Installation Guide
PROPRIETARY INFORMATION
THIS MATERIAL CONTAINS, AND IS PART OF, A COMPUTER SOFTWARE APPLICATION
WHICH IS PROPRIETARY INFORMATION OWNED BY ORACLE CORPORATION. THE
APPLICATION, INCLUDING THIS MATERIAL, MAY NOT BE DUPLICATED, DISCLOSED OR
REPRODUCED IN WHOLE OR IN PART FOR ANY PURPOSE WITHOUT THE EXPRESSED
WRITTEN AUTHORIZATION OF ORACLE CORPORATION.
This Document is subject to change without notice, and Oracle Corporation does not warrant that
the material contained in this Document is error-free. If you find any problems with this Document,
please report them to Oracle Corporation in writing.
Oracle Corporation and Oracle are registered trademarks of Oracle Corporation or one of its
subsidiaries. All other products or company names mentioned are used for identification purposes
only, and may be trademarks of their respective owners.
Table of Contents
Table of Contents .......................................................................................................................... 3
Appendix ...................................................................................................................................... 27
Where is SPLSDKCommon? .................................................................................................. 27
Remove COBOL References .................................................................................................. 27
Suppressing Java Problems relating to undeclared serialVersionUID ................................... 28
Server does not start; unsupported lookup version ................................................................ 29
Setting up the Oracle Utilities SDK for a new Application Server ........................................... 29
Multiple CM Development and Deployment............................................................................ 30
Hardware Requirements
The following hardware configurations are per workstation.
Recommended
Windows 7
AMD64/x86-64, dual core CPU
8 GB RAM
40 GB hard drive space
Minimum
Windows 7
AMD64/x86-64, dual core CPU
4 GB RAM
20 GB hard drive space
Prerequisite Steps
Ensure that the following is done before continuing with the SDK setup program.
Create a development database for your application. All developers typically share this
database. Refer to the product installation guide for details.
Your application server must at least be running on JDK 1.8 (64-bit). The SDK will use
the same JAVA_HOME as your application server.
Install and configure a Windows application server (e.g. CCB, MDM, ETM, MWM, etc.) on
the developer’s computer. Refer to the product installation guide for details.
Note that this must be an “exploded” environment; the SDK does not update the archive
files (ear/war) for certain types of changes.
Perl should already be installed as a result of the application server installation. Check
the Windows executable PATH to make sure that the same Perl is used by the SDK
scripts. Windows commands “where perl” and “perl -version” can be used to verify that.
Perl v5.10.1 was used to certify this version of the SDK.
This version of the SDK was certified on Luna, which can be downloaded from the
following links. Earlier versions of Eclipse are also supported. The downloaded file will
be unzipped to the correct folder later.
64-bit:
http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release
/luna/SR2/eclipse-java-luna-SR2-win32-x86_64.zip
Client Setup
Run ClientSetup-4.3.0.0.x.exe to install the SDK. The installation wizard will prompt you for the
following information in the first input dialog:
SDK Folder: Specify the folder where you want the SDK will be installed. This is defaulted to
c:\ouafsdk_4_3_0_0_x. The SPLSDKROOT environment variable will hold this value. We
recommend that you keep this default so that you could distinguish between SDK
installations that are already installed in your workstation.
Application Server Folder: This is the folder where the Oracle Utilities Application Server
has been installed. ClientSetup will also obtain database information defaults from this folder.
The Eclipse workspace folder for this application server will also be created.
The installation wizard will obtain the JAVA_HOME and database logon information from the
application server’s ENVIRON.INI file.
Note: While ClientSetup would allow you to specify the SDK Folder to be the same as the
Application Server Folder, it is recommended that you DO NOT specify the same folder for both.
Also, the Oracle Client, Eclipse, Java, and Perl installations must be in 64-bit mode. The Oracle
Utilities Application Framework (v4.3.0) runs only in 64-bit bit mode.
The second input dialog will then prompt you to verify the defaulted database information:
Database Name: This defaults with the database name obtained from the
hibernate.properties file in the application server folders. Change only when if necessary.
Username: This defaults with the user id obtained from the hibernate.properties file in the
application server folders. Change if necessary.
Password: This defaults with the password obtained from the hibernate.properties file in the
application server folders. The password must be in clear text. Change if necessary.
When you have verified the database information, ClientSetup will proceed with the installation
and create a Program Group with shortcuts to the client scripts and Help library.
You may edit the setsplenv.bat file located in the environment specific “etc” folder of the Oracle
Utilities SDK installation folder (e.g. C:\ouafsdk_4_3_0_0_x\%SPLENVIRON%\etc) if you need to
make changes to the database information after the installation.
Running Eclipse
At this point, you should have downloaded Eclipse and hibernate-3.2.5.ga.jar. Have the zip file
name and jar location handy. Running Start Eclipse (from the Oracle Utilities SDK 4.3.0.0.x
Program Group) for the first time will set up the Oracle Utilities SDK for Eclipse for you. You just
need to provide the complete path to the Eclipse zip file and hibernate-3.2.5.ga.jar.
When Eclipse comes up, you should be all set to start an Oracle Utilities project.
Note: The URL can be copied from the application server’s hibernate.properties file – i.e.
%SPLEBASE%\splapp\standalone\config\hibernate.properties.
Click on the “New OUAF Project” to create a new Oracle Utilities project.
On the New Project dialog, supply a project name. Eclipse will create the project in the default
location. It will be named after the project name you entered. However, you could override this by
removing the check from the “Use default location” checkbox and entering your desired location.
Click Finish.
You may be prompted to switch to the Oracle Utilities perspective, but for now stay with either the
Java perspective or Java EE perspective.
You will be prompted to “Enter your CM Owner”. This is defaulted to “cm”. Accept this default for
now and click OK.
Note: You only need to change the default CM Owner if you are participating in the development
of a Multiple CM project. If you are, be sure to copy cm.jar (from CM Owner cm) to
%APPSVRDIR%\etc\lib and %APPSVRDIR%\splapp\standalone\lib before clicking Finish. If
you copied cm.jar after the fact, include a reference to it in the –appJars argument in your
project’s Generate Artifacts launch configuration. Multiple CM development is described in more
detail in the Appendix.
Wait for the New Project dialog to disappear and the project should be created similar to this (it
may take a few seconds). Note that the folder names are prefixed by an underscore (_). That is
because they are linked folders to the actual folders in the application server directory structure.
In addition, a set of new Run Configurations should have been created to run artifact generator
and development versions of ThreadPoolWorker and SubmitJob for batch testing. Open the Run
button drop down and click Run Configurations… to bring up the Run Configurations dialog.
Under Java Applications, you should see configurations to Generate Artifacts, to invoke Submit
Job (for batch programs), and to invoke the ThreadPoolWorker (for batch programs).
Running a configuration will register it in the launch history of the Run button drop down.
Note: When starting a ThreadPoolWorker in Eclipse, the Eclipse Console view might appear to
be stuck or not working. If so, edit the _config/ tpwlog4j.properties and change the rootCategory
property to include A1 (ConsoleAppender) – e.g. “log4j.rootCategory=info, F1, A1”
Customer Modifications
Customers Modifications (or CM) is code that is not shipped with the Oracle Utilities product. CM
is developed by the Oracle customer and is written to meet specific customer requirements. Any
new Oracle Utilities Project is a CM project and is a collection of algorithms, change handlers,
etc. To create these classes and interfaces, navigate to File, New, Other…, and then scroll down
to the Oracle Utilities section. Under Customizations are listed templates for classes and
interfaces. Select the type of object you want to create. Each type of object has its own
specialized wizard that would help you create a skeleton Java class in your workspace.
Deploying CM Code
Open the External Tools button drop-down and click Run Configurations… to bring up the
External Tools Configurations dialog.
From there, look for the Deploy CM that corresponds to your project under Ant Build. Click it and
then click the Run button at the bottom of the dialog. Eclipse will remember this run configuration
and will register it in the launch history of the External Tools button drop down. The output of the
Ant build will show on the Eclipse console.
Once deployed, reboot your local application server and you should be able to test your custom
code in the online application. If this is the very first deployment of cm.jar, the
cm_jar_structure.xml file may need to be created and the application server rebuilt as described
below.
Create cm_jars_structure.xml
If your application server never had CM code previously deployed to it, you may need to create a
cm_jars_structure.xml file in %APPSVRDIR%\structures. If it does not exist, this template can be
used to create it:
Open up a Command Prompt for your application server environment and run initialSetup. This
will rebuild and redeploy the application server to include your customizations.
Note that the initialSetup script uses this xml file to deploy your cm.jar to the appropriate
locations in the app server. On all subsequent deployments from Eclipse using the Deploy CM
launch configuration, initialSetup is not required as the Eclipse launch configuration will update
the necessary files.
Additional Pointers
Oracle Utilities SDK 4.3.0.0.x will use the spl-tools jar that is appropriate for your
application server. Ensure that the FW_VERSION_NUM entry in your application server’s
etc\ENVIRON.INI file specifies your Oracle Utilities Framework version.
Consider it a best practice to stop the instance of Weblogic (that is running your
application server) prior to deployment. This ensures the proper deployment of your
code.
The next time your run any of the shortcuts in the program group, the SDK will prompt you to for
an environment context under which the shortcut would run, for example:
The Command Prompt will run splenviron on the application server and will also initialize the SDK
environment. The current working folder should be the SDK shortcuts folder
(%SPLSDKROOT%\SDK\shortcuts).
Type “dir” to see all the available scripts.
Follow the prompts of the script you choose to run.
Note: In the SDK\Scripts\bin folder, the following scripts are obsolete: createCMEnv.pl and
switchenvironments.pl. The createCMEnv.pl script has been replaced by the
SDK\shortcuts\createNewEnv.bat script, which is launched using the Create Workspace shortcut
in the Oracle Utilities SDK program group. The switchenvironments.pl script is unnecessary
because the SDK now allows several Command Prompt windows to be opened under the context
of different application servers.
From the Eclipse main menu, the SDK documentation is available at Help Help Contents.
Supplementary Guide
This guide describes additional setup that may be necessary once the initial installation as
detailed above has been completed.
Development Project
Workstation Repository
Sync / Submit Code
Sy
st
em
D
at
a
Project
Dev DB
Development Environment
Development
Client
The following are both Development
Clients:
• Project Repository
• Development Workstation
Development Client
Project Repository
The project repository serves the following purposes:
It is the central storage for all completed, unit-tested code.
It provides the environment from which to build the latest state of the project.
It provides the latest state of the project dev app server from which all developers can
synchronize with.
It is the source for CM Packaging.
To support these purposes:
It has to be accessible to all developers.
It is set up as a development client, i.e., similar to a development workstation (see
Development Workstation below).
Development Workstation
Developers write, generate, compile, and test code on development workstations. A development
client is installed for each project that the developer works on.
The main components of a development client are the following:
Project Dev App Server. Code is developed on and executables built into the project dev
app server.
Oracle Utilities Software Development Kit Client. This is the primary development tool of
the Oracle Utilities Software Development Kit.
Eclipse SDK. This is the Java development tool used in the Oracle Utilities Software
Development Kit.
Packaging CM Code
Packaging CM (Customer Modifications) code facilitates the preparing and the deploying of your
CM code to another application server that is different from the one that you are currently working
on.
CM Packaging Scripts are distributed in the same zip file as ClientSetup.exe, under the CM
Packaging Tool Folder.
Expand the appropriate archive to your source and target environments – extracting the
CM_Packaging folder (from AppServerPackaging archive) and oracle folders (from DBPackaging-
Oracle.zip).
It is assumed that you have perl installed in both source and target environments.
SOURCE: This is the Source Environment and is typically a Windows-based environment where
developers code and test their code under the Eclipse IDE. Code is deployed to Weblogic. CM
Source is extracted from this environment.
RELEASE: This is the Release Environment where release packages (or patches) are finally
deployed (or applied in the case of patches).
1. Run extractCMSource.
2. Create/copy cm_jars_structure.xml
3. Copy the extracted CM source to the packaging environment.
4. Copy spl-shared jar file to $SPLEBASE/splapp/standalone/lib/
5. Run applyCM.
Run extractCMSource
The extractCMSource script extracts all CM changes deployed to the current application server.
This script is typically executed from within the CM_Packaging folder. An example Windows
usage of this script is:
This command line traverses the application server directory tree, picks up any deployed CM
code, and copies the CM source code to c:\cmextract in a subfolder that is named prefixed with
000.
Run applyCM
Remain logged on to the packaging environment, Note that the applyCM script requires you to be
in the extracted CM source folder. You will need to fully qualify applyCM in order to invoke it.
Running applyCM in Unix would look like this:
The script will then proceed with building several jar and ear files. Address any error that may
come up and run applyCM once again.
You should see “BUILD SUCCESSFUL” on the console once this script completes. At this point,
the CM source has been applied to the application server that is deployed in the packaging
environment. You have this opportunity to test the applied CM code.
The log files for this process will be in the extract folder. The artifact generator log will be in the
packaging application server’s “logs” directory.
Note: Please ensure that that the JDK version you are using is version 1.7. If not the CM build
process will fail because of a version mismatch. If you really need to use a newer version of the
JDK, you could edit the “target” parameter of the javac task in CMBuild.xml.
create_CM_Release: This script prepares a full release package that only contains customer
modification files.
create_CM_Patch: This script prepares an incremental release package that only contains
customer modification files that differ between two CM versions.
Both scripts require to be executed within the CM Packaging directory, but before you execute
either script, create a directory that will hold old and new release packages.
Log on and set up the packaging environment before running the scripts.
create_CM_Release
To prepare a full release package, run create_CM_Release. Here is an example:
create_CM_Patch
To prepare a patch package, run create_CM_Patch. Here is an example:
./create_CM_Patch.sh -d /versions
The -d parameter is the directory containing the release packages. This directory is also where
the new patch package will be created.
The release environment is presumed to already have an installation of the application server.
The customer modifications should be installed after running the install script. Verify that the
installation package was applied properly.
Packaging CM Data
The previous sections dealt exclusively with CM code. Packaging CM data takes a separate
process on the same environments:
1. Copy the database from development environment to the packaging (project release)
environment. You may need the help of a DBA to do this task for you.
2. Generate a blueprint file from the packaging (project release) database.
3. Apply the blueprint file to a target release (product release) database.
In the expanded oracle folder (taken from DBPackaging-Oracle.zip) are two scripts CM-
extract.bat and CM-upload.bat. Modify both files to specify any logon information that is needed
to connect to the source and target databases.
Note: The blueprint tools -- OraSDBp and OraSDUpg -- are 32-bit Windows executables. These
require you to install a 32-bit Oracle client.
Important: This process does not guarantee that the customizations will be migrated free of
errors. We strive to remain compatible with older versions at all times, but there are occasionally
circumstances where that is not possible. In those cases it may be necessary to modify the
custom code.
%SPLEBASE%\services\CM*.cbl
%SPLEBASE%\splapp\applications\appViewer\data\source\${cm_owner}\*
%SPLEBASE%\splapp\applications\appViewer\data\xml\${cm_owner}\*
%SPLEBASE%\splapp\applications\appViewer\data\javadocs\com\splwg\${cm_owner}
%SPLEBASE%\structures\${cm_owner}_*.xml
%SPLEBASE%\templates\${cm_owner}.*.template
%SPLEBASE%\scripts\cm
%SPLEBASE%\etc\lib\cm*.jar
%SPLEBASE%\splapp\applications\root\${cm_owner}
%SPLEBASE%\splapp\applications\help\XXX\cm
%SPLEBASE%\splapp\xai\schemas\cm*.*
%SPLEBASE%\java\target\cm\services\CM*.xml
%SPLEBASE%\splapp\applications\root\cmFlush*.jsp
Take note that OUAF 4.3.0 dropped support of COBOL so the source code in the
following folders need to be addressed appropriately:
%SPLEBASE%\cobol\source\cm\CM*.cbl
%SPLEBASE%\java\source\cm\cobolServices\CM*.xml
5. Start Eclipse and set up a project for the new application server. Refer to Running
Eclipse.
6. Run artifact generator and refresh the Eclipse project to compile the Java source.
Correct any errors before proceeding.
Appendix
The following additional steps may be necessary to configure the SDK.
Where is SPLSDKCommon?
Prior to Oracle Utilities SDK 4.2.0.2.3, Eclipse projects are created in
SPLSDKCommon\eclipseProject folder in the root of the application server directory structure.
Oracle Utilities SDK 4.2.0.2.3 eliminated the SPLSDKCommon directory structure and defaults
the project folder to the project workspace located at the root of the Oracle Utilities SDK
installation folder. Eclipse projects are now created in the respective application server
workspaces where the Oracle Utilities SDK is installed.
If this is the case, the Generate Artifacts run configuration needs to be edited.
Go to Run -> Run Configurations…
Under Java Application, select the appropriate Generate Artifacts configuration, for example
Under VM Arguments, remove the property that references “cobol” as shown in the red rectangle
in the above snapshot. Note that the dash before the “Dspl…” is in fact part of the property
definition and needs to be removed as well.
These warnings should not affect your Java development in any way. The Artifact Generator will
be enhanced to address this issue in a future release. For now, should you really need to
suppress these warnings, you will need to bring up the Eclipse Preferences dialog and navigate
to Java Compiler Errors/Warnings:
Scroll down to “Potential Programming Problems” and change the value for “Serializable class
without serialVersionUID” to “Ignore”. The next build will suppress the warnings.
This error is most likely caused by an incompatible JVM version. Your Eclipse installation should
be using the same JVM version used by the application server. Edit the setsplenv.bat file in the
etc folder of your Oracle SDK workspace to change the JAVA_HOME environment variable.
Environmental Requirements
A developer site for CM would normally have an application server that would function as the
source environment; a clone for the source environment will function as a packaging
environment; and another clone of the source environment that will function as a target
environment. Each instance of the application server will require clones of the same database to
serve as the source database, the packaging database, and a target database.
1 Source Environment + 1 Source Database
1 Packaging Environment + 1 Packaging Database
1 Target Environment + 1 Target Database
All developer sites in the multiple CM project should follow the same setup. Note that all of these
environments could be installed in the same physical server box. The databases could be
identical schemas in the same database server.
By default CM is the cm owner of the installation, but in a multiple CM deployment, the cm owner
is CM99:
insert into ci_lookup_val
(FIELD_NAME,FIELD_VALUE,EFF_STATUS,VERSION,OWNER_FLG,VALUE_NAME)
VALUES('OWNER_FLG','CM99','A',1,'CM99','cm99');
The –m option takes the module name/project directory name (lowercase CM owner) as a
parameter. This is a required parameter to properly extract CM01 source.
After extraction, copy the extract to your packaging environment and run the applyCM script. This
builds the extracted source code.
Finally, run the create_CM_release script to create a target environment installation. If an
installation package already exists, you may opt to run the create_CM_patch script to create a
target environment patch instead.
Refer to the CM Packaging Utilities Cookbook for details in using the App Server CM
Packaging Scripts.
In the target environment, each blueprint and installation package from the Multiple CM Project
participants should be uploaded and installed individually. Again, the installation owner
(F1_INSTALLATION) for the target environment should be different from the developer owners –
CM99.