JDeveloper and Fusion Applications Explained (Part 2)
By Oliver Steinmeier-Oracle on Feb 28, 2013
In the first part of this series we explained how to find the appropriate version of JDeveloper for your Fusion Applications customization or extension project. We also covered the installation. This second post walks you through the next steps on your journey: we will launch JDeveloper with the necessary parameters and configure the domain of the integrated WebLogic Server (WLS).
The Fusion Applications Developer Guide documents a number of environment variables that need to be set before JDeveloper can be launched. For the purpose of this blog post we are looking at Windows as the host operating system; Linux-based developers can hopefully easily adjust the necessary syntax. One way to define the environment variables is by adding them to a little launch script (let's call it launchjdev.cmd). For example:
JDeveloper Launch Script
Copy/paste-able version – be sure to adjust for your machine’s specific directories:
set MW_HOME=C:\Oracle\Middleware set JAVA_HOME=%MW_HOME%\jdk160_24 set PATH=%JAVA_HOME%\bin;c:\PYTHON27;%PATH% set JDEV_USER_HOME=c:\Projects\FaDevRel set FADEV_VERBOSE=true set USER_MEM_ARGS=-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000 %MW_HOME%\JDeveloper\jdev\bin\jdev
The JDEV_USER_HOME variable defines the location where JDeveloper by default puts workspaces. It is also the location of the "System" directory, home of many JDeveloper settings. And the Default Domain of the integrated WebLogic Server resides in the "System" directory.
Instead of a launch script you can also set up the environment variables using the standard Windows mechanism (System Properties dialog). I prefer the script because it's easier for me to see what the settings are and to modify them as appropriate.
Run the launchjdev.cmd script and choose the pre-selected Default role. We have not yet installed the Fusion-specific extensions. As you will see in a minute, they will add additional roles. Once JDeveloper has completely launched, dismiss the Tip of the Day dialog and choose "Check for Updates" from the "Help" menu. In step 2 of the wizard click the "Add" button (note: if you are behind a corporate firewall, you may be prompted to enter information about your proxy server before you can click the button). With the help of the "Add" button we're adding a local (on your disk) update center from which JDeveloper can install extensions. Enter a meaningful name and then select via the "Browse" button the fusion_apps_updatecenter.xml file from your unzipped Companion DVD/zip file (see part 1 for details). It should be in a directory called "fusion_apps_extensions" together with a lot of zip files (the actual extensions).
Adding Local Update Center
Back in Step 2 of the Wizard, make sure the only update center that is selected is the local one you just added before moving on to Step 3. Here you select "Fusion Apps Development Environment 11.1.1.x" extension (version depends on your release) and that will automatically also select all the dependent extensions.
Select the Fusion Applications Development Environment Extension
Click "Next" and the extensions will be installed. JDeveloper will claim that it is "downloading" updates, but those are really pulled from the local update center (=files) on your disk and copied into the JDeveloper MW_HOME. Step 5 of the wizard then confirms which extensions and their versions were installed. As you can see, quite a few were added to the base JDeveloper install that we started out with.
The List of Newly Installed Extensions
Close the wizard and confirm that you want to restart JDeveloper at this time to enable the extensions. The IDE will close, and it will appear that nothing else is happening. But resist the temptation to restart it manually and just leave the computer alone for a couple of minutes: JDeveloper will in fact "magically" start again and present you with the role picker. It may seem that nothing changed, but if you scroll through the list of roles, you should at the end see two new roles that were provided by the extensions we installed:
The New Roles
The "Oracle Fusion Applications Administrator Customization" role is only used to create meta-data customizations. For instance, you can use it to add a validation to an existing business object (EO). The second new role, "Oracle Fusion Applications Developer" role, is more versatile and lets you create entirely new artifacts -- pages, business components, task flows etc. These extensions can then be integrated into existing product functionality by, for example, customizing an existing page (using the Administrator Customization role). Future parts of this blog post series will show you an example. You can also read more about it in the Extensibility Guide.
For now, to complete the setup of JDeveloper, we need to create the Default domain for the integrated WebLogic Server (WLS). In fact, once you select the "Oracle Fusion Applications Developer" role and proceed with the launch of JDeveloper, the IDE will actually prompt you to do just that. Select "Yes" to enter the Domain Configuration wizard.
A side note: depending on your release, you may at this time see scary looking warnings in the JDeveloper console log about Exceptions "while querying ExalogicOptimizationsEnabled Attribute" and even memory leaks. These can be ignored (and have been reported as bugs).
The first step of the wizard lets you choose between the standalone and integrated domain configuration. Choose "integrated" -- it's for the WebLogic Server that's part of the JDeveloper installation.
In step 2 you are being asked for the password for the "weblogic" user for WLS. This admin user account gives you access to the WebLogic console. A password is defaulted. The masking (*********) makes it impossible to tell that it is the standard WLS default password -- "weblogic1". For an installation that needs access protection, be sure to change it.
Step 2 of the Domain Creation Wizard
In some releases (screenshot is from Release 4) there is an additional field "Fusion Family Name". It was removed in future versions and if you have it, you can leave it as defaulted: "Common".
In step 3 of the wizard, enter the database information for your Fusion Applications database. One of the many schemas, "OWSM MDS", is typically not in the Fusion Applications database, but rather in the identity management (IDM) database. Override the connect string if necessary. In general, it's worthwhile double-checking all the usernames and passwords via SQL*Plus or SQL*Developer to make sure they are correct as the domain will otherwise be configured incorrectly. Unfortunately the current version of the wizard does not offer any built-in validation feature (an enhancement request has been filed).
Step 3 of the Domain Creation Wizard
Step 4 requires that you know the parameters for the LDAP server for your Fusion Applications environment. The domain will be configured to use that server for authentication and authorization. If you don't know the values to be entered here, please contact the administrator of your Fusion environment.
Step 4 of the Domain Creation Wizard
Once you finish the wizard, the domain creation and configuration begins. You can follow the progress in the JDeveloper console pane. It will, depending on the speed of your machine, take a few minutes. As part of the process, the WebLogic Server will be started; this is necessary to configure the LDAP server as a security provider.
Don't be discouraged by the seemingly endless messages that stream by in the console pane. If everything works smoothly and as expected, you should in the end have a running WLS server. If WLS does not start up properly, you need to review the console log for possible errors.
WLS Domain Configuration Failed
As you can see in the above screenshot, the configuration script advises you which log files to review for detailed errors. They are located in the system directory. The third part of this blog post series will discuss some of the more common problems we have seen people run into.