PK
UvLoa, mimetypeapplication/epub+zipPK UvL META-INF/container.xml
This preface introduces the new and changed administrative features of Oracle Fusion Middleware that are described in this guide, and provides pointers to additional information.
The following topics introduce the new and changed features of Oracle Fusion Middleware and other significant changes that are described or referred to in this guide, and provides pointers to additional information.
The impact of Oracle Real-Time Integration Business Insight on moving your environment from a test to a production environment. See Table 20-1.
Backup and recovery procedures for Oracle Real-Time Integration Business Insight. See Table 16-1.
The following topics introduce the new and changed features of Oracle Fusion Middleware and other significant changes that are described or referred to in this guide, and provides pointers to additional information.
In previous releases, you invoked WLST from different locations, depending on whether you were using the commands for Oracle WebLogic Server, system components, or Java components such as Oracle SOA Suite. In this release, you invoked WLST from:
(UNIX) ORACLE_HOME/oracle_common/common/bin/wlst.sh (Windows) ORACLE_HOME\oracle_common\common\bin\wlst.cmd
New move plan properties for Oracle B2B including contacts and identifiers. See Table A-22.
The WLDF Watches and Notifications are renamed to Policies and Actions. See Section 13.3.5.
Additional FIPS compliance features are added. See Table 8-1 and Table 8-2.
The following topics introduce the new and changed features of Oracle Fusion Middleware and other significant changes that are described or referred to in this guide, and provides pointers to additional information.
Node Manager support for the OPSS Keystore Service. See Section 2.7.2 for information about configuring Node Manager.
Revised support for moving the OPSS Keystore Service to a new environment. See Section 20.2.3. Also see Table A-13 for move plan properties related to the Keystore Service.
Support for moving the following components to a new environment:
Oracle User Messaging Service. See Table A-21 for the move plan properties.
Oracle Managed File Transfer. See Table A-24 for the move plan properties.
Oracle Enterprise Data Quality, which uses the move plan properties for Java components. See Table A-13.
See Table 20-1 for a complete list of components that support the movement scripts.
Enhanced move plan properties for Oracle B2B. See Table A-22.
Support for AES encryption for Oracle Wallets. See Section G.1.4.1.3 and Section G.1.4.1.4.
Support for certificate trust flags in Oracle Wallets. See Section G.1.4.4.
Ability to import PKCS#12 files to Oracle Wallet. See Section G.1.4.5.
FIPS-140 support in Oracle Fusion Middleware. See Chapter 8.
The following topics introduce the new and changed features of Oracle Fusion Middleware and other significant changes that are described or referred to in this guide, and provides pointers to additional information. This book is the new edition of the formerly titled Oracle Fusion Middleware Administrator's Guide.
Redefining of the Oracle home and elimination of the Middleware home. See "New And Deprecated Terminology for 12c" in Understanding Oracle Fusion Middleware.
OPMN is no longer used in Oracle Fusion Middleware. Instead, system components are managed by the WebLogic Management Framework, which includes WLST, Node Manager and pack and unpack. See "What Is the WebLogic Management Framework" in Understanding Oracle Fusion Middleware.
Support for a "per domain" Node Manager. See "What Is Node Manager?" in Understanding Oracle Fusion Middleware.
Oracle Web Cache is no longer part of Oracle Fusion Middleware.
Changes in moving from a source to a target environment:
Because of the redefining of Oracle home and elimination of Middleware home, some of the parameters to the scripts have changed. See Section A.1.2.
Support for moving a standalone domain. See Section 20.3.5.
Support for moving the Oracle home and binary files using storage-level cloning tools. See Section 20.3.3.
A move plan for Oracle Coherence. See Table A-15.
A move plan for Oracle Web Services Manager. See Table A-16.
The OPSS Keystore Service is introduced. See Section 7.1.1.3.
SSL procedures for Oracle WebLogic Server have been updated. See Section 6.5.1.
Fusion Middleware Control supports cross-component wiring. See Section 3.3.
Oracle Fusion Middleware has introduced service tables, which provide a way for service providers to publish endpoint information about their services, and clients of these services to query and bind to these services. See Section 3.1.
Updated procedures for backup and recovery, including procedures for recovering a standalone domain. See Chapter 18.
Enhanced support for querying diagnostic incidents. See Section 13.4.2.3.
Support for creating aggregated incidents. See Section 13.4.6.2.
Support for extended log format for access logs. See Section 12.1.1.
This part provides an overview to Oracle Fusion Middleware and its concepts as they relate to administering Oracle Fusion Middleware.
Topic:
Before you deploy Oracle Fusion Middleware applications, such as Java EE applications, you should understand the deployment process, such as designing and developing applications and deploying those applications to Managed Servers.
Topics:
A user in the role of deployer is responsible for deploying applications, such as Java EE applications, and ADF applications, to WebLogic Server instances or clusters.
A user who is functioning as a deployer should be granted the Oracle WebLogic Server deployer security role. The deployer security role allows deployment operations, as well as viewing the server configuration and changing startup and shutdown classes. To grant this role to a user, from Fusion Middleware Control:
From the WebLogic Domain menu, select Security, then Users and Groups.
The Users and Groups page is displayed.
If you do not have such a user, click Create.
The Create a User page is displayed.
Enter a name for the user and a password. Confirm the password.
Click Create.
On the Users and Groups page, select the user.
On the Settings for User page, select Deployers from the Available pane and move it to the Chosen pane.
Click Save.
This section describes the general procedures involved in moving from application design and development to deployment in a production environment. It contains the following topics:
In many cases, developers use Oracle JDeveloper to create their applications. Oracle JDeveloper is an integrated development environment (IDE) for building service-oriented applications using the latest industry standards for Java, XML, Web services, portlets, and SQL. JDeveloper supports the complete software development life cycle, with integrated features for modeling, coding, debugging, testing, profiling, tuning, and deploying applications.
In this environment, you use the integrated Oracle WebLogic Server, which is packaged with Oracle JDeveloper for testing your applications.
For information about developing your applications, see:
After you have designed and tested your application with the integrated Oracle WebLogic Server, you can deploy the application to a Managed Server instance. For example, you may have installed Oracle WebLogic Server and configured a domain, including a Managed Server, in your production environment and you want to deploy the application to that Managed Server.
The following books provide specific information about deploying the different types of applications:
For Java EE applications, see Deploying Applications to Oracle WebLogic Server
For Oracle ADF, see Administering Oracle ADF Applications
For Oracle SOA Suite, see the Developing SOA Applications with Oracle SOA Suite
For Oracle WebCenter Portal, see Administering Oracle WebCenter Portal
This section provides an outline of the major steps involved when you migrate your application from the integrated Oracle WebLogic Server to an environment separate from the development environment. Those general steps are:
Package the application:
For Java EE applications, you package the application in an EAR file. See "Preparing Applications and Modules for Deployment" in Deploying Applications to Oracle WebLogic Server.
For Oracle ADF, you package the application in an EAR file. See "What You May Need to Know About EAR Files and Packaging" in Developing Fusion Web Applications with Oracle Application Development Framework.
For Oracle SOA Suite, you package the application into a JAR or ZIP file. See "Understanding the Packaging Impact" in the Developing SOA Applications with Oracle SOA Suite.
For Oracle WebCenter Portal, you package the application in an EAR file. See "Packaging a WebCenter Portal Application" in Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper
Set up your environment. This includes:
Installing and configuring a domain and a Managed Server that is configured with the correct domain template. For example, if you are deploying an Oracle SOA Suite application, the Managed Server must use the Oracle SOA Suite domain template. The appropriate domain template is applied when you create the domain using the Configuration Wizard. Alternatively, you can extend a domain to use another domain template, as described in Section 19.2.
For more information about installing and configuring for specific components, see:
For Oracle ADF: "How to Install the ADF Runtime to the WebLogic Installation" in Administering Oracle ADF Applications
For Oracle SOA Suite: "Installing Oracle SOA Suite and Oracle Business Process Management Suite", "Configuring the Oracle SOA Suite Domain" and "Configuring the Oracle Business Process Management Domain" in Installing and Configuring Oracle SOA Suite and Business Process Management
For Oracle WebCenter Portal: "Installing Oracle WebCenter Portal" and "Configuring Oracle WebCenter Portal" in the Installing and Configuring Oracle WebCenter Portal
Creating any necessary schemas in an existing database. See Creating Schemas with the Repository Creation Utility.
Registering the MDS Repository with the Oracle WebLogic Server domain, if your application uses the MDS Repository. For example, Oracle SOA Suite applications require MDS. Some ADF applications involve customizations using MDS. See Section 14.3.2.1.1 for information about registering the MDS Repository.
If your application uses a database, set up the JDBC data sources.
For more information about setting up the JDBC data sources, see:
For pure Java EE applications: Administering JDBC Data Sources for Oracle WebLogic Server
For Oracle ADF: "How to Create a JDBC Data Source for Oracle WebLogic Server" in Administering Oracle ADF Applications
For Oracle SOA Suite: "Creating Data Sources and Queues" in the Developing SOA Applications with Oracle SOA Suite
For Oracle WebCenter Portal: "Choosing the Data Source" in the Administering Oracle WebCenter Portal
For Oracle SOA Suite, create connection factories and connection pooling. For more information, see "Creating Connection Factories and Connection Pooling" in the Developing SOA Applications with Oracle SOA Suite.
Create a connection to the target Managed Server.
From Oracle JDeveloper, you can deploy your applications to Managed Server instances that reside outside JDeveloper. To do this, you must first create a connection to the server instance to which you want to deploy your application.
For more information, see:
For Oracle ADF: "How to Create a Connection to the Target Application Server" in Developing Fusion Web Applications with Oracle Application Development Framework
For Oracle SOA Suite: "Creating an Application Server Connection" in the Developing SOA Applications with Oracle SOA Suite
For Oracle WebCenter Portal: "Creating a WebLogic Managed Server Connection" in Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper
For Oracle SOA Suite, create a SOA-MDS connection, if the SOA composite application shares metadata with other composites. See "Creating a SOA-MDS Connection" in Developing SOA Applications with Oracle SOA Suite.
Create a configuration plan or deployment plan, which contains information about environment-specific values, such as JDBC connection strings or host names of various servers. For more information, see:
For pure Java EE applications: "Creating a New Deployment Plan to Configure an Application" in Deploying Applications to Oracle WebLogic Server
For Oracle SOA Suite: "Introduction to Configuration Plans" in Developing SOA Applications with Oracle SOA Suite
Migrate application security, such as credentials, identities, and policies. For more information, see:
For pure Java EE applications: "Migrating Security Data" in Administering Security for Oracle WebLogic Server 12c (12.2.1)
For Oracle ADF: "Preparing the Secure Application for Deployment" in Developing Fusion Web Applications with Oracle Application Development Framework
For Oracle SOA Suite: "Enabling Security" in Developing SOA Applications with Oracle SOA Suite
For Oracle WebCenter Portal: "Managing WebCenter Portal Application Security" in Administering Oracle WebCenter Portal
Create a deployment profile. A deployment profile packages or archives a custom ADF, WebCenter Portal, or SOA application and associated files so that the application can be deployed to an Oracle WebLogic Server Managed Server instance. Deployment profiles are created at the project and application level.
For more information, see:
For Oracle ADF: "How to Create Deployment Profiles" in Developing Fusion Web Applications with Oracle Application Development Framework
For Oracle SOA Suite: "Optionally Creating a Project Deployment Profile" in Developing SOA Applications with Oracle SOA Suite
For Oracle WebCenter Portal: "Creating Deployment Profiles" in Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper
Migrate Oracle JDeveloper extensions for Oracle SOA Suite. Table 9-1 shows the extensions and where they are documented:
Table 9-1 Oracle JDeveloper Extensions
Component | Extension | See: |
---|---|---|
Oracle SOA Suite |
SOA extensions |
"Enabling Oracle JDeveloper Extensions" in Installing Oracle JDeveloper |
Oracle WebCenter Portal |
WebCenter Portal extensions |
"Creating and Provisioning a WebLogic Managed Server Instance" in Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper |
Deploy the application to a Managed Server.
For more information, see:
For pure Java EE applications: "Exporting an Application for Deployment to New Environments" in Deploying Applications to Oracle WebLogic Server
For Oracle ADF: "Deploying the Application" in Developing Fusion Web Applications with Oracle Application Development Framework
For Oracle SOA Suite: "Deploying SOA Composite Applications" in Developing SOA Applications with Oracle SOA Suite
For Oracle WebCenter Portal: "Deploying the Application to a WebLogic Managed Server" in Administering Oracle WebCenter Portal
You can automate the migration of an application by using WLST or ant scripts. This makes it easier to deploy your application to multiple environments or Managed Servers and to deploy updated versions of the application.
For more information about using scripts to migrate an application to other environments, see:
For pure Java EE applications: "Using the WebLogic Scripting Tool" in Understanding the WebLogic Scripting Tool
For Oracle ADF: "Deploying Using Scripts and Ant" in Administering Oracle ADF Applications
For Oracle SOA Suite: The following sections in Developing SOA Applications with Oracle SOA Suite:
For Oracle WebCenter Portal: "Creating and Provisioning a WebLogic Managed Server Instance" in Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper
The following describes some of the typical problems that you may encounter when you deploy an application to a Managed Server:
Connection information. Ensure that you have correctly configured the connection to the target Managed Server. See Steps 4, 5, and 6 in Section 9.2.2.
Oracle JDeveloper extensions. Ensure that you have migrated any Oracle JDeveloper extensions. See Table 9-1.
Data sources. Ensure that you have correctly configured JDBC data sources. See Step 3 in Section 9.2.2.
Security configuration. Ensure that you have migrated application security, such as credentials, identities, and policies. See Step 8 in Section 9.2.2.
In addition, see "Troubleshooting Common Deployment Errors" in the Developing SOA Applications with Oracle SOA Suite for information about troubleshooting SOA applications.
Many Oracle Fusion Middleware components use metadata repositories to hold configuration information about the component and metadata for applications. This chapter provides information on managing the metadata repositories used by Oracle Fusion Middleware.
Topics:
A metadata repository contains metadata for Oracle Fusion Middleware components, such as Oracle Application Development Framework. It can also contain metadata about the configuration of Oracle Fusion Middleware and metadata for your applications.
Oracle Fusion Middleware supports multiple repository types. A repository type represents a specific schema or set of schemas that belong to a specific Oracle Fusion Middleware component (for example, Oracle Application Development Framework.) Oracle Fusion Middleware supports Edition-Based Redefinition (EBR), which enables you to upgrade the database component of an application while it is in use, thereby minimizing or eliminating down time. The schemas in a repository can be EBR-enabled schemas.
A particular type of repository, the Oracle Metadata Services (MDS) Repository, contains metadata for certain types of deployed applications. This includes custom Java EE applications developed by your organization and some Oracle Fusion Middleware component applications. For information related specifically to the MDS Repository type, see Section 14.3.
You can create a database-based repository or, for MDS, a database-based repository or a file-based repository. For production environments, you use a database-based repository. Some components require that a schema be installed in a database, necessitating the use of a database-based repository. MDS supports Edition-Based Redefinition (EBR) enabled schemas.
Note: After the database for the metadata repository has been used for the Oracle Fusion Middleware installation, the database, service name, or SID cannot be changed. |
You use the Oracle Fusion Middleware Repository Creation Utility (RCU) to create the metadata repository in an existing database.You can use RCU to create the MDS Repository or a repository for metadata for particular components. RCU creates the necessary schemas for the components. See Creating Schemas with the Repository Creation Utility for a list of the schemas and their tablespaces and datafiles.
With RCU, you can also drop component schemas.
For information about the supported databases and the supported versions, as well as using these databases with the MDS Repository, see "Supported Databases for the MDS Schema" in the Oracle Fusion Middleware System Requirements and Specifications.
Note: Oracle recommends that all metadata repositories reside on a database at the same site as the components to minimize network latency issues. |
For information about managing an MDS Repository, see Section 14.3.
For information about how to use RCU to create a database-based metadata repository, see Creating Schemas with the Repository Creation Utility.
Oracle Metadata Services (MDS) Repository contains metadata for certain types of deployed applications. Those deployed applications can be custom Java EE applications developed by your organization and some Oracle Fusion Middleware component applications, such as Oracle B2B and Oracle Web Services Manager. A Metadata Archive (MAR), a compressed archive of selected metadata, is used to deploy metadata content to the MDS Repository, which contains the metadata for the application.
You should deploy your applications to MDS in the following situations, so that the metadata can be managed after deployment:
The application contains seeded metadata packaged in a MAR.
You want to enable user personalizations at run time.
You have a SOA composite application (SCA).
The following topics provide information about the MDS Repository:
Registering and Deregistering a Database-Based MDS Repository
Configuring an Application to Use a Different MDS Repository or Partition
Moving from a File-Based Repository to a Database-Based Repository
See Also: High Availability Guide for information about using an MDS Repository with Oracle Real Application Clusters (Oracle RAC) |
The MDS framework allows you to create customizable applications. A customized application contains a base application (the base documents) and one or more layers containing customizations. MDS stores the customizations in a metadata repository and retrieves them at run time to merge the customizations with the base metadata to reveal the customized application. Since the customizations are saved separately from the base, the customizations are upgrade safe; a new patch to the base can be applied without breaking customizations. When a customized application is launched, the customization content is applied over the base application.
A customizable application can have multiple customization layers. Examples of customization layers are industry and site. Each layer can have multiple customization layer values, but typically only one such layer value from each layer is applied at run time. For example, the industry layer for a customizable application can contain values for health care and financial industries; but in the deployed customized application, only one of the values from this layer is used at a time. For more information about base documents and customization layers, see "Customizing Applications with MDS" in Developing Fusion Web Applications with Oracle Application Development Framework.
An MDS Repository can be file-based or database-based. For production environments, you use a database-based repository. You can have more than one MDS Repository for a domain.
A database-based MDS Repository provides the following features that are not supported by a file-based MDS Repository:
Efficient query capability: A database-based MDS Repository is optimized for set-based queries. As a result, it provides better performance on such searches with the database repository.
The MDS Repository query API provides constructs to define the query operation and to specify conditions on metadata objects. These conditions are a set of criteria that restrict the search results to a certain set of attribute types and values, component types, text content, and metadata paths. The API allows multiple conditions to be combined to achieve dynamic recursive composition using OR and AND constructs.
Atomic transaction semantics: A database-based MDS Repository uses the database transaction semantics, which provides rollbacks of failed transactions, such as failed imports or deployments.
Versioning: A database-based MDS Repository maintains versions of the documents in a database-based repository. Versioning allows changes to metadata objects to be stored as separate versions rather than simply overwriting the existing data in the metadata repository. It provides version history, as well as the ability to label versions so that you can access the set of metadata as it was at a given point in time.
Isolate metadata changes: A database-based MDS Repository has the capability to isolate metadata changes in a running environment and test them for a subset of users before committing them for all users.
Support for external change detection based on polling: This allows one application to detect changes that another application makes to shared metadata. For example, if you have an application deployed to Managed Servers A and B in a cluster, and you modify the customizations for the application deployed to Managed Server A, the data is written to the database-based repository. The application deployed to Managed Server B uses the updated customizations. This supports high availability (in particular, active/active scenarios.)
Clustered updates: A database-based MDS Repository allows updates from multiple hosts to the metadata. For a file-based MDS Repository, updates can be made from only one host at a time.
Multiple applications can share metadata by configuring a shared metadata repository. When you do this, changes made by one application to the metadata in this repository are seen by other applications using the shared repository, if you configure external change detection for the applications.
In an MDS Repository, each application, including Oracle Fusion Middleware components, is deployed to its own partition. A partition is an independent logical repository within one physical MDS Repository, whether it is database-based or file-based.
For information about deploying applications and associating them with an MDS Repository, see Chapter 10.
Note the following points about patching the MDS Repository:
An MDS Repository must be registered with a domain before it is patched. Otherwise, the applied patches cannot be rolled back and no additional patches can be applied.
You can apply patches to the following:
The MDS metadata
An MDS jar file
An MDS shared library
An MDS schema in the database-based metadata repository. The patch can include additive changes such as adding a new column or increasing the size of a column. Note that you cannot rollback this type of patch.
The MDS database PL/SQL in the database-based metadata repository. The patch can include changes to a PL/SQL package or new PL/SQL packages and procedures.
An MDS schema or PL/SQL in the database-based metadata repository that requires a corresponding MDS JAR file patch.
The MDS Repository supports Oracle databases, as well as non-Oracle databases, including SQL Server, DB2, and MySQL.
For information about the supported databases and the supported versions, as well as using these databases with the MDS Repository, see "Supported Databases for the MDS Schema" in the Oracle Fusion Middleware System Requirements and Specifications.
You can use Fusion Middleware Control or WLST commands to perform most operations on the MDS Repository. However, for some operations that do not have a custom user interface in Fusion Middleware Control or do not have WLST commands, you must use the System MBeans.
The sections that follow describe using Fusion Middleware Control and WLST commands to perform the operations, unless only System MBeans are supported. In that case, the sections describe how to use System MBeans to perform the operation.
You can view information about the repositories, including the partitions and the applications deployed to each partition. You can also perform operations on the partitions, such as purging, deleting, importing metadata, or exporting metadata.
Note the following when you use the MDS operations described in the sections that follow:
The export operation exports a versioned stripe (either the tip version or based on a label) of metadata documents from an MDS Repository partition to a file system directory or archive. If you export to a directory, the directory must be accessible from the host where the application is running. If you export to an archive, the archive can be located on the system on which you are executing the command.
Because versioning of metadata is not supported for file-based repositories, the tip version (which is also the only version) is exported from a file-based repository.
The import operation imports metadata documents from a file system directory or archive to an MDS Repository partition. If you exported to a directory, the directory must be accessible from the host where the application is running. If you exported to an archive, the archive can be located on the system on which you are executing the command.
If the target repository is a database-based repository, the metadata documents are imported as new tip versions. If the target repository is a file-based repository, the metadata documents are overwritten.
Note:
|
Table 14-1 lists the logical roles needed for each operation. The roles apply whether the operations are performed through the WLST commands, Fusion Middleware Control, or MBeans.
Table 14-1 MDS Operations and Required Roles
Operation | Logical Role |
---|---|
Clear cache |
Operator role for application |
Clone metadata partition |
Admin role for domain |
Create metadata label |
Admin role for application |
Create metadata partition |
Admin role for domain |
Delete metadata |
Admin role for application |
Delete metadata label |
Admin role for application |
Delete metadata partition |
Admin role for domain |
Deregister metadata database repository |
Admin role for domain |
Deregister metadata file repository |
Admin role for domain |
Destroy sandbox |
Admin role for application |
Export metadata |
Monitor role for application |
Export sandbox metadata |
Monitor role for application |
Import MAR |
Admin role for application |
Import metadata |
Admin role for application |
Import sandbox metadata |
Admin role for application |
List metadata label |
Monitor role for application |
List sandboxes |
Monitor role for application |
Promote metadata label |
Admin role for application |
Purge metadata |
Admin role for application |
Purge metadata labels |
Admin role for application |
Register metadata database repository |
Admin role for domain |
Register metadata file repository |
Admin role for domain |
For information about how these roles map to WebLogic Server roles, see "Mapping of Logical Roles to WebLogic Roles" in Securing Applications with Oracle Platform Security Services.
The following topics describe how to register and deregister a database-based MDS Repository:
Note: Note the following if you invoke the following WLST commands or comparable MBeans in a script:
In this release and previous releases, the commands or MBeans have the following behavior:
However, you can start an editing session explicitly. If you do, the automatic activation of the changes are deprecated. |
Before you can deploy an application to an MDS Repository, you must register the repository with the Oracle WebLogic Server domain. You can register a database-based MDS Repository using Fusion Middleware Control or WLST, as described in the following topics:
You create a database-based MDS Repository using RCU, as described in Section 14.2.
To register a database-based MDS Repository using Fusion Middleware Control:
From the WebLogic Domain menu, choose Other Services, then Metadata Repositories.
The Metadata Repositories page is displayed, as shown in the following figure:
In the Database-Based Repositories section, click Register.
The Register Database-Based Metadata Repository page is displayed.
In the Database Connection section, enter the following information:
For Database Type, select the type of database.
For Host Name, enter the name of the host.
For Port, enter the port number for the database, for example: 1521
.
For Service Name, enter the service name for the database. The default service name for a database is the global database name, comprising the database name, such as orcl
, and the domain name. In this case, the service name would be orcl.domain_name.com
.
For User Name, enter a user name for the database which is assigned the SYSDBA role, for example: SYS
.
For Password, enter the password for the user.
For Role, select a database role, for example, SYSDBA.
Click Query.
A table is displayed that the metadata repositories in the database, as shown in the following figure:
Select a repository, then enter the following information at the bottom of the page:
For Repository Name, enter a name.
For Schema Password, enter the password you specified when you created the schema.
Click OK.
The repository is registered with the Oracle WebLogic Server domain and is targeted to the Administration Server. To target the repository to other servers, see Section 14.3.2.2.
In addition, a system data source is created with the name mds-repository_name. Global transaction support is disabled for the data source.
To register a database-based MDS Repository using the command line, you use the WLST registerMetadataDBRepository
command. For example, to register the MDS Repository mds-repos1, use the following command:
registerMetadataDBRepository(name='mds-repos1', dbVendor='ORACLE', host='hostname', port='1521', dbName='ora11', user='username', password='password', targetServers='server1')
When you register an MDS Repository using Fusion Middleware Control, the repository is targeted to the Administration Server. You can target the repository to additional servers.
To target the MDS Repository to additional servers:
From the navigation pane, expand Metadata Repositories.<