Specify a properties file with the idresgen utility

Administer > Transforming, loading, and extracting data > Overview of the mass load utilities > Resolve identifiers

Specify a properties file with the idresgen utility

You can use an alternative Java properties file to describe which columns of a primary entry should be used as lookups for tables, which require the identifier of a primary row. This definition takes precedence over the unique index resolution method.

The default properties file is IdResolveKeys.properties, but you can modify it or specify the own file when invoking the idresgen utility.
The IdResolveKeys.properties is located in the following directory:

WC_INSTALL/properties

workspace_dir/wc/properties

If you do not place this file is in the current directory when you run the igresgen utility, you can place it in a directory defined in the classpath environment variable. You can also specify the full path to this file.
To change IdResolveKeys.properties:

Procedure

Copy IdResolveKeys.properties from the WC_INSTALL/properties directory and save it to the WC_INSTALL/instances/ instance.xml directory.

Make any necessary changes to this new file.

Results

You can use the properties file...

Use a properties file to generate identifiers

Use a properties file with compound keys

Use a properties file with cascaded primary keys

Using a properties file to generate identifiers
In the following example, resolve identifiers ADDRBOOK_ID and ADDRESS_ID for ADDRBOOK and ADDRESS records respectively. The identifiers for the MEMBER records are already known. Each record requires a valid identifier for the WebSphere Commerce database. In addition, the ADDRBOOK_ID in the ADDRESS record requires the identifier from the primary table to satisfy its foreign-key constraint.
 
<MEMBER
    MEMBER_ID="100"
    TYPE="U"
    STATE="1"
  />  
<MEMBER
    MEMBER_ID="101"
    TYPE="U"
    STATE="1"
  />  
<ADDRBOOK
    MEMBER_ID="100"
    DISPLAYNAME="Friends"            
Actual value of the DISPLAYNAME column
    DESCRIPTION="All my friends"
    TYPE="P"
  />  
<ADDRESS
    ADDRBOOK_ID="@Friends"           
Refers to the ADDRBOOK using the DISPLAYNAME 
                                     value as a lookup
    MEMBER_ID="101"
    NICKNAME="Bob"
    ADDRESS1="15 Brave Developers St."
    CITY="Toronto"
    ZIPCODE="A0A0A0"
    COUNTRY="Canada"
    STATUS="P"
  />
You need a properties file to identify which columns in the primary row will be used by the relationship rows in resolving the identifier for the foreign-key column. The following procedure ensures that parsing of the preceding file proceeds correctly.
In IdResolveKeys.properties, specify the following:
NAMEDELIMITER=@
  SELECTDELIMITER=: 
  ADDRBOOK=@DISPLAYNAME:DISPLAYNAME
  ADDRESS=@NICKNAME:NICKNAME
NAMEDELIMITER and SELECTDELIMITER set the delimiters used throughout the properties file, and they must be used consistently.

ADDRBOOK=@DISPLAYNAME:DISPLAYNAME states that when an address-book record is received, the identifier for the address-book row is created.

The DISPLAYNAME field is extracted from the input record and used to form an association to the new identifier. The DISPLAYNAME string is used to match the address-book row DISPLAYNAME and resolve the identifier needed by the foreign key.

Use the previous input example, in which the DISPLAYNAME is Friends, assume that the identifier created for this record is 12951. The DISPLAYNAME is used as a key look-aside for 12951. Processing continues with the next record, ADDRESS, where ADDRBOOK_ID has the form of "@..." (which indicates that what follows the delimiter is to be used for looking up the address-book identifier). The string matches the DISPLAYNAME, and 12951 is returned and placed in the ADDRBOOK_ID attribute.
 
<MEMBER
    MEMBER_ID="100"
    TYPE="U"
    STATE="1"
  />  
<MEMBER
    MEMBER_ID="101"
    TYPE="U"
    STATE="1"
  />  
<ADDRBOOK
    ADDRBOOK_ID="12951"                  
Generated primary key
    MEMBER_ID="100"
    DISPLAYNAME="Friends"                
Value of ADDRBOOK DISPLAYNAME unchanged
    DESCRIPTION="All my friends"
    TYPE="P"
  />  
<ADDRESS
    ADDRESS_ID="13051"                   
Generated primary key
    ADDRBOOK_ID="12951"                  
ADDRESS refers to correct ADDRBOOK
    MEMBER_ID="101"
    NICKNAME="Bob"
    ADDRESS1="15 Brave Developers St."
    CITY="Toronto"
    ZIPCODE="A0A0A0"
    COUNTRY="Canada"
    STATUS="P"
  />
The ADDRBOOK table does not need to have the primary column specified in the input XML file. The idresolver contains logic to find out that ADDRBOOK_ID is the primary key of ADDRBOOK, and then generates the value for this column and writes it to the output file. The same logic applies to the ADDRESS_ID column of the ADDRESS table.
Using a properties file with compound keys
A key made up of more than two columns is a compound key. You can define a compound-key lookup in the properties file by specifying both NAMEDELIMITER and SELECTDELIMITER followed by the field names.
To have the lookup criteria for ADDRBOOK records be the compound of the display name and the member ID, for example, specifying the following in the properties file:
  ADDRBOOK=@DISPLAYNAME@MEMBER_ID:DISPLAYNAME MEMBER_ID
then the following XML input-file fragment:
 
<ADDRBOOK
    MEMBER_ID="100"
    DISPLAYNAME="Friends"                
ADDRBOOK "Friends" of MEMBER 100
    DESCRIPTION="All my friends"
    TYPE="P"
  />  
<ADDRBOOK
    MEMBER_ID="101"
    DISPLAYNAME="Friends"                
ADDRBOOK "Friends" of MEMBER 101
    DESCRIPTION="All my friends"
    TYPE="P"
  />  
<ADDRESS
    ADDRBOOK_ID="@Friends@100"           
Lookup the primary key for ADDRBOOK 
                                         "Friends" of MEMBER
100
    MEMBER_ID="101"
    NICKNAME="Bob"
    ADDRESS1="15 Brave Developers St."
    CITY="Toronto"
    ZIPCODE="A0A0A0"
    COUNTRY="Canada"
    STATUS="P"
  />
would yield the following after resolution:
 
<MEMBER
    MEMBER_ID="100"
    TYPE="U"
    STATE="1"
  />  
<MEMBER
    MEMBER_ID="101"
    TYPE="U"
    STATE="1"
  />  
<ADDRBOOK
    ADDRBOOK_ID="12951"                  
ADDRBOOK of interest
    MEMBER_ID="100"
    DISPLAYNAME="Friends"
    DESCRIPTION="All my friends"
    TYPE="P"
  />  
<ADDRBOOK
    ADDRBOOK_ID="12952"
    MEMBER_ID="101"
    DISPLAYNAME="Friends"
    DESCRIPTION="All my friends"
    TYPE="P"
  />  
<ADDRESS
    ADDRESS_ID="13051"
    ADDRBOOK_ID="12951"                  
ADDRESS refers to correct ADDRBOOK
    MEMBER_ID="101"
    NICKNAME="Bob"
    ADDRESS1="15 Brave Developers St."
    CITY="Toronto"
    ZIPCODE="A0A0A0"
    COUNTRY="Canada"
    STATUS="P"
  />
Using a properties file with cascaded primary keys
The primary table STOREENT defines a primary key STOREENT_ID. STORE, a foreign table referencing STOREENT, defines a primary key STORE_ID that is a foreign key to the primary table STOREENT. This means that the value of STORE_ID must be one of the STOREENT_ID values. STORE_ID, the primary key of the foreign table STORE, therefore has a dual role: primary and foreign.
Let us assume that another table, CONTRACT, is a foreign table on STORE and that the foreign key for CONTRACT, STORE_ID, references the primary key STORE_ID in STORE. The STORE table is therefore a primary table for the CONTRACT table.
Because the STORE table's STORE_ID is referenced from the STOREENT_ID rather than created, the idresgen utility does not create an internal-alias and ID-value association for the STORE table. When the CONTRACT table tries to resolve the STORE_ID from the STORE table, it gets the empty value.
Because of this special condition, explicitly specify the creation of the internal alias by creating an entry in the properties file. In IdResolveKeys.properties, specify the following:
"STORE=@STORE_ID:STORE_ID"
This forces the idresgen utility to:

Create the internal-alias and ID-value association while resolving the STORE_ID as a foreign reference

Use the association while resolving the STORE_ID for the CONTRACT table

Use the STORE=@STORE_ID:STORE_ID entry in the properties file and the following XML input-file fragment:
 
<STOREENT
    IDENTIFIER="Out Fashions"
    MEMBER_ID="-2000"
    STOREENT_ID="@storeent_id_1"
    TYPE="G"
  />  
<STORE
    STORE_ID="@storeent_id_1"
    STOREGRP_ID="1"
    STORELEVEL="store_level"
  />  
<CONTRACT
    CONTRACT_ID="@contract_id_1"
    STATE="0"
    STORE_ID="@storeent_id_1"
  />
would yield the following after resolution:
 
<STOREENT
    IDENTIFIER="Out Fashions"
    MEMBER_ID="-2000"
    STOREENT_ID="10501"
    TYPE="G"
  />  
<STORE
    STORE_ID="10501"
    STOREGRP_ID="1"
    STORELEVEL="store_level"
  />  
<CONTRACT
    CONTRACT_ID="@contract_id_1"
    STATE="0"
    STORE_ID="10501"
  />
Related concepts

Overview of the mass load utilities

Related tasks

Configure the idresgen utility
Resolve identifiers
Create an XML file to use internal-alias ID resolution
Create an XML file to use unique-index ID resolution

Related reference

idresgen utility

+
Search Tips | Advanced Search