Best Practices Select IDE Connections.

6-42 Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository

6.3.11 Best Practices

This section describes best practices for the Harvester. It contains the following topics: ■ Section 6.3.11.1, Recommended Privileges for Harvesting ■ Section 6.3.11.2, Do Not Override the Namespace Parameter ■ Section 6.3.11.3, Namespaces in WSDL Files ■ Section 6.3.11.4, Harvesting Completed Work ■ Section 6.3.11.5, Harvesting and Maintenance Releases of XSD ■ Section 6.3.11.6, Harvesting Metadata throughout the Asset Lifecycle ■ Section 6.3.11.7, Downloading WSDL Artifacts ■ Section 6.3.11.8, Harvesting Retired Endpoints ■ Section 6.3.11.9, Harvesting SOA Projects ■ Section 6.3.11.10, Harvesting from Oracle JDeveloper 11g ■ Section 6.3.11.11, Harvesting a File in the Harvester Folder ■ Section 6.3.11.12, Running Harvester and Exchange Utility on the Same Computer ■ Section 6.3.11.13, Harvesting Composite Service WSDL

6.3.11.1 Recommended Privileges for Harvesting

Only Registrars or individuals with the authority to view all the assets in Oracle Enterprise Repository should harvest assets. If individuals do not have permission to view all assets in the repository, they may harvest assets that already exist and unintentionally duplicate assets.

6.3.11.2 Do Not Override the Namespace Parameter

Harvester offers you with the ability to set the project namespace for the assets being harvested. The project namespace is used in detecting duplicate assets, as different namespaces will result in different assets. In most cases, you are recommended not to override this parameter. However, harvester automatically sets the project namespace based on the Oracle SOA Suite or Oracle Service Bus project name when harvesting from those products, which is the recommended behavior.

6.3.11.3 Namespaces in WSDL Files

In the WSDL files that you harvest, it is recommended that you use a unique namespace for each unique interface, service, and endpoint. Correlation to existing assets in the Oracle Enterprise Repository is done through QNames, so if you make significant changes to interface, service, or endpoint assets and do not change the QNames, you will overwrite the existing asset with the modified asset. Table 6–7 shows the correlation of Oracle Enterprise Repository assets with WSDL structure: Configuring and Using Automated Harvesting in Design-time and Runtime Environments 6-43

6.3.11.4 Harvesting Completed Work

It is recommended that you harvest only work that is completed or near completion. If you regularly harvest from a development environment, the Oracle Enterprise Repository can become cluttered with outdated versions of assets. Oracle Enterprise Repository promotes only services that have endpoints and hosted WSDL to Oracle Service Registry. In addition, only services with concrete WSDL can be consumed through JDeveloper. It is recommended that you harvest from the runtime environment to obtain the endpoints and WSDL location.

6.3.11.5 Harvesting and Maintenance Releases of XSD

Some schema development patterns involve the maintenance release of schemas that fix defects or add minor structures but do not change the namespace of the schema. It should be recognized that subsequent harvesting of slightly modified schema artifacts can have the effect of creating a significant number of new artifact assets in the repository. Oracle Enterprise Repository correlates artifact assets based on a hash, or Software File ID SFID, of the contents of the artifacts. The SFID is calculated over the contents of each artifact after all imports and includes have been inlined. Consequently, a change in an XSD that is imported by a WSDL will result in both a new XSD artifact and a new WSDL artifact. This is particularly important to keep in mind when considering schemas that are widely used throughout the enterprise. For example, consider a low-level schema such as customer.xsd that is widely imported by other schemas, WSDLs, XSLTs, BPELs. A material change to customer.xsd, and a subsequent re-harvesting of all of an enterprise’s artifacts for example, some kind of regular batch harvesting would result in a large number of similar artifact assets in the repository that reference customer.xsd either directly or indirectly.

6.3.11.6 Harvesting Metadata throughout the Asset Lifecycle

Harvester can be invoked from several places in the asset lifecycle and each invocatoin gathers artifacts and metadata from different sources. The following list describes the recommendation on how to use harvester during an asset’s lifecycle to keep Oracle Enterprise Repository up to date: 1. DesignDevelopment time After implementation, assets should be published to Oracle Enterprise Repository. Any policies associated with the assets will also be published to Oracle Enterprise Repository. The Oracle Enterprise Repository Governance process provides a means of verifying that the implementation aligns with the organizations policies before it is made available for reuse to the general consumer community. Recommended approach : Invoke the harvester from the IDE JDeveloper, Oracle Service Bus Workshop, Eclipse or VS.NET. 2. Deployment time Table 6–7 Correlation of Oracle Enterprise Repository Assets with WSDL Structures Repository Asset WSDL Structure Service definitionservicename Endpoint definitionserviceportname Interface definitionportTypename 6-44 Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository Immediately after deployment, assets should be published to Oracle Enterprise Repository. At deployment, the production endpoints are harvested and the assets metadata is updated with the endpoint information. An organization may have multiple endpoints supporting their development, test, staging, and production environments. Endpoints, when harvested into Oracle Enterprise Repository, may also go through a governance process. For example, development and testing endpoints may be made available to the entire consumer community, but production endpoints may not be provided until a service provider and a service consumer negotiate a service contract. Recommended approach : Invoke the harvester from the deployment script WLST, ant, or command-line. Invoke harvester at the end of deployment. Harvest the deployed artifacts from the running server, using the -remote_server argument. 3. Runtime Once the project is deployed and running, runtime metrics are harvested and associated with Oracle Enterprise Repository assets. There are several options available for harvesting runtime metrics. One alternative is the EM-Integration, which gathers runtime metrics from Enterprise Manager and updates Oracle Enterprise Repository. For more information, see Oracle Enterprise Manager Connectors Integration Guide. Another alternative is to rely upon runtime monitoring tools such as Actional and Amberpoint, that publish runtime metrics to UDDI registries. Once in the UDDI Registry, the metrics can be propagated back to Oracle Enterprise Repository using the Oracle Registry Repository Exchange Utility. For more information about Amberpoint integration, see Chapter 5, Integration with Amberpoint in Oracle Fusion Middleware Integration Guide for Oracle Enterprise Repository.

6.3.11.7 Downloading WSDL Artifacts

When consuming a WSDL artifact in Oracle Enterprise Repository, you have the ability to download the WSDL file. In many cases, the location of this file is on a remote location. Also, the URL for that file may end in ?wsdl. In these cases, when saving that WSDL, the browser may, by default, give the file the extension as .xml. Then, you should replace.xml with.wsdl. A WSDL file can be hosted on an HTTPHTTPS or FTP server.

6.3.11.8 Harvesting Retired Endpoints

When endpoint is changed, either retired or moved to another location, then it is recommended to retire endpoint from Oracle Enterprise Repository and remove endpoint for Oracle Service Registry. Then, reharvest the same WSDL service with a new endpoint.

6.3.11.9 Harvesting SOA Projects

As a best practise for the SOA life cycle, it is recommended to harvest any SOA projects to Oracle Enterprise Repository, deploy to the SOA server, run the Exchange Utility to publish to Oracle Service Registry, and then consume published assets from Oracle Enterprise Repository or Oracle Service Registry. Note: If you re-run the Exchange Utility publisher, it will not delete retired endpoint from Oracle Service Registry. Configuring and Using Automated Harvesting in Design-time and Runtime Environments 6-45

6.3.11.10 Harvesting from Oracle JDeveloper 11g

It is not recommended to change namespace when harvesting from Oracle JDeveloper 11g. Also, it is recommended not to harvest same composite from JDeveloper 11g using two different status, for example, registered and submitted.

6.3.11.11 Harvesting a File in the Harvester Folder

It is recommended not to harvest a file that is located within the unzipped Harvester folder, 11.1.1.x.x-OER-Harvester.zip. Currently, this is not supported.

6.3.11.12 Running Harvester and Exchange Utility on the Same Computer

When publishing a service to Oracle Service Registry, it is recommended that you run Exchange Utility and Harvester on the same computer so they resolve to the same URL. You can also run these on separate computers where the access points in a WSDL are not fully formed, but you must ensure that they resolve to the same URL on both computers. If the access points are resolved to different URL for Harvester and Exchange Utility, then the service fails to publish with error.

6.3.11.13 Harvesting Composite Service WSDL

It is recommended that a WSDL of exposed composite service should never be harvested separately by itself. It is always best to harvest as whole Composite Project to get the complete and correct SOA asset model in Oracle Enterprise Repository.

6.3.12 Known Issues