Domain Value Maps (DVMs) are simply mapping objects. They are used in composites to map data that may be stored in one application in one format, to that of the target application in another format. For example, the contents of a CountryCodes.dvm file can be as follows:

<?xml version = '1.0'?>
<dvm name="CountryCodes" xmlns="http://xmlns.oracle.com/dvm">
  <description>DVM description</description>
  <columns>
    <column name="CountryCode"/>
    <column name="CountryName"/>
  </columns>
  <rows>
    <row>
      <cell>US</cell>
      <cell>United States</cell>
    </row>
    <row>
      <cell>UK</cell>
      <cell>United Kingdom</cell>
    </row>
    <row>
      <cell>ZA</cell>
      <cell>South Africa</cell>
    </row>
  </rows>
</dvm>

In this example, country code may be stored as US in one application and United States in another, and by using transformation functions within SOA composites, developers can look up and map values as needed.

Although database tables can be used as a substitute for DVMs, DVMs are static in nature and are optimized for speed and performance. DVMs are typically created by developers at design time, or they can be created manually and the .dvm files can be imported directly into the MDS via Ant.

Cross references are slightly different in that they are used to dynamically map values from one application to another. For example, you may have two applications, each maintaining its own customer table wherein customer-specific information such as customer ID, customer name, customer address, and other customer metadata is stored. However, each application may have a different format for the unique identifier called customer ID. For example, SAP may create customer IDs in a format different from Oracle E-Business Suite, as shown in the following table:

Thus, Cross references are used to map these dynamic customer IDs across applications. Cross References, or XREFs, consist of two parts:

Similar to DVMs, Cross references can be created by the developer at design time, or they can be created manually and the .xref files can be imported directly into the MDS via Ant. The good news is that, from an administrative standpoint, aside from using Ant to import .dvm and .xref files to the MDS, there is not much to do. In general, it is valuable to understand each.

Administering DVMs

In an earlier section in this chapter, we explained how SOA Composer can be used to manage runtime configuration changes for human workflow tasks. The web-based SOA Composer console can additionally be used to modify deployed domain value maps at runtime. This eliminates the need to use Ant to reimport DVMs if there is a need for dynamic changes. Access to the SOA Composer console is controlled by associating users and groups to the SOADesigner role under the soa-infra application stripe.

The expected administrative tasks related to DVMs include:

• Using Ant to import DVMs into the MDS.
• Using SOA Composer to add or edit values in a DVM at runtime.

Perform the following steps to modify DVM values at runtime:

1. Log in to SOA Composer at http://<soahost>:<soaport>/soa/composer.
2. Click on Create Session to initiate a change window.
3. By default, the SOA Composer organizes resources by Deployment View (that is, by the deployed composites that they are packaged into).
4. Change this to Types View by clicking on the icon.
5. Expand Domain Value Maps to click on the DVM that needs to be edited.
6. Click on one of the add (), edit (), or delete () icons as shown in Figure 7.43 to modify a DVM row.
7. After the change is done, click on the Save button.
8. For the runtime change to come into effect, click on Publish.

The following screenshot displays an example DVM in the SOA Composer:

Figure 7.43: Modifying DVM values at runtime via the SOA Composer