Whenever you create new projects, you must first create an application using the Fusion Web Application (Oracle ADF) template. The system will then automatically create the data model and user interface projects for you. The default names that JDeveloper provides for these projects are Model
and ViewController
.
After your projects have been created, you must manually add the Applications Core library to the data model project and the Applications Core Tag library to the user interface project.
This chapter discusses:
Technology scopes are attributes on the project that can be used to identify the different technologies used for that particular project. These attributes are used only within JDeveloper to assist you as you work. With technology scopes, the choices presented to you in the New Gallery and in the menus and palettes are filtered so that you see only those items that are most relevant to you as you work. Technology scopes have no effect on the data in the project itself.
The JDeveloper online Help has more information.
The application's Enterprise Archive (EAR) will be available for developers to pick up when creating a custom application workspace. An EAR is a Java EE archive file that is used in deploying applications on a Java EE application server. Framework applications are deployed using both a generic EAR file, which contains the application and the respective runtime customization, and a targeted EAR file, which contains only the application for deployment to the application server. An administrator that provisions the environment will be responsible for providing developers with the following:
EAR locations for the various applications.
jazn-data for the various applications.
LDAP/credential store that the developer can set up for authentication.
In addition, the Oracle Fusion Applications Customization Application Wizard will create a complete development environment for customizing existing Oracle Fusion applications. See the online Help in the wizard, and "Using Oracle JDeveloper for Customizations" in the Extensibility Guide for Developers.
Use these directions to add the Applications Core
, Applications Core (Attachments Model)
, Topology Manager
, Functional Setup Model
, BC4J Service Runtime
, Java EE 1.5
, and Java EE 1.5 API
libraries to the data model project. The default name, provided by JDeveloper, for this project is Model
.
To add the necessary libraries to a data model project:
Use these directions to add the Applications Core Tag Library to the user interface project. The default name provided by JDeveloper for this project is ViewController
.
To add the Applications Core Tag library to the user interface project:
The most common use of Applications Core setup UIs is through Oracle Fusion Functional Setup Manager tasks that invoke the UIs running on the Applications Core Setup Java EE application. Applications Core setup UIs are part of the Applications Core (Setup UI) shared library, which is hosted centrally in the Applications Core Setup Java EE application. Consequently, developers typically will not need to include the shared library in their own Java EE applications.
Every Oracle Fusion application registers ADF task flows with the Functional Setup Manager, which provides a single, unified user interface that allows implementers and administrators to configure all applications by creating set up data.
For example, a Human Resources application can register setup activities such as "Create Employees" and "Manage Employee Tree Structure." For more information, see the Oracle Fusion Functional Setup Manager User’s Guide.
To make these task flows available to developers, implementers or administrators, a developer integrates the desired Applications Core setup UI task flows with Functional Setup Manager. For information about specific task flows, see:
The most common use of setup UIs is through Oracle Fusion Functional Setup Manager tasks. This is true even for product-specific tasks that invoke the task flows with parameters that restrict the results to a single object or set of objects.
To determine your requirements, familiarize yourself with these three scenarios and decide which one best fits your needs. The first two patterns are the typical use cases. The third is for approved exceptions only.
Scenario 1 is a generic setup task that invokes a setup task flow running in the Applications Core Setup Java EE application. For example, you want to give your product administrator roles access to the generic Manage Descriptive Flexfields setup task.
Scenario 2 is a product team-specific setup task that invokes a setup task flow running in the Applications Core Setup Java EE application and passes in product-specific parameters to restrict the objects to only those relevant to this specific task. For example, you want to give your product administrator roles access to a Manage GL Descriptive Flexfields setup task that launches the Manage Descriptive Flexfields setup UI for descriptive flexfields belonging to the GL module only.
Scenario 3 is a product team-specific setup task that invokes a setup task flow running in the product team's own Java EE application. This scenario is for approved exceptions only. For example, you plan to embed the setup UI within another UI in your own product team's Java EE application. For instance, the Manage Item Categories UI in Product Information Management (PIM) embeds the Manage Extensible Flexfields setup UI.
Follow the instructions in Table 3-1 that are relevant to your scenario to integrate Applications Core setup UIs into Functional Setup Manager.
Table 3-1 Instructions for Each Scenario
Step | Scenario 1 | Scenario 2 | Scenario 3 |
---|---|---|---|
Follow Functional Setup Manager guidelines to create product-specific setup tasks in the Application Design Repository. Tailor the behavior of the setup UI by passing allowed values to the task flow parameters. Decide what Applications Core setup UI task flows that you want to incorporate and locate the chapter (see What You May Need to Know About Setup UIs in Oracle Fusion ) that describes each task flow and its parameter values. |
X |
X |
|
Product teams should set the value of the Enterprise Application field (in the Application Design Repository) to the appropriate Java EE application for any of their product-specific Functional Setup Manager tasks that use Applications Core setup task flows. Typically, this should be set to the Applications Core Setup Java EE application. |
X |
X |
|
Ensure product team roles inherit the appropriate Applications Core duty role. The duty roles support securing the setup tasks so only authorized users have access. |
X |
X |
X |
If you intend to integrate a product-team specific setup UI and it will run in your product team's own Java EE application, your application will need to include the Applications Core shared library. |
X |
||
For any of the duty roles and their associated privileges that your application inherits, include permissions for those privileges in your application's |
X |
A connection to a valid database is necessary to run most, if not all, applications.
When you have added the libraries as described in Adding Necessary Libraries to Your Data Model Project and Adding the Applications Core Tag Library to Your User Interface Project to your project, the connections for the ApplicationDB, ApplicationAuditDB, and AppMasterDB databases will have been created. You just need to update them to have the connection information for your actual environment.
To create or update a database connection:
ECSF provides developers a set of tools and a framework to quickly and efficiently integrate Oracle Secure Enterprise Search (SES) into enterprise applications to expose business objects for full text search.
Developers use ECSF to integrate search functionality in Oracle Fusion applications by defining searchable objects and searchable attributes. Defining searchable objects and searchable attributes enables the corresponding view objects and view object attributes for search, and creates the necessary metadata for ECSF. However, before you can define searchable objects and searchable attributes, you must add the Search navigation tab to the overview editor in JDeveloper.
For more information about defining searchable objects, see Creating Searchable Objects.
To add the Search navigation tab to the overview editor in JDeveloper, download the JDeveloper extension for ECSF.
To download the JDeveloper extension for ECSF:
When the Search navigation tab is added, the oracle.ecsf.dt.jar
file appears in the oracle_home/jdev/extensions
directory and the following files appear in the oracle_home/ecsf/lib directory
:
ecsfSchema.sql
ecsfSysView.sql
search_admin_wsclient.jar
ecsf.jar
ecsf-dt_bundle.zip
search_client.jar
ecsfSeedData.sql
The Search navigation tab appears in the overview editor of JDeveloper, as shown in Figure 29-3.
Use the Search navigation tab to configure the search-related properties.
For more information, see Creating Searchable Objects.
In an Oracle Fusion application, strings are not hard-coded; they are placed in resource bundles. An application can have multiple resource bundles.
However, you may need to change a specific string in all places where that string appears without having to change it on a per-instance (page/ADF BC object) basis. For instance, you may need to change "worker" to "employee," "activity" to "task," or "expenditure" to "cost." The method to use is the override resource bundle.
In the Oracle Fusion Middleware Developing Web User Interfaces with Oracle ADF Faces guide, see:
Internationalizing and Localizing Pages for information about setting up resource bundles.
How to Define Custom Validator and Converter Messages for All Instances of a Component for general instructions on overriding a resource bundle.
This bundle is specified in the adf-config.xml
file and is created at runtime. For Oracle Fusion applications, there are two important points:
This file must be named FusionAppsOverrideBundle.xlf
Although an application can have multiple resource bundles, it can have only one override resource bundle.
Oracle Enterprise Scheduler Service applications, also known as Oracle Enterprise Scheduler Service hosting applications, are deployed to an Oracle Enterprise Scheduler Service-configured runtime or cluster that has been pre-deployed with the base ESSAPP infrastructure Java EE application. Following standards, Oracle Enterprise Scheduler Service workspaces exist one per product family and are responsible for containing these supporting projects:
Oracle Enterprise Scheduler Service projects for containing Job, Job Set, Incompatibility and Schedule Metadata as well as source files for any Java Job implementation.
ADF data model projects for containing Parameter view object business components.
ADF user interface projects for containing Parameter task flows.
Optional servlet or UI task flow projects for development-time testing.
SuperEss consolidating the Enterprise JavaBeans deployment descriptors for the entire Oracle Enterprise Scheduler Service hosting application. See How to Create the SuperEss Project in the ADF UI Workspace.
Note:
All the projects in an Oracle Enterprise Scheduler Service application, regardless of their content type, should have an ADF Business Components Shared Library deployment profile.
A typical Oracle Enterprise Scheduler Service workspace structure resembles Figure 3-5.
Figure 3-5 Typical Oracle Enterprise Scheduler Service Workspace Structure in JDeveloper
In Oracle Fusion Applications, all Oracle Enterprise Scheduler Service workspaces must contain a SuperEss project that contains the EJB deployment descriptors to register the hosted application with the ESSAPP base application, and to register both the MetadataService and RuntimeService EJBs. This technique avoids having multiple projects with conflicting deployment descriptors in a single deployment archive (EAR).
RuntimeService and MetadataService beans are hosted by the ADF UI application and the Oracle Enterprise Scheduler Service hosting application.
If you are creating a new Oracle Enterprise Scheduler Service workspace or your Oracle Enterprise Scheduler Service workspace does not already have a SuperEss project, create one using these steps:
src/META-INF
.src/META-INF
directory.Create the ejb-jar.xml
and weblogic-ejb.jar.xml
files. See "Building a Combined Oracle Enterprise Scheduler Application" in the Developing Applications for Oracle Enterprise Scheduler. Save the files in the src/META-INF
directory.After completing these steps, the SuperEss project will be complete. Follow How to Build the EAR/MAR Profiles to build the EAR/MAR deployment profiles. An EAR (Enterprise Archive) is a Java EE archive file that is used in deploying applications on a Java EE application server. Framework applications are deployed using both a generic EAR file, which contains the application and the respective runtime customization, and a targeted EAR file, which contains only the application for deployment to the application server. A MAR (Metadata Archive) is a compressed archive of selected metadata used to deploy metadata content to the MDS Repository.
Oracle Enterprise Scheduler Service-hosted applications are built into EAR files and deployed as Java EE applications. The EAR archive must contain the SuperEss EJB JAR, the MAR archive containing all Oracle Enterprise Scheduler Service metadata, and all the Job and Job-related classfiles using JARs in the APP-INF/lib
directory. Follow these steps to create the appropriate deployment profiles.
Note:
Oracle Enterprise Scheduler Service is used in the instructions because it is the primary, but not only, use case.
To simplify patching of Oracle Enterprise Scheduler Service metadata artifacts and align with code-level patching, it is essential to have project-level deployment artifacts. To support this requirement, EARs with multiple MAR files can be deployed. This section describes what must be done to properly build Oracle Enterprise Scheduler Service workspaces to support project-level MARs.
In contrast to standard MAR deployment, in which a single .mar file is created as a metadata aggregate from contributors defined from one or more projects in the application workspace, this approach focuses on the creation of a JAR-based deployment profile in each project where the target file is named with a .mar extension. The resultant .mar files are then deployed into the application workspace's jlib
folder, which is added to the top-level directory of the EAR by the EAR deployment profile.
Follow these steps to implement the project-level MAR deployment.
Prepare the Application Workspace EAR deployment profile.
Open your Oracle Enterprise Scheduler Service Workspace in JDeveloper.
Open the Application Properties, select the Deployment panel, choose your application's EAR deployment profile and click Edit.
These steps will need to be repeated if you have multiple EAR deployments for development or test purposes.
Select File Groups and click New to create a new file group. Leave the type as Packaging and name this group MAR Group.
Leave the remaining values at their defaults and click OK.
Select the Contributors heading beneath the new MAR Group file group and click Add.
Browse to find the application workspace-level jlib
directory and click OK.
In the Filters heading beneath the MAR Group, remove all the filters and add these two rules so they display in this order:
Include *.mar
Exclude *.*
Prepare each metadata project JAR(MAR) deployment profile.
These steps will need to be repeated if you have multiple projects containing Oracle Enterprise Scheduler Service metadata.
Select the Oracle Enterprise Scheduler Service metadata containing project and open the project properties.
Select the Deployment panel and click New.
If necessary, select the JAR File archive type and provide a meaningful profile name, such as <ProjectName>_MAR.
In the JAR Options panel, change the JAR File destination to point to the application workspace-level jlib
directory, and change the file's .jar extension to .mar.
Select File Groups > Project Output > Contributors and de-select Project Output Directory and Project Dependencies.
Click Add to add a new contributor and browse to and select the essmeta
project-level directory.
Select File Groups > Project Output > Filters and confirm the addition of the relevant Oracle Enterprise Scheduler Service metadata files.
Click OK.
Deploy as JAR and verify.
Complete the Application Workspace EAR deployment profile.
These steps will need to be repeated if you have multiple EAR deployments for test or development purposes.
Open the Application Properties.
Select the Deployment panel and choose the EAR deployment profile for your application.
In the MAR Group file group, select Filters and ensure that all of your project level MAR archives are selected.
Select the Application Assembly heading and de-select the application workspace-level MAR profile.
Click OK.
Select the Profile Dependencies in the left-hand side.
Check the boxes for each of the new JAR-based MAR profiles.
Click OK.
Deploy as EAR and verify.
The EAR profile pulls together all of the previously-created EJB and MAR profiles to build the Oracle Enterprise Scheduler Service-hosted application. All the Oracle Enterprise Scheduler Service workspace projects should have ADF library JAR deployment profiles, and those with Job-supporting implementation classes should be deployed to a directory that can be added to the Oracle Enterprise Scheduler Service EAR's contributor list.
To create the EAR profile, follow these steps:
ess workspace root path
/jlib
.APP-INF/lib
File Group's contributors, add the directory that holds all of the Job-supporting Implementation classes (not data model projects with ADF Business Components for parameter view objects or parameter task flows).Ess/jlib
).Note that the EAR profile should contain only the SuperEss EJB JAR, the MAR, and the JAR files for the Job implementation classes. The Oracle Enterprise Scheduler Service hosting application's EAR file must not contain JARs, descriptors or other artifacts for UI, data model or services functionality. Should your application contain projects with servlet or UI task flows for development testing, they must be bundled into a separate, UI-specific, set of EAR/MAR deployment profiles.
When deploying an Oracle Enterprise Scheduler Service hosting application, the target managed server must have the ESSAPP base application pre-deployed and configured to run against a working Oracle Enterprise Scheduler Service database schema. A database schema is a named collection of objects, such as tables, views, clusters, procedures, packages, attributes, object classes, and their corresponding matching rules, which are associated with a particular user.
For deployment from JDeveloper, you will need to create an Application Server connection in the JDeveloper resources palette before or as part of the deployment activity using the New Connection feature. When your Oracle Enterprise Scheduler Service application is ready for deployment, including all requisite project and application-level profiles, you can initiate deployment by following these steps:
JDeveloper will build the EJB JAR and the MAR, and bundle those archives, along with the JAR files, in the APP-INF/lib
contributor location. This packaged archive will be sent to the managed server for deployment. During deployment, the Oracle Enterprise Scheduler Service hosting application will register itself through the ESSAPP base application using the ESSAppEndpoint descriptor in your ejb-jar.xml
file.
When deployment is finished, jobs can be submitted programmatically or through the Oracle Enterprise Scheduler Service UI submission task flows. These methods are documented in the Developing Applications for Oracle Enterprise Scheduler guide.
Before you can deploy your web project, you need to complete several preliminary steps. These include setting up your web project and configuring your user interface project; creating the SuperESS project; creating the appropriate deployment profiles; and creating and setting up Oracle WebLogic Server.
When you choose the Oracle Fusion Applications Developer role when starting JDeveloper, many settings default automatically for you. However, there are still certain options that you need to set manually to configure your project.
This section discusses the specific options that need to be set manually to configure your user interface project. The default name for the project that JDeveloper provides is ViewController
.
Follow the steps in How to Create the SuperEss Project. The differences are that the ejb-jar.xml
file will have no ESSAppEndpoint MDB and the weblogic-ejb.jar.xml
file will be empty.
Deployment is the process of packaging application files and artifacts and transferring them to a target application server to be run. During application development using JDeveloper, developers can test the application using Integrated WebLogic Server that is built into the JDeveloper installation, or they can use JDeveloper to directly deploy to a standalone application server.
After the application has been developed, administrators can deploy it to production application servers.
Note:
This section assumes that you are deploying a web project to Standalone WebLogic Server. Creating deployment profiles is not necessary if you are running the project in Integrated WebLogic Server from within JDeveloper. In this case, JDeveloper, behind the scenes, creates an in-memory deployment profile.
For other deployment options, see Deployment Techniques for Development or Production Environments in the Developing Fusion Web Applications with Oracle Application Development Framework.
To deploy the web project to Standalone Weblogic Server, you must:
Create a Web Archive (WAR) deployment profile. This file is used in deploying applications on a Java EE application server. WAR files encapsulate in a single module all of the components necessary to run an application. WAR files typically contain an application's servlet, JSP, and JSF JSP components. To create the WAR deployment profile, see How to Create Deployment Profiles in the Developing Fusion Web Applications with Oracle Application Development Framework.
When you have defined the WAR, create an EAR deployment profile that includes the WAR profile, for the application. To create an EAR deployment profile, see Creating an Application-Level EAR Deployment Profile in the Developing Fusion Web Applications with Oracle Application Development Framework.
Create, if necessary, and prepare the standalone application server for deployment. To run ADF applications, you must install the standalone application server with the ADF runtime. You can include the ADF runtime during a new application server installation or you can install the ADF runtime into an existing application server installation.
Deploy the application using one of these methods:
Oracle Enterprise Manager Fusion Middleware Control
WebLogic Scripting Tool (WLST) commands (see Deployment Commands in the WLST Command Reference for WebLogic Server) or WebSphere Application Server (wsadmin) commands
Command scripts and Ant scripts
Oracle WebLogic Administration Console or IBM WebSphere Administrative Console