Setting up a Portal application development environment
A application development environment must be set up before any application can be created within an Oracle Portal installation. It's important to set up this environment correctly so that application developers can access the application and the application can access the database objects on which it will be based.
These are the steps for setting up environment, and the order in which they should be completed:
Ensure you or other users have the correct privileges to begin
Before you begin, ensure that you or other members of your application development team have these global privileges:
|
CREATE ALL PROVIDERS or higher privilege
|
Enables the user to create a new application. |
|
CREATE ALL SCHEMAS or higher privilege
|
Enables the user to create the application's schema, access objects in the schema storing the application's data and, if necessary, create any new data schemas. This privilege will typically be granted to a Database Administrator.
|
Hint: A user who is a member of the DBA group is by default granted MANAGE ALL PROVIDERS and MANAGE ALL SCHEMAS privileges, that is, all of the privileges required to perform the tasks below.
A user with the CREATE ALL SCHEMAS or higher global privilege must create the application schema. Every Oracle Portal application maps to a database schema that stores the packages containing the database portlets that comprise the application, and optionally, database objects on which the application is based.
The user creating the application schema must ensure the Provider Schema check box on the Create Schema page is selected. This identifies the schema to Oracle Portal as one available for building applications.
Optionally create a schema for the application's data
The application schema can optionally store database objects such as tables and views on which the application's database portlets will be based. If you prefer to keep the objects used by a application in a separate schema or multiple schemas, you need to create these if they don't already exist in the database.
Give the application schema access to objects
If the database objects that will be used by the application are already in the application schema, you don't need to provide any special access.
If the database objects are in a different schema, you must explicitly grant to the application schema Oracle privileges on each object. These privileges include but aren't restricted to:
|
Privilege |
Enables user to |
|
DELETE |
Remove rows from a table or view's base table. |
|
EXECUTE |
Execute a procedure or function |
|
INSERT |
Insert rows into a table or a view's base table. |
|
SELECT |
Retrieve data from one or more tables or views. |
|
UPDATE |
Change existing values in a table or view's base table. |
The privileges you grant depend on what you want the application to do. You can use Oracle database commands or the Portal Navigator to grant these privileges.
Note The database portlets in the application schema are stored as PL/SQL procedures that execute with the privileges of the application schema. Therefore, you must explicitly grant privileges on each object to the application schema. Because PL/SQL does not recognize privileges granted through roles, you cannot grant them using a role.
Give the application schema access to objects in remote databases
If the database objects that will be used by the application are in a remote database, you need to set up database links to access them. Use the Portal database link wizard to create a link to the remote database schema or schemas containing the objects. Then, for each object you want your application to access, create a synonym in the form:
object@dblink
where
object is name of the object you want to access, for example, MY_TABLE, MY_PROCEDURE, etc.
dblink is the database link to the schema in the remote database.
To ensure the synonyms can be accessed by the application schema:
Create them in the application schema itself, or
Create them in another schema in the same database as the application schema. Then, grant the application explicit EXECUTE privileges on each synonym. Or,
Select the Public check box on the Schema, Synonym Name, and Object Type step of the Synonym wizard. If you make your synonyms public, however, all users will be able to access your data.
All synonyms that are accessible by the application display in build wizard LOVs, so application developers can select them in the Tables/Views step when building a database portlet. This may cause a problem, however, if you create a synonym to a trigger. You will still see this synonym in the Tables/Views LOV and will get an error if you select it and move to the next step of the wizard. As with all synonyms, you may want to use a naming convention that makes the synonym's purpose clear.
Create the application
A user with the CREATE ALL PROVIDERS or higher privilege can now create a new application. (By default, users who are members of the the PORTAL_ADMINISTRATORS, DBA, or PORTAL_DEVELOPERS groups have this privilege.) The user can choose to map the application to the application schema created above.
A user who creates a application is automatically granted Manage access privileges on the application.
Grant Portal developers access to the application
Provider-level access privileges define the actions you can perform on a application. The privileges are Manage, Edit, View Source, Customize, and Execute. For example, if you have Edit privileges, you can create, edit, and delete database portlets in the application.
Provider-level privileges also potentially apply to all database portlets in a application. Any database portlet built in a application by default inherits privileges from the application.
The user who created the application, any user with MANAGE ALL PROVIDERS global privileges or any user with MANAGE application-level access privileges, can now grant other Portal developers access to the application. You can grant access to individual users or to groups.
For example, you may want to grant Edit privileges to some users that allow them to create and edit any database portlet they choose in the application. You may want to restrict other users group to VIEW SOURCE privileges if you plan to allow them to test but not create database portlets.
What are applications?
What are application access privileges?