2 Setting Up Your Development Environment

This chapter describes how to configure and test your development environment. It includes the steps for setting up your JDeveloper environment and Oracle Application Development Framework (Oracle ADF) installation, running and deploying applications on Integrated WebLogic Server, and the basic steps for setting up your Oracle SOA Suite development environment.

This chapter includes these sections:

2.1 Introduction to the Development Environment

Important:

Although JDeveloper works well in a 32-bit environment, this chapter assumes that you are using a 64-bit operating system and a 64-bit JDK.

If you do need to create and run Standalone WebLogic Server on a local PC, such as when doing SOA work, then the operating system must be 64-bit. The MW_HOME directory that is installed contains several Oracle Homes and the Oracle Business Intelligence installation is 64-bit only.

Also, a 32-bit operating system is limited to accessing 4GB of RAM. 8GB of RAM is preferred.

Oracle Fusion Applications provisioning involves installing, patching, configuring, and deploying all the enterprise components. At the end of the provisioning process, the system will be operational. An application administrator will be able to log in to the application and begin the process of configuring the functional (application specific) components.

On-site, the administrator uses eDelivery or the DVD media to kick-start the provisioning processes to create the test environment and the production environment. These environments are completely isolated from one another and set up in an identical manner. There is no reuse of, for example, the database from the production environment in the test environment, or reuse of the Identity Store across the environments.

These environments need to be extremely stable and should not be affected by development projects. Typical development projects include creating new customizations for existing Oracle Fusion applications, developing new in-house Oracle Fusion applications, and extending Oracle Fusion applications with additional functionality. These development projects will typically involve a team of developers that needs to reuse certain parts, but still needs the isolation to run, test, and debug without affecting other team members.

As a developer, you will work with one development environment that has two parts:

  • Shared environment

    This fully-provisioned Oracle Fusion Applications environment includes the database and LDAP. It also can host the instance of WebLogic Server if you require SOA for your customization work. The shared environment usually is designated as the Test environment.

  • Personal environment

    This is the JDeveloper instance and an instance of Integrated WebLogic Server that can run on your local desktop or laptop. You still would connect to the database and LDAP instances on the shared environment.

    Important:

    To use Integrated WebLogic Server, the connection to a database and an LDAP server is required. The database needs all the correct schemas for Oracle Fusion applications and a properly-seeded LDAP.

    The Personal environment also can have a standalone MW_HOME and WebLogic Server domain, such as:

    • standalone: Only the AdminServer where you can run and deploy ADF applications.

    • adminsoa: AdminServer plus SOA managed server.

    • adminall: AdminServer configured for a standalone domain and a SOA managed server.

    • adminadfess: AdminServer configured for standalone domain and an ESS managed server.

The shared environment plus the personal environment form the complete development environment.

2.1.1 Shared Environment

The shared environment is a fully-provisioned Oracle Fusion Applications environment to be shared among multiple developers. It normally will be set up by an administrator using the provisioning framework. This environment normally is set up on a machine that is more powerful than the normal developer's machine, which often is a laptop.

Developers would obtain the EAR files to be customized from the filesystem from this environment.

The database, WebLogic Servers and common services provided by this environment would be used by the developers' applications.

When it is provisioned, the shared environment contains:

  • Database

  • Oracle Middleware Home

  • WebLogic Server domains

  • Identity Store and Policy Store

Properties and features of the shared environment include:

  • The shared environment can be accessed from the personal environment (see Section 2.1.2, "Personal Environment") so developers can reach the installation directory that normally is called MW_HOME.

  • The exploded EAR directory in Middleware home can be opened from JDeveloper and a workspace can be created. The exploded EARs in Middleware home have the connections.xml and adf-config.xml files set up correctly to point to the correct database and other deployed applications in the shared environment.

  • The LDAP and OPSS credentials in the personal environment point to the Identity Store and the Policy Store in the shared environment.

  • WebLogic Server domains run in the shared environment and Oracle Fusion applications are deployed to those domains.

    The shared environment is a completely-provisioned Oracle Fusion Applications instance.

For more information about provisioning an environment, see "Provisioning a New Applications Environment" in the Oracle Fusion Applications Installation Guide, and the Oracle Fusion Applications release notes.

2.1.2 Personal Environment

Each developer has a personal environment that uses the database, Middleware home, and the Identity and Policy stores from the shared environment. The shared environment is made available by using NFS mount or a mapped drive in the personal environment. In this environment, developers can use JDeveloper to run, test, and debug their changes. If network sharing is not an option, exploded EAR files can be copied to a local directory of the personal environment.

The personal environment consists of two parts:

  • The JDeveloper-based environment that is created by installing JDeveloper, extension bundles and patches.

  • The environment for Standalone WebLogic Server that is created using scripts and installer files.

Manually Deploying the oracle.apps.common.resource Shared Library

When an Integrated or a Standalone WebLogic Server instance has been launched, you will need to use the WebLogic Server Console to deploy oracle.apps.common.resource.ear as a shared library using oracle.apps.common.resource as the name. The file is located in the APPLTOP/fusionapps/applications/com/deploy/ path of the fully-provisioned Oracle Fusion Applications installation on the central server. See Section 2.2.3.1, "Managing Integrated WebLogic Server."

If you forget to deploy that shared library, you will get an error when you try to run any Oracle Fusion application in your Integrated or Standalone WebLogic Server because they all have dependencies on this shared library.

2.2 Setting Up the JDeveloper-based Personal Environment

You assemble this environment on your machine by performing these steps in this order:

  • Installing JDeveloper

  • Installing Extension Bundles

  • Applying patches

Using JDeveloper and the Oracle Fusion Domain wizard, you can create the fusion_apps_wls.properties file and a credential store. You will enter the host, port, and other details for the database and Identity Store from the shared environment. Eventually, the wizard will do the following:

  • Create DefaultDomain.

  • Extend DefaultDomain with WebLogic Server templates so that the shared libraries are added to the CLASSPATH and the system properties are set.

  • Configure DefaultDomain with datasources and the Identity Store that are available in the shared environment.

DefaultDomain is run as part of Integrated WebLogic Server from within JDeveloper. To create customizations for a shipped Oracle Fusion application, you can use JDeveloper to point to the exploded EAR directory of the application in the shared environment's Middleware home. A customization workspace will be created in JDeveloper with the adf-config.xml file being modified such that the Metadata Service (MDS) metadata store points to the filesystem. However, the DefaultDomain is configured with the ApplicationDB datasource that points to the fusion runtime schema that is installed in the database from the shared environment. Since the MDS namespace has been altered while incorporating the exploded EAR directory, the customizations that are created on the filesystem are picked up when the application is run within Integrated WebLogic Server.

2.2.1 Before You Begin

Before you can use JDeveloper, there are several things you need to do.

2.2.1.1 Removing the SCIM Process

Note:

This step is not applicable if you are running a Windows environment.

If you are using your own workstation, you probably have a process called SCIM (Smart Common Input Method) running. SCIM is an input method platform used for multilingual work.

This process may prevent you from entering a password in the Oracle Fusion Domain wizard or anywhere a JPasswordField occurs. If it does interfere with your work, you can remove SCIM from your system by executing this command.

sudo yum remove scim

If you do not want to remove it completely, you can just kill the processes by executing the following command. However, if you just kill the processes instead of removing SCIM, you must kill them each time you reboot your system.

ps -ef | grep -i scim

You then can kill -9 all those processes.

2.2.1.2 Increasing Open File Limit on Linux Machines

This system configuration change is required on Linux machines to increase the open file limit and resolve several JDeveloper, WebLogic Server and other "Too many files" errors when doing a build.

  • Add these two instructions to the /etc/security/limits.conf file:

    * soft nofile 8192
    * hard nofile 8192
    

    Note the leading asterisk (*).

  • Restart the machine to have these values take effect.

  • To check whether the settings took effect, change to a bash shell and run this command.

    [userid@blah ~]  bash
    bash-3.1$ > ulimit -n
    8192
    

2.2.1.3 Installing JDeveloper

Using the Oracle eDelivery system, download the Oracle JDeveloper 11g and Oracle Application Development Framework 11g and Oracle Fusion Applications Companion ZIP files that are appropriate for your operating system. Make sure to follow the instructions in the Readme file (click Readme at the top of the page).

Important:

Always use the Oracle eDelivery system. Do not download a random version from Oracle Technology Network (OTN).

Your administrator should make the contents of the ZIP files available on a shared directory. We strongly recommend that the administrator make the contents of the Oracle Fusion Applications Companion ZIP file available on a shared directory.

Important:

The directions in this section assume that you are installing from the directory into which you extracted the JDeveloper and Companion files, and that you are using a 64-bit operating system and the 64-bit version of the JDK.

Follow these two basic steps to install JDeveloper.

  • If you have not already done so, you must download and install the 64-bit JDK. To avoid the possibility of script errors, do not install to a directory location containing spaces, such as Program Files.

    When installing JDeveloper, you will select the 64-bit JDK location you just installed.

    If a 32-bit JDK was already installed and used, you must delete the old %MW_HOME% installation and the system directory in %JDEV_USER_HOME% before reinstalling JDeveloper and the Oracle Fusion Applications extensions updates.

  • Install JDeveloper from the top level of the directory into which you extracted the ZIP files you downloaded from Oracle eDelivery.

    Important:

    There are 2 installation options: Complete and Custom. To be able to specify the path to the 64-bit JDK, you must select the Custom option. If you do not, the included 32-bit JDK will be used.

    For Windows, you can use the jdevstudioxxxxxinstall.exe installer (where xxxxx is the version number). For Linux, you can use the jdevstudioxxxxxinstall.bin installer. If you decide to use the generic jdevstudioxxxxxinstall.jar installer, you must first install JDK 6 Update 24 from the Oracle Technology Network and then install JDeveloper using the generic installer.

    The installation will let you specify the directory into which to install JDeveloper. To avoid possible errors when the installation scripts run, do not include any spaces in the path. This installation directory is referred to as MW_HOME.

    When you have started JDeveloper, you will need to install the extension bundles from the fusion_apps_extensions directory in the location in which you extracted the Oracle Fusion Applications Companion files. See Section 2.2.1.4, "Adding Customization Extension Bundles to the jdev.conf File" and Section 2.2.1.5, "Setting Up the JDeveloper-based Development Environment."

Related Links

The following document provides additional information related to subjects discussed in this section:

2.2.1.4 Adding Customization Extension Bundles to the jdev.conf File

You must set this option before starting to customize an application if your application contains product-specific customization classes.

In $MW_HOME/jdeveloper/jdev/bin, open the jdev.conf file in a text editor and add this line:

AddVMOption -Dide.extension.extra.search.path /path/to/customization/bundles/directory1:/path/to/customization/bundles/directory2

where -Dide.extension.extra.search.path /path/to/customization/bundles/directory1:/path/to/customization/bundles/directory2 is the fully-qualified path or paths to the directory or directories in which the JAR files containing the product-specific customization classes are located. Paths already exist as part of the provisioned environment.

  • Check your adf-config.xml file to see if you are including any customization classes other than the ones described in "Personalizations Are Also Handled by the Customization Engine in MDS" in the Oracle Fusion Applications Extensibility Guide for Developers and EnterpriseCC, which is deprecated. Those are your product-specific customization classes.

    Example 2-1 shows customization class entries in the adf-config.xml file.

    Example 2-1 Customization Class Entries in the adf-config.xml File

    <cust-config>
       <match path="/">
        <customization-class name="oracle.apps.fnd.applcore.customization.GlobalCC"/>
        <customization-class name="oracle.apps.fnd.applcore.customization.SiteCC"/>
        <customization-class
           name="oracle.apps.fnd.applcore.customization.ProductCC"/>
         <customization-class
           name="oracle.apps.fnd.applcore.customization.EnterpriseCC"/>
        <customization-class name="oracle.apps.hcm.common.core.HcmCountryCC"/>
        <customization-class name="oracle.apps.hcm.common.core.HcmOrganizationCC"/>
        <customization-class name="oracle.apps.fnd.applcore.customization.UserCC"/>
       </match>
    </cust-config>
    

    In Example 2-1, these two customization classes are outside the list:

    <customization-class name="oracle.apps.hcm.common.core.HcmCountryCC"/>
    <customization-class name="oracle.apps.hcm.common.core.HcmOrganizationCC"/>
    
  • If you do have such product specific customization classes, you must modify your jdev.conf file to include the JAR files containing such customization classes. These JAR files have an Ext* prefix and are found under the application's APP_INF/lib directory.

  • To find the path to such JAR files, contact your system administrator who can use these steps to locate APP_INF/lib/Ext*.jar:

    • Look under APP-INF/lib under the exploded EAR for all JAR files that start with Ext.

    • Find the JAR files that contain the product specific customization classes. These classes can be found in the adf-config file. If the product-specific customization class cannot be found in any of the JAR files under APP_INF/lib/Ext*.jar, look at all JAR files under the EarContents.

2.2.1.5 Setting Up the JDeveloper-based Development Environment

Follow these steps to create a development environment based on Integrated WebLogic Server:

  1. From a command prompt, run python -V to see if you have Python 2.7.x on your machine. If you do not, install Python version 2.7.x. To avoid errors, do not install Python version 3.x. You can download Python from https://www.python.org.

  2. Set these environment variables.

    Note:

    In many cases, it is convenient to have these in a script that is used to start JDeveloper. This is specially useful when you want to have different work directories for separate projects.

    csh commands:

    setenv PATH /path/to/python/bin:$PATH
    setenv HOME /path/to/user_dir (Important: If this variable is not set, the FADevConfigure.py script, which is called while creating an Oracle Fusion domain in JDeveloper, will fail.)
    setenv MW_HOME /path/to/JDeveloper/installation/directory
    setenv JAVA_HOME path/to/installed/64-bit/jdk (Important: A 32-bit JDK is installed into $MW_HOME when your install JDeveloper. If you are running the recommended 64-bit operating system, you will need to install a 64-bit JDK and set the JAVA_HOME variable to it.)
    setenv PATH $JAVA_HOME/bin:$PATH
    setenv JDEV_USER_HOME /path/to/a/directory
    (Optional) setenv FADEV_VERBOSE true
    setenv USER_MEM_ARGS "-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000"
    

    bash commands:

    export PATH=/path/to/python/bin:$PATH
    export HOME=/path/to/user_dir (Important: If this variable is not set, the FADevConfigure.py script, which is called while creating an Oracle Fusion domain in JDeveloper, will fail.)
    export MW_HOME=/path/to/JDeveloper/installation/directory
    export JAVA_HOME=path/to/installed/64-bit/jdk (Important: A 32-bit JDK is installed into $MW_HOME when your install JDeveloper. If you are running the recommended 64-bit operating system, you will need to install a 64-bit JDK and set the JAVA_HOME variable to it.)
    export PATH=$JAVA_HOME/bin:$PATH
    export JDEV_USER_HOME=/path/to/a/directory
    (Optional) export FADEV_VERBOSE=true
    export USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000"
    

    Windows command prompt commands:

    set HOME=\path\to\user_dir (Important: If this variable is not set, the FADevConfigure.py script, that is called while creating an Oracle Fusion domain in JDeveloper, will fail. In Windows 7, HOME typically is c:\users\userid, such as c:\users\herbie.)
    set MW_HOME=\path\to\JDeveloper\installation\directory (Important: The path must not contain spaces.)
    set JAVA_HOME=path\to\installed\64-bit\jdk (Important: A 32-bit JDK is installed into $MW_HOME when your install JDeveloper. If you are running the recommended 64-bit operating system, you will need to install a 64-bit JDK and set the JAVA_HOME variable to it. You can download a 64-bit JDK from the Oracle Technology Network here: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u24-oth-JPR)
    set PATH=%JAVA_HOME%\bin;%PATH%
    set JDEV_USER_HOME=\path\to\a\directory (Important: The path must not contain spaces.)
    set USER_MEM_ARGS=-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000
    (Optional) set FADEV_VERBOSE=true
    
  3. Change directory to $MW_HOME/jdeveloper/jdev/bin.

  4. Open the jdev.conf file in a text editor and add this line:

    AddVMOption -Djdev.wlst.env.vars=HOME,JDEV_USER_HOME
    

    JDeveloper checks the environment before running Oracle WebLogic Scripting Tool or starting Oracle WebLogic Server. The domain creation scripts require access to certain environment variables. jdev.wlst.env.vars allows these environment variables to be accessed.

    Note that the HOME variable exists by default in Linux systems but must be set explicitly in Windows systems. See "Windows command prompt commands" in Step 2.

    If necessary, add other options from Table 2-1.

    Save and close the jdev.conf file.

    Table 2-1 VMOptions in jdev.conf

    Name Value Comments

    -Dide.extension.extra.search.path

    /x/y/z

    Fully qualified path or paths to the directory or directories where Customization Extension Bundles are located. You probably will need to get this information from an administrator.

    -DURLChooser.forceUseList

    true

    Optional.

    -DURLChooser.disableCompletionPopup

    true

    Optional.

    -DUNIX_WEB_BROWSER

    /usr/bin/firefox

    Location of the browser executable specific to the environment at the customer's site.

    -Djbo.SecondaryADFLibVisible

    true

     

    -Ddeployment.jario.writepolicy

    recreate

     

    -Doracle.webcenter.portlet.enableApplicationStriping

    true

     

    -Doracle.webcenter.portlet.dt.excludeExportSet

    true

     

    -Dadflib.project.open.refresh

    false

     

    -Djdev.wlst.env.vars

    HOME,JDEV_USER_HOME

    These are sanctioned environment variables that will be allowed for use in WebLogic Server Scripting Tool (WLST) scripts. Environment variables that are not in this list will be ignored by the script. You can add variables to this list.

    -XX:MaxPermSize

    512M

     

    -Xmx1024M

       

    -Xms256M

       

    -XX:+DisableExplicitGC

       

  5. Start JDeveloper.

    Linux

    jdev &
    

    Windows

    jdeveloper.exe
    

    If you need more details about the JDeveloper startup, you can use the verbose command line argument, such as:

    jdev -verbose
    

    When prompted, select the Default Role, as shown in Figure 2-1.

    Figure 2-1 Selecting the Default Role

    Described in surrounding text.

    Because you will need to select a different role later, you should make sure you select the Always prompt for role selection on startup option.

    The JDeveloper environment can be tailored based on the role you select. The modified environment removes unneeded items from JDeveloper, including menus, preferences, New Gallery, and even individual fields on dialogs. The JDeveloper role you select determines which technologies and options are available to you as you work in JDeveloper.

    Table 2-2 provides a brief explanation of the available roles.

    Table 2-2 JDeveloper Roles

    Role Description

    Default Role

    This role allows you general access to all of JDeveloper's features without role-specific customizations. The other roles provide important shaping features that are not included in the Default Role. Some of these will be available once the Oracle Fusion Applications Extensions have been added to the IDE.

    Oracle Fusion Applications Administrator Customization

    This is the main customization role for Oracle Fusion Applications customers.

    Important: You must use this Role for customizing SOA Composites.

    Oracle Fusion Applications Developer

    This is for Oracle Fusion Applications developers to use to build new applications.

    Database Edition

    This gives you access to just the core database development tools.

    Java EE Edition

    This includes only features for core Java EE development.

    Java Edition

    This includes only features for core Java development.

    BPM Process Analyst

    Configures the product for a BPM Business Analyst.

    Customization Developer

    Configures the product for customizing metadata.

    Oracle Fusion Applications Customization

    Configures JDeveloper for customizing metadata for Oracle Fusion Applications developers.


    Click OK. As JDeveloper loads, the Migrate User Settings prompt may display. If it does and you are not sure whether to migrate settings, you should click No.

  6. Install the Fusion Apps Development Environment extension bundle, an all-encompassing JDeveloper bundle that is specific for Oracle Fusion Applications. To install the bundle:

    1. Select Help > Check for Updates.

    2. Click Next past the Welcome dialog.

    3. If the Proxy Setup dialog displays, enter the applicable information for your situation, as shown in Figure 2-2.

      Figure 2-2 Completing the Proxy Setup Dialog

      Described in surrounding text.

      Ignore any error messages that might be displayed when you click the Test Proxy button.

    4. Click OK. The Source dialog, shown in Figure 2-3, displays.

      Figure 2-3 Available Update Centers

      Described in surrounding text.
    5. Unselect any marked Update Centers.

    6. Click Add to display the Update Center dialog, shown in Figure 2-4.

      Figure 2-4 Adding a New Update Center

      Described in surrounding text.
    7. Enter a name for the new Update Center, such as Oracle Fusion Applications Update Center.

    8. Click Browse to locate and select the fusion_apps_update_center.xml file, as shown in Figure 2-5. The location of this file in on the Oracle Fusion Applications Companion 11g (11.1.1.7.1) disk in the fusion_apps_extensions directory, or on a shared directory provided by the administrator.

      Figure 2-5 Browsing for the Update File

      Described in surrounding text.
    9. Click Open.

    10. Click OK.

    11. Select the newly-defined Update Center, as shown in Figure 2-6.

      Figure 2-6 Selecting the New Update Center

      Described in surrounding text.

      Note that only the new Update Center should be selected.

    12. Click Next to display the Updates dialog, shown in Figure 2-7. Note that, initially, no updates will be selected.

      Figure 2-7 Selecting the Updates

      Described in surrounding text.
    13. Select the Fusion Apps Development Environment extension bundle. The other bundles automatically will be selected.

    14. Click Next to display the Download dialog and start the download, as shown in Figure 2-8.

      Figure 2-8 Downloading the Updates

      Described in surrounding text.

      When the download finishes, the Summary dialog, similar to that shown in Figure 2-9, displays automatically.

      Figure 2-9 Summary Dialog

      Described in surrounding text.
    15. Click Finish. If you are using JDeveloper on a Linux system, the Confirm Exit prompt shown in Figure 2-10 displays.

      Figure 2-10 Confirm Exit Prompt

      Described in surrounding text.
    16. Click Yes to exit JDeveloper.

      Note: If you are using JDeveloper on Windows the prompt will ask if you want to restart JDeveloper. If you click Yes, JDeveloper is automatically restarted.

  7. Restart JDeveloper, selecting either the Oracle Fusion Applications Developer role or the Oracle Fusion Applications Administrator Customization role, as shown in Figure 2-11. The restart results in installing the extension bundles that were downloaded.

    Figure 2-11 Selecting the Oracle Fusion Applications Developer Role

    Described in surrounding text.

    If you do not have an administrator-supplied fusion_apps_wls.properties file in the default location, you will be prompted to configure WebLogic Server (launch the Oracle Fusion Domain wizard) as shown in Figure 2-12. Click Yes. See Section 2.2.2, "How to Use the Oracle Fusion Domain Wizard."

    Important:

    If you do not have access to a database and LDAP server, click No. Integrated WebLogic Server requires access to a valid database and LDAP server.

    Note that if you do have an administrator-supplied fusion_apps_wls.properties file, the administrator also must supply the entire o.jdevimpl.rescat2 folder from his $JDEV_USER_HOME/system11.1.1.xx.yy.zz folder. See Section 2.2.1.7, "Distributing the fusion_apps_wls.properties and cwallet.sso Files."

    Figure 2-12 WebLogic Server Not Configured Prompt

    Described in surrounding text.

When JDeveloper and Oracle WebLogic Server are properly installed and configured, the environment should have all the components in the correct locations. You should be able to create new, or customize existing, Oracle Fusion applications.

2.2.1.6 Using the OWSM_MDS Schema

The administrator has to make sure a database includes the Oracle Web Services Manager_Metadata Service (OWSM_MDS) schema. Typically, and particularly in a test environment and a production environment, this schema is in the Oracle Identity Manager (IDM) database. The administrator probably will not provide the shared environment schema connections because the schema would be locked down. The administrator should install a new MDS schema somewhere and provide that connection.

There are two options for how a developer can use the OWSM_MDS schema.

  • The recommended method is for the administrator to use the Oracle Fusion Applications Repository Creation Utility to create the MDS schema, described in Section 2.3.1.1, "Creating the OWSM_MDS Schema," in the database in the shared environment. The schema name must have a prefix of owsm. This will create a schema named OWSM_MDS. Developers, then, will not need to do anything else to use the schema.

  • The developers have to provide the connect string and other details of the owsm_mds schema available in the central IDM or LDAP while creating the properties file. This requires that an administrator provide the IDM database details. These are the host, port, userid, password, and SID. Figure 2-13 shows how the wizard's Database dialog will be completed.

    Figure 2-13 Setting Up the OWSM_MDS Schema

    Described in surrounding text.

2.2.1.7 Distributing the fusion_apps_wls.properties and cwallet.sso Files

Instead of each developer creating the properties file and the credential store using the Oracle Fusion Domain wizard, the administrator can create them once and distribute them to the entire development team. The administrator can use the wizard and enter the property values, which include connect strings to the database and to the Identity Store. These values are captured in the fusion_apps_wls.properties file and the passwords are stored in an encrypted form using the credential store. Both the fusion_apps_wls.properties file and the cwallet.sso file, which is the credential store, are created in the o.jdevimpl.rescat2 sub-folder under the $JDEV_USER_HOME/system11.1.1.7.xx.yy.zz folder. The administrator can distribute the entire o.jdevimpl.rescat2 sub-folder to the development team. The developers can install JDeveloper and install the bundles. The developers then can copy the entire o.jdevimpl.rescat2 sub-folder under their own $JDEV_USER_HOME/system11.1.1.7.xx.yy.zz folder. This way, the administrator can enforce uniformity and the developers will not have to go through the wizard to create the properties file.

Now, if developers need to use their own SOAINFRA or MDS_SOA schemas, they can manually launch the wizard and provide connect strings specifically for those schemas.

Note:

Although the Oracle Fusion Domain wizard includes additional properties for Standalone WebLogic Server, the same fusion_apps_wls.properties and cwallet.sso files are used for both Integrated WebLogic Server and Standalone WebLogic Server creation and configuration.

2.2.2 How to Use the Oracle Fusion Domain Wizard

The wizard helps you to create and update a fusion_apps_wls.properties file and a cwallet.sso file that are used to set up the Oracle WebLogic Server domain for Oracle Fusion Applications development. The wizard incorporates two main paths: one for configuring an Integrated WebLogic Server domain (in which JDeveloper manages the server) and one for setting up a remote Standalone WebLogic Server domain.

In the case of Integrated WebLogic Server, completion of the wizard will create the domain. For Standalone WebLogic Server, you will have to create the domain from the command line, using a Python script and the fusion_apps_wls.properties and cwallet.sso files that were populated using the wizard.

The wizard can be run multiple times to change properties in the fusion_apps_wls.properties file. If certain critical properties are changed, the domain will have to be re-created. This will be done automatically for the Integrated WebLogic Server domain, but will be a manual step for a Standalone WebLogic Server domain.

The wizard can be launched automatically or manually. It will be launched automatically under either of these conditions:

  • The fusion_apps_wls.properties file is not found when JDeveloper starts. The name of the file defaults to fusion_apps_wls.properties, and the location defaults to the system11.1.1.xx.yy.zz/o.jdevimpl.rescat2 directory.

  • The fusion_apps_wls.properties file is not found when you select to Run an application from JDeveloper, or you select to Start Server Instance from JDeveloper.

To start the wizard manually from within JDeveloper:

  • Select View > Application Server Navigator.

  • Expand the Application Servers node.

  • Right-click IntegratedWebLogicServer and select the Configure Fusion Domain option, as shown in Figure 2-14.

    Figure 2-14 Manually Starting the Oracle Fusion Domain Wizard

    Described in surrounding text.

The properties that can be captured in the wizard are shown in Table 2-3. The properties are defined under section headers that are surrounded by [square brackets], for example:

[domain]
domainType=adminall

Table 2-3 Properties to be Captured in the Oracle Fusion Domain Wizard

Property Name Standalone/ Integrated Required Default Comments

domainType

Standalone

Yes

standalone

Valid values are:

adfess: Admin server only for Oracle ADF and ESS

adminsoa: Admin server (EM) and SOA managed server

adminall: Combination of standalone and adminsoa (Oracle ADF,ESS,SOA)

adminessadf: Admin server for Oracle ADF and ESS managed server

standalone: Default setting. This is an admin server only; not a managed server.

domainName

Standalone

Yes

fusion_domain

This can be any name. It is used only for Standalone Weblogic Server.

domainDir

Standalone

Yes

 

The location in the file system in which the domain will be created. To avoid possible errors during script execution, the directory name should not include spaces.

If it is not specified, the domain will be created in the default location which is $MW_HOME/user_projects/<domain_name>.

installerLocation

Standalone

Yes

 

Location of the Oracle Fusion Applications installer files. These usually are located on a central server, rather than on each developer's system. Ask your administrator for the location.

listenPort

Standalone

Yes

Default based on Standalone or Integrated. Default is 7011 for Standalone WebLogic Server.

 

soaPort

Standalone

Yes, only when domainType is adminsoa/adminall.

 

Needed for adminsoa and adminall.

As this is on their own machines, developers choose the values.

essPort

Standalone

Yes, only when domainType is adminess.

 

As this is on their own machines, developers choose the values.

wlName

Both

Yes

weblogic

 

wlPassword

Both

Yes

NA

Users must supply the password by using the wizard.

ldapHost

Both

Yes

 

This is a string value similar to: ldaphostname.yourcompany.com.

ldapPort

Both

Yes

 

Example: 3060

ldapUser

Both

Yes

 

Example: cn=wlsproxyuser

ldapPass

Both

Yes

 

Example: welcome1

Important: In the UI, the password will display as the normal ******* mask. The password is not saved in the fusion_apps_wls.properties file. It is encrypted and saved in the cwallet.sso file maintained in the system11.1.1.xx.yy.zz/o.jdevimpl.rescat2/ directory.

ldapUserDN

Both

Yes

 

Example: cn=users,dc=us,dc=yourcompany,dc=com

ldapGroupDN

Both

Yes

 

Example: cn=groups,dc=us,dc=yourcompany,dc=com

ldapSSLEnabled

Both

No

false

true or false

opssHost

Standalone

No

 

Optional separate OPSS store. This is a string value similar to: opsshostname.yourcompany.com.

For Integrated WebLogic Server, the DefaultDomain uses the XML-based Policy Store (such as system-jazn-data.xml). For Standalone WebLogic Server, if undefined, the standalone domain defaults to the XML-based Policy Store (such as system-jazn-data.xml).

For information and directions on how to migrate the OPSS policy store using the migrateSecurityStore.py OPSS script, see:

opssPort

Standalone

No

 

Example: 3061

opssUser

Standalone

No

 

Example: cn=wlsproxyuser

opssPass

Standalone

No

 

Important: In the UI, the password will display as the standard ***** mask. The password is not saved in the fusion_apps_wls.properties file. It is encrypted and saved in the cwallet.sso file maintained in the system11.1.1.xx.yy.zz/o.jdevimpl.rescat2/ directory.

opssSSLEnabled

Standalone

No

false

true or false

jpsRootContext

Standalone

No

 

Text field

Example: cn=FADevPolicies

biHostPort

Standalone

No

 

Oracle Business Intelligence will only be supported in the Standalone WebLogic Server environment.

Specify a port to point to the BI server. This generates a BIP configuration file that gets added to the domain home. The template then adds the location of the configuration file as a system property to be set when Oracle WebLogic Server is started.

familyName

Both

Yes

 

Family names are: COMMON, IC, HCM, FIN, PRC, PRJ, SCM, and CRM.

fusionDb - connect string

Both

Yes

 

JDBC connect string.

Note: This is split into sub-fields:

  • fusionDbUser

  • fusionDbPassword

  • fusionDbHost

  • fusionDbPort

  • fusionDbSid

This is applicable to these schemas:

  • activityDb

  • apmDb

  • AppMasterDb

  • essMdsDb

  • fusionAq

  • fusionEdn

  • fusionMds

  • oraessDb

  • orasdpmDb

  • owsmMdsDb

  • portletDb

  • soadatasrcDb

  • soaMdsDb

  • wcDb

activityDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_activities. Your system administrator will provide the connection details and schema password to be used.

apmDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_apm. Your system administrator will provide the connection details and schema password to be used.

AppMasterDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_runtime. Your system administrator will provide the connection details and schema password to be used.

essMdsDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_mds_ess. Your system administrator will provide the connection details and schema password to be used.

fusionAqUser - connect string

Both

Yes, but the database connection is the same as for fusionDb.

 

You can connect to the fusionDB database as fusion_aq. Your system administrator will provide the connection details and schema password to be used.

fusionEdnUser - connect string

Both

Yes, but the database connection is the same as for fusionDb.

 

Note: CRM will be replaced with the familyName that is passed in.

You can connect to the fusionDB database as crm_fusion_soainfra. Your system administrator will provide the connection details and schema password to be used.

fusionMdsUser - connect string

Both

Yes, but the database connection is the same as for fusionDb.

 

You can connect to the fusionDB database as fusion_mds. Your system administrator will provide the connection details and schema password to be used.

oraEssDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_ora_ess. Your system administrator will provide the connection details and schema password to be used.

orasdpmDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_orasdpm. Your system administrator will provide the connection details and schema password to be used.

owsmMdsDbUser - connect string

Both

No

 

You can connect to the fusionDB database as owsm_mds. Your system administrator will provide the connection details and schema password to be used.

portletDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_portlet. Your system administrator will provide the connection details and schema password to be used.

soadatasrcDbUser - connect string

Both

No

 

Family name used in prefix.

You can connect to the fusionDB database as crm_fusion_soainfra. Your system administrator will provide the connection details and schema password to be used.

soaMdsDbUser - connect string

Both

No

 

Family name used in prefix.

You can connect to the fusionDB database as crm_fusion_mds_soa. Your system administrator will provide the connection details and schema password to be used.

wcDbUser - connect string

Both

No

 

You can connect to the fusionDB database as fusion_webcenter. Your system administrator will provide the connection details and schema password to be used.


2.2.2.1 Creating the Properties File for Default Integrated Server

Note:

The wizard requires considerable information about the network and various servers, such as LDAP and database. In normal situations, the administrator will disseminate his entire o.jdevimpl.rescat2 folder from his $JDEV_USER_HOME/system11.1.1.xx.yy.zz folder to developers who will copy the folder into the correct directory. See Section 2.2.1.7, "Distributing the fusion_apps_wls.properties and cwallet.sso Files."

If the fusion_apps_wls.properties file is not found when you start JDeveloper, the prompt shown in Figure 2-12 displays. You also can start the wizard manually.

Click Yes to launch the wizard and display the Usage page, as shown in Figure 2-15.

Figure 2-15 Selecting Domain Usage

Selecting Domain Usage
  • Default Integrated Server

    Select this option, the default, to configure and create a server that will be controlled by JDeveloper. This is the normal choice for development work. When the wizard finishes, an Integrated WebLogic Server domain will be created and can be used to run and test your applications.

  • Standalone Server

    Selecting this option only creates or updates the fusion_apps_wls.properties and cwallet.sso files. See Section 2.2.2.2, "Completing the Oracle Fusion Domain Wizard for Standalone Server" for the dialogs that are specific to creating the fusion_apps_wls.properties file for a Standalone WebLogic Server domain.

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

Further wizard pages depend on the selected Usage. The flow for the Default Integrated Server selection is covered first. The flow for the Standalone Server selection is covered in Section 2.2.2.2, "Completing the Oracle Fusion Domain Wizard for Standalone Server."

When you select the Default Integrated Server Usage option and click Next, the Domain dialog, shown in Figure 2-16, displays.

Figure 2-16 Configuring the Domain

Described in surrounding text.

If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.

  • WebLogic User Name

    This value defaults to weblogic. Change it if necessary.

  • WebLogic Password / Confirm Password

    The password requires at least one numeral.There is no default, and you must supply the password. Note that the password is not stored in the fusion_apps_wls.properties file. It is encrypted and stored in the cwallet.sso file.

  • Fusion Family Name

    This name is used during Java Message Service queue creation; and as the SOA cluster name when creating an instance of Standalone Weblogic Server. The value should match the product you are customizing.

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

Click Next to display the Database dialog, shown in Figure 2-17

Figure 2-17 Configuring the Database

Described in surrounding text.

If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.

Note: If you do not have access to a database, click Cancel.

Notes:

  • Values entered in the wizard are not validated, so the connection details must be validated outside the wizard.

  • If a credential that is listed in the Database dialog does not have the same password as the corresponding schema name itself, you must provide the password using the fields to the right of the credential list.

  • If the credential that is listed in the Database dialog has to be mapped to a schema other than the default schema, you should provide the appropriate schema name and password using the fields to the right of the credential list. For example, the OWSM MDS credential is mapped to the owsm_mds schema by default. But, if it has to be mapped to the hcm_fusion_mds_soa schema, you can choose the OWSM MDS credential from the list and then enter hcm_fusion_mds_soa in the Username field and specify the password in the Password field on the right. Again, the Connect String field can be left blank if the schema is in the same database.

  • If each of the credentials in the Database dialog have the same password as the corresponding schema name, you only need to enter values in the Fusion Database field in the host:port:SID format.

  • Fusion Database User

    This schema name comes from the database installation. fusion_runtime is a recommended standard name.

  • Fusion Database Password

    Enter the password. You probably will need to get this from an administrator if the cwallet.sso file was not provided to you. (Passwords are encrypted and stored in that file.)

  • Fusion Database

    Enter the host, port, and the SID information using a colon (:) delimiter, such as a.your.company.com:1234:xyzzyon. You probably will need to get this from an administrator if the fusion_apps_wls.properties file was not prepared for you.

  • Credential Type List

    Several credentials are supplied with Oracle Fusion Applications and are included in the fusion_apps_wls.properties file. When you click a credential, the three fields to the right will display the default values. The Password field will remain blank because any passwords are encrypted and stored in the cwallet.sso file.

    If OWSM_MDS is selected, and the administrator has chosen to open up the IDM database in which the schema already exists, you will need to enter all the necessary information in this dialog. However, if the administrator has created the OWSM_MDS schema in the transaction database, you may not need to enter any data here. For more information about the owsm_mds schema, see Section 2.3.1.1, "Creating the OWSM_MDS Schema."

    You can change the default values of almost all the credentials, if necessary.

    • User Name

      This field corresponds to the Fusion Database User field.

    • Password

      This field corresponds to the Fusion Database Password field.

    • Connect String

      This field corresponds to the Fusion Database field.

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

Click Next to display the Security dialog, shown in Figure 2-18.

Figure 2-18 Configuring Security for Integrated Domain Server

Described in surrounding text.

If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.

Note: If you do not have access to an LDAP server, click Cancel.

  • LDAP Server

    This field cannot be edited directly. Click the edit icon to display the Edit LDAP Server dialog shown in Figure 2-19.

    Figure 2-19 Editing the LDAP Server

    Described in surrounding text.
    • Host

      Enter the name of your LDAP host, such as ldap_server.your_company.com.

    • Port

      Enter the port number, such as 1066.

    • Principal

      This is the internal LDAP user name by which you connect to LDAP, such as cn=wlsproxyuser.

    • Password

      Enter the password used by the Principal. The password will be encrypted and stored in the cwallet.sso file, and not in the fusion_apps_wls.properties file.

    • SSL Enabled

      This value defaults to LDAP (not checked). Select this check box if you want to use LDAPS.

    • User Base DN

      Enter the User DN based your LDAP. A sample User DN resembles cn=users,dc=us,dc=your_company,dc=com.

      The DN (Distinguished Name) is the LDAP attribute that uniquely defines an object. Each DN must have a unique name and location.

      The components include cn=common name, ou=organizational unit, and dc=domain content. DC often is listed with two entries, dc=cp and dc=com.

    • Group Base DN

      Enter the Group DN based your LDAP. A sample Group DN resembles cn=groups,dc=us,dc=your_company,dc=com.

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

Click Next to display the Finish dialog shown in Figure 2-20.

Figure 2-20 Finishing the Integrated Domain

Described in surrounding text.
  • Click Finish to save the properties in the following file

    This value cannot be edited. The field simply shows the name of the fusion_apps_wls.properties file and the directory in which it will be created or updated.

  • Create the Domain Now

    This defaults to Yes (checked). When selected and you click Finish, the Integrated WebLogic Server domain will be created so you can test your applications by selecting one of the JDeveloper Run options.

    Note:

    Creating the domain involves a great deal of background work to correctly set up the environment. This process can take several minutes.

2.2.2.2 Completing the Oracle Fusion Domain Wizard for Standalone Server

When you select the Standalone Server Usage option and click Next, the Domain dialog, shown in Figure 2-21, displays.

Figure 2-21 Configuring the Standalone Domain

Described in surrounding text.

If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.

Note:

If an administrator has not created the fusion_apps_wls.properties file for you, with this information, you will need to get most of this information from an administrator.

  • Domain Type

    This is the type of domain you wish to create. It can be:

    • adfess: Configured for Oracle ADF and Oracle Enterprise Scheduler technologies.

    • adminsoa: Creates an Oracle SOA Suite domain with an AdminServer with Oracle Enterprise Manager Fusion Middleware Control deployed, and a managed server, named soa_server1, where SOA composites are deployed and run.

    • adminall: A combination of standalone and Oracle SOA Suite, AdminServer for Oracle ADF/Oracle Enterprise Scheduler and managed server soa_server1 for Oracle SOA Suite.

    • adminessadf: Admin server for Oracle ADF and Oracle Enterprise Scheduler Service (ESS) managed server.

  • Domain Name

    The name of your domain. If you have more than one domain, you need to change this value and the domainDir value.

    Follow these steps if you are using a Linux operating system:

    • Create a new fusion_apps_wls.properties file with domainName=Domain1 and domainDir=$MW_HOME/user_projects/Domain1.

    • When the properties file has been created, copy fusion_apps_wls.properties to fusion_apps_wls_Domain1.properties in the $JDEV_USER_HOME/system11.1.1.*/o.jdevimpl.rescat2 directory.

    • Run FADevCreateDomain.py -p $JDEV_USER_HOME/system11.1.1.*/o.jdevimpl.rescat2/fusion_apps_wls_Domain1.properties to create Domain1.

    • Edit fusion_apps_wls.properties and change domainName=Domain2 and domainDir=$MW_HOME/user_projects/Domain2.

    • Copy fusion_apps_wls.properties to fusion_apps_wls_Domain2.properties in the $JDEV_USER_HOME/system11.1.1.*/o.jdevimpl.rescat2 directory.

    • Run FADevCreateDomain.py -p $JDEV_USER_HOME/system11.1.1.*/o.jdevimpl.rescat2/fusion_apps_wls_Domain2.properties to create Domain2.

      You now have two properties files in the o.jdevimpl.rescat2 folder and two domains.

    Follow these steps if you are using a Windows operating system:

    • Create a new fusion_apps_wls.properties file with domainName=Domain1 and domainDir=%MW_HOME%\user_projects\Domain1.

    • cd %JDEV_USER_HOME%\system11.1.1.*\o.jdevimpl.rescat2

    • copy fusion_apps_wls.properties fusion_apps_wls_Domain1.properties

    • Run FADevCreateDomain.py -p %JDEV_USER_HOME%\system11.1.1.*\o.jdevimpl.rescat2\fusion_apps_wls_Domain1.properties to create Domain1.

    • Edit fusion_apps_wls.properties and change domainName=Domain2 and domainDir=%MW_HOME%\user_projects\Domain2.

    • cd %JDEV_USER_HOME%\system11.1.1.*\o.jdevimpl.rescat2

    • copy fusion_apps_wls.properties fusion_apps_wls_Domain2.properties

    • Run FADevCreateDomain.py -p %JDEV_USER_HOME%\system11.1.1.*\o.jdevimpl.rescat2\fusion_apps_wls_Domain2.properties to create Domain2.

      You now have two properties files in the o.jdevimpl.rescat2 folder and two domains.

  • Installer Location

    This is the location of the Oracle Fusion Applications installer files, usually on a central server.

  • Domain Location

    The location in the file system in which the domain will be created.

    If it is not specified, it will be created in the default location, which is $MW_HOME/user_projects/<domain_name>.

    This can be changed by setting the domainDir property in the fusion_apps_wls.properties file. If you have more than one domain, you need to change this value. See the description of domainName.

  • Listen Port

    Listen Port is the adminserver listen-port you want to use.

  • SOA Port

    This field, which displays only if the Domain Type is adminall or adminsoa, is the port number for your Oracle SOA Suite managed server (soa_server1) if you are using Oracle SOA Suite. If you are not using Oracle SOA Suite, you can leave this blank.

  • BI Host Port

    This is the host:port where the BI Publisher server is running. The format for the value for this field is hostname:port, such as my.domain.com:9999. You may need to get this value from your administrator.

  • WebLogic User Name

    This value defaults to weblogic. Change it if necessary.

  • WebLogic Password / Confirm Password

    The password requires at least one numeral.There is no default, and you must supply the password. Note that the password is not stored in the fusion_apps_wls.properties file. It is encrypted and stored in the cwallet.sso file.

  • Fusion Family Name

    This name is used during Java Message Service queue creation; and as the SOA cluster name when creating an instance of Standalone Weblogic Server. The value should match the product you are customizing.

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

Click Next to display the Database dialog, shown in Figure 2-22

Figure 2-22 Configuring the Database

Described in surrounding text.

If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.

Note: If you do not have access to a database, click Cancel.

Notes:

  • Values entered in the wizard are not validated, so the connection details must be validated outside the wizard.

  • If a credential that is listed in the Database dialog does not have the same password as the corresponding schema name itself, you must provide the password using the fields to the right of the credential list.

  • If the credential that is listed in the Database dialog has to be mapped to a schema other than the default schema, you should provide the appropriate schema name and password using the fields to the right of the credential list. For example, the OWSM MDS credential is mapped to the owsm_mds schema by default. But, if it has to be mapped to the hcm_fusion_mds_soa schema, you can choose the OWSM MDS credential from the list and then enter hcm_fusion_mds_soa in the Username field and specify the password in the Password field on the right. Again, the Connect String field can be left blank if the schema is in the same database.

  • If each of the credentials in the Database dialog have the same password as the corresponding schema name, you only need to enter values in the Fusion Database field in the host:port:SID format.

  • Fusion Database User

    This schema name comes from the database installation. A recommended standard name is fusion_runtime.

  • Fusion Database Password

    Enter the password. You probably will need to get this from an administrator if the cwallet.sso file was not provided to you. (Passwords are encrypted and stored in that file.)

  • Fusion Database

    Enter the host, port, and the SID information using a colon (:) delimiter, such as a.your.company.com:1234:xyzzyon. You probably will need to get this from an administrator if the fusion_apps_wls.properties file was not prepared for you.

  • Credential Type List

    Several credentials are supplied with Oracle Fusion Applications and are included in the fusion_apps_wls.properties file. When you click a credential, the three fields to the right will display the default values. The Password field will remain blank because any passwords are encrypted and stored in the cwallet.sso file.

    If OWSM_MDS is selected, and the administrator has chosen to open up the IDM database in which the schema already exists, you will need to enter all the necessary information in this dialog. However, if the administrator has created the OWSM_MDS schema in the transaction database, you may not need to enter any data here. For more information about the owsm_mds schema, see Section 2.3.1.1, "Creating the OWSM_MDS Schema."

    You can change the default values of almost all the credentials, if necessary.

    • User Name

      This field corresponds to the Fusion Database User field.

    • Password

      This field corresponds to the Fusion Database Password field.

    • Connect String

      This field corresponds to the Fusion Database field.

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

Click Next to display the Security dialog shown in Figure 2-23.

Figure 2-23 Configuring Security for Standalone Server

Described in surrounding text.

If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.

Note: If you do not have access to an LDAP server, click Cancel.

  • LDAP Server

    This field cannot be edited directly. Click the edit icon to display the Edit LDAP Server dialog shown in Figure 2-24.

    Figure 2-24 Editing the LDAP Server

    Described in surrounding text.
    • Host

      Enter the name of your LDAP host, such as ldap_server.your_company.com.

    • Port

      Enter the port number, such as 1066.

    • Principal

      This is the internal LDAP user name by which you connect to LDAP, such as cn=wlsproxyuser.

    • Password

      Enter the password used by the Principal. The password will be encrypted and stored in the cwallet.sso file, and not in the fusion_apps_wls.properties file.

    • SSL Enabled

      This value defaults to LDAP (not checked). Select this check box if you want to use LDAPS.

    • User Base DN

      Enter the User DN based your LDAP. A sample User DN resembles cn=users,dc=us,dc=your_company,dc=com.

      The DN (Distinguished Name) is the LDAP attribute that uniquely defines an object. Each DN must have a unique name and location.

      The components include cn=common name, ou=organizational unit, and dc=domain content. DC often is listed with two entries, dc=cp and dc=com.

    • Group Base DN

      Enter the Group DN based your LDAP. A sample Group DN resembles cn=groups,dc=us,dc=your_company,dc=com.

  • OPSS Server

    Defining the Oracle Platform Security Services (OPSS) Server is optional. Define this if its policy store is in a different location than your LDAP policy store. If OPSS-related properties are not specified, the domain is configured to use the XML-based Policy Store, such as system-jazn-data.xml.

    For information and directions on how to migrate the OPSS policy store using the migrateSecurityStore.py OPSS script, see:

    Figure 2-25 Editing the OPSS Server

    Described in surrounding text.
    • Host

      Enter the name of your LDAP host, such as ldap_server.your_company.com.

    • Port

      Enter the port number, such as 1066.

    • Principal

      This is the internal LDAP user name by which you connect to LDAP, such as cn=wlsproxyuser1.

    • Password

      Enter the password used by the Principal. The password will be encrypted and stored in the cwallet.sso file, and not in the fusion_apps_wls.properties file.

    • SSL Enabled

      This value defaults to not enabled. Select this check box if you want to enable SSL.

    • JPS Root Context

      Enter the JPS Root Distinguished Name, which is the top-level (outermost) node that contains OPSS data in an LDAP directory, such as cn=FAPolicies.

Click Next to display the Finish dialog shown in Figure 2-26.

Figure 2-26 Finishing the Standalone Domain Configuration

Described in surrounding text.
  • Click Finish to save the properties in the following file

    This value cannot be edited. The field simply shows the name of the fusion_apps_wls.properties file and the directory in which it will be created or updated.

  • To create the domain ...

    This value cannot be edited. The field simply shows the directory in which the script file will be created, and the name of the script file, FADevCreateDomain.py, you will need to run at the command line. See Section 2.3.3.1, "Creating a Domain for Standalone WebLogic Server."

  • Messages

    A message is displayed in this field if any errors occur in the definition. These errors must be corrected before you continue.

2.2.3 How to Start Integrated WebLogic Server

You can start Integrated WebLogic Server before running or deploying any applications. If you run an application without having already started Oracle WebLogic Server, JDeveloper will start it.

Starting Integrated WebLogic Server

There are two ways to start Integrated WebLogic Server.

  • Right-click and run a page from a project. If the server is not running, it will be started.

  • From the JDeveloper main menu, select Run > Start Server Instance, as shown in Figure 2-27.

    Figure 2-27 Start Server Using Start Server Instance

    Described in surrounding text.

Stopping Integrated WebLogic Server and the Application

To stop Integrated WebLogic Server or the application from either the Integrated Server window or from the JDeveloper menu bar, click the red stop button and select either the IntegratedWebLogicServer or the connection option, as shown in Figure 2-28.

Figure 2-28 Stopping Integrated WebLogic Server or the Application

Described in surrounding text.

If you select the connection option, the application will be undeployed and the server will remain running.

If you select the IntegratedWebLogicServer option, the deployed application will be undeployed and the server shut down. Wait for the application to be undeployed and the server to stop.

If the shutdown of Integrated WebLogic Server did not respond or shut down the server, click the red shutdown button again to kill the process, as shown in Figure 2-29.

Figure 2-29 Forcing Shutdown of Integrated WebLogic Server

Described in surrounding text.

If you still do not see the Process Exited message when you terminate Integrated WebLogic Server, you will have to manually kill the process.

Manually killing the process from Linux

  1. From a terminal window, execute this command.

    /usr/sbin/lsof -i -P | grep 7101
    

    Note:

    7101 is the default Integrated WebLogic Server port. It may be different.

  2. Kill the process. For instance, if the process is 15846, you would execute this command:

    kill -9 15846
    

Manually killing the process from Windows

  1. Start the Windows Task Manager.

  2. Click the Processes tab if it is not already active.

  3. Click the Image Name column heading to place the processes in an alphabetical order.

  4. Locate and select the java.exe process.

    Figure 2-30 Selecting the java.exe Process in Task Manager

    Selecting the java.exe process in Task Manager
  5. Right-click the process name and select End Process.

    Figure 2-31 Selecting End Process

    Selecting End Process

2.2.3.1 Managing Integrated WebLogic Server

The WebLogic Server Console is deployed by default and can be accessed to manage Integrated WebLogic Server. To access the WebLogic Server Console, enter the following URL in your web browser: http://<hostname.domainname>:<port>/console, such as http://localhost:7101/console.

2.3 Improving Shared and Personal Environments Performance

This section presents three situations whose security or performance can be improved:

  • Creating a local OWSM_MDS Schema

  • Using alternate database schemas

  • Running Standalone WebLogic Server from the personal environment

2.3.1 How to Create the OWSM_MDS Schema

This step is optional and depends on how the environment is set up and the type of security that is required.

The mds-owsm datasource must be correctly configured to point to an MDS schema. In the production environment, this schema would be in the LDAP infrastructure database.

To configure the datasource, you need to know the schema password. The recommendation is for the administrator to create a new MDS schema and give developers the password for it.

2.3.1.1 Creating the OWSM_MDS Schema

This section provides detailed snapshots on how to create the OWSM_MDS schema using the Oracle Fusion Applications Repository Creation Utility.

In a production environment, the OWSM_MDS schema is in the IDM database. The IDM is typically locked down so information such as schema passwords are not handed out. But, to configure the domain, the schema and the password are required to set up the mds-owsm datasource. The starter transaction database does not contain the OWSM_MDS schema. This is correct and the base template to create the starter transaction database should not be changed to include it. To avoid widely disseminating the schema password of the IDM database, an extra MDS should be added to the development's transaction database using the Oracle Fusion Applications Repository Creation Utility with a prefix of OWSM.

You do not have to do anything else apart from adding this schema. The schema will be correctly populated when your domain starts, if it does not already contain the correct data.

There may be several Oracle Fusion Applications Repository Creation Utilities available. To provision Oracle Fusion Applications, you will have created an installer repository. In this repository, you will see the following:

installers/
   fmw_rcu/
      linux/
         rcuHome_fusionapps_linux.zip
      windows/
         rcuHome_fusionapps_win.zip
   biapps_rcu/
   fmw_rcu/

Copy the appropriate ZIP file to your system from the installers/apps_rcu directory.

When you get the ZIP file to your machine, follow these steps:

Linux system

% mkdir fa_rcu
% cd fa_rcu
% cp /from_zip_file_location/rcuHome_fusionapps_linux.zip .
% unzip rcuHome_fusionapps_linux.zip
% cd bin
% ./rcu

Windows system

md fa_rcu
cd fa_rcu
copy \from_zip_file_location\rcuHome_fusionapps_win.zip .
unzip rcuHome_fusionapps_win.zip
\path_to_rcu_utility\rcu

The Oracle Fusion Applications Repository Creation Utility starts and displays the Create Repository dialog, shown in Figure 2-32.

Figure 2-32 Creating the Repository

Described in surrounding text.

Select Create and click Next to display the Database Connection Details dialog, shown in Figure 2-33.

Figure 2-33 Creating the Database Connection

Described in surrounding text.

Enter your database connection details and click Next to display the Checking Global Prerequisites dialog, shown in Figure 2-34.

Figure 2-34 Checking Global Prerequisites

Described in surrounding text.

Click OK to display the Select Components dialog, shown in Figure 2-35.

Figure 2-35 Selecting Components

Described in surrounding text.

Select Create a new Prefix and enter OWSM as the name.

Expand AS Common Schemas and select Metadata Services.

Click Next to display the Checking Component Prerequisites dialog, shown in Figure 2-36.

Figure 2-36 Checking Component Prerequisites

Described in surrounding text.

Click OK to display the Schema Passwords dialog, shown in Figure 2-37.

Figure 2-37 Setting Schema Passwords

Described in surrounding text.

Select Use same passwords for all schemas and enter the password for the OWSM_MDS schema in the Password and Confirm Password fields.

Click Next to display the Map Tablespaces dialog, shown in Figure 2-38.

Figure 2-38 Mapping Tablespaces

Described in surrounding text.

In the Default Tablespace field, select FUSION_TS_TOOLS.

In the Temp Tablespace field, select either FUSION_TEMP or TEMP3.

Click Next to display the Validating and Creating Tablespaces dialog, shown in Figure 2-39.

Figure 2-39 Validating Created Tablespaces

Described in surrounding text.

Click OK to display the Summary dialog, shown in Figure 2-40.

Figure 2-40 Summary

Described in surrounding text.

Verify the information and click Create.

When the operation has completed successfully, the Completion Summary dialog, shown in Figure 2-41, displays.

Figure 2-41 Completion Summary

Described in surrounding text.

Click Close.

The OWSM_MDS schema now can be used to configure the mds_owsm datasource in the domain.

2.3.2 How to Use Alternate Database Schemas

The main reason to use an alternate database is to improve performance. For instance, if the main database is remote, you can improve performance by installing the dehydration store, EDN, MDS and OraSDPM on your local machine.

To use an alternate database schema, follow these steps.

  1. Create the required database schemas, as shown in Example 2-2.

    Note:

    These steps need the number of processes in the database to be set to at least 200. If needed, log in as sysdba, run this command, and restart the database.

    alter system set processes=200 scope=SPFILE;
    

    Example 2-2 Creating database schemas

    Follow these steps if you are using a Linux operating system:

    cd $RCU_SHIPHOMELOC/bin
    DB_HOST=localhost
    DB_PORT=1521
    DB_SID=XE
    CONNECT_STRING=$DB_HOST:$DB_PORT:$DB_SID
    

    Follow these steps if you are using a Windows operating system:

    cd %RCU_SHIPHOMELOC%\bin
    set DB_HOST=localhost
    set DB_PORT=1521
    set DB_SID=XE
    set CONNECT_STRING=%DB_HOST%:%DB_PORT%:%DB_SID%
    
  2. Drop the Repository, as shown in Example 2-3. Enter the SYS password when prompted.

    Example 2-3 Dropping the repository

    Run this command if you are using a Linux operating system:

    ./rcu -silent -dropRepository -connectString $CONNECT_STRING -dbUser sys -dbRole sysdba -lockSchemas false -schemaPrefix SH -component SOAINFRA -component MDS -component ORASDPM -component BAM
    

    Run this command if you are using a Windows operating system:

    rcu.bat -silent -dropRepository -connectString %CONNECT_STRING% -dbUser sys -dbRole sysdba -lockSchemas false -schemaPrefix SH -component SOAINFRA -component MDS -component ORASDPM -component BAM
    

    If the -silent switch is omitted, a wizard will be launched. It will ask you to enter the same values as shown in Example 2-2.

  3. Recreate the Repository, as shown in Example 2-4. Enter the SYS password when prompted.

    Example 2-4 Recreating the repository

    Run this command if you are using a Linux operating system:

    ./rcu -silent -createRepository -connectString $CONNECT_STRING -dbUser sys -dbRole sysdba -lockSchemas false -schemaPrefix SH -component SOAINFRA -component MDS -component ORASDPM -component BAM
    

    Run this command if you are using a Windows operating system:

    rcu.bat -silent -createRepository -connectString %CONNECT_STRING% -dbUser sys -dbRole sysdba -lockSchemas false -schemaPrefix SH -component SOAINFRA -component MDS -component ORASDPM -component BAM
    

    Note:

    You will need to supply passwords for the different users. You will have to remember all the passwords because you will need them when you configure the DataSources.

2.3.3 How to Set Up the Personal Environment for Standalone WebLogic Server

Following the steps in this section will give you a portable working environment without needing access to the full environment until you are ready to deploy and unit test.

While the JDeveloper-based environment with Integrated WebLogic Server is useful in creating and validating customizations to the Oracle ADF artifacts, it cannot be used to validate SOA customizations. Anything that relies upon SOA infrastructure for development (such as BPM and ESS) will need the standalone environment in the following situations:

  • Rapid testing of development before publishing to the full development environment.

  • Remote access using either dial-up or VPN proves either to be too slow or unstable to connect to the full environment for successful deployment will benefit from the standalone environment installed locally on the developer's machine (64bit required).

To create this environment, you run Python scripts that are part of the JDeveloper-based environment and the repository of installer files that are used to create the shared environment. You first will have to create the JDeveloper-based environment, create or update the fusion_apps_wls.properties file, and then execute the scripts that are packaged with the fa_dev_bundle.zip extension bundle to create the standalone environment. One of the inputs to the Python script is the location of the repository that contains the installer files. You can use the Oracle Fusion Domain wizard from the JDeveloper-based environment to update the fusion_apps_wls.properties file such that it can be used in the standalone environment. So, the same properties file can be used to create both the JDeveloper-based environment and the standalone environment.

When the Python scripts are executed, they automatically do the following:

  • Create a lightweight MW_HOME directory that is a subset of the Middleware home that is available in the shared environment.

  • Create a Standalone WebLogic Server domain with an AdminServer and a ManagedServer.

  • Use the domainType defined in the fusion_apps_wls.properties file to apply appropriate WebLogic Server templates and set up system properties for Oracle Fusion applications.

  • Configure the domain with the data sources and the Identity Store that are available in the shared environment.

  • Configure the domain to either point to the LDAP-based Policy Store in the shared environment or a local XML-based Policy Store.

Typically in this environment, you have to deploy the exploded EAR directory of the application from the Middleware home of the shared environment using the WebLogic Server Console. Consequently, the adf-config.xml descriptor contains an MDS metadata store that points to the database in the shared environment and the customizations are picked up from the MDS repository. If you have created customizations on the filesystem using the JDeveloper-based environment, you should import those customizations to the MDS schema in the database that is running as part of the shared environment to test and validate them. When you import the customizations to the repository and database in the shared environment, it will affect all the developers who are using the shared environment. You will be able to test and validate the customizations by exercising all the applications that have a touch-point with the customized application, to ensure that things outside the application are working as expected.

Because Standalone WebLogic Server for SOA points to a separate SOAINFRA MDS schema, the customizations need to be exported and imported into the shared environment when they are successfully tested by developers.

See "Managing the Metadata Repository" in the Oracle Fusion Middleware Administrator's Guide.

Even though the Standalone WebLogic Server domain that is created as part of this environment is used to deploy the application from the same APPL_TOP and is configured to point to the same data sources, the Identity Store, and the Policy Store, as the domains that are part of the shared environment, you have the flexibility in setting up the domain that is part of the standalone environment in a way that it can work on a laptop or desktop without requiring excess resources. The domains that are created in the shared environment by the provisioning processes have one AdminServer and three ManagedServers. But, the domain in the standalone environment has just one AdminServer and one ManagedServer. You can decide whether to target SOA or ESS or various technologies at the ManagedServer based on the project.

2.3.3.1 Creating a Domain for Standalone WebLogic Server

Installer files are used to create and run Standalone WebLogic Server domains. You may need to obtain the files from an administrator.

Notes:

  • The installer repository on Windows must be a local or a mapped drive.

  • Windows and Linux operating systems must be 64-bit.

  • You are using the 64-bit version of the JDK.

This install also allows Oracle SOA Suite developers to create their domains without extra installs or steps.

2.3.3.1.1 How to Create a Special SOAINFRA Schema

If you are creating a SOA customization, a special SOAINFRA schema that is in the database in the shared environment may need to be created so your work does not interfere with the normal database.

Because the existing composites reference Web Service Description Language (WSDL) and schemas in MDS, when new SOAINFRA and MDS_SOA schemas are created for the standalone environment, all the WSDLs and schemas needed by the composites to be customized need to be exported from the shared MDS_SOA and imported into the new standalone MDS_SOA schema.

See "Managing the Metadata Repository" in the Oracle Fusion Middleware Administrator's Guide.

2.3.3.1.2 How to Set Up the Environment for Standalone WebLogic Server

Follow these steps to create a Standalone WebLogic Server environment. These steps assume that you already have downloaded and installed JDeveloper and the Fusion Apps Development Environment extension bundle.

  1. If you have not already done so, download and install the 64-bit JDK, preferably not to a directory location containing spaces, such as \Program Files.

    When installing JDeveloper, you will select the 64-bit JDK location you just installed.

    If a 32-bit JDK already was installed and used, you must delete the old %MW_HOME% installation and the system directory in %JDEV_USER_HOME% before reinstalling JDeveloper and the Oracle Fusion Applications extensions updates.

    If you are using Windows XP and encounter issues running Integrated Weblogic Server, you will need to change to the 64-bit version of Windows 7.

  2. You will need installer files from the provisioned environment. The site administrator should make the installer files available. When the system administrator downloaded the Oracle Fusion Applications DVDs and unzipped them, the installer files were placed in the installers directory that now contains numerous sub-directories. A directory listing looks similar to Figure 2-42.

    Figure 2-42 Installer Directory of a Provisioned Environment

    Explained in surrounding text.

    If you are not able to access a provisioned environment on a server, you will need to copy these directories (defined in the FADevInstallMwHome.py script file) and their contents from the installation disk to the installerLocation described in Table 2-3. (If you do not have the disk, you will need to download the entire 60GB Oracle Fusion Applications package from eDelivery.)

    • atgpf

    • biappsshiphome

    • bishiphome (if included on the release)

    • odi

    • soa

    • wc

    • weblogic

    • jdk

    This subset of the entire installation package is approximately 20GB in size, with biappsshiphome using approximately 10GB.

    Important:

    The installers directory is platform-specific. So if your production environment is Linux and you want to install Standalone WebLogic Server on a Windows machine, you will need to get the subset of installers from a Windows Oracle Fusion Applications download.

  3. Update the properties file that was created for Integrated WebLogic Server so that it can be used to create Standalone WebLogic Server:

    • In the Integrated WebLogic Server environment you already created, start JDeveloper, select the Oracle Fusion Applications Developer role, and launch the Oracle Fusion Domain wizard, as described in Section 2.2.2, "How to Use the Oracle Fusion Domain Wizard."

    • Select the Standalone Server option on the wizard's Usage dialog. Selecting this option creates or updates the fusion_apps_wls.properties and cwallet.sso files.

    • On the Domain dialog, set Installer Location to the directory that the administrator has provided. See Step 2.

      Set Domain Location appropriately, such as /path_to_domain/FAStandaloneDomain. Make sure that the directory name you enter does not exist.

  4. Create the Standalone WebLogic Server environment.

    • Set these environment variables:

      csh commands:

      setenv MW_HOME /path_to/FAStandalone_MW_HOME
      setenv JDEV_MW_HOME /path/to/JDeveloper/install_directory
      setenv ANT_HOME $JDEV_MW_HOME/jdeveloper/ant
      setenv JAVA_HOME /path/to/JDK/installation/directory
      

      bash commands:

      export MW_HOME=/path_to/FAStandalone_MW_HOME.
      export JDEV_MW_HOME=/path/to/JDeveloper/install_directory
      export ANT_HOME=$JDEV_MW_HOME/jdeveloper/ant
      export JAVA_HOME=/path/to/installed/JDK
      

      Windows command prompt commands:

      set MW_HOME=\path_to\FAStandalone_MW_HOME
      set JDEV_MW_HOME=\path\to\JDeveloper\install_directory
      set ANT_HOME=%JDEV_MW_HOME%\jdeveloper\ant
      set JAVA_HOME=C:\JDK_install_directory
      
    • mkdir /path_to/FAStandaloneWork

    • [for *nix only] chmod +x $JDEV_MW_HOME/jdeveloper/fadev/bin/*.py

    • [Windows]

      %JDEV_MW_HOME%\jdeveloper\fadev\bin\FADevInstallMwHome.py
      -m %MW_HOME%
      -i \path\to\installer_files
      -w \path_to\stagingdirectory
      -v
      
    • Create a lightweight MW_HOME directory by running the FADevInstallMwHome.py script. This script is installed when you install the Fusion Apps Development Environment extension bundle, described in Step 6 of Section 2.2.1.5, "Setting Up the JDeveloper-based Development Environment." Note that the options have been placed on separate lines for clarity. When you run the script, all must be on the same line.

      Run this command if you are using a Linux operating system:

      $JDEV_MW_HOME/jdeveloper/fadev/bin/FADevInstallMwHome.py
         -m $MW_HOME
         -i /path/to/installer_files
         -w /path_to/stagingdirectory
         -v
      

      Run this command if you are using a Windows operating system:

      %JDEV_MW_HOME%\jdeveloper\fadev\bin\FADevInstallMwHome.py
         -m %MW_HOME%
         -i \path\to\installer_files
         -w \path_to\stagingdirectory
         -v 
      

    Example 2-5 FADevInstallMwHome.py Options

    Valid options are:
       -m : MW_HOME (standalone - will be created if it does not exist)
       -i : Installer location (the provisioning repository)
       -w : Working/staging directory. Used for response files, unzip installers
            Defaults to the current directory
       -r : reinstall MW_HOME
       -v : verbose
    
    • -m <mw_home>: Use an MW_HOME directory other than the default, for an initial install or after it has already been created.

    • -i: The location of the installer files. This setting is required only for a Standalone WebLogic Server domain and overrides the installerLocation setting in the properties file.

    • -w: Set the working/staging directory for log and other temporary files.

    • -r: Reinstall the MW_HOME directory. Note that this will remove all items in the existing MW_HOME directory.

    • -v: Turn on verbose mode.

  5. Patch the MW_HOME directory.

    For the standalone domain creation to succeed, you must patch these directories in the standalone MW_HOME directory using the patches from the installer repository before executing the script to create the standalone domain. Otherwise, the standalone domain creation will not be complete and trying to deploy Oracle Fusion applications to the standalone domain will result in issues.

    • atgpf

    • biappsshiphome

    • bishiphome (if included on the release)

    • odi

    • soa

    • webcenter

    • oracle_common

    • Smart Update for Oracle Weblogic Server

    Follow these steps to patch the directories in the standalone MW_HOME directory using all the opatches that are in the repository. The example uses the atgpf directory. Except for the Smart Update for Oracle Weblogic Server, replace atgpf in the opatch command with the names of the other directories, such as odi and soa.

    Linux system

    % setenv ORACLE_HOME $MW_HOME/atgpf
    % setenv ATGPF_ORACLE_HOME $ORACLE_HOME
    % setenv JHOME $MW_HOME/jdk6 [Note: Must be a 64-bit JDK.]
    % setenv INV_LOC $ORACLE_HOME/oraInst.loc
    % setenv PATH $ORACLE_HOME/OPatch:$PATH
     
    % opatch napply <installer_repository_location>/installers/atgpf/patch -jdk $JHOME -invPtrLoc $INV_LOC
    

    Repeat, substituting the names of the other directories in place of atgpf.

    For the Smart Update, first change to the bsu directory:

    % cd installation_directory/utils/bsu
    

    Then use a command similar to the following, which installs the patch IRZ2 from the patch download directory that has been established for the current system:

    % bsu -prod_dir=Oracle/Middleware/wlserver_10.3 -patchlist=IRZ2 -verbose -install
    

    When executed, the preceding command displays the following output showing that the patch was successfully applied:

    Checking for conflicts.
    No conflict(s) detected
     
    Starting installation of Patch ID: IRZ2
    Installing /Oracle/Middleware/download-dir/IRZ2.jar
    Result: Success
    

    Windows system

    c:\> set ORACLE_HOME=%MW_HOME%\atgpf
    c:\> set ATGPF_ORACLE_HOME=%ORACLE_HOME%
    c:\> set JHOME=%MW_HOME%\jdk6 [Note: Must be a 64-bit JDK.]
    c:\> set PATH=%ORACLE_HOME%\OPatch;%PATH%
     
    opatch napply <installer_repository_location>\installers\atgpf\patch -jdk %JHOME%
    
    where -jdk is the location of the JDK under Oracle Fusion Middleware home.
     
    [Note: For Windows, do not specify the invPtrLoc command-line argument.]
    

    Repeat, substituting the names of the other directories in place of atgpf.

    For the Smart Update, first change to the bsu directory:

    cd c:\installation_directory\utils\bsu
    

    Then use a command similar to the following, which installs the patch IRZ2 from the patch download directory that has been established for the current system:

    bsu -prod_dir=c:\Oracle\Middleware\wlserver_10.3 -patchlist=IRZ2 -verbose -install
    
  6. Create, extend and configure the Standalone WebLogic Server domain by running the FADevCreateDomain.py script. Note that the options have been placed on separate lines for clarity. When you run the script, all must be on the same line.

    Run this command if you are using a Linux operating system:

    $JDEV_MW_HOME/jdeveloper/fadev/bin/FADevCreateDomain.py
       -m $MW_HOME
       -p $JDEV_MW_HOME/jdeveloper/system11.1.1.7.xx.yy.zz/o.jdevimpl.rescat2/fusion_apps_wls.properties
       -i /path/to/installer_files
       -w /path_to/FAStandaloneWork -v
    

    Run this command if you are using a Windows operating system:

    %JDEV_MW_HOME%\jdeveloper\fadev\bin\FADevCreateDomain.py
       -m %MW_HOME%
       -p %JDEV_MW_HOME%\jdeveloper\system11.1.1.7.xx.yy.zz\o.jdevimpl.rescat2\fusion_apps_wls.properties
       -i \path\to\installer_files
       -w \path_to\FAStandaloneWork
       -v
    

FADevCreateDomain.py options

If you execute FADevCreateDomain.py -help, the help shown in Example 2-6 will be displayed.

Example 2-6 FADevCreateDomain.py Options

-p : property file
-m : MW_HOME (standalone - will be created if does not exist)
-i : installer location (Provisioning repository)
     overrides installerLocation in the properties file
-w : working/staging directory for log and other temp files
-v : verbose
  • -p <properties file>: Use a different fusion_apps_wls.properties file to configure the domain.

  • -m <mw_home>: Use an MW_HOME directory other than the default, for an initial install or after it has already been created.

  • -i: The location of the installer files. This setting is required only for a Standalone WebLogic Server domain and overrides the installerLocation setting in the properties file.

  • -w: Set the working/staging directory for log and other temporary files.

  • -v: Turn on verbose mode.

2.3.3.1.3 How to Fix Domain Creation Errors

These three causes of a domain creation error are easily corrected:

  • The domain creation may fail in FADevCreateDomain.py related to the properties file such as:

    Creating domain for Fusion Applications Development ...
    ... checkWorkingDir
    ... checkPropFile
    Traceback (most recent call last):
    File "C:\Oracle\Middleware\jdeveloper\fadev\bin\FADevCreateDomain.py", line 546, in <module>
    checkPropFile()
    File "C:\Oracle\Middleware\jdeveloper\fadev\bin\FADevCreateDomain.py", line 146, in checkPropFile
    defaultPropFile= os.path.join(os.getenv('HOME'),'fusion_apps_wls.properties')
    File "C:\Python27\Lib\ntpath.py", line 96, in join
    assert len(path) > 0
    TypeError: object of type 'NoneType' has no len()
    

    For an Integrated WebLogic Server domain, this is caused by a Python installation issue. The suggested fix is to uninstall and re-install Python.

    For a Standalone WebLogic Server domain, the fix is to set the HOME environment variable. The recommended setting is to the user's home directory.

  • The domain creation fails with:

    File "C:\Oracle\Middleware\jdeveloper\fadev\bin\FADevFusionAppsDomain.py", line 1754, in targetSharedLibraries
    KeyError: oracle.appstrace.model
    

    There is a synchronization issue between the domain creation scripts and templates used. This can be fixed by adding the entries tagged with "WORKAROUND" in the FADevFusionAppsDomain.py:

    'oracle.appltest.diagfwk.executor':14,   # ess-soa-adf
    'oracle.appstrace.model':2,              # WORKAROUND
    'oracle.appstrace.webapp':2,             # WORKAROUND
    'oracle.bi.adf.model.slib':15,           # ess-soa-adf-admin
    
  • The domain creation can fail with:

    com.oracle.cie.domain.script.jython.WLSTException: com.oracle.cie.domain.script.jython.WLSTException:
      com.oracle.cie.domain.script.ScriptException: unable to parse "template-info.xml" from template jar 
    "c:\standalone\oracle_common\common\templates\applications\oracle.clickhistory_template_11.1.1.jar
    

    Check whether the oracle.clickhistory_template_11.1.1.jar file exists. If it does not exist, copy it from JDEV_HOME to the standalone home:

    C:\Oracle>copy \oracle\Middleware\oracle_common\common\templates\applications\oracle.clickhistory_template_11.1.1.jar \standalone\oracle_common\common\templates\applications
    
2.3.3.1.4 How to Test the Server

To test the server:

  • Start the server using a command line command similar to:

    [Windows]

    C:\standalone\fusion_domain\bin\startWebLogic.cmd
    

    [*nix]

    /standalone/fusion_domain/bin/startWebLogic.sh
    
  • Once started, it can be accessed from a web browser, using a URL similar to:

    http://1.23.45.678:7011/console
    
2.3.3.1.5 How to Manage the Standalone WebLogic Server Lifecycle

There will be times when you want to change the properties in fusion_apps_wls.properties, or point to a different Identity Store, or you may want to delete the domain and start from scratch. To do these, you will have to stop the running server, remove the domain directory, edit the properties file using the wizard, and recreate the domain. Follow these steps to accomplish the tasks. Remember to change any example directory names to the names you have used.

  • Stop the server

    When you stop the server, use the same shell that was used to create the domain and execute these commands:

    From Linux

    <path_to_stopManagedWeblogic.sh>/stopManagedWeblogic.sh
    

    If the script does not succeed, you will need to kill the process:

    ps
    kill -9 <pid_of_startWebLogic.sh> <pid_of_java>
    

    From Windows

    <path_to_stopManagedWeblogic.cmd>\stopManagedWeblogic.cmd
    

    If you had started the ManagedServer, you should kill it, too.

  • Remove the domain

    You may want to start over by removing the domain. Execute the following commands in a shell window:

    rm -rf /path/to/FAStandaloneDomain
    rm -rf /path/to/FAStandaloneWork/*
    

    Execute these commands from a command prompt if you are using a Windows operating system:

    rmdir /S /Q \path\to\FAStandaloneDomain
    rmdir /S /Q \path\to\FAStandaloneWork\*
    
  • Edit the fusion_apps_wls.properties file

    There may be times when you have to use a different Identity Store or modify some properties. In such an event, restart JDeveloper and follow these steps:

    • Manually launch the Oracle Fusion Domain wizard. See Section 2.2.2, "How to Use the Oracle Fusion Domain Wizard."

    • Right-click the Integrated Servers node and select the Configure Fusion Domain... option.

    • Select the Standalone Server option from the first wizard dialog.

    • Continue through the wizard, changing the property values as necessary.

  • Recreate the domain

    To do so, execute these commands. Note that the options have been placed on separate lines for clarity. When you run the FADevCreateDomain.py script, all must be on the same line.

    Run these commands if you are using a Linux operating system:

    rm -rf /path/to/FAStandaloneDomain
    rm -rf /path/to/FAStandaloneWork/*
    $JDEV_MW_HOME/jdeveloper/fadev/bin/FADevCreateDomain.py
       -m $MW_HOME
       -p $JDEV_MW_HOME/jdeveloper/system11.1.1.7.xx.xx.xx/o.jdevimpl.rescat2/fusion_apps_wls.properties
       -i /path/to/Repository/installers
       -w /path/to/FAStandaloneWork -v
    

    Run these commands if you are using a Windows operating system:

    rmdir /S /Q \path\to\FAStandaloneDomain
    rmdir /S /Q \path\to\FAStandaloneWork\*
    %JDEV_MW_HOME%\jdeveloper\fadev\bin\FADevCreateDomain.py
       -m %MW_HOME%
       -p %JDEV_MW_HOME%\jdeveloper\system11.1.1.7.xx.xx.xx\o.jdevimpl.rescat2\fusion_apps_wls.properties
       -i \path\to\Repository\installers
       -w \path\to\FAStandaloneWork
       -v
    

2.4 Using Deployment Profiles Settings

When creating an Oracle ADF library deployment profile, you can include connection information. When a project attaches that Oracle ADF library, the connection information is merged with its own connection information. This provides runtime consistency. The Oracle ADF library, by including the connection information, can ensure that all of the resources that it needs (the connections) are properly propagated to the consumers.

When creating an Oracle ADF library deployment profile, the default is to include all connection details for every connection in the connections.xml, which is a workspace level file. Subsequently, when the Oracle ADF library is attached to a project, all of the connections are merged with the connections.xml for that project's workspace. This causes a proliferation of the connections across Oracle Fusion Applications. While the propagation of the connections is desirable, it is propagating much more than is really needed.

Example of Connections Propagation

A Financials project creates an Oracle ADF library with the defaults. All of the connection information for that Financials workspace is included in the Oracle ADF library. HCM picks up that Oracle ADF library. HCM's workspace now contains all connections that HCM needs, and all of the connections from the Financials workspace. If the defaults are retained, all of HCM's projects contain connection information from Financials plus HCM. If CRM picks up any of those HCM Oracle ADF libraries, it merges the connection information into the CRM workspace; which now contains all of Financials plus HCM plus CRM.

2.4.1 How to Use Service Deployments

A project that contains an Oracle ADF Business Components-based service can have two purposes. The Oracle ADF Business Components code can be invoked as a service or it can be used as a regular Oracle ADF Business Components object. Oracle ADF provides two different deployment profiles to handle each of these cases.

For the service scenario, the BC Service Profile creates two JAR files. One is the Common one that contains information that is needed by the service invoker (Web Service Description Language (WSDL), XML schema definition (XSD), Service Interface). The MiddleTier one is an Enterprise JavaBeans (EJB) JAR file that contains the actual implementation.

For use as an Oracle ADF Business Components object, consumers must get an Oracle ADF library. That is the only way the Oracle ADF Business Components objects are exposed to consumers in the Oracle ADF Business Components design time wizards. Oracle ADF library also has no option for filtering, so it includes all the artifacts from the project including the WSDL, XSD, and Service Interface. Additionally, the Oracle ADF library includes the connection information for invoking the service. Because of this, developers inherit extra connection information if they want to use a service-enabled application module, not as a service, but as an application module.

Common must be an Oracle ADF library because consumers of this need a connection entry to be injected into the consumers' connections.xml file. This does not happen with ordinary JAR files.

2.4.2 How to Update the Standard

All Oracle ADF library deployment profiles should be updated to selectively include connections that are important to that one project. Common scenarios include:

  • Data Model Project

    • ApplicationDB database connection

    • ApplicationsRepository, if you use Attachments

    • Service connections for any ServiceFactory invocations

    • Essbase

  • User interface project

    • Portlet producers

    • Web Service Data Control connections

In the Edit ADF Library JAR Deployment Profile Properties dialog, choose to include Connection Name Only, as shown in Figure 2-43

Figure 2-43 Editing a Deployment Profile

Described in surrounding text.

2.5 Configuring the Oracle Enterprise Scheduler (ESS)

If you have elected to use Standalone WebLogic Server for Oracle Fusion Applications ESS development, you will need to perform the tasks in this section.

For information about using the Oracle Enterprise Scheduler, see the Oracle Fusion Middleware Developer's Guide for Oracle Enterprise Scheduler.

For information about setting up cross-domain security, see Enabling Trust Between WebLogic Server Domains.

Important:

The ESS and Fusion schema must be located in the same database and must be linked to each other.

Provisioning should set up all the required synonyms and grants between the schema. The FUSION schema has views, such as ESS_REQUEST_HISTORY, that are linked to the ESS schema. To validate that some linking is in place, check to see if the view works. (Although this is not a complete check of all links, it will fail if no linking has been established.)

2.5.1 How to Provision the Runtime Environment

Section 2.3.3, "How to Set Up the Personal Environment for Standalone WebLogic Server" shows how to configure the fusion_apps_wls.properties file and run the FADevConfigDomain.py script to stage and deploy the necessary infrastructure. For Oracle Enterprise Scheduler, you must ensure that you have configured the domainType property in the fusion_apps_wls.properties file to standalone, adminall or adminessadf. Example 2-7 shows correctly configured Oracle Enterprise Scheduler database and schema information, and ESS-related settings.

Example 2-7 Sample Showing Correctly-Configured Oracle ESS Database and Schema Information, and ESS-related Settings

[domain]
domainType=adminessadf
domainName=fusion_domain
listenPort=7011
soaPort=7012
wlName=weblogic
wlPassword=password
...
[wlsconfig]
fusionDbHost=host.example.com
fusionDbPort=1522
fusionDbSid=fusiondbsid
...
# leave oraessDbHost, oraessDbPort, oraessDbSid blank if using fusion database
oraessDbHost=
oraessDbPort=
oraessDbSid=
oraessDbUser=oraess_dbuser
oraessDbPassword=password
#
essMdsDbHost=
essMdsDbPort=
essMdsDbSid=
essMdsDbUser=fusion_mds_ess
essMdsDbPassword=password

After provisioning the runtime, you should create the supporting database schema before starting the managed servers which is covered in Section 2.5.2, "How to Create Supporting Database Schema."

2.5.2 How to Create Supporting Database Schema

There are two approaches to creating the database schema: using the Oracle Fusion Applications Repository Creation Utility or creating the schema using SQL scripts. The latter allows greater flexibility in the naming of the schema and user, but requires use of SQL*Plus.

For pre-requisite steps and configuration of the Oracle Enterprise Scheduler schema using the Oracle Fusion Applications Repository Creation Utility, see Section 2.3.2, "How to Use Alternate Database Schemas." Example 2-8 shows how to configure the Oracle Enterprise Scheduler schema using the Oracle Fusion Applications Repository Creation Utility schema.

Example 2-8 Configuring Oracle Enterprise Scheduler Schema Using the Oracle Fusion Applications Repository Creation Utility Schema

Run these commands if you are using a Linux operating system:

cd $RCU_SHIPHOMELOC/bin
DB_HOST=localhost
DB_PORT=1521
DB_SID=XE
CONNECT_STRING=$DB_HOST:$DB_PORT:$DB_SID
 
./rcu -silent -createRepository -connectString $CONNECT_STRING -dbUser sys -dbRole sysdba -lockSchemas false -schemaPrefix D8B2 -component ESS

Run these commands if you are using a Windows operating system:

cd %RCU_SHIPHOMELOC%\bin
set DB_HOST=localhost
set DB_PORT=1521
set DB_SID=XE
set CONNECT_STRING=%DB_HOST%:%DB_PORT%:%DB_SID%
 
rcu.bat -silent -createRepository -connectString %CONNECT_STRING% -dbUser sys -dbRole sysdba -lockSchemas false -schemaPrefix D8B2 -component ESS

Alternatively, creating the schema by running scripts in SQL*Plus can be performed as shown in Example 2-9

Note:

You should determine the appropriate TEMP tablespace by reviewing the entries in dba_tablespaces before attempting to run these scripts.

Example 2-9 Using SQL*Plus Scripts to Create Schema

cd $MW_HOME/rcu/rcu/integration/ess/sql
sqlplus sys/manager as sysdba;
@createuser_ess_oracle.sql oraess_d8b2 oraess_d8b2 SYSTEM TEMP;
connect oraess_d8b2/oraess_d8b2
@createschema_ess_oracle.sql  oraess_d8b2

2.5.3 Post-Installation Checks

Perform these steps to make sure the ESS installation was successful.

2.5.3.1 Verifying the Temp Directory Location and Write Permissions

The ESSAPP (also known as the ESS Base application) is the deployed infrastructure that supports the deployment of the product team Oracle Enterprise Scheduler applications, known as hosted applications. By default, this application writes all request log and output to a directory path known as the userFileDir, which is configured in the ess.xml file.

The ESS application defaults to file persistence mode and writes all the request log and output to a directory path known as the RequestFileDirectory, which is configured in the ESSAPP connections.xml file. By default, the temp directory will point to /tmp/ess/requestFileDirectory. Ensure that the directory exists and, if not, create it as the user who will start the ESS managed server.

2.5.3.2 Verifying ESS Artifacts Deployment Targets

Make sure ESS datasources and shared libraries are targeted to clusters and managed servers. Stop and Start WebLogic Servers as needed.

2.5.3.3 Checking ESS Health

Run ESS Health checks by accessing these links:

  • Checking health of an ESS Node: http:/<hostName>:<port>/EssHealthCheck/checkHealth.jsp

  • Checking health of an ESS Cluster: http:/<hostName>:<port>/EssHealthCheck/diagnoseHealth.jsp

2.6 Testing Your Installation

To test your JDeveloper and Oracle ADF installation, perform the following steps to create both a data model project and a user interface project, create an ApplicationDB database connection, and create and run a simple page.

  1. In JDeveloper, select the Application Navigator menu, then select New Application to open the Create Application wizard. See Figure 2-44.

    Figure 2-44 Naming Your Application

    Described in surrounding text.

    Tip:

    The name of the wizard changes according to the application template that is selected.

  2. Complete the following:

    Application Name: Enter Setuptest

    Application Package Prefix: Enter oracle.apps.test

    Application Template: Choose Fusion Web Application (ADF)

  3. Click Next to access the Name Your ADF-Model Project dialog. See Figure 2-45.

    Note:

    The system automatically will create data model and user interface projects for you. The default names for these projects that JDeveloper provides are Model and ViewController

    You can enter a new name for your data model project or you can keep the default name Model.

    Figure 2-45 Naming Your Oracle ADF Model Project

    Described in surrounding text.

    Note:

    The Project Technologies are automatically selected based on the application template that was chosen. You can select additional technologies if required.

  4. Click Next to access the Configure Java Settings for the ADF-Model dialog.

    This dialog displays the Java settings for your data model project. See Figure 2-46.

    Figure 2-46 Configuring Java Settings for the ADF Model

    Described in surrounding text.
  5. Click Next to access the Name Your ADF ViewController Project dialog.

    You can enter a new name for your user interface project or you can keep the default name ViewController. See Figure 2-47.

    Figure 2-47 Naming Your Oracle ADF User Interface Project

    Described in surrounding text.

    Note:

    The Project Technologies are automatically selected based on the application template that was chosen. You can select additional technologies if required.

  6. Click Next to access the Configure Java Settings for the ViewC... dialog.

    This dialog displays the Java settings for your user interface project. See Figure 2-48.

    Figure 2-48 Configuring Java Settings for the Oracle ADF User Interface Project

    Described in surrounding text.

    Click Finish to create your new application.

  7. Add the Applications Core, Applications Core (Attachments Model), Topology Manager, Functional Setup Model, BC4J Service Runtime, and Java EE 1.5 libraries to the data model project. See Section 3.3, "Adding Necessary Libraries to Your Data Model Project."

  8. Add the Applications Core (ViewController) tag library to the user interface project. See Section 3.4, "Adding the Applications Core Tag Library to Your User Interface Project."

  9. Add this option to the Model projects's Run options:

    -Doracle.jdbc.createDescriptorUseCurrentSchemaForSchemaName=true
    

    Note: Setting this JVM parameter helps avoid an error caused by the username for the current schema being set to "fusion" instead of "fusion_runtime" Setting the username to "fusion" results in incorrect data type associations. This parameter sets the username back to "fusion_runtime."

    To add the option:

    • Right-click the Model project and select Project Properties.

    • Select Run/Debug/Profile.

    • In the Run Configurations list, select Default and click Edit.

    • Select Launch Settings.

      As shown in Figure 2-49, enter the option string in the Java Options field.

      Figure 2-49 Adding a Java Option to the Run Configuration

      Described in surrounding text.
    • Click OK.

    • Click OK.

  10. The ApplicationDB database connection is created automatically when the Applications Core library is attached to the model project. However, you will need to adjust the values that are defined in the connection to reflect the database you want to use. See Section 3.6, "Creating or Updating a Database Connection." For this example, enter these connection details:

    Connection Type: Choose Oracle (JDBC)

    Username / Password: Enter the username and password for your team's Fusion_Runtime database schema.

    Deploy Password: Select this option.

    Host Name: Enter the host name, such as my.host.com

    JDBC Port: Enter the port number for your database.

    SID: Enter the database name, such as mydb.

  11. Choose Application Navigator > Model. Right-click and choose New from the menu to open the New Gallery.

  12. Choose the Business Tier > ADF Business Components category. Select the Business Components from Tables item to launch the Create Business Components from Tables wizard. See Figure 2-50.

    Figure 2-50 Create Business Components from Tables — Entity Objects

    Described in surrounding text.
  13. Complete the following to create your entity object:

    1. Filter Types: Select only Tables to narrow your search for schema objects.

    2. Filter Name: Enter a filter, such as %EMP% to narrow your search to tables.

    3. Query: Click this button to perform your search.

      Note:

      The results of your search displays in the Available column.

    4. Choose the required object, such as FND_DEMO_EMP and click > to shuttle it over to the Selected column.

    5. Click Next to go to the next step in the wizard.

  14. Choose the required entity object located in the Available column and click > to shuttle it over to the Selected column. See Figure 2-51.

    Figure 2-51 Create Business Components from Tables — Updatable View Objects

    Described in surrounding text.
  15. Click Finish to create your updateable view object and to close the Business Objects wizard.

  16. Ensure that your application module configuration is using JDBC data source.

    This is required for your application module to run on the WebLogic Server.

    To update your application module configuration:

    1. Go to the Application Navigator and select your application module. Right-click and select Configurations from the menu.

    2. Choose the configuration <AM Name>Local, then choose Edit.

    3. Change the Connection Type to JDBC DataSource and Datasource Name to java:comp/env/jdbc/ApplicationDBDS. Click OK.

  17. Validate your model with the Business Component Tester to make sure that the ApplicationDBDS data source has been configured for the Integrated WebLogic Server environment.

    In the Navigator tree, right-click the application module and select Run, as shown in Figure 2-52.

    Figure 2-52 Running the Application Module

    Described in surrounding text.

    If your installation is set up correctly, a dialog similar to that shown in Figure 2-53 displays. If an error message displays, you will need to re-check that the previous steps have been performed correctly.

    Figure 2-53 Application Module in Business Component Browser

    Described in surrounding text.

    In this example, right-click FndDemoEmpView1 and select Show to display data, as shown in Figure 2-54.

    Figure 2-54 Showing Data in the Business Component Browser

    Described in surrounding text.
  18. Choose Application Navigator > ViewController. Right-click and select New from the menu to open the New Gallery.

  19. Choose the Web Tier > JSF category. Select the JSF Page item and click OK to open the Create JSF Page dialog.

  20. Complete the following:

    • File Name: Enter Setup.jsp

    • Select to create jspx file.

    • Click OK.

  21. Go to the Data Controls panel and drag the collection onto the open Setup.jspx window. See Figure 2-55.

    Figure 2-55 Data Controls Panel - FndDemoEmp1 Collection

    Described in surrounding text.
  22. Select to create Forms > ADF read-only from the context menu that displays. See Figure 2-56.

    Figure 2-56 Context Menu

    Described in surrounding text.
  23. Remove some of the rows that are displayed in the opened dialog so that your page only lists a few fields. Select the Include Navigation Controls checkbox and click OK. See Figure 2-57.

    Figure 2-57 Editing Form Fields

    Described in surrounding text.
  24. Click the Run button located on the toolbar to run your page.

    Note:

    Make sure the URL uses the full host name. For instance, if the displayed URL is http://127.0.0.1:7101/ApplCoreCRMDemo/faces/Region6UIShellPage, you should edit it manually so it appears similar to http://myhost.name.com:7101/ApplCoreCRMDemo/faces/Region6UIShellPage.

    When your page is displayed, you can use the buttons that appear at the bottom of your page to view next and previous employees.

2.7 Using Best Practices for Setting Up the Development Environment

Implementing these best practices when using JDeveloper will significantly reduce problems.

2.7.1 How to Implement Best Practices for JDeveloper

These recommendations are specific to improving the performance of JDeveloper.

Increase the Number of Lines in the Log Message Window

The default of 3000 lines generally is insufficient for Oracle Fusion applications, and important errors and exceptions may be removed too quickly. The solution is to increase the number of lines, such as to 30000. Whenever you create a new view and run JDeveloper for the first time, increase the limit. Open Tools > Preferences Environment > Log and edit the Maximum Log Lines setting.

Running JDeveloper in Verbose Mode

You can run JDeveloper in its default non-verbose mode, or in its verbose mode.

  • jdev: The default non-verbose mode limits the amount of information displayed to the console. This helps you focus on the important information being displayed.

  • jdev -v: The verbose mode displays all the information to your console. Although this information is not useful for everyday workflow, when something goes wrong, more information can help you debug your problem.

Increase the minimum / maximum heap size for JDeveloper (and other Java parameters)

This is specifically about increasing the heap size for JDeveloper, since JDeveloper itself is a Java executable and runs in its own Java Virtual Machine (JVM). This will not affect Integrated WebLogic Server; for that you set USER_MEM_ARGS, since it's a separate process and therefore a separate JVM.

To change the values for minimum and maximum Java heap, modify the corresponding parameters in $jdev_install/ide/bin/ide.conf.

Other parameters can be set in $jdev_install/jdev/bin/jdev.conf.

Do not set Xms or Xmx in the jdev.conf file because it will just result in duplicating the parameter on the command line because it already is set in the ide.conf file. You can add any other parameter than is not already passed on the command line in this file, using the same format as the existing parameters.

Enable the JDeveloper Java heap meter

You can enable the JDeveloper heap monitor (that is, the heap, permgen, and dustbin icon that forces garbage collection on the status bar of the main jdev window). Add this line to the $jdev_install/jdev/bin/jdev.conf file.

     AddVMOption -DMainWindow.MemoryMonitorOn=true

The heap monitor shows the current size of the heap; not necessarily the maximum size. The heap is created at the specified minimum size. When additional space is required, and if garbage collection cannot free up enough space, the heap size is increased. If the heap reaches its maximum and there still is not enough space after garbage collection, an OutOfMemoryException is thrown.

2.7.2 How to Refresh the Oracle ADF Library Dependencies Library

The Oracle ADF Library Dependencies library is refreshed by doing the Refresh ADF Library Dependencies.

  • There is a new library file per project in the project directory. This file will only exist if the project has unresolved deployment dependencies required by the directly-imported Oracle ADF JAR files in the project.

  • The file should be added to the project source-controlled file set.

  • The file should be included in all transactions where it was updated during the design time.

  • If a runtime exception, such as No Def Found or No Class Def Found occurs, the project menu command to refresh the Oracle ADF Library Dependencies is necessary to update the file. This could happen because of updated lower-level dependency changes outside of the design time session.

2.7.3 How to Manage OutOfMemory Exceptions (PermGen)

When you use Integrated WebLogic Server, make sure the USER_MEM_ARGS environment variable is set before starting JDeveloper.

USER_MEM_ARGS=-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000
  • The csh command is: setenv USER_MEM_ARGS "-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000"

  • The bash command is: export USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000"

Verify that it is set correctly.

$ env | grep USER_MEM_ARGS

$USER_MEM_ARGS is read by the WebLogic Server startup scripts, and is used to override the default JVM memory settings. If using the default MaxPermSize=256M, you will regularly get outOfMemoryExceptions due to exhausted permGen. Setting permGen higher doesn't completely fix the problem, but it does mean you can work longer before deployment fails with a permGen-related outOfMemoryException.

In the JDeveloper message log window, you will see this line when Integrated WebLogic Server is started. Make sure it reflects the overridden values defined in $USER_MEM_ARGS.

JAVA Memory arguments: -Xms256M -Xmx1024M -XX:CompileThreshold=8000 -XX:PermSize=64M -XX:MaxPermSize=512M

Remember that overriding the Java memory arguments is a balancing act, and if you set them too high for your machine resources, either JDeveloper or WebLogic Server may fail to start, may hang, or may fail with a resource-related exception. For example, setting XX:MaxPermSize=1024m may be too high. If you experience problems after increasing the permanent generation size, try unsetting $USER_MEM_ARGS to see if it could be the cause.

Example exceptions

java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:344)
Truncated. see log file for complete stacktrace

Sometimes deployment just becomes very slow before it eventually fails.

When you hit OutOfMemoryExceptions, if you then try and close Integrated WebLogic Server, the first attempt may fail because it is in a bad state. If you try a second time, JDeveloper now does a kill -9, which should clear it. You should no longer need to kill WebLogic Server by manually issuing the kill command from another terminal session. However, if you ever do need to, try identifying the WebLogic Server process. This command assumes that you are using the default port 7101.

$ "/usr/sbin/lsof -i -P | grep 7101"

If you have another instance of WebLogic Server running, and the port is already in use, JDeveloper will use another port. Also, you may have changed the port in fusion_apps_wls.properties.

This command lists the Java processes with the full command line, which should help you to identify the WebLogic Server process.

$ ps -elf | grep java | grep <userid>

2.7.4 How to Work with Oracle ADF Libraries at Design Time

Every data model or user interface project should have an Oracle ADF library deployment profile. Service projects are the exception.

Oracle ADF libraries should be added to your project using the Resource Catalog by creating a File connection. From there, you can right-click any of the libraries and select Add to Project. Then all Oracle ADF libraries get managed under a Library called ADF Libraries. Mixing and matching different methods of adding Oracle ADF libraries can cause them to appear under different Libraries and sometimes under multiple libraries. That makes it hard to manage.

All references to components contained in Oracle ADF libraries are resolved when the workspace is loaded in JDeveloper. If a reference to a component or Java class in an Oracle ADF library cannot be resolved because, for instance, it does not exist or is incompatible with the existing reference, you probably will receive a compilation error.

Closing and restarting JDeveloper with a workspace open does not refresh the references to Oracle ADF libraries. Closing the workspace, and re-opening it does.

If you have a specific project selected in the JDeveloper navigator pane, select View > Refresh ADF Library Dependencies for *.jpr to refresh the references to Oracle ADF libraries.

When you make any changes to the components in a project, where the components are being referenced as an Oracle ADF library by your user interface project, you need to redeploy the Oracle ADF library and refresh the Oracle ADF library dependencies for your user interface project. The same applies to one model project referencing from another model project.

If you are developing or debugging code in a data model project while running the referencing user interface project to test it, it may be easier to add the model project as a build output dependency, so you do not have to go through the cycle of redeploying the Oracle ADF library or refreshing Oracle ADF library references each time you make a change.