10 Configuring Oracle Enterprise Repository to Exchange Metadata with the Oracle Service Registry

This chapter describes how to configure Oracle Enterprise Repository to exchange metadata with the Oracle Service Registry.

This chapter contains the following sections:

10.1 Getting Started With the Oracle Registry Repository Exchange Utility

This section describes how to get started with Oracle Registry Repository Exchange Utility and sample use cases using the utility.

This section contains the following topics:

10.1.1 What is the Oracle Registry Repository Exchange Utility?

The Oracle Registry Repository Exchange Utility synchronizes Oracle Enterprise Repository and Oracle Service Registry bi-directionally so that the metadata from either of these products can flow in either direction through the utility. The following are the metadata entities that are handled by the utility.

The Oracle Registry Repository Exchange Utility is capable of:

  • Publishing services and endpoints from design-time to the run-time environment using UDDI.

  • Submitting newly discovered run-time services, and endpoints to the repository so that they can be managed and governed.

  • Communicating service performance information that is deposited into the UDDI registry back into the repository to better inform prospective service consumers and portfolio managers.

  • Being triggered by Oracle Business Process Management workflows to automatically publish assets to the Oracle Service Registry.

10.1.1.1 Valid Metadata Entities

The following metadata entities are handled by the Oracle Registry Repository Exchange Utility:

  • All UDDI enabled services and SCA Service type as well as any custom services of any Oracle Enterprise Repository Asset Type developed by end users.

  • Business Entities that provide Business Services.

    For more information about how the Oracle Registry Repository Exchange Utility arrives at the Business Entities, see Section 10.3.2.1, "Synchronizing the Metadata Published from Oracle Enterprise Repository to Oracle Service Registry" and Section 10.3.2.2, "Synchronizing the Metadata from Oracle Service Registry to Oracle Enterprise Repository".

  • Endpoint assets that are linked to the Services that provide access point to the services. For example, there can be multiple endpoints that can be tagged as staging or production and are mapped to the UDDI binding template appropriately.

  • Oracle Enterprise Repository Categorizations are mapped to UDDI t-models. When a categorization is applied to a Service asset, an appropriate entry is added to the UDDI Category Bag and is linked to the appropriate taxonomy t-model. These t-models are also automatically loaded into Oracle Service Registry the first time they are encountered, or they can be loaded manually by the Oracle Enterprise Repository Exchange Utility

    For more information, see the -publish_tmodel option, in Table 10-4.

  • Service Registration Status and Active Status are added as items to the Category Bag of the Business Service in Oracle Service Registry when the services are pushed to Oracle Service Registry.

  • Non-WSDL based services are published to the UDDI Registry.

  • Services without an HTTP transport are not published to the UDDI Registry.

  • Service Keys - When Oracle Enterprise Repository promotes services to multiple service registries, the service keys remain consistent and the same service key appears in each service registry. If services are published from an Oracle Service Registry to Oracle Enterprise Repository, then Oracle Enterprise Repository uses that service key whenever it promotes services to other service registries.

10.1.1.2 Prerequisites

Before using the Oracle Registry Repository Exchange Utility, you must perform the following prerequisites:

  • Oracle Registry Repository Exchange Utility requires Java SDK version 6 or higher.

10.1.2 Example Use Cases

Because Oracle Registry Repository Exchange Utility is bi-directional, it is able to support the following use cases:

  • When a service in Oracle Service Registry is modified, such as when more endpoints are added to it (for example, for staging and production environments), the Oracle Registry Repository Exchange Utility can relate the service with one or more endpoints in Oracle Enterprise Repository. When services and assets are published to multiple UDDI registry environments, a single UDDI ServiceKey is preserved in each registry.

  • When Business Services are moved to different Business Entities in Oracle Enterprise Repository using asset relationships, the new relationship is also reflected in Oracle Service Registry when the Services are re-synchronized.

  • When synchronizing Oracle Enterprise Repository metadata with Oracle Service Registry, the Oracle Registry Repository Exchange Utility merges any changes so that endpoint changes are preserved.

  • The Exchange Utility publishes certain kinds of Non-WSDL services from Oracle Enterprise Repository to Oracle Service Registry. These services are not bi-directional, which means that the Exchange Utility cannot publish back to Oracle Enterprise Repository from Oracle Service Registry.

  • The endpoints of matched services can be filtered based on the specified Asset Lifecycle of the endpoints, so that only the matched endpoints are published to the repository. This query is useful when there are separate registries: one that lists the staged endpoints and another that lists the production endpoints.

    Note:

    The Oracle Registry Repository Exchange Utility can be invoked by the Oracle Enterprise Repository workflows, such that synchronization between Oracle Enterprise Repository and Oracle Service Registry can be triggered by an asset lifecycle stage change, or by any other event trigger.

    For more information, see Section A.2.2, "Automated Workflows".

  • Exchange Utility is capable of bringing in services from third-party UDDI registries such as SAP. For more information about integration with SAP, see the "Integration with SAP" chapter in Oracle Fusion Middleware Integration Guide for Oracle Enterprise Repository.

  • Exchange Utility can also receive metrics from Oracle Service Registry, which are published to Oracle Service Registry from Oracle Business Transaction Management 10g. For more information, see the "Integration with Amberpoint" chapter in Oracle Fusion Middleware Integration Guide for Oracle Enterprise Repository.

10.2 Configuring the Oracle Registry Repository Exchange Utility

This section describes how you can install and configure Oracle Registry Repository Exchange Utility.

This section contains the following topics:

10.2.1 Installing and Configuring the Oracle Registry Repository Exchange Utility

Before you can use the Oracle Registry Repository Exchange Utility to publish and receive Oracle Enterprise Repository metadata to and from Oracle Service Registry, you must complete the following configuration steps:

10.2.1.1 Install the Oracle Registry Repository Exchange Utility

When Oracle Enterprise Repository is installed, by default, the Oracle Registry Repository Exchange Utility files are found at

<Oracle_HOME>\repositoryXXX\core\tools\solutions

The Oracle Registry Repository Exchange Utility files for Oracle Enterprise Repository 11g are as follows:

  • 11.1.1.x.x-RR-ExchangeUtility.zip: Contains the package for the Exchange Utility.

You can unzip the 11.1.1.x.x-RR-ExchangeUtility.zip file into the directory on your file system where Oracle Enterprise Repository is installed, typically Oracle_HOME\repositoryXXX. When the zip file containing the Oracle Registry Repository Exchange Utility is unzipped to your file system, it creates the following structure.

  orrxu  <ExchangeUtility Tool Home>
    |      lib

Within the <ExchangeUtility Tool Home> directory, you will find the Oracle Registry Repository Exchange Utility files, such as the orrxu.xml, UDDIMappings.xml, orrxu.properties, orrxu.bat, and encrypt.bat files.

10.2.1.2 Configure Using the Asset Type Name

When a solutions pack is imported to a system that has existing Asset Types with different UUIDs than the pack, then those Asset Types are created and versioned. The orrxu.properties file specifies asset types by name, which causes results to be inaccurate. This is because it tries to use the asset types that already existed, and not the ones that were included in the new solutions pack.

In previous versions of Oracle Enterprise Repository, some Asset Types were not created by the solutions pack, but rather manually, which generated a random UUID.

If you have an existing asset with the same name as the datapack, then the work around is to rename the asset in their system, before they import the new datapack.

10.2.2 Installing Oracle Service Registry

You can install Oracle Service Registry and acquire the UDDI Inquiry URL such as http://host:port/registry/uddi/inquiry.

For more information about installing Oracle Service Registry, see http://download.oracle.com/otndocs/tech/soa/OSR11gR1ProductDocumentation.pdf.

10.2.3 Configuring the Oracle Registry Repository Exchange Utility Configuration File

This section describes how to configure the Oracle Registry Repository Exchange Utility configuration file for your environment. It contains the following topics:

10.2.3.1 Setting the Repository Connection Information

Open the orrxu.xml file located at <ExchangeUtility Tool Home> and modify the following XML section so that it points to your Oracle Enterprise Repository instance with the appropriate credentials.

<repository>
    <uri>http://localhost:7101/oer</uri> 
  <credentials>
    <user>admin</user> 
    <password>*****</password> 
     //To ensure security, the password must be encrypted.
     //The password encryption tool (encrypt.bat/encrypt.sh), which is located in
<Oracle_home>/repositoryXXX/core/tools/solutions/11.1.1.x.x-OER-PasswordTools.zip,
allows you to encrypt
// the passwords that are stored in the Oracle Registry Repository Exchange Utility configuration (orrxu.xml) file.
  </credentials>
</repository>

where URI = Oracle Enterprise Repository URI, using the following format:

http://<host>:<port>/<Oracle Enterprise Repository web app name>

Note:

It is recommended that you run the Exchange Utility as a user with the Basic Access Settings for Assets - View, Edit, Accept, and Register.

For more information about encrypting passwords, see Chapter 5, "Diagnostics and Password Encryption".

10.2.3.2 Setting the Registry Connection Information

The Oracle Registry Repository Exchange Utility can publish to one or more registries and can read from multiple registries (it requires separate transactions to read from each registry). The first step is to create one or more <registry> nodes with the connection info, as shown below:

<registries>
    <registry name="osr">
      <inquiryURI>http://localhost:7001/registry/uddi/inquiry</inquiryURI>
      <publishURI>http://localhost:7001/registry/uddi/publishing</publishURI>
      <securityURI>http://localhost:7001/registry/uddi/security</securityURI>
      <credentials>
        <user>admin</user> 
        <password>*****</password> 
     //To ensure security, the password must be encrypted.
     //The password encryption tool (encrypt.bat/encrypt.sh), which is located in
<Oracle_home>/repositoryXXX/core/tools/solutions/11.1.1.x.x-OER-PasswordTools.zip,
allows you to encrypt
// the passwords that are stored in the Oracle Registry Repository Exchange Utility configuration (orrxu.xml) file.
    </credentials>
    </registry>
    <registry name="osr2">
      <inquiryURI>http://localhost:7201/registry/uddi/inquiry</inquiryURI>
      <publishURI>http://localhost:7201/registry/uddi/publishing</publishURI>
      <securityURI>http://localhost:7201/registry/uddi/security</securityURI>
      <credentials>
        <user>admin</user> 
        <password>*****</password> 
     //To ensure security, the password must be encrypted.
     //The password encryption tool (encrypt.bat/encrypt.sh), which is located in
<Oracle_home>/repositoryXXX/core/tools/solutions/11.1.1.x.x-OER-PasswordTools.zip,
allows you to encrypt
// the passwords that are stored in the Oracle Registry Repository Exchange Utility configuration (orrxu.xml) file.
      </credentials>
    </registry>
  </registries>

10.2.3.3 Setting the Repository Query

The following configuration snippets demonstrate how to build a query to run against Oracle Enterprise Repository and receive the list of services that should be published to Oracle Service Registry. This filters the services to be pushed to Oracle Service Registry in the form of a query. There are a number of ways that services can be queried and you can create one or more queries. Some of the ways that services can be queried are:

10.2.3.3.1 Query by Name

When the <services> element is configured, the service name specified is published to Oracle Service Registry. However, due to a limitation in the Oracle Enterprise Repository REX API, only one <services> element can be added.

<query>
    <repositoryQuery>
      <services>
        <service name="HelloWorld" /> 
      </services>
      <registrationStatus></registrationStatus>
      <serviceCategorizations type="AssetLifecycleStage" value=""/>

The Query by Name also supports wildcard char % which finds the matching Service name, for e.g. if the query has <Service name="Hello%">, the query would find all the services whose names start with "Hello". e.g. <Service name="%"> would return all the services in OER.

10.2.3.3.2 Query by Registration Status

When the <registrationStatus> element is configured, only the services with the specified Registration Status are published. For example, if this field is set to Registered, then only registered services are published to Oracle Service Registry, while ignoring all other matched services that are not in this state.

  <registrationStatus>Registered</registrationStatus>

The acceptable values for registration status, which are not case sensitive, are as follows:

  • registered

  • rejected

  • under_review

  • pending_review

  • submitted

  • unsubmitted

  • undefined

10.2.3.3.3 Query by Categorizations

When the <serviceCategorizations> element is configured, only the services with the specified categorization is published. For example, when using the following categorization, only the Released services are published to Oracle Service Registry.

  <serviceCategorizations type="AssetLifecycleStage" value="Stage 4 - Release"/>

Note:

The serviceCategorization type supports all categorizations found under the taxonomy of the service asset. For example:

<serviceCategorizations type="Classification" value="Approved"/> 
<serviceCategorizations type="AssetFuntion" value="Governance"/>
10.2.3.3.4 Query by Filters

You may want to limit the kinds of services that are promoted to a UDDI registry from Oracle Enterprise Repository. The Filters element further narrows the selection based on the type of service besides registration status, service categorizations, and endpoint asset lifecycle. When configured, services that meet the specified criteria are the only services published. Each <filter> element has three attributes: type, exclude, and value.

  • Type (required field): There are two types of filters: metadata and wsdllocation.

    • metadata: In Oracle Enterprise Repository, a service asset has several types of metadata. This data can be filtered based on the metadata type name and the xpath for the field.

      An example is Service Type. This is a piece of metadata applied to all services created by the Harvester. The metadata type is internal.introspector and the xpath for the field is /sync/Service_Type.

      The format for the filter is as follows (prefixed by "metadata."):

      <filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />

    • wsdllocation: When harvesting services into Oracle Enterprise Repository, the WSDL location can be stored either on a remote server or as a local file information in Oracle Enterprise Repository.

    Note:

    When a service with a local file information is published, information on that WSDL will not be added to Oracle Service Registry, only metadata of the service.

  • Value (required field): Each type has its own set of possible values. This value is what is used to determine which services to filter on.

    • metadata values: Accepted values depend on the metadata type being filtered. For example:

      Service_Type: Proxy Service or Split-Join Service

      <filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />

      Scope: global or local

      <filter type="metadata.internal.introspector.store/sync/Scope" value="global" />

      Local indicates services that are not consumable.

      Deployment_Status: run-time or design-time

      <filter type="metadata.internal.introspector.store/sync/Deployment_Status" value="run-time" />

    • wsdllocation values: remote, local. The following will publish services with a remote WSDL.

      <filter type="wsdllocation" value="remote" />

  • Exclude (optional field): The exclude flag, if set to the value of true, publishes all services except those that match the criteria in the filter. The following publishes all services except those with a WSDL stored in a local file information.

    <filter exclude="true" type="wsdllocation" value="local" />

If the Exclude flag is set, then there can be multiple filters of the same type. This means that a search can be performed where a service is of the type Business Service or Split-Join Service. However, if the Exclude flag is not set, then multiple filters of the same type will not work, meaning a search cannot be performed where a service is of the type Business Service and Split-Join Service.

You can only combine multiple FILTER criteria when you are excluding the criteria from the search results. The EXCLUDE Business Service and the EXCLUDE proxy service will work. However, the INCLUDE business service and the INCLUDE proxy service will not work.

For example,

<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Business Service" />
or
<filter exclude="true" type="metadata.internal.introspector.store/sync/Service_Type" value="Business Service" />
<filter exclude="true" type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />

The following example will not work:

<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Business Service" />
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />

Example 1

The following example is the default configuration for Exchange Utility. It publishes services that are not of the service type Proxy Service from Oracle Service Bus and only services that have remote WSDLs.

<repositoryQuery>
  <services>
  <service name=" "/>
  </services>
  <!--Search criteria for the registration status of the service in
 Oracle Enterprise Repository -->
   <registrationStatus></registrationStatus>
   !--Search criteria for a categorization assigned to the service in
 Oracle Enterprise Repository -->           
   <serviceCategorizations type="AssetLifecycleStage" value=""/>
   <!--Name of UDDI Registries to publish to.  This name corresponds with
 UDDI Registry definitions -->
   <!--below under the <registries> section -->
   <destinationRegistries>
   <destinationRegistry name="TEST_UDDI">
   <endpointAssetLifecycleStatus></endpointAssetLifecycleStatus>
   </destinationRegistry>
   </destinationRegistries>
   <!--Filter: identify metadata to apply filter on services to
 publish-->
   <filters>
   <filter type="wsdllocation" value="remote" />
   <filter type="metadata.internal.introspector.store/sync/Scope"
 value="global" />
   <filter exclude="true"
 type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy
 Service" />
     </filters>
</repositoryQuery>

Example 2

The following will publish services with both remote and locally stored WSDLs and only services of the type Proxy Service.

<filters>
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />
</filters>

Example 3

The following publishes only Web services and exclude Business, Proxy, and Split-Join services:

<filters>
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Web Service" />
</filters>

10.2.3.4 Setting the Destination Registries

The following configuration snippet demonstrates how to use the <destinationRegistries> element to configure one or more destination registries where the matched Oracle Enterprise Repository Services will go. Each destination registry may contain an endpointAssetLifecycleStatus property. This serves to filter service endpoints of a certain Asset Lifecycle Stage Categorization type to be published to that registry, which means only endpoints that possess the given Asset Lifecycle Stage Categorization are published to the registry that is defined as such. The endpointAssetLifecycleStatus property is an optional property.

These registries are used when services are picked from Oracle Enterprise Repository and are moved to Oracle Service Registry (for example, Oracle Enterprise Repository > Oracle Service Registry).

<services>
    <service name="%"/>
</services>
<destinationRegistries>
<destinationRegistry name="DEV"> 
<endpointAssetLifecycleStatus>Stage3- Build</endpointAssetLifecycleStatus>
</destinationRegistry>
<destinationRegistry name="PROD"> 
<endpointAssetLifecycleStatus>Stage4-Release</endpointAssetLifecycleStatus>
</destinationRegistry>
</destinationRegistries>

Modify the destination registries and add the endpointLifecycleStatus element to them.

10.2.3.5 Setting the Registry Query

The following configuration snippet demonstrates how to use the <registryQuery> element to build a query to run against Oracle Service Registry and receive the list of services that need to be fetched from Oracle Service Registry and placed in Oracle Enterprise Repository.

<registryQuery>
    <businessEntities> 
      <businessEntity name="Account Services"/>
    </businessEntities> 
    <services>
      <service name="AddCustomerService%" /> 
    </services>
    <qualifiers>
      <qualifier>approximateMatch</qualifier> 
    </qualifiers>
  <sourceRegistry>osr</sourceRegistry> 
  </registryQuery>

Follow these configuration guidelines:

  • Ensure that the businessEntities name or service name value is not empty.

  • For the businessEntities name, the exact name must be specified.

  • For the service name, at least one wildcard character should be used. For example, to get all services specify "%".

  • Search criteria for an Oracle Service Registry query is case-sensitive.

Services can be searched in the following ways:

  • Search by one or more Service names. The Service names can be a wildcard if the qualifier is approximate. For example, if the service name is "Google%", any service that starts with "Google" is fetched and placed in Oracle Enterprise Repository.

  • Select one or more Business Entity and all the services in those Business Entities are fetched and placed in Oracle Enterprise Repository. The Business Entity name has to be exact, the wild card is supported only for Services and not for Business Entities.

    WARNING:

    If both Business Entity query and Service query are specified, the Business Entity query will override the Service query.

10.2.3.6 Setting the Source Registry

The <sourceRegistry> element tells the registry where the Services are picked and placed in Oracle Enterprise Repository. This registry is used when Services are picked from Oracle Service Registry and they move to Oracle Enterprise Repository (for example, Oracle Service Registry > Oracle Enterprise Repository).

<sourceRegistry>osr</sourceRegistry>

10.2.4 Configuring Oracle Enterprise Repository Categorizations in the UDDI Mappings File

Prior to publishing assets to Oracle Service Registry, Oracle Enterprise Repository Categorizations are mapped in the UDDI Mappings file, UDDIMappings.xml, which is stored in the <ExchangeUtility Tool Home> directory, as shown in the following XML snippet:

<uddi:uddiSettings xmlns:uddi="http://www.bea.com/aler/integration/config/uddi">
  <categorizationMappings>
    <categorizationType alerCategorizationTypeName="AssetLifecycleStage"
 alerCategorizationTypeId="112"
 uddiCategoryTModelKey="uddi:bea.com:aler:categorization:AssetLifecycleStage">
      <categorization alerCategorization="Stage 1 - Propose" uddiKeyName="Stage 1
 - Propose" uddiKeyValue="Stage 1 - Propose" /> 
      <categorization alerCategorization="Stage 2 - Plan" uddiKeyName="Stage 2 -
 Plan" uddiKeyValue="Stage 2 - Plan" /> 
      <categorization alerCategorization="Stage 3 - Build" uddiKeyName="Stage 3 -
 Build" uddiKeyValue="Stage 3 - Build" /> 
      <categorization alerCategorization="Stage 4 - Release" uddiKeyName="Stage 4
 - Release" uddiKeyValue="Stage 4 - Release" /> 
      <categorization alerCategorization="Stage 5 - Target For Retirement"
 uddiKeyName="Stage 5 - Target For Retirement" uddiKeyValue="Stage 5 - Target For
 Retirement" /> 
      <categorization alerCategorization="Stage 6 - Retirement" uddiKeyName="Stage
 6 - Retirement" uddiKeyValue="Stage 6 - Retirement" />

An Oracle Enterprise Repository Categorization is honored in Oracle Service Registry only if a corresponding mapping is present in the UDDI Mappings file; otherwise, the Categorization will simply be ignored. Therefore, if a new asset Categorization is created in Oracle Enterprise Repository, you must regenerate the UDDI Mappings file for that Categorization to be honored in Oracle Service Registry.

10.2.5 Configuring the tModelKey UDDI Setting

This section describes the steps to configure the tModelKey UDDI setting when creating a new categorization type in Oracle Enterprise Repository.

Some Oracle Service Registry published services contain extra metadata in the form of Categorizations that need to be pulled into Oracle Enterprise Repository. This allows you to create custom categorization types in Oracle Enterprise Repository and bind them to these custom categorizations.

Oracle Registry Repository Exchange Utility now allows binding Oracle Service Registry custom categorizations with Oracle Enterprise Repository custom categorizations by using the "tModel Key v3" option when creating a categorization type in Oracle Enterprise Repository, as shown in Figure 10-1. The key entered in this field must be the tModel Key of the associated Oracle Service Registry categorization.

Figure 10-1 The Edit Categorization Dialog

Description of Figure 10-1 follows
Description of "Figure 10-1 The Edit Categorization Dialog"

The steps to configure the tModelKey UDDI setting are as follows:

  1. In the Asset Editor window, select Actions, and then Configure Categorizations. The Configure Categorization dialog is displayed. This creates custom categorization types that mirror Oracle Service Registry categorizations.

    Note:

    The tModel Key v3 field is set to uddi:oracle.com:aia:service:lifecyclestatus, which is exactly what is in the Oracle Service Registry service category's tModel key.

  2. Click Add to add a categorization. The Add Categorization dialog is displayed. For example, add the AIA-LifeCylceStatus categorization.

  3. Enter the values in the Add Categorization dialog, as shown in Figure 10-2.

    Figure 10-2 The Add Categorization Dialog

    Description of Figure 10-2 follows
    Description of "Figure 10-2 The Add Categorization Dialog"

  4. Select AIA-LifeCycleStatus in the pane below the tModel Key v3 field, and then click Add. The Add Categorization dialog is displayed.

  5. Enter Active in the Name field, as shown in Figure 10-3.

    Figure 10-3 The Add Categorization Dialog

    Description of Figure 10-3 follows
    Description of "Figure 10-3 The Add Categorization Dialog"

  6. Click OK.

  7. Similarly, add the following values for the categorization: Deprecated, Obsolete, and Planned, as shown in Figure 10-4.

    Figure 10-4 The Add Categorization Dialog

    Description of Figure 10-4 follows
    Description of "Figure 10-4 The Add Categorization Dialog"

  8. Click OK.

  9. In the Asset Editor window, click Actions, Manage Types. The Type Manager window is displayed.

  10. Select the Service asset type. The Service asset type details are displayed in the right pane.

  11. In the Tabs pane, select Taxonomy. The corresponding elements for the Taxonomy are displayed in the Elements pane.

  12. Click the Add button adjacent to the Elements pane. The Select an Element Type to Add dialog is displayed.

  13. Select Categorization: AIA-LifeCycleStatus from the Element Type list, as shown in Figure 10-5.

    Figure 10-5 The Select An Element Type to Add Dialog

    Description of Figure 10-5 follows
    Description of "Figure 10-5 The Select An Element Type to Add Dialog"

  14. Click OK. The Edit Categorization: AIA-LifeCycleStatus dialog is displayed.

  15. Click OK.

  16. Click the Viewer tab.

  17. In the Hidden Elements pane, select AIA-LifeCycleStatus and click Display In Group. The Move Element dialog is displayed.

  18. Select Taxonomy in the Move AIA-LifeCycleStatus to field, as shown in Figure 10-6.

    Figure 10-6 The Move Element to Dialog

    Description of Figure 10-6 follows
    Description of "Figure 10-6 The Move Element to Dialog"

  19. In the Exchange Utility tool, generate the UDDIMappings.xml file. Specify the connection information to the Oracle Enterprise Repository instance in the orrxu.xml file.

  20. From the Exchange Utility tool, install orrxu.bat -map.

  21. Verify that the UDDIMappings.xml file contains the newly created Oracle Enterprise Repository categorization:

    Figure 10-7 UDDIMappings.xml File

    Description of Figure 10-7 follows
    Description of "Figure 10-7 UDDIMappings.xml File"

    When Oracle Service Registry services are received into Oracle Enterprise Repository, the Oracle Enterprise Repository service asset now has this categorization value set and is visible in the Oracle Enterprise Repository web UI.

10.2.6 Understanding the Oracle Registry Repository Exchange Utility's Property File

This section describes the properties in the Property file, orrxu.properties, file that is stored in the <ExchangeUtility Tool Home> directory. Some properties already exist in the Oracle Enterprise Repository System Settings and some of the properties are new for the Oracle Registry Repository Exchange Utility.

  • cmee.uddi.service.endpoint.relationship=Deployment-Deployed - relationship between Service and Endpoint.

  • cmee.import.uddi.business.assettype=SOA - Business Entity -Business Entity asset type.

  • cmee.import.uddi.accesspoint.assettype=Endpoint - Endpoint asset type.

  • cmee.import.uddi.artifactwsdl.relationship=Sync-Defines - relationship between Service and WSDL artifact.

  • cmee.import.uddi.receiver.batch.size=100 - Only when receiving from Oracle Service Registry, this determines the batch size.

  • cmee.import.uddi.publish.ifendpointmissing : By default, if a service in Oracle Enterprise Repository does not have one or more endpoints or the existing endpoints have invalid access points, then Exchange Utility will not publish it. If this setting is set to true, then services with no endpoints are published to the Oracle Service Registry.

    Caution:

    The following properties will only be used if the corresponding property is not set in the Oracle Enterprise Repository System Settings. If the Oracle Enterprise Repository System Settings property is configured, that setting will override the property in the orrxu.properties file.

  • cmee.uddi.business.service.relationship=BusinessService - relationship between Service and Business Entity asset types.

  • cmee.import.uddi.service.assettype=Service - Service asset type.

  • cmee.uddi.default.business=A UDDI Node - only when publishing services to Oracle Service Registry, when the asset is not linked to a Business Entity.

For more information about other Oracle Enterprise Repository System Settings, see Oracle Fusion Middleware User's Guide for Oracle Enterprise Repository.

10.2.7 XU Support

By default, XU supports the publication of WSDL-based HTTP Services to OSR that originate in OER from harvesting operations using the asset types provided in the Harvester solution pack. These services, together with their interfaces, artifacts, endpoints and system-supplied relationships, are rendered in OSR in a way that allows them to be consumed by tools that integrate with OSR, including the Oracle Service Bus console.

Noteus:

All services are consumable by Oracle Service Bus in Oracle Service Registry unless otherwise noted.

Table 10-1 XU Support for Harvested WSDL Services

Service Type/Origin Service Model in OER Includes XU Publishes from OER to OSR? Notes

Harvested WSDL-based HTTP Services with WSDL attachment

Artifact: WSDL attached to interface

Yes, if WSDL has remote URI

Services do not require an endpoint in order to be published, however they need the endpoint in order to be consumed by OSB.

10.2.7.1 XU Support for Manually-Created Services

Configured differently, XU also supports a wide variety of non-WSDL HTTP service types in OER originating from different sources and with different models.

Table 10-2 XU Support for Manually-Created* Services

Service Type/Origin Service Model in OER Includes XU Publishes from OER to OSR? Notes

Manually-created WSDL-based HTTP Services with attachment (no harvesting)

Artifact:WSDL manually attached to Interface

Yes, if WSDL has remote URI

Different asset and relationships can be used and mapped in XU mapping file, if the MODEL is consistent with SOA model that has Service, interface, endpoint, Artifact: WSDL

Manually-created non-WSDL-based HTTP Services with XSD attachment

Artifact: XSD or similar Artifact manually attached to interface via relationship mapped in XU. No interface type defined.

Yes, if XSD has remote URI; XSD is published as tModel: uddi-org:resource:type with value=xsd

  • OSB will not consume the XSD

  • Published as Messaging Service Type with Input XML/Output XML

Manually-created non-WSDL HTTP Services with artifact (e.g. REST with WADL)

Different type of Artifact (non-XSD, e.g. WADL) attached to Interface via relationship mapped in XU

Yes, as long as artifact has remote URI; artifact is published as tModel: uddi-org:resource:type with value=xml

  • OSB will not consume the XSD

  • Published as Messaging Service Type with Input XML/Output XML

Manually-created non-WSDL HTTP Services without artifact (e.g. REST)

No attached XSD or similar Artifact

Yes

Published as Messaging Service Type with Input XML/Output XML

Note:

Services that are manually created in OER (not harvested) must, at a minimum, have an endpoint and an interface in order to be published to OSR in a form that is consumable by Oracle Service Bus.

*Also applies to services that are created using the REX API

10.2.7.2 XU Support for Non-WSDL Services Harvested from Oracle Service Bus

Configured differently, XU also supports a wide variety of non-WSDL HTTP service types in OER originating from different sources and with different models.

Table 10-3 XU Support for Non-WSDL Services Harvested from Oracle Service Bus

Service Type/Origin Service Model in OER Includes XU Publishes from OER to OSR? Notes

OSB-Harvested WSDL-based HTTP Services with WSDL attachment

Artifact: WSDL attached to Interface

Yes, if WSDL has remote URI

Similar to WSDL services harvested by OER Harvester.

OSB-Harvested non-WSDL-based HTTP Services

Any XML (not REST)

Yes

  

OSB-Harvested non-WSDL-based HTTP Services

Any SOAP (not REST)

Yes

  

OSB-Harvested non-WSDL-based HTTP Services

Messaging with MFL only; Artifact:MFL attached

No

  • Not consumable by OSB in OSR.

  • MFL artifacts do not have a remote URI in OER.

OSB-Harvested non-WSDL-based HTTP Services (including REST Proxy services)

All Messaging except MFL; may or may not have an Artifact:XSD

Yes, however XSD artifacts are not published without a remote URI

  

OSB-Harvested REST HTTP business services

No Artifact:XSD or similar Artifact attached to interface

  

Not consumable by OSB in OSR.

Note:

Services must, at a minimum, have an endpoint and an interface in order to be published to OSR in a form that is consumable by Oracle Service Bus.

Only one type of XU-mapped relationship (e.g. between interface and Artifact) can be used in the publication of non-WSDL or manually-created services in any given XU session. This is concurrently supported with harvested WSDL-based services. XU can publish non-WSDL services with a single designated system-supplied relationship (either system supplied or manually-supplied) but not more than one type at once.

10.2.7.3 Configuring XU to Publish Non-Harvested or Custom Asset Types and Relationships

XU defines what asset types and relationships make up a service and its endpoints. For example, the OER Service asset type defines the UDDI Business Service. The Endpoint asset defines the access point, and the relationship, Deployed-To, relates the two asset types together. With these default settings, services created by the Harvester are published to OSR.

However, if you create services without the Harvester or use your own asset types and relationships which differ from the default configuration, you must follow these configuration steps, in order for the services to be published to OSR, such as non-WSDL-based HTTP services harvested from OSB .

Only one service asset type can be published at a time. When using asset types and relationships other than the ones defined by default:

  • Change the system setting in OER, cmee.import.uddi.service.assettype, to point to the custom asset type. By default, it points to Service, but it can point to any asset type desired.

  • Modify the orrxu.properties:

    • cmee.import.uddi.accesspoint.assettype=<custom endpoint asset type>

For WSDL Services

  • cmee.import.uddi.artifactwsdl.assettype=<custom artifact WSDL asset type>

Note:

This custom artifact WSDL type NAME must begin with Artifact.

For Non-WSDL Services

  • cmee.import.uddi.definingartifact.relationship=<custom artifact asset type>

  • cmee.import.uddi.artifactwsdl.relationship=<custom relationship between endpoint/interface and artifact asset>

  • cmee.import.uddi.interface.service.relationship=<custom relationship between service and interface assets>

  • cmee.uddi.service.endpoint.relationship=<custom relationship between service and endpoint>

Non-Harvested Services

  • In the Type Manager, select the asset type being used to define the access point (Endpoint out-of-the-box) and add the following Custom Data URL element: endpoint-uri.

  • This endpoint-uri field must be manually populated with the access point of the service to be published to the UDDI Registry.

Example 10-1 Service definition in the WSDL

<service name=”OERSearchService”>
                        <port name=”OERSearchPort” binding=”typens:OERSearchBinding”>                              <soap:address location=”http://api.oracle.com/search/oer”/>                     </port>      </service>

10.3 Using the Oracle Enterprise Repository Exchange Utility

This section describes how you can use the Oracle Registry Repository Exchange Utility to synchornize metadata and search for exchanged metadata in Oracle Enterprise Repository.

This section contains the following topics:

10.3.1 Running the Oracle Registry Repository Exchange Utility

The Oracle Registry Repository Exchange Utility is run from a command-prompt, using the following syntax:

  > orrxu.bat <options>

Table 10-4 defines the configuration options available when running the Oracle Registry Repository Exchange Utility.

Table 10-4 Oracle Registry Repository Exchange Utility Command-line Options

Option Required What it Does

-mode <mode>

Yes

Configures the utility to run in either publish or receive mode.

  • To publish Services to Oracle Service Registry from Oracle Enterprise Repository, use:

    orrxu.bat -mode publish

  • To receive Services from Oracle Service Registry into Oracle Enterprise Repository, use:

    orrxu.bat -mode receive

-config <File Name>

Optional

Passes the orrxu.xml file as a parameter.

Example usage:

orrxu.bat -mode publish -config C:\rm\uddi\orrxu.xml

If this parameter is omitted, the configuration XML file is loaded from the current directory where the orrxu.bat file is located using the system's Classpath.

-map <Dir Name>

Optional

Generates a UDDIMappings.xml file by connecting to Oracle Enterprise Repository and populating it with the t-models based on the configured Categorizations. Also, this loads the Oracle Registry Repository Exchange Utility configuration using the -config parameter from the default location. You can customize this file if the t-model already exists in Oracle Service Registry and map an Oracle Enterprise Repository categorization to a t-model.

Example usage: orrxu.bat -map c:/rm/uddi

For more information about the UDDIMappings.xml file, see Section 10.2.4, "Configuring Oracle Enterprise Repository Categorizations in the UDDI Mappings File".

-publish_tmodel <File Name>

Optional

Publishes all the t-models configured in the UDDIMappings.xml file to Oracle Service Registry. If a t-model already exists in Oracle Service Registry, it is skipped. You need to manually delete the existing t-models if you want the Oracle Registry Repository Exchange Utility to populate those t-models. Also, this loads the Oracle Registry Repository Exchange Utility configuration using the -config parameter from the default location.

Example usage: orrxu.bat - publish_tmodel c:/rm/UDDIMappings.xml

For more information about the UDDIMappings.xml file, see Section 10.2.4, "Configuring Oracle Enterprise Repository Categorizations in the UDDI Mappings File".

10.3.1.1 Invoking the Oracle Registry Repository Exchange Utility Using Workflows

By using workflows to invoke the Oracle Registry Repository Exchange Utility, you can automate the synchronization of Oracle Enterprise Repository and Oracle Service Registry.

This section contains the following topics:

For more information about the workflow.xml file and configuring workflows, see Chapter A, "Configuring Oracle Enterprise Repository Workflow".

10.3.1.1.1 Prerequisities

This section describes the prerequisite configuration steps required prior to running Oracle Registry Repository Exchange Utility workflows:

  1. Download the Oracle Registry Repository Exchange Utility solution pack, 11.1.1.x.x-RR-ExchangeUtility.zip, from <Oracle_HOME>\repository111\core\tools\solutions.

  2. Extract the zip file and copy the following files from it to <Oracle_Home>\obpm\enterprise\server\aler_engine directory:

    • plugins

    • orrxu.properties

    • orrxu.xml

    • log4fl.properties

    • types.properties

    • UDDIMappings.xml

    These files are required to run the Oracle Registry Repository Exchange Utility workflows from Oracle BPM.

  3. Configure orrxu.xml for the connection information of Oracle Enterprise Repository instance that generates events from and for the Oracle Service Registry instance, and also for publishing/receiving assets.

  4. Ensure that the passwords in the files are encrypted using the encrypt tool.

10.3.1.1.2 Synchronizing Using Timer Based Workflows

A timer based workflow can be used to synchronize Oracle Enterprise Repository from Oracle Service Registry, or to synchronize Oracle Service Registry from Oracle Enterprise Repository.

Table 10-5 shows the names and descriptions of the timer based workflows:

Table 10-5 Timer Based Workflows

Workflow Name Description

autoSyncAlerToUddi

Moves services from Oracle Enterprise Repository to Oracle Service Registry.

autoSyncUddiToAler

Moves services from Oracle Service Registry to Oracle Enterprise Repository.

The timer can be configured to wake up based on the timerInterval settings in the workflow.xml file. The following example shows the autoSyncAlerToUddi and autoSyncUddiToAler workflows configured in the workflow.xml file:

<automation>
    <autoSyncAlerToUddi configFilename="AlerToUddiSyncOrrxuConfig.xml"
    mappingFileName="AlerToUddiSyncOrrxuMapping.xml" timerInterval="2d"/>
    <autoSyncUddiToAler configFileName="UddiToAlerSyncOrrxuConfig.xml"
    mappingFileName="UddiToAlerSyncOrrxuMapping.xml" timerInterval="3d"/>
</automation>
10.3.1.1.3 Synchronizing When Events are Triggered

Individual services and their metadata can be moved to Oracle Service Registry by wiring the events that get triggered when these services are registered or a lifecycle of a service is changed.

The PublishAssetToUDDI workflow can be used to move the services. The PublishAssetToUDDI workflow can be wired to any event trigger, depending on the requirements.

For example, the following configuration moves the service when the Asset Lifecycle stage is QA:

<state name="urn:com:bea:aler:events:type:CategorizationChanged:AssetLifecycleStage" value ="QA">
<action>PublishAssetToUddi</action>
<alrrxConfigFileName>my_orrxu.xml</alrrxConfigFileName>
<alrrxMappingFileName>my_uddiMappings.xml</alrrxMappingFileName>
</state>

Also, note that the configuration related to where the registry is running is configured using the alrrxConfigFileName setting, and that the mapping file related to the categorization is configured using the alrrxMappingFileName setting.

Note:

The files specified in <alrrxConfigFileName> and <alrrxMappingFileName> are to be present in the aler_engine folder in obpm.

You could have differerent configuration files configured to point to different registries. Depending on the lifecycle, the services can be moved to different registries based on the Asset Lifecycle triggers.

10.3.1.1.4 Example Use Cases

Oracle Enterprise Repository supports the following use cases for automated workflows:

  • Automated workflows can automate synchronizing Oracle Enterprise Repository and Oracle Service Registry based on a configured timer interval.

  • When different registries are running to categorize services based on the Lifecycle, services can be published automatically to these registries by wiring the Asset Lifecycle event trigger to publish to the relevant registry.

  • Services can be automatically published to Oracle Service Registry if a service is submitted to Oracle Enterprise Repository. When a service is submitted to Oracle Enterprise Repository, it triggers an event which is processed by the workflows. The workflows will move this to Oracle Service Registry automatically, if it is configured to do so.

10.3.2 How the Exchanged Metadata Is Synchronized

This section describes how metadata is synchronized when assets are exchanged between Oracle Enterprise Repository and Oracle Service Registry. This section contains the following topics:

10.3.2.1 Synchronizing the Metadata Published from Oracle Enterprise Repository to Oracle Service Registry

This section describes how metadata is synchronized when publishing assets from Oracle Enterprise Repository to Oracle Service Registry. It contains the following topics:

Note:

When synchronizing a service to Oracle Service Registry that was previously synchronized, Oracle Service Registry does not show the updated values if an Oracle Service Registry browser instance is already open. Therefore, all the Oracle Service Registry browser instances need to be restarted to see the updated values.

For more information, see Section 10.3.5, "Known Issues".

10.3.2.1.1 Business Entities

Check if the Service asset being published has a related (by configured relation) Business Entity asset:

  • If yes, use the existing Business Entity asset to relate to newly created Service asset using configured relation.

  • If no, get default Business Entity name from configuration, as follows:

    • Check if default business entity asset is configured in the Oracle Enterprise Repository System Settings.

    • If yes, use that as the default Business Entity.

    • If no, use the default Business Entity name from the orrxu.properties file.

10.3.2.1.2 Service Keys

When you publish services to Oracle Service Registry, the Exchange Utility automatically generates a new service key and assigns it to the service in Oracle Enterprise Repository as well as Oracle Service Registry. You can also supply your own service key on a service through the Asset Editor.

Note:

When supplying your own service key, it must contain only alpha-numeric characters, plus ':', '.', '%', '_', and '-'. When the service is published to a UDDI Registry, the service key is converted to an org.apache.axis.types.URI object. Therefore, it must conform to the URI syntax.

For Types that have the UDDI Plugin applied, you could use the Service Key field, which is located in the Technical tab under the UDDI Service section. If this field is populated, then the service key is synchronized to Oracle Service Registry. However, once this service is published, this field will no longer be editable.

Oracle Enterprise Repository determines the published status by the existence of UDDI Registries that the service has been published to.

Note:

If the UDDI Registry tables are cleared out from all Endpoints or the Service using the Delete feature, the Service Key becomes writable. However, changing the service key and re-publishing to a UDDI Registry can cause the service keys to be out of sync. This is not supported. If the Service Key is changed, the corresponding Services in the UDDI Registry should be deleted and republished.

To see this, a table displaying the UDDI Registries is available to the Endpoints that belong to the Service. This table can be found in the Technical tab. However, if the Service is defined by a WSDL that is stored locally in Oracle Enterprise Repository, the Endpoints will not be published to the UDDI Registry. Due to this, the table can be found in the Service asset within the Technical tab.

If the Exchange Utility configuration is not using the Endpoint asset type, then you must add the UDDI Registries plugin manually. To do this, go to the Type Manager and select the asset type that is being used. Select the desired tab and under Elements, select Add. From the list, select UDDI Registries. Also, ensure that you add this plugin to the Viewer tab.

For more information about modifications to asset types, see Oracle Fusion Middleware User's Guide for Oracle Enterprise Repository.

10.3.2.1.3 Endpoint

Check if the Service asset being published has one or more related endpoint assets, as follows:

  • If yes, then create UDDI Binding Templates if this is the first time. If this was synchronized before, update the existing Binding Templates. Use the Endpoint URI in the Endpoint asset to arrive at the UDDI Access point. Derive the port from the WSDL that is attached to the File Info of the endpoint asset. If the WSDL is stored locally in Oracle Enterprise Repository, the existing binding template in Oracle Service Registry will not be updated.

  • If no, then create the Binding Templates based on the WSDL that is attached to the File Info of the Service asset if the WSDL contains the port info. The Binding Templates are created only for WSDLs that are located remotely (http://). WSDLs that are stored locally in Oracle Enterprise Repository are not included.

  • If Asset Life cycle is attached to the endpoint and if the Endpoint Asset Life cycle Query is used, then filter the endpoints based on the Asset Lifecycle. For example, you can publish the staging endpoint to the Staging Registry and publish the production endpoint to the production registry.

10.3.2.1.4 Categorizations

Check if Categorizations are applied to Service and Endpoint assets, as follows:

  • If yes, then load the Categorization mapping for each of the applied Categorizations from the UDDIMappings.xml file.

    • If the mapping is found, then add an entry to the Category Bag, either to the Business Service or Binding Template.

    • If the t-model is not found in the Oracle Service Registry, then automatically create the t-models.

  • If no, then the Categorization will not be applied to the Service in Oracle Service Registry.

10.3.2.1.5 Registration and Active Status

The Registration and Active Status are added to Category Bags. Figure 10-8 illustrates how references appear in Oracle Service Registry.

Figure 10-8 Oracle Service Registry t-model Categories for a WSDL Service

Description of Figure 10-8 follows
Description of "Figure 10-8 Oracle Service Registry t-model Categories for a WSDL Service"

Figure 10-9 illustrates how two endpoints that are linked to a service in Oracle Enterprise Repository appear in Oracle Service Registry.

Figure 10-9 WSDL Bindings in Oracle Service Registry

Description of Figure 10-9 follows
Description of "Figure 10-9 WSDL Bindings in Oracle Service Registry"

Figure 10-10 and Figure 10-11 illustrate how the different entities and their relationships appear in the Oracle Enterprise Repository Navigator.

Figure 10-10 Entity Relationship in Oracle Enterprise Repository Navigator

Description of Figure 10-10 follows
Description of "Figure 10-10 Entity Relationship in Oracle Enterprise Repository Navigator"

Figure 10-11 Another Entity Relationship in Oracle Enterprise Repository Navigator

Description of Figure 10-11 follows
Description of "Figure 10-11 Another Entity Relationship in Oracle Enterprise Repository Navigator"

10.3.2.1.6 Sample Flow of Metadata from Oracle Enterprise Repository to Oracle Service Registry

Figure 10-12 illustrates the Oracle Enterprise Repository > Oracle Service Registry metadata synchronization described in this section.

Figure 10-12 Flow of Metadata Published from Oracle Enterprise Repository to Oracle Service Registry

Description of Figure 10-12 follows
Description of "Figure 10-12 Flow of Metadata Published from Oracle Enterprise Repository to Oracle Service Registry"

10.3.2.2 Synchronizing the Metadata from Oracle Service Registry to Oracle Enterprise Repository

This section describes how metadata is synchronized when receiving assets into the repository from Oracle Service Registry. It contains the following topics:

10.3.2.2.1 Business Entities

Check if the Service asset being received exists and is related to a Business Entity asset, as follows:

  • If yes, the same Business Entity relationship is used.

  • If no, the Business Entity on the Oracle Service Registry side is used. If the Business Entity does not exist in Oracle Enterprise Repository, it is created.

If the Service asset is newly created, get the default Business Entity asset type for UDDI Business from the Oracle Enterprise Repository configuration:

  • If found in the System Settings

  • If not, from the orrxu.properties file

Check if an asset exists with that name and type, as follows:

  • If yes, simply relate that existing asset to newly created service asset using configured relation.

  • If no, create a new asset and relate it to newly created service asset using configured relation.

10.3.2.2.2 Endpoint

Check if the Service asset being received has one or more Endpoint assets related, as follows:

  • If yes, create check if the Endpoint assets are the same as the existing Binding Templates using the UUID. If they are same, update the Endpoints.

  • If no, create the Endpoints for each Binding Template and relate them to the Service asset.

10.3.2.2.3 Categorizations

Check if Categorizations are present in the Category Bag, as follows:

  • If yes, load the Categorization mapping for each of the applied Categorizations from the UDDIMappings.xml file.

  • If the mapping is found, set the Categorizations of the Service asset.

10.3.2.2.4 Sample Flow of Metadata from Oracle Service Registry to Oracle Enterprise Repository

Figure 10-13 illustrates the Oracle Service Registry > Oracle Enterprise Repository metadata synchronization described in this section.

Figure 10-13 Flow of Metadata Received from Oracle Service Registry

Description of Figure 10-13 follows
Description of "Figure 10-13 Flow of Metadata Received from Oracle Service Registry"

10.3.3 Searching for Oracle Service Registry Exchanged Metadata in Oracle Enterprise Repository

The Oracle Registry Repository Exchange Utility tags each published and received Service with information that can be used for querying, as follows:

  • Publish or Receive Date and Time

  • Source and Destination Registries.

To query published/received Service information, use the Oracle Enterprise Repository More Search Options feature, as follows:

  1. In the Oracle Enterprise Repository Web console, open the Assets page.

  2. In the Search box in the sidebar, click the More Search Options link. The More Search Options dialog is displayed.

  3. Select the Filter by Additional Criteria option to reveal the additional filtering criteria options.

  4. In the Select a Field list, select the internal.alrr.exchange.store option.

  5. In the field next to the Add button, enter the date the metadata was exchanged, as shown in Figure 10-14.

    Figure 10-14 More Search Options Dialog

    Description of Figure 10-14 follows
    Description of "Figure 10-14 More Search Options Dialog"

  6. Click the Search button at the bottom of the dialog.

    For more information about using the Oracle Enterprise Repository search options, see Oracle Fusion Middleware User's Guide for Oracle Enterprise Repository.

10.3.4 Checking the Oracle Registry Repository Exchange Utility Log File

The Oracle Registry Repository Exchange Utility uses log4j for logging the detailed tasks performed. The log file is stored in the <ExhangeUtility Tool Home> directory. The logging options can be changed by updating the log4fl.properties file located in the <ExhangeUtility Tool Home> directory.

10.3.5 Known Issues

This section describes the known issues when using the Oracle Registry Repository Exchange Utility. It contains the following topics:

10.3.5.1 Resynchronizing Oracle Service Registry Services

When synchronizing a service to Oracle Service Registry that was previously synchronized, there is a known issue where Oracle Service Registry does not show the updated values if an Oracle Service Registry browser instance is already open. Therefore, all the Oracle Service Registry browser instances need to be closed and restarted to see the updated values.

10.3.5.2 Publishing Services to Oracle Service Registry

  1. Once services from Oracle Enterprise Repository are published to Oracle Service Registry, it is possible that you may encounter an error when trying to open the WSDL Location URL of the service in Oracle Service Registry.

    Workaround:

    Copy and paste the URL of the WSDL location to the same browser instance where Oracle Enterprise Repository console is logged into.

  2. When the Oracle Enterprise Repository Registry Exchange Utility was used to publish a service to the Oracle Service Registry, a new service key was generated for the service in the Service Registry. Now, service keys are kept consistent between the service asset and all Service Registry instances. Since, Oracle Enterprise Repository Exchange Utility supports publishing service endpoints to multiple registry at the same time, the service key is kept consistent for a service across all registries.

    Workaround:

    None.

  3. When an Oracle Enterprise Repository service that does not contain a service key is submitted to Oracle Service Registry, a service key is created from the service asset's UUID. This service key is then maintained across all registries when this service is published to multiple registries.

    Workaround:

    None.

10.3.5.3 Running an Incorrect Version of Java

While running Oracle Enterprise Repository Registry Exchange Utility, If you are not using the minimum required JDK 1.6 version, then the following error message is displayed:

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad
version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
@         at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
@         at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
@         at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)