| Oracle® Fusion Applications Developer's Guide 11g Release 6 (11.1.6) Part Number E15524-11 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 6 (11.1.6) Part Number E15524-11 |
|
|
PDF · Mobi · ePub |
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:
Section 2.2, "Setting Up the JDeveloper-based Personal Environment"
Section 2.3, "Improving Shared and Personal Environments Performance"
Section 2.4, "Configuring Oracle SOA Suite and Oracle Enterprise Manager Fusion Middleware Control"
Section 2.6, "Configuring the Oracle Enterprise Scheduler (ESS)"
Section 2.8, "Using Best Practices for Setting Up the Development Environment"
Section 2.9, "Configuring Hierarchy Providers for Approval Management (AMX)"
Note:
This chapter assumes that you are using a 64-bit operating system although JDeveloper works well in a 32-bit environment.
However, 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 a number of Oracle Homes and the Oracle Business Intelligence installation is 64-bit only.
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.
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.
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.
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.
Each developer has this 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 without affecting other team members.
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
Once an Integrated or a Standalone WebLogic Server has been launched, you will need to deploy the oracle.apps.common.resource.ear shared library. You may need to get the location of the file from an administrator and then use the WebLogic Server Console to deploy it as a shared library using oracle.apps.common.resource as the name. See Section 2.2.3.1, "Managing Integrated WebLogic Server."
You assemble this environment on your machine by performing these steps in this order:
Installing JDeveloper
Installing Extension Bundles
Applying patches (if necessary)
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.
Before you can use JDeveloper, there are several things you need to do.
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 running. This process may prevent you from entering a password in the Oracle Fusion Domain wizard or anywhere a JPasswordField occurs. You can remove SCIM from your system by executing this command.
sudo yum remove scim
You also 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.
This system configuration change is required on local Linux servers to increase the open file limit and resolve a number of JDeveloper, WebLogic Server and other "Too many files" errors when doing a build or merge.
Add these two instructions to the /etc/security/limits.conf file:
soft nofile 8192
hard nofile 8192
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
JDeveloper is supplied on the Oracle JDeveloper 11g and Oracle Application Development Framework 11g (11.1.1.5.3) disk. JDeveloper support files, such as extensions, are supplied on the Oracle Fusion Applications Companion 11g (11.1.1.5.3) disk. Your administrator may choose to make the contents of the disks available on a shared directory that will have the same directory structure as the disks. We strongly recommend that the administrator make the contents of the Oracle Fusion Applications Companion 11g (11.1.1.5.3) disk available on a shared directory.
Note:
The directions in this section assume that you are installing from the disk.
Install the Studio edition of JDeveloper from the top-level directory of the Oracle JDeveloper 11g and Oracle Application Development Framework 11g (11.1.1.5.3) disk.
For Windows, you can use the jdevstudio11115install.exe installer. For Linux, you can use the jdevstudio11115install.bin installer. If you decide to use the generic jdevstudio11115install.jar installer, you must first install JDK 6 Update 24 from the Oracle Technical Network and then install JDeveloper using the generic installer.
The installation will let you specify the directory into which to install JDeveloper. 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 on the Oracle Fusion Applications Companion 11g (11.1.1.5.3) disk. See Section 2.2.1.5, "Setting Up the JDeveloper-based Development Environment."
For more installation information, see the Oracle Fusion Middleware Installation Guide for Oracle JDeveloper (Oracle Fusion Applications Edition).
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. You will have to get one or more paths from an administrator. The administrator can use these steps to locate the JAR files:
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 to find it.
Follow these steps to create a development environment based on Integrated WebLogic Server:
From a command prompt, run python -V to see if you have Python 2.4.3 or later on your machine. If you do not, install Python version 2.4.3 or newer.
Set these environment variables:
csh commands:
setenv PATH /path/to/python/bin:$PATH setenv MW_HOME /path/to/JDeveloper/installation/directory setenv JAVA_HOME $MW_HOME/jdk160_24 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 MW_HOME=/path/to/JDeveloper/installation/directory export JAVA_HOME=$MW_HOME/jdk160_24 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 MW_HOME=\path\to\JDeveloper\installation\directory (Important: The path must not contain spaces.) set JAVA_HOME=%MW_HOME%\jdk160_24 (Recommended: 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
Change directory to $MW_HOME/jdeveloper/jdev/bin.
Open the jdev.conf file in a text editor and add this line:
AddVMOption -Djdev.wlst.env.vars=HOME,JDEV_USER_HOME
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 |
|---|---|---|
|
|
/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. |
|
|
true |
Optional. |
|
|
true |
Optional. |
|
|
/usr/bin/firefox |
Location of the browser executable specific to the environment at the customer's site. |
|
|
true |
|
|
|
recreate |
|
|
|
true |
|
|
|
true |
|
|
|
false |
|
|
|
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. |
|
|
512M |
|
|
|
||
|
|
||
|
|
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.
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 to access all of JDeveloper's features. The other roles provide subsets of these features. |
|
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 or not to migrate settings, you should click No.
Install the Fusion Apps Development Environment extension bundle, an all-encompassing JDeveloper bundle that is specific for Oracle Fusion Applications. To install the bundle:
Select Help > Check for Updates.
Click Next past the Welcome dialog.
If the Proxy Setup dialog displays, enter the applicable information for your situation, as shown in Figure 2-2.
Ignore any error messages that might be displayed when you click the Test Proxy button.
Click OK. The Source dialog, shown in Figure 2-3, displays.
Unselect any marked Update Centers.
Click Add to display the Update Center dialog, shown in Figure 2-4.
Enter a name for the new Update Center, such as Oracle Fusion Applications Update Center.
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.5.3) disk in the fusion_apps_extensions directory, or on a shared directory provided by the administrator.
Click Open.
Click OK.
Select the newly-defined Update Center, as shown in Figure 2-6.
Note that only the new Update Center should be selected.
Click Next to display the Updates dialog, shown in Figure 2-7. Note that, initially, no updates will be selected.
Select the Fusion Apps Development Environment extension bundle. The other bundles automatically will be selected.
Click Next to display the Download dialog and start the download, as shown in Figure 2-8.
When the download finishes, the Summary dialog, similar to that shown in Figure 2-9, displays automatically.
Click Finish. If you are using JDeveloper on a Linux system, the Confirm Exit prompt shown in Figure 2-10 displays.
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.
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.
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."
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."
Once JDeveloper is up, the environment should have all the components in the correct locations. You should be able to create new, or customize existing, Oracle Fusion applications.
There are two options for how a developer can use the OWSM_MDS 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.
The administrator will 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.
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.5.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.5.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.
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. Note that the properties file and the cwallet.sso file must be in the same location.
The wizard can be run multiple times to change properties in the file. If certain critical properties are changed, the domain may 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.
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 |
|---|---|---|---|---|
|
|
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. |
|
|
Standalone |
Yes |
fusion_domain |
|
|
|
Standalone |
Yes |
The location in the file system in which the domain will be created. If it is not specified, the domain will be created in the default location which is |
|
|
|
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. See Section 2.3.3.1.2, "How to Set Up the Environment for Standalone WebLogic Server." for a list of the files needed. |
|
|
|
Standalone |
Yes |
Default based on Standalone or Integrated. Default is 7011 for Standalone WebLogic Server. |
|
|
|
Standalone |
Yes, only when domainType is adminsoa/adminall. |
Needed for adminsoa and adminall. As this is on their own machines, developers choose the values. |
|
|
|
Standalone |
Yes, only when domainType is adminess. |
As this is on their own machines, developers choose the values. |
|
|
|
Both |
Yes |
weblogic |
|
|
|
Both |
Yes |
NA |
Users must supply the password by using the wizard. |
|
|
Both |
Yes |
This is a string value similar to: |
|
|
|
Both |
Yes |
Example: |
|
|
|
Both |
Yes |
Example: |
|
|
|
Both |
Yes |
Example: Important: In the UI, the password will display as the normal ******* mask. The password is not saved in the |
|
|
|
Both |
Yes |
Example: |
|
|
|
Both |
Yes |
Example: |
|
|
|
Both |
No |
false |
true or false |
|
|
Standalone |
No |
Optional separate OPSS store. This is a string value similar to: For Integrated WebLogic Server, the DefaultDomain uses the XML-based Policy Store (such as |
|
|
|
Standalone |
No |
Example: |
|
|
|
Standalone |
No |
Example: |
|
|
|
Standalone |
No |
Important: In the UI, the password will display as the standard ***** mask. The password is not saved in the |
|
|
|
Standalone |
No |
false |
true or false |
|
|
Standalone |
No |
Text field Example: |
|
|
|
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. |
|
|
|
Both |
Yes |
Family names are: COMMON, IC, HCM, FIN, PRC, PRJ, SCM, and CRM. |
|
|
|
Both |
Yes |
JDBC connect string. Note: This is split into sub-fields:
This is applicable to these schemas:
|
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
Yes, but the database connection is the same as for |
You can connect to the |
|
|
|
Both |
Yes, but the database connection is the same as for |
Note: CRM will be replaced with the You can connect to the |
|
|
|
Both |
Yes, but the database connection is the same as for |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
You can connect to the |
|
|
|
Both |
No |
Family name used in prefix. You can connect to the |
|
|
|
Both |
No |
Family name used in prefix. You can connect to the |
|
|
|
Both |
No |
You can connect to the |
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."
The wizard will start automatically if the fusion_apps_wls.properties file is not found when you start JDeveloper. You also can start the wizard manually. See Section 2.2.2, "How to Use the Oracle Fusion Domain Wizard."
If the fusion_apps_wls.properties file is not found when you start JDeveloper, the prompt shown in Figure 2-15 displays.
Click Yes to launch the wizard and display the Usage page, as shown in Figure 2-16.
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. Creating a Standalone WebLogic Server domain must be done from the command line using the fusion_apps_wls.properties file as input. See Section 2.3.3, "How to Set Up the Personal Environment 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.
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-17, displays.
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
Leave this at the default value.
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-18
If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.
Notes:
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. For example, if the password of the Activities credential happens to be fooBar812 instead of fusion_activities (which is the schema name), you should select the Activities credential from the list and provide the password for the fusion_activities schema as fooBar812 in the Password field. The Username field will contain fusion_activities. You do not have to provide anything in the Connect String field for this schema, as it will be in the same database.
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. Once 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
A number of 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-19.
If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.
LDAP Server
This field cannot be edited directly. Click the edit icon to display the Edit LDAP Server dialog shown in Figure 2-20.
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 different name and location from all other objects in Active Directory.
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-21.
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.
When you select the Standalone Server Usage option and click Next, the Domain dialog, shown in Figure 2-22, displays.
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.
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.
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
Leave this at the default value.
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-23
If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.
Notes:
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. For example, if the password of the Activities credential happens to be fooBar812 instead of fusion_activities (which is the schema name), you should select the Activities credential from the list and provide the password for the fusion_activities schema as fooBar812 in the Password field. The Username field will contain fusion_activities. You do not have to provide anything in the Connect String field for this schema, as it will be in the same database.
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. Once 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
A number of 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-24.
If the fusion_apps_wls.properties file already exists and is in place, the fields will show the values that are in the file.
LDAP Server
This field cannot be edited directly. Click the edit icon to display the Edit LDAP Server dialog shown in Figure 2-25.
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 different name and location from all other objects in Active Directory.
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.
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-27.
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.
Integrated WebLogic Server and the deployed applications are separate entities. You can start Integrated WebLogic Server before running or deploying any applications.
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-28.
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-29.
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-30.
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 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.
Kill the process. For instance, if the process is 15846, you would execute this command:
kill -9 15846
The WebLogic Server Console can be deployed and 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.
This section presents three situations whose performance can be improved:
Creating a local OWSM_MDS Schema
Using alternate database schemas
Running Standalone WebLogic Server from the personal environment
Typically, and particularly in a test environment and a production environment, this schema is in the Oracle Identity Manager (IDM) database. In the case of a development environment, being able to access the Oracle Web Services Manager_Metadata Service (OWSM_MDS) schema provides the same options that Oracle Fusion Applications developers at Oracle have.
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 needs to 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. If the administrator allows all developers to know the schema password for this MDS schema, then a new MDS schema does not need to be created.
If the schema password is locked down, then follow the steps in this section to create a new MDS schema for OWSM use. See Section 2.3.1.1, "Creating the OWSM_MDS Schema."
If you have a local database, you probably will want to create the schema in the local database.
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 a number of 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/
apps_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.
Once 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-31.
Select Create and click Next to display the Database Connection Details dialog, shown in Figure 2-32.
Enter your database connection details and click Next to display the Checking Global Prerequisites dialog, shown in Figure 2-33.
Click OK to display the Select Components dialog, shown in Figure 2-34.
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-35.
Click OK to display the Schema Passwords dialog, shown in Figure 2-36.
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-37.
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-38.
Click OK to display the Summary dialog, shown in Figure 2-39.
Verify the information and click Create.
When the operation has completed successfully, the Completion Summary dialog, shown in Figure 2-40, displays.
Click Close.
The OWSM_MDS schema now can be used to configure the mds_owsm datasource in the domain.
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.
Create the required database schemas, as shown in Example 2-1.
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;
Drop the Repository, as shown in Example 2-2. Enter the SYS password when prompted.
Example 2-2 Dropping the repository
./rcu -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-1.
Recreate the Repository, as shown in Example 2-3. Enter the SYS password when prompted.
Example 2-3 Recreating the repository
./rcu -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 should make the username and the password for that user the same, such as jmaus/jmaus. You will have to remember all the passwords. You will need them when you configure the DataSources.
Following the steps in this section will give you a portable workspace 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 need 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. As a result, 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 once 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.
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.
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.
Important: You must use the Oracle Fusion Applications Administrator Customization role for customizing SOA Composites.
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.
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.
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.
You will need installer files from the provisioned environment. The site administrator should make the installer files available.
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.
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.
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
chmod +x $JDEV_MW_HOME/jdeveloper/fadev/bin/*.py
Create a working/staging directory, such as C:\standaloneStage on a Windows installation, to be used during the installation.
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.
$JDEV_MW_HOME/jdeveloper/fadev/bin/FADevInstallMwHome.py -m $MW_HOME -i /path/to/installer_files -w /path_to/stagingdirectory -v
Example 2-4 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.
Patch the MW_HOME directory. For more information, see the Oracle Fusion Middleware Patching Guide.
For the standalone domain creation to succeed, you must patch the atgpf directory 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.
Follow these steps to patch the atgpf directory in the standalone MW_HOME directory using all the opatches that are in the repository:
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
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 C:\jdk_installed_location
where -jdk is the location of the JDK under Oracle Fusion Middleware home.
[Note: For Windows, do not specify the invPtrLoc command-line argument.]
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.
$JDEV_MW_HOME/jdeveloper/fadev/bin/FADevCreateDomain.py -m $MW_HOME -p $JDEV_MW_HOME/jdeveloper/system11.1.1.5.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-5 will be displayed.
Example 2-5 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.
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()
This is caused by a Python installation issue. The suggested fix is to uninstall and re-install Python.
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
To test the server:
Start the server using a command line command similar to:
C:\standalone\fusion_domain\bin\startWebLogic.cmd
Once started, it can be accessed from a web browser, using a URL similar to:
http://1.23.45.678:7011/console
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 xterm that was used to create the domain and execute these commands:
ps kill -9 <pid_of_startWebLogic.sh> <pid_of_java>
If you had started the ManagedServer, you should kill it, too.
Remove the domain
You may want to start over by removing the domain. Use the same xterm that was used to create the Standalone WebLogic Server domain and execute these commands:
rm -rf /path/to/FAStandaloneDomain rm -rf /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.
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.5.xx.xx.xx/o.jdevimpl.rescat2/fusion_apps_wls.properties -i /path/to/Repository/installers -w /path/to/FAStandaloneWork -v
This section discusses configuration options for the Oracle Service Oriented Architecture Suite and Oracle Enterprise Manager Fusion Middleware Control servers.
Note:
Only Oracle SOA Suite applications developers need to perform these steps.
To use the Application Logging Service, complete these steps.
Set up your environment to use the Oracle SOA Suite and Java Apps Logger.
Update the oracle.soa.bpel.jar, file as shown in Example 2-6.
Example 2-6 Updating the oracle.soa.bpel.jar
cp $MW_HOME/jdeveloper/jdev/oaext/services/Applcore-Logging-XPath.jar $MW_HOME/jdeveloper/soa/modules/oracle.soa.ext_11.1.1 cp $MW_HOME/jdeveloper/jdev/oaext/services/Applcore-Logging-XPath.jar $MW_HOME/jdeveloper/soa/modules/oracle.soa.ext_11.1.1 $MW_HOME/modules/org.apache.ant_1.7.0/bin/ant -f $MW_HOME/jdeveloper/soa/modules/oracle.soa.ext_11.1.1/build.xml
Update the soa-infra-wls.ear file, as shown in Example 2-7.
Example 2-7 Updating soa-infra-wls.ear
pushd $MW_ORA_HOME/soa/applications mkdir -p soa-infra-wls cp soa-infra-wls.ear soa-infra-wls.ear.orig cd soa-infra-wls #add library reference unzip -o ../soa-infra-wls.ear META-INF/weblogic-application.xml mv META-INF/weblogic-application.xml META-INF/weblogic-application.xml.orig sed '/<\/weblogic-application>/i<library-ref>\n <library-name>oracle.applcore.model</library-name>\n</library-ref>\n<library-ref>\n <library-name>Diagnostics-Engine</library-name>\n</library-ref>' META-INF/weblogic-application.xml.orig > META-INF/weblogic-application.xml rm META-INF/weblogic-application.xml.orig zip -f ../soa-infra-wls.ear META-INF/weblogic-application.xml #add resource reference unzip -o ../soa-infra-wls.ear ejb_ob_engine_wls.jar unzip -o ejb_ob_engine_wls.jar META-INF/ejb-jar.xml mv META-INF/ejb-jar.xml META-INF/ejb-jar.xml.orig sed '/<ejb-name>BPELEngineBean<\/ejb-name>/a\ <resource-ref>\n <res-ref-name>jdbc/ApplicationDBDS</res-ref-name>\n <res-type>javax.sql.DataSource</res-type>\n <res-auth>Container</res-auth>\n </resource-ref>' META-INF/ejb-jar.xml.orig > META-INF/ejb-jar.xml zip -f ejb_ob_engine_wls.jar META-INF/ejb-jar.xml zip -f ../soa-infra-wls.ear META-INF/weblogic-application.xml popd
Update the config.xml file if localhost access is required, as shown in Example 2-8.
Example 2-8 Updating config.xml
if [ -z "$(grep '<listen-address></listen-address>' $DOMAIN_HOME/config/config.xml)" ];then mv $DOMAIN_HOME/config/config.xml $DOMAIN_HOME/config/config.xml.orig sed 's@<listen-address>.*</listen-address>@<listen-address></listen-address>@' $DOMAIN_HOME/config/config.xml.orig > $DOMAIN_HOME/config/config.xml fi
Restart (or start) Integrated WebLogic Server.
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.
Cleanup
Developers should audit the current deployment profiles for all of Oracle Fusion applications to make sure they are not including all of the connection information. Developers need to make sure their deployment profiles only include the connections that are truly needed directly by that project.
Developers also need to remove any unnecessary connections from the connections.xml files from each workspace. The connections.xml file should be a superset of all of these connections and not include unnecessary connections.
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' connection.xml file. This does not happen with ordinary JAR files.
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-41
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.
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-9 shows correctly configured Oracle Enterprise Scheduler database and schema information, and ESS-related settings.
Example 2-9 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.6.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-10 shows how to configure the Oracle Enterprise Scheduler schema using the Oracle Fusion Applications Repository Creation Utility schema.
Example 2-10 Configuring Oracle Enterprise Scheduler Schema Using the Oracle Fusion Applications Repository Creation Utility Schema
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
Alternatively, creating the schema by running scripts in SQL*Plus can be performed as shown in Example 2-11
Note:
You should determine the appropriate TEMP tablespace by reviewing the entries in dba_tablespaces before attempting to run these scripts.
Perform these steps to make sure the ESS installation was successful.
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.
Make sure ESS datasources and shared libraries are targeted to clusters and managed servers. Stop and Start WebLogic Servers as needed.
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.
In JDeveloper, select the Application Navigator menu, then select New Application to open the Create Application wizard. See Figure 2-42.
Tip:
The name of the wizard changes according to the application template that is selected.
Complete the following:
Application Name: Enter Setuptest
Application Package Prefix: Enter oracle.apps.test
Application Template: Choose Fusion Web Application (ADF)
Click Next to access the Name Your ADF-Model Project dialog. See Figure 2-43.
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.
Note:
The Project Technologies are automatically selected based on the application template that was chosen. You can select additional technologies if required.
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-44.
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-45.
Note:
The Project Technologies are automatically selected based on the application template that was chosen. You can select additional technologies if required.
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-46.
Click Finish to create your new application.
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."
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."
Add this option to the Model projects's Run options:
-Doracle.jdbc.createDescriptorUseCurrentSchemaForSchemaName=true
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-47, enter the option string in the Java Options field.
Click OK.
Click OK.
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 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.
Choose Application Navigator > Model. Right-click and choose New from the menu to open the New Gallery.
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-48.
Complete the following to create your entity object:
Filter Types: Select only Tables to narrow your search for schema objects.
Filter Name: Enter a filter, such as %LOOK% to narrow your search to tables.
Query: Click this button to perform your search.
Note:
The results of your search displays in the Available column.
Choose the required object, such as FND_LOOKUPS and click > to shuttle it over to the Selected column.
Click Next to go to the next step in the wizard.
Choose the required entity object located in the Available column and click > to shuttle it over to the Selected column. See Figure 2-49.
Click Finish to create your updateable view object and to close the Business Objects wizard.
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:
Go to the Application Navigator and select your application module. Right-click and select Configurations from the menu.
Choose the configuration <AM Name>Local, then choose Edit.
Change the Connection Type to JDBC DataSource and Datasource Name to java:comp/env/jdbc/ApplicationDBDS. Click OK.
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-50.
If your installation is set up correctly, a dialog similar to that shown in Figure 2-51 displays. If an error message displays, you will need to re-check that the previous steps have been performed correctly.
In this example, right-click FndDemoEmp1 and select Show to display data, as shown in Figure 2-52.
Choose Application Navigator > ViewController. Right-click and select New from the menu to open the New Gallery.
Choose the Web Tier > JSF category. Select the JSF Page item and click OK to open the Create JSF Page dialog.
Complete the following:
File Name: Enter Setup.jsp
Select to create jspx file.
Click OK.
Go to the Data Controls panel and drag the collection onto the open Setup.jspx window. See Figure 2-53.
Select to create Forms > ADF read-only from the context menu that displays. See Figure 2-54.
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-55.
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.
Implementing these best practices when using JDeveloper will significantly reduce problems.
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 originally 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.
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 should be used to update the file. This could happen because of updated lower-level dependency changes outside of the design time session.
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. Session servers and workstations may respond differently.
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.
Once 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>
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.
Human Capital Management (HCM) maintains complex hierarchies and uses web services to retrieve this information. These services are known as service extensions. One of these extensions is the hierarchy provider, which allows you to walk up a hierarchy to retrieve information about a manager or subordinate. A simple example would be you, your manager, your manager's manager, and so on.
See "Using Approval Management" in Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
Before you begin
Before you can configure hierarchy providers, you need to update the credential store using the WebLogic Scripting Tool. Follow these steps:
Run the wlst.sh command from the current working directory and answer the prompts.
wls:/offline> connect()
Please enter your username [weblogic]:weblogic
Please enter your password [weblogic]:password
Please enter your server URL [t3://localhost:7001]:t3://999.99.999.99:7101
Connecting to
t3://localhost:7101 with userid weblogic ...
Run these WLST commands (exactly as they are here) to create credentials within the domain's credential store.
wls:/DefaultDomain/serverConfig> updateCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="password", desc="Keystore key") wls:/DefaultDomain/serverConfig> updateCred(map="oracle.wsm.security", key="enc-csf-key", user="orakey", password="password", desc="Encryption key") wls:/DefaultDomain/serverConfig> updateCred(map="oracle.wsm.security", key="sign-csf-key", user="orakey", password="password", desc="Signing key") wls:/DefaultDomain/serverConfig> updateCred(map="oracle.wsm.security", key="basic.credentials",user="weblogic",password="password",desc="User credentials key") wls:/fusion_domain/serverConfig> createCred(map="oracle.wsm.security", key=" FUSION_APPS_AMX_APPID-KEY ", user="FUSION_APPS_AMX_APPID", password="password", desc="User credentials key")
After running the commands, a message similar to this displays:
desc=User credentials key, map=oracle.wsm.security, password=password, user=FUSION_APPS_AMX_APPID, key=FUSION_APPS_AMX_APPID-KEY }
There are three types of hierarchy providers.
Supervisory: A hierarchy that allows you to walk up and down a user's management chain.
Job-level: A supervisory hierarchy provider with additional job-level information attached to each user.
Position: An HCM hierarchy in which a position's manager is another position. Position has one or more users as its members. Because position is not a native entity in Identity Service Management, you need to set up additional web services to retrieve its data. These services are considered to be service extensions. Service extensions include hierarchy-provider, position-lookup, and display-name-lookup web services.
Each list builder may have a corresponding hierarchy provider.
A hierarchy principal is something that participates in the hierarchy. It has certain parameters that the hierarchy provider uses to determine which hierarchy to walk up to. These parameters are:
userID
assignmentID
effectiveDate (of the assignment)
hierarchyType (to use)
propertyBag (additional parameters map)
Note:
Integration with Oracle HCM is native. That is, you provide the WSDL URL for each hierarchy provider.
Service extension is defined in the workflow-identity-config.xml file under $ORACLE_HOME/user_projects/domains/soainfra/config/soa-infra/configuration.
The file location also may come from MetaData Service (MDS). The file could be updated at the MDS location by using a WebLogic Scripting Tool command, such as importMetadata and exportmetaData. For example:
# ./wlst.sh
# connect('weblogic','weblogic1','t3://<your_host>:7001')
# importMetadata(application='soa-infra',server='AdminServer',fromLocation='<your_path>',docs='/soa/configuration/default/workflow-identity-config.xml')
# exit()
Identity Service Configuration (tag ISConfiguration) has two sections: configurations and service extensions.
Under configurations, service extension is specified using the IdentityServiceExtension property.
Under service extensions (tag serviceExtensions), three hierarchy providers can be specified: JobLevel hierarchy provider, Supervisory hierarchy provider, and Position hierarchy provider. Two special service providers can be specified: position-lookup and position-display-name. All are service providers. JobLevel and Supervisory use the same Java class oracle.bpel.services.identity.hierarchy.providers.hcm.HCMHierarchyProvider.
The position-lookup provider allows you to look up the members of a position and all the positions that belong to a user. The position-display-name provider allows you to retrieve the display names of a list of positions for a particular language.
The sample Identity Service Configuration XML code shown in Example 2-12 specifies a service extension, HCMIdentityServiceExtention, for JpsProvider. It then specifies the providers in the service extension.
Note:
Within each provider, the attribute classname points to a Java implementation of the service provider. The parameter wsdlURL points to the URL of the concrete Web Service Description Language (WSDL) for the provider's web service. You should replace this value with the actual URL.
Example 2-12 Sample workflow-identity-config.xml File for Specifying HCM Providers
<?xml version = '1.0' encoding = 'UTF-8'?>
<ISConfiguration xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig" >
<configurations>
<configuration realmName="jazn.com">
<provider providerType="JPS" name="JpsProvider" service="Identity">
<property name="jpsContextName" value="default" />
<property name="IdentityServiceExtension" value="HCMIdentityServiceExtension"/>
</provider>
</configuration>
</configurations>
<property name="caseSensitive" value="false"/>
<serviceExtensions>
<serviceExtension name="HCMIdentityServiceExtension">
<serviceProvider type="supervisoryHierarchyProvider" classname="oracle.bpel.services.identity.hierarchy.providers.hcm.HCMHierarchyProvider">
<initializationParameter name="wsdlUrl" value="HierarchyProviderService?WSDL"/>
<!-- Optional parameters. Depicts how the defaults could be overridden to specify different values -->
<initializationParameter name="policyFile" value="file://hcm-client-policy.xml"/> <!-- using different owsm policy, see below for sample policy file -->
<initializationParameter name="csf-key-name" value="hcm-csf-key-other"/> <!-- using different name for the csf-key-->
<initializationParameter name="http-read-timeout" value="6000"/> <!-- Use this value to specify HTTP read timeout in miliseconds, default is 5000 milisec-->
<!-- securityPolicyName controls the local policy attachment to use. This value is used along with csf-key-name to use elevated privileges See Bug 10368000 for more information-->
<initializationParameter name="securityPolicyName" value="oracle/wss10_saml_token_client_policy"/>
</serviceProvider>
<serviceProvider type="positionHierarchyProvider" classname="oracle.bpel.services.identity.hierarchy.providers.hcm.HCMPositionHierarchyProvider">
<initializationParameter name="wsdlUrl" value="http://<host>/HierarchyProviderService?WSDL"/>
</serviceProvider>
<serviceProvider type="positionLookupProvider" classname="oracle.bpel.services.identity.position.provider.hcm.PositionLookupServiceProvider">
<initializationParameter name="wsdlUrl" value="http://f<host>/positionLookupService?WSDL"/>
</serviceProvider>
<serviceProvider type="positionDisplayNameProvider" classname="oracle.bpel.services.identity.position.provider.hcm.PositionDisplayNameProvider">
<initializationParameter name="wsdlUrl" value="http://<host>/HierarchyProviderService?WSDL"/>
</serviceProvider>
<serviceProvider type="jobLevelHierarchyProvider" classname="oracle.bpel.services.identity.hierarchy.providers.hcm.HCMHierarchyProvider">
<initializationParameter name="wsdlUrl" value="http://<host>/HierarchyProviderService?WSDL"/>
</serviceProvider>
</serviceExtension>
</serviceExtensions>
</ISConfiguration>
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|