Oracle® Fusion Applications Customer Data Management Implementation Guide 11g Release 1 (11.1.3) Part Number E20433-03

Contents

Previous

Next

24 Define Data Quality

This chapter contains the following:

Define Data Quality: Explained

Manage Data Quality Engine

Manage Server Configurations

Manage Data Quality Engine Matching Setup

Manage Matching Configurations

Manage Data Quality Engine Cleansing Setup

Manage Cleansing Configurations

Manage Data Synchronization

Troubleshooting Oracle Fusion Data Quality Services and IIR Servers

FAQs for Define Data Quality

Define Data Quality: Explained

Defining data quality involves setting up two functionalities, matching and address cleansing, by performing related regular and manual setup and maintenance tasks. Manual setup and maintenance tasks are performed on the related third-party data quality (DQ) engine, Informatica Identity Resolution (IIR).

The Oracle Fusion Trading Community Data Quality matching and address cleansing services are designed to cater to all Oracle Fusion applications that use the trading community registry.

Matching is the identification of potential duplicates for organizations, persons, and locations. Potential duplicate records are identified and displayed in the data quality functionality consuming Oracle Fusion Applications during a variety of activities such as duplicate prevention in real-time when a customer record is being created or duplicate identification in batch mode for existing records.

Address cleansing is the process of correction and validation of address data, based on postal requirements. For example, if a user enters valid values for postal code, city, and country, the data quality functionality may return a value for state. Likewise, if a user enters valid values for city, state, and country, the data quality functionality automatically supplies a postal code value.

This figure illustrates the data quality management architecture. The data quality services receive matching or cleansing requests, such as duplicate prevention or address validation, from a variety of consuming applications, such as Oracle Fusion Sales and Oracle Fusion Trading Community Hub, and then internally invoke the appropriate third party services based either on a default configuration or a specific configuration passed to the services.

Matching and address cleansing are independent functionalities and are set up separately using the following steps:

• Setting up the third-party data quality (DQ) engine, Informatica Identity Resolution (IIR)

  Note

  You can find the IIR vendor documentation in <PROV.TOP>/InformaticaIR/pdf directory within the IIR Installation.

• Setting up the Fusion DQ Connector to IIR, by performing data quality related regular setup and maintenance tasks, such as defining and managing lookup choices and configurations used in data matching, cleansing, and matching index synchronization

• Connecting Oracle Fusion Applications to the third-party data quality (DQ) engine, Informatica Identity Resolution (IIR)

Managing Lookups

Review and define lookup values that provide choices for data matching and cleansing, such as address fields, quality error messages, and match tolerances.

Managing Data Quality Configurations

Perform the configurations required to enable data quality processes such as data quality matching and cleansing operations.

You can enable data quality processes such as matching and address cleansing for real-time or batch matching and cleansing, and as part of the data import process.

Real-time matching can prevent individual entry of duplicate trading community entities, such as organization, person, or location, into the trading community registry. Batch matching leads to identification of duplicates entries in the trading community registry.

As part of defining and managing data quality configurations, you search, review, and edit seeded matching and cleansing configurations for real-time and batch matching and cleansing of trading community entities.

Managing Server Configurations

Define, review, and update the data quality server configurations to integrate with the embedded data quality engine.

Next, associate the server name with the matching and cleansing configurations to perform duplicate prevention, batch duplicate identification, and real-time and batch data cleansing.

Managing Matching Index Synchronization

Review and update matching index synchronization options, to synchronize Oracle Fusion Trading Community Hub registry data with the data quality engine repository, such as system and identity tables. View the latest synchronization results, evaluate errors, and reset for continued processing after resolving error conditions.

Manage Data Quality Engine

Informatica Identity Resolution Setup: Procedures

Follow this procedure to verify the installation of the third-party data quality (DQ) engine, Informatica Identity Resolution (IIR), used by Oracle Fusion Trading Community Data Quality, and perform IIR setup operations. The IIR setup operation are manual setup and maintenance tasks performed using the UI of the third-party data quality (DQ) engine.

Performing Post-Provisioning Checks

Once Fusion Application environment is provisioned by Oracle Fusion Application Provisioning Framework, do the following to verify IIR installation:

• Check whether InformaticaIR directory exists under PROV.TOP.

• Check whether IIR is already running using ps -ef | grep InformaticaIR. There should be eight processes (or four pairs of parent-child processes) running per server.

  Note

  If IIR post-provisioning verifications fail, perform IIR maintenance activities.

This table lists the processes that run when IIR is working.

An instance of IIR uses seven ports. If IIR is provisioned through the framework, the value of the license server port is determined by the value of the property provisioning.setup.app-ports.core.iir.port that is set in the provisioning plan. If IIR is installed manually, the value of the license server port is determined by IIR_INSTANCE_1_PORT in the install.props file.

The seven ports are listed here. For example, if the port value set for provisioning.setup.app-ports.core.iir.port uses the default value 1601, the ports occupied for Informatica Identity Resolution would have the following values:

• SSA_LIPORT= <value set for the property provisioning.setup.app-ports.core.iir.port>=1601

• SSA_SEPORT=1666

• SSA_COPORT=1667

• SSA_RBPORT=1668

• SSA_CSPORT=1669

• SSA_XMPORT=1670

• SSA_HTPORT= <value set for the property provisioning.setup.app-ports.core.iir.port> + 11= 1612

Post-Provisioning Operations

When post-provisioning checks are successful, perform these post-provisioning operations sequentially to set up IIR:

1. IIR Matching Setup. For more information, see: Informatica Identity Resolution Matching Setup: Procedures.

2. IIR Address Cleansing Setup. For more information, see: Informatica Identity Resolution Address Cleansing Setup: Procedures.

3. Oracle Fusion Data Quality Connector Setup. For more information, see: Fusion Data Quality Connector Setup: Procedures.

Setting up Multiple Informatica Identity Resolution Instances: Overview

Set up multiple Informatica Identity Resolution (IIR) instances to make use of client load balancing capabilities of IIR to implement failover. You can configure the Oracle Fusion Data Quality Connector to allow Oracle Fusion Applications to speed up data quality management operations and to avoid overload by sending matching and cleansing calls to different IIR instances. Note that the multiple instances do not require any data or repository replication and can work with one Oracle Fusion Application Database.

Use multiple instances of the IIR and setup the Oracle Fusion Data Quality Connector appropriately to make use of load balancing to implement failover as follows:

• Load Balancing by matching and cleansing on different dedicated hosts

• Load balancing by matching with a secondary match server

• Load balancing and failover by matching and cleansing using a secondary instance

For more information on these load balancing and failover scenarios, refer to the topics in the Related Topics section of this topic.

Assumptions and Constraints

Take note of the following assumptions and constraints before using multiple instances of the IIR and the Oracle Fusion Data Quality Connector setup for load balancing and failover:

• CRM is provisioned with only one instance of IIR. Consequently, load balancing and failover using multiple instances of the IIR and the Oracle Fusion Data Quality Connector setup require manual installation of IIR for every additional instance. Since the installation of IIR through provisioning includes a bare minimum of IIR schema objects required in Oracle Fusion Applications Database, make sure that those schema objects are not installed again during the manual installation of IIR.

• Load balancing cleansing is not described as a separate scenario. Instead, the steps for load balancing and failover of cleansing operations are included as optional steps in the scenarios for load balancing and failover of matching operations.

• One or more instances of Oracle Fusion Applications and IIR may be installed on an Oracle Fusion Applications host.

• You cannot load balance and failover the update synchronizer. It can run only on one host.

• Any rollback of changes, for example reverting to a single instance, while load balancing using a secondary server requires a delete_secondary_server.sql and also requires the bouncing of application servers hosting Oracle Fusion Applications that use real-time data quality.

Load Balancing by Matching and Cleansing on Different Dedicated Hosts: Procedures

Use this procedure for load balancing with no specific requirement for high availability, or failover, by performing the matching and cleansing operations on dedicated hosts.

This figure provides a visual representation of the load balancing process achieved by matching and cleansing on different dedicated hosts.

Configuring the primary and Secondary IIR Hosts

Use the following steps to configure the IIR hosts:

1. Manually install Informatica Identity Resolution (IIR) on the secondary host, making sure INSTALL_IIR_OBJECTS=N. In other words, make sure that the schema objects installed during installation of IIR through provisioning are not installed again during the manual installation of IIR. For more information, see: Manually Installing Informatica Identity Resolution: Procedures

2. Perform all the matching setup steps in the primary IIR host.

3. Perform all the cleansing setup steps in the secondary IIR host.

Configuring the Oracle Fusion Data Quality Connector

Use the following steps to configure Oracle Fusion Data Quality Connector:

1. In the Real-time and Batch Basic Server, enter the server address and server port of the primary IIR host, the IIR Matching Server.

2. In the Real-Time Cleanse Server and Batch Cleanse Server, enter the server address and server port of the secondary IIR host, the IIR cleansing server.

Load Balancing by Matching and Cleansing with Secondary Servers: Procedures

Use this procedure for load balancing with no specific requirement for high availability, or failover, by performing the matching operations on a secondary match server.

This figure provides a visual representation of the load balancing process for matching operations achieved by matching with a secondary match server.

Configuring the Secondary Match Server

Use the following steps to configure the secondary match server:

1. Manually install Informatica Identity Resolution (IIR) on the secondary match server, making sure INSTALL_IIR_OBJECTS=N. In other words, make sure that the schema objects installed during installation of IIR through provisioning are not installed again during the manual installation of IIR. For more information, see: Manually Installing Informatica Identity Resolution: Procedures.

2. Make sure IIR on the secondary match server has access to an Oracle DB client to connect to the Fusion Application Database and the tnsnames.ora has all the relevant SID information. Shut down IIR on the secondary match server.

3. Perform all the matching setup steps using IIR on primary match server. Shut down IIR on primary match server.

4. Start IIR on primary match server.

5. Start IIR as a search server only on the secondary match server by doing the following:

   <PROV.TOP>/InformaticaIR/bin > bash
   <PROV.TOP>/InformaticaIR/bin  > . ./setfusionEnv.sh
   <PROV.TOP>/InformaticaIR/bin  > . ../env/isss
   <PROV.TOP>/InformaticaIR/bin  > ./ssasrsv -n{SEPORT2} -h{RBHOST1}:{RBPORT1} -1$SSATOP/iirlog/idssrsv.log -2$SSATOP/iirlog/idssrsv.err -3$SSATOP/iirlog/ids.dbg &
   
   

    

   Note

   The Search Server in Host 2 is started by pointing its port (SEPORT2) to the Rulebase Server's host (RBHOST1) and port (RBPORT1) in the primary match server. Here:

   • SEPORT2 = Search Server Port (SSA_SEPORT defined in InformaticaIR/env/isss on IIR Host 2. The default port is 1666).

   • RBHOST1 = Hostname or IP of IIR Host 1

   • RBPORT1 = Rulebase Server Port (SSA_RBPORT defined in InformaticaIR/env/isss on IIR Host 2. The default port is 1668.

6. On Host 1 (Primary Host), start the IIR Update Synchronizer process using the following steps:

   1. Sign in the Informatica Identity Resolution (IIR) host machine.

   2. Enter cd <PROV.TOP>/InformaticaIR/bin

   3. Enter setfusionEnv.sh

   4. Start the IIR console client using the admin option, ./idsconc -a

   5. Select Run Synchronizer on the Tools menu to launch the synchronizer.

   6. In the Update Synchronizer dialog, select All as the value for IDT Name, use the default values for the rest of the fields, and click OK.

   7. Verify that the updated and newly created person records are available in IIR, by searching for persons in the Per-dup tab of IIR Web Search Client.

   8. Sign out of the Informatica Identity Resolution (IIR) user interface.

7. In the Oracle Fusion DQ Connector, on the Manage Server Configuration page, update the SecondaryServer1Address and SecondaryServer1Port values respectively for the host name and port of the Secondary Server (Host 2). These parameters can be found in the Server Parameter Values section.

8. Select the Enable High Availability checkbox for each server operation.

9. Click Save and Close.

   Note

   Repeat steps 7, 8, and 9 for each server configuration: Realtime and BatchBasic Server, Batch Cleanse Server, and Realtime Cleanse Server

10. Restart the Oracle Fusion Applications instances that require data quality management to enable Oracle Fusion Data Quality Connector to commence load balancing and failover.

Load Balancing and Failover by Matching and Cleansing Using a Secondary Instance: Procedures

Use this procedure for load balancing to implement high-availability, or failover, by performing both matching and cleansing operations using a secondary instance of Informatica Identity Resolution (IIR).

This figure provides a visual representation of the load balancing and failover process achieved by matching and cleansing using a secondary instance.

Configuring the Secondary instance of IIR to Load Balance and Failover

Use the following steps to configure the secondary instance of Informatica Identity Resolution (IIR) to load balance and failover matching and cleansing:

1. Manually install Informatica Identity Resolution (IIR) on the secondary host, making sure INSTALL_IIR_OBJECTS=N. In other words, make sure that the schema objects installed during installation of IIR through provisioning are not installed again during the manual installation of IIR. For more information, see: Manually Installing Informatica Identity Resolution: Procedures.

   Note

   Since there are two fusion application instances in this scenario, the secondary IIR instance may already be installed. In such cases, you need to only configure the Oracle Fusion Data Quality Connector so that it points to the same Oracle Fusion Database as the primary IIR instance. For more information, see: Oracle Fusion Data Quality Connector Setup: Procedures.

2. Make sure IIR on the secondary host has access to an Oracle DB client to connect to the Fusion Application Database and the tnsnames.ora has all the relevant SID information. Shut down IIR on the secondary host.

3. Perform all the matching setup steps using IIR on primary host. Shut down IIR on primary host.

4. Start IIR on primary host, Host 1, by starting the Rulebase Server first followed by starting the Search Server.

   <PROV.TOP>/InformaticaIR/bin > bash
   <PROV.TOP>/InformaticaIR/bin  > . ./setfusionEnv.sh
   <PROV.TOP>/InformaticaIR/bin  > . ../env/isss
   <PROV.TOP>/InformaticaIR/bin  > ./ssasrsv -m{RBPORT1} -gFusionRBSG,ssa:rtunitrb -w1 -1$SSATOP/iirlog/priRB.log -2$SSATOP/iirlog/priRB.err -3$SSATOP/iirlog/priRB.dbg &
   <PROV.TOP>/InformaticaIR/bin  >./ssasrsv -n{SEPORT1}  -gFusionRBSG,ssa:rtunitrb -1$SSATOP/iirlog/priSE.log -2$SSATOP/iirlog/priSE.err -3$SSATOP/iirlog/priSE.dbg &
   
   

    

5. Start IIR on the secondary host, Host 2, by starting the Rulebase Server first, followed by starting the Search Server.

   <PROV.TOP>/InformaticaIR/bin > bash
   <PROV.TOP>/InformaticaIR/bin  > . ./setfusionEnv.sh
   <PROV.TOP>/InformaticaIR/bin  > . ../env/isss
   <PROV.TOP>/InformaticaIR/bin  >./ssasrsv -m{RBPORT2} -gFusionRBSG,ssa:rtunitrb -w1-1$SSATOP/iirlog/secRB.log -2$SSATOP/iirlog/secRB.err -3$SSATOP/iirlog/secRB.dbg &
   <PROV.TOP>/InformaticaIR/bin  >./ssasrsv -n{SEPORT2}  -gFusionRBSG,ssa:rtunitrb -1$SSATOP/iirlog/secSE.log -2$SSATOP/iirlog/secSE.err -3$SSATOP/iirlog/secSE.dbg &
   

    

6. Start IIR Console on the primary host, Host 1.

   <PROV.TOP>/InformaticaIR/bin > ./ssacssv -o -n{CSPORT1} -hselocalhost:{SEPORT1} -hcolocalhost:{COPORT1} 
   -hhtlocalhost:{HTPORT1} -gFusionRBSG,ssa:rtunitrb -w$SSATOP/ids 
   -1$SSATOP/iirlog/cons.log -2/$SSATOP/iirlog/cons.err 
   -3$SSATOP/iirlog/cons.dbg &
   

    

   For example:

   <PROV.TOP>/InformaticaIR/bin > ./ssacssv -o -n1669 -hselocalhost:1666 -hcolocalhost:1667 
   -hhtlocalhost:1612 -gFusionRBSG,ssa:rtunitrb -w$SSATOP/ids 
   -1$SSATOP/iirlog/cons.log -2/$SSATOP/iirlog/cons.err 
   -3$SSATOP/iirlog/cons.dbg &
   

    

7. Start IIR Connection Server on the primary host, Host 1.

   <PROV.TOP>/InformaticaIR/bin > ./ssacosv -hlocalhost:{SEPORT1} -n{COPORT1} -t5 -1$SSATOP/iirlog/conn.log 
   -2/$SSATOP/iirlog/conn.err -3$SSATOP/iirlog/conn.dbg &
   
   

    

   For example:

   <PROV.TOP>/InformaticaIR/bin > ./ssacosv -hlocalhost:1666 -n1667 -t5 -1$SSATOP/iirlog/conn.log 
   -2/$SSATOP/iirlog/conn.err -3$SSATOP/iirlog/conn.dbg &
   
   

    

   Note

   • RBPORT1 and RBPORT2 respectively are the ports for the Rulebase Server on IIR Host 1 and IIR Host 2 respectively. The values for these parameters should respectively be the value of SSA_RBPORT in InformaticaIR/env/isss on Hosts 1 and 2.

   • SEPORT1 and SEPORT2 respectively are the ports for the Search Server on IIR Host 1 and IIR Host 2. The values for these parameters should respectively be the value of SSA_SEPORT in InformaticaIR/env/isss on Hosts 1 and 2.

   • CSPORT1 is the port for the Console Server on IIR Host 1. The values for this parameter should be the value of SSA_CSPORT in InformaticaIR/env/isss on Hosts 1.

   • COPORT1 is the port for the Connection Server on IIR Host 1. The values for this parameter should be the value of SSA_COPORT in InformaticaIR/env/isss on Hosts 1.

   • HTPORT1 is the port for the HTTP Search Server on IIR Host 1. The values for this parameter should be the value of SSA_HTPORT in InformaticaIR/env/isss on Hosts 1.

   • The parameter w1 specifies that the polling frequency of the Secondary Server to determine if the Primary Server is active is one second. For example, if the value of the parameter is set to w10 then the polling frequency of the Secondary Server to determine if the Primary Server is active will be 10 seconds.

   • The steps 4 and 5 essentially start the Rulebase Servers in a group, making sure, that even if one matching instance fails, the other can continue to function. Only one rulebase server (primary) in the group is permitted to respond to queries and the other (secondary) server periodically polls the primary server to determine if it is active.

   • In the scenario in which load balancing is done by matching with a secondary match server, if the primary server (Host 1) fails, matching will stop functioning unless it is restored.

     In contrast, in the present scenario, if the primary server (Host 1) fails, the secondary server (Host 2) takes the role of the primary server, with no expectation of Host 1 to be restored. However, there is a small latency in the secondary server assuming the role of the primary server and there could be a loss of the matching functionality during this temporary latency period.

8. On Host 1 (Primary Host), start the IIR Update Synchronizer process using the following steps:

   1. Sign in the Informatica Identity Resolution (IIR) host machine.

   2. Enter cd <PROV.TOP>/InformaticaIR/bin

   3. Enter setfusionEnv.sh

   4. Start the IIR console client using the admin option, ./idsconc -a

   5. Select Run Synchronizer on the Tools menu to launch the synchronizer.

   6. In the Update Synchronizer dialog, select All as the value for IDT Name, use the default values for the rest of the fields, and click OK.

   7. Verify that the updated and newly created person records are available in IIR, by searching for persons in the Per-dup tab of IIR Web Search Client.

   8. Sign out of the Informatica Identity Resolution (IIR) user interface.

9. In the Oracle Fusion DQ Connector, on the Manage Server Configuration page, update the SecondaryServer1Address and SecondaryServer1Port values respectively for the host name and port of the Secondary Server (Host 2). These parameters can be found in the Server Parameter Values section.

10. Select the Enable High Availability checkbox for each server configuration.

11. Click Save and Close.

    Note

    Repeat steps 9 to 11 for each server operation: Realtime and BatchBasic Server, Batch Cleanse Server, and Realtime Cleanse Server.

12. Restart the Oracle Fusion Applications instances that require data quality management to enable Oracle Fusion Data Quality Connector to commence load balancing and failover.

Informatica Identity Resolution Server Maintenance and Administration: Procedures

Administration and maintenance includes start up and shutdown activities of the Informatica Identity Resolution (IIR) server and how Oracle database interacts with the IIR server. It also includes locking and unlocking of the Rulebase and how you can use the Informatica IR Console Client.

Starting Up and Shutting Down IIR

To start the IIR server, enter the following commands:

<PROV.TOP>/InformaticaIR/bin> bash
<PROV.TOP>/InformaticaIR/bin>. ./setfusionEnv.sh

<PROV.TOP>/InformaticaIR/bin> ./liup
<PROV.TOP>/InformaticaIR/bin> ./idsup
<PROV.TOP>/InformaticaIR/bin> ./idsconc -a

To shutdown the server, enter the following commands:

<PROV.TOP>/InformaticaIR/bin> bash
<PROV.TOP>/InformaticaIR/bin>. ./setfusionEnv.sh

<PROV.TOP>/InformaticaIR/bin> ./idsdown
<PROV.TOP>/InformaticaIR/bin> ./lidown

Shutting Down Servers for High Availability

To shutdown the primary and secondary servers make sure the following steps are followed:

1. Stop Update Synchronizer on the primary server.

2. Stop license server on the Primary and all other servers on both Primary and secondary server as follows:

   <PROV.TOP>/InformaticaIR/bin > bash
    <PROV.TOP>/InformaticaIR/bin > . ./setfusionEnv.sh
    <PROV.TOP>/InformaticaIR/bin > lidown
    <PROV.TOP>/InformaticaIR/bin > ./ssashut -h<HOST>:<PORT>
   
   

    

   Note

   Do the ssashut for all servers started using their respective host and port.

Verifying Informatica Identity Resolution (IIR) Configuration

Before handing over an environment for business use, you need to perform certain checks to determine if IIR is in working condition. Perform the checks after performing any of following activities:

• Setting Up Informatica Identity Resolution sever for the first time

• Restarting the Informatica Identity Resolution sever for any reason such as after a maintenance window or a scheduled downtime (patching, bouncing the database, troubleshooting and so on)

If any of the IIR configuration checks fail, the data quality functionality will not work. For information on troubleshooting, refer to the Troubleshooting Informatica Identity Resolution and Data Quality Setup: Overview help topic listed in the Related Topics section.

Perform the following checks to verify Informatica Identity Resolution (IIR) configuration:

• IIR Server Check: Verify that the total number of processes running for IIR search components is eight.

  The following table lists the names and numbers of the processes running for IIR search components.

  
  

  IIR Search Component Process Name	Number of Processes
  ssasrsv	2
  ssalisv	2
  ssacssv	2
  ssacosv	2

  On a Linux operating system, run the following command to verify that the total number of processes running for IIR search components is eight: ps -ef | grep InformaticaIR | grep -v updsync

   

• IIR Update Synchronizer Check: Verify that the total number of processes running for Update Synchronizer is two.

  On a Linux operating system, run the following command to verify that the total number of processes running for Update Synchronizer is two: ps -ef | grep InformaticaIR | grep updsync

• IIR Test Search Client Check: Use the following steps to perform this check:

  1. Run the following command to get the search client: grep SSA_HTPORT <PROV.TOP>/InformaticaIR/env/isss

  2. Use a browser and the following URL syntax to access the client application: http://Your_IIR_Host_Env_IP_Address:SSA_<HTPORT>/systems

     Here is a placeholder example: http://xyz123.us.zzz.com:1612/systems

  3. Select any system from the drop-down list and click Next.

  4. Type an appropriate value and click Submit Search.

  5. Note that there are no errors.

• IIR ASM Server Check: Use the following steps to perform this check:

  1. In the command line on $InformaticaIR/bin enter ./asmcli -b to bring up the console.

  2. Note that the console comes up without any issues.

  3. Shut the console down.

• IIR Wiring Check: Verify that the data quality Web Services are up and running and EM is accessible. Use the following steps to perform this check:

  1. Sign in to Oracle Enterprise Manager.

  2. From the Navigation menu, select Fusion Applications - Oracle Fusion Customer Relationship Management.

  3. Select CrmCommonApp and then select CRMCommonServer_1.

  4. Under the Web Services section, select DQRealTimeService and click Test to launch the Web Service Tester.

  5. On the Test Web Service Page, select cleanseAddress from the Operation drop down list.

  6. On the Request tab, select Custom Policy security option and enter the Policy URL syntax oracle/wss11_username_token_with_message_protection_client_policy and the username and password for a user who has the ZCH_MASTER_DATA_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB role. For example, in development environments, this could be MDM_ADMIN_V1.

  7. Under Input Arguments, select XML View.

  8. Run the following blocks of code by selecting the corresponding operation from the drop-down list for each blocks of code and clicking Test Web Service.

     • Select the operation cleanseAddress from the Operation drop-down list and submit the following payload:

       <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body xmlns:ns1="http://xmlns.oracle.com/apps/cdm/dataQuality/realTime/publicModel/types/">
       <ns1:cleanseAddress>
       <ns1:input xmlns:ns2="http://xmlns.oracle.com/apps/cdm/dataQuality/realTime/publicModel/">
         <ns2:DataQualityRequestId /> 
         <ns2:ConfigCode>RT_LOC_CLEANSE</ns2:ConfigCode> 
         <ns2:ErrorCode /> 
         <ns2:Message /> 
         <ns2:DataQualityAddress>
         <ns2:DataQualityRequestId /> 
         <ns2:DataQualityRecordType /> 
         <ns2:AddressLine1>500 oracle pky</ns2:AddressLine1> 
         <ns2:AddressLine2 /> 
         <ns2:AddressLine3 /> 
         <ns2:AddressLine4 /> 
         <ns2:City /> 
         <ns2:Country>US</ns2:Country> 
         <ns2:CountrySubEntity /> 
         <ns2:LocationIdentifier /> 
         <ns2:PostalCode>94065</ns2:PostalCode> 
         </ns2:DataQualityAddress>
         </ns1:input>
         </ns1:cleanseAddress>
         </soap:Body>
         </soap:Envelope>
       

        

     • Select the operation matchOrganization from the Operation drop-down list and submit the following payload:

       <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body xmlns:ns1="http://xmlns.oracle.com/apps/cdm/dataQuality/realTime/publicModel/types/">
       <ns1:matchOrganization>
       <ns1:input xmlns:ns2="http://xmlns.oracle.com/apps/cdm/dataQuality/realTime/publicModel/">
         <ns2:DataQualityRequestId /> 
         <ns2:ConfigCode>RT_ORG_DUP_PREV</ns2:ConfigCode> 
         <ns2:ErrorCode /> 
         <ns2:Message /> 
         <ns2:DataQualityOrg>
         <ns2:OrganizationName>Yamaha</ns2:OrganizationName> 
         </ns2:DataQualityOrg>
         </ns1:input>
         </ns1:matchOrganization>
         </soap:Body>
         </soap:Envelope>
       

        

  9. Check if the responses to the above requests do not return the following ErrorCode:

     <ns0:ErrorCode>ERRORED</ns0:ErrorCode>
     <ns0:Message>ZCQ_CMN_ENG_CONNECT_ERR</ns0:Message>
     
     

      

     If any of the responses contain this ErrorCode , it indicates that IIR is either not wired or is not functional.

Locking and Unlocking of Rulebase

If you are setting up IIR for matching, you must understand how the IIR Server interacts with the Oracle database. When you start an IIR server, the Rulebase Server also starts, but it does not connect to the Oracle database until the first client makes a request. This can be a search request, for example, a match call made from Oracle Fusion Applications, or, it can be an administrator request, for example, a user starting the Informatica IR Console client. A Rulebase server uses and maintains this connection unless IIR is brought down with an idsdown command. Once a Rulebase server connects to the Oracle database, it creates a lock that ensures that no other Rulebase server connects to the Rulebase.

When the IIR server is up and the Oracle database is shutdown or crashes, or if there is a network issue that affects connectivity, the Rulebase lock remains active. In such cases where a lock is active, all future search requests fail with an error that indicates there is another Rulebase server running.

This table lists various situations that can occur after the IIR and Oracle database connection has been established.

Every time an IIR server starts, a new pair of parent and child Rulebase also start. The parent server generates a new unique ID and this ID is stored in the Rulebase. In case of a Rulebase lock, if the ID generated by the parent is not equal to the ID stored in the Rulebase, the child server fails to start.

You must unlock the Rulebase manually. To do this, set an environment variable to the same ID that locks the Rulebase. Here is an example of a message that appears when a Rulebase lock is in force:

IS ANOTHER RULEBASE SERVER RUNNING?

Rulebase sdb:file:c:\a3i\ids\rule In use by ssa.identitysystems.com IP=203.2.203.109 on port=1668, SSA_RB_RESTART_ID=281753650

For this message, enter <PROV.TOP>/InformaticaIR/bin > set SSA_RB_RESTART_ID=281753650 and then start the IIR server.

When the Rulebase server starts, it uses the environment variable to unlock the Rulebase when the two IDs match. It then uses the freshly generated parent ID to lock it again. A locked Rulebase can be unlocked only once using the same ID.

Using the Informatica IR Console Client

You can use the Informatica IR Console client for the following operations:

• For creating and indexing IIR search systems.

• Starting or monitoring the Update Synchronizer.

• Perform test searches using the search client or enabling search traces to understand or debug search behavior.

• For advanced configuration, where an existing system is edited using the System Editor to change its behavior.

These are the restrictions on using the Informatica IR Console client:

• The console client is not a multiuser application when it is used with -a (administrative) option, which has read and write privileges. Only single invocation of the client is possible with -a option. Without -a option, the Rulebase opens read only.

• Once the administration operations have been performed, there is no need for the client to be open. Close it after use. For example, after starting the Update Synchronizer, you can close the console client but this does not affect the synchronizer.

• If the Informatica IR Console client is left connected for several days and there is a database or network interruption, the following situations can occur:

  • If the Update Synchronizer fails, it cannot be restarted through the client unless the client is restarted.

  • Client loses all functionality except for Tools and Search Client unless restarted.

  • You do not need to restart the IIR server for restarting client connection.

Encrypting the Informatica Identity Resolution Dictionary-alias File: Explained

Clients such as Console Client or Fusion Real-Time and Batch that connect to IIR, pass a mandatory parameter called rulebase name. It is an alias for the connection string required by IIR to connect to the FUSION_DQ schema in the Fusion Application Database. The alias is defined in a file called ssadb.dic in <PROV.TOP>/InformaticaIR/ids directory.

The following example shows how a typical ssadb.dic would look like.

rtunitrb odb:0:fusion_dq/fusion_dq@rws65311
fusion_s01 odb:1:fusion_dq/fusion_dq@rws65311
btunitrb odb:1:fusion_dq/fusion_dq@rws65311
fusion_s02 odb:2:fusion_dq/fusion_dq@rws65311
zcqsrc odb:99:fusion_dq/fusion_dq@rws65311

The alias rtunitrb is the alias for the rulebase name. The remaining aliases are used for different purposes. For example, fusion_s01 is used to create the FusionDQRealtime System, zcqsrc is used by the loader process to get source data from Oracle Fusion and so on.

Changing Rulebase Names

In Oracle Fusion, the predefined alias for the rulebase name is rtunitrb. If there is ever a need to change the rulebase name, you can change it in the dictionary file, and ensure that the change is also carried over to the Server Operation Page (used in IIR Matching). For example, if rtunitrb is changed to foo, then the rulebase alias in the Server Operation Page should be changed from ssa:rtunitrb to ssa:foo. If you made this change while the server was up and running, you need to restart the IIR Server to bring the change into effect.

Encryption ssadb.dic

It is recommended to create a backup copy of the ssadb.dic file and store it as a template for future use, before encrypting it. It is also recommended to replace the password on the backup copy with an empty string. You can later provide a password for this backed up copy, if you intend to use it.

Access the directory where PERL is available, either using $PATH or the absolute path and do the following:

• On Windows, run the following commands:

  • PROV.TOP\InformaticaIR\bin > isss.bat

  • PROV.TOP\InformaticaIR\bin > perl convfusiondict.pl <password>

• On Oracle Enterprise Linux, run the following commands:

  • PROV.TOP/InformaticaIR/bin >. .setfusionEnv.sh

    Note

    If using C-SHELL, use source setfusionEnv.csh instead of setfusionEnv.sh

  • PROV.TOP/InformaticaIR/bin > perl convfusiondict.pl <password>

  Note

  In these commands, <password> can be any string that the administrator chooses. Password protects the dictionary file from being edited (either to add a new entry or delete an existing entry). In Oracle Fusion, this password is a place holder to run the iirdict utility.

Changing Password after Encryption

After ssadb.dic is encrypted, there may be occasions where the password for FUSION_DQ might be changed by a database administrator, as part of security due diligence.

To change the password for ssadb.dic, do the following.

1. Take a backup of the existing ssadb.dic (as mentioned in the earlier section).

2. Delete the existing ssadb.dic (in use).

3. Enter the new password for the backup up file and rename the file to ssadb.dic.

4. Encrypt the file as mentioned earlier.

Manually Installing Informatica Identity Resolution: Procedures

This help topic describes the provisioning and platform support, software requirements, and the steps for the manual installation of Informatica Identity Resolution (IIR).

Assessing Provisioning and Platform Support

Use this information to determine whether you need to install IIR manually.

When CRM is provisioned using the provisioning framework, an instance of IIR (64 Bit) is provisioned on the following platforms: OEL 64 Bit, Windows 64 Bit, AIX 64 Bit, Solaris Sparc 64 Bit.

However, IIR is not provisioned as part of CRM Provisioning for the Solaris X-64 Bit platform. For this platform, install IIR manually on any of the supported platforms such as OEL 64 Bit. Except for the manual install, IIR setup steps for Solaris X-64 Bit platform are identical to those for other platforms such as OEL 64 Bit.

Assessing Software Requirements

Use this information to ensure compliance with the software requirement for the manual installation of IIR.

The host on which IIR is installed should have access to an Oracle DB Client for connecting to the Fusion Application Database.

The host should have its GNU libc version 2.5 or later.

The size of FUSION_TS_DQ (the default table space for the Oracle Fusion data quality and hence the repository for IIR), should have a table space size at least 10 times the size of the data. The data here represents the fields used in FusionDQ Realtime.sdf.

Installing Informatica Identity Resolution

Use the following steps to manually install IIR on the OEL 64 Bit platform.

1. Unzip the following files in an appropriate location

   • IIR_901sp1_linux_amd64.zip

   • Fusion-Exts-IIR-901sp1.zip

     Note

     This file resolves to fusion_iir after unzipping.

2. Go to the fusion_iir directory and edit theinstall.props file to make sure the properties described in the following table are populated correctly.

   Note

   This table describes the properties and their values that must be populated correctly for installing IIR manually. None of the properties except the ones mentioned in this table should be modified.

   
   

   Properties	Value Descriptions (To be Replaced with Actual Values)	Sample Values
   ORACLE_HOME	Oracle home for DB client used by IIR
   TNS_ADMIN	TNS_ADMIN for DB client used by IIR
   LD_LIBRARY_PATH	Library path on IIR host
   FUSION_STAGE_DIR	Directory where Fusion Ext Zip is unzipped
   IIR_STAGE_DIR	Directory where IIR Zip is unzipped
   IIR_VERSION	Name of the version to which that the IIR unzip resolves	IIR_901sp1_linux_amd64
   IIR_DB_HOSTNAME	Fusion application DB host
   IIR_DB_PORT	Fusion application DB port
   IIR_DB_SID	Fusion Application DB SID
   IIR_DB_USER	fusion_dq
   IIR_DB_PASSWD	Credentials for fusion_dq
   IIR_INSTALL_LOG_LOC	Location to which Install logs should go
   IIR_INSTANCE_1_PORT	Start port for the license server	1660 (if available, this port should work fine as the default port
   INSTALL_IIR_OBJECTS	Yes or No	No (if IIR is installed as a Secondary Server; for more information, see: Setting up Multiple Informatica Identity Resolution Instances: Overview

3. Execute the following command after changing to the fusion_iir directory: runInstaller.sh install.props.

   It typically takes about 8 to 12 minutes to install IIR.

Manage Server Configurations

Server Configurations: Explained

Server configurations are predefined configurations for third-party data quality servers.

You can search, review, and edit server configurations. Although you can edit the configuration name, server address, server port, and values of some of the configuration parameters, you cannot add or delete a server configuration parameter.

There are four predefined server configurations:

• Real-Time and Batch Basic Match Server

• Real-Time Cleanse Server

• Batch Cleanse Server

• Advanced Batch Match Server

Real-Time and Batch Basic Match Server

Used for basic real-time duplicate prevention and batch data matching and duplicate identification. This configuration requires you to synchronize the Oracle Fusion Trading Community Hub registry data with the third party data quality engine repository periodically to ensure appropriate matching indexes are updated continuously.

Real-Time Cleanse Server

Used for real-time data cleansing operations that happen at touch point applications, such as Oracle Fusion Sales and Oracle Fusion Customer Center, and so do not need synchronization.

Batch Cleanse Server

Used for batch cleansing operations during which records in a batch are sent to the data quality server for cleansing one at a time, and the data quality engine returns the cleansed record to the registry likewise, one at a time, thus completing the loop.

Advanced Batch Match Server

Used for advanced batch matching that is done to find duplicates amongst a group of records before uploading them to the Oracle Fusion Trading Community Hub registry. For example, an acquiring company may do an advanced batch match of the legacy data of the acquired company before uploading the data to the registry. In such a case, data is uploaded to the repository of the data quality engine directly for duplication identification and after the duplication identification processing it is imported to the Oracle Fusion Trading Community Hub registry.

Oracle Fusion Data Quality Connector Setup: Procedures

Once you complete the Informatica Identity Resolution (IIR) matching and cleansing setups, you must ensure that Oracle Fusion Applications is connected to the data quality engine.

Connecting Oracle Fusion Applications to Data Quality Engine

To connect Oracle Fusion Applications to the data quality engine:

1. Map Oracle Fusion Applications to IIR Matching server.

   1. Log in to the Functional Setup Manager application as an administrator user.

   2. Under Assigned Implementation Tasks, search for Manage Server Configuration setup tasks.

   3. Select Go to Task. This opens the task-flow page.

   4. Click Search to find all existing configurations.

   5. In the Search Results, select Realtime and BatchBasic Server.

   6. Select Actions - Edit.

   7. Enter the Server Address and Server Port of the IIR Matching Server. The default port is 1666. To know the current port, use grep SSA_SEPORT=$<PROV.TOP>/InformaticaIR/env/isss.

   8. Select Enable Matching.

   9. (Optional) Select Enable High Availability.

   10. Click Save and Close.

2. Map Oracle Fusion Applications to IIR Cleansing server.

   1. Log in to the Functional Setup Manager Application as an administrator user.

   2. Under Assigned Implementation Tasks, search for Manage Server Configuration setup tasks.

   3. Select Go to Task. This opens the task-flow page.

   4. Click Search to find all existing configurations.

   5. In the Search Results, select Realtime Cleanse Server.

   6. Select Actions - Edit.

      Note

      Repeat the steps to select Batch Cleanse Server from the search results and edit it.

   7. Enter the Server Address and Server Port of the IIR Cleansing server. The default port is 1666. To know the current port, use grep SSA_SEPORT=$<PROV.TOP>/InformaticaIR/env/isss.

   8. Select Enable Cleansing.

   9. (Optional) Select Enable High Availability.

   10. Click Save and Close.

   Note

   By default, the IIR server instance is the same for both matching and cleansing, but you can configure separate instances if required.

Manage Data Quality Engine Matching Setup

Informatica Identity Resolution Matching Setup: Procedures

When you use the configurations provided by Oracle Fusion Trading Community Data Quality, matching consists of initial indexing and index synchronization.

Initial Indexing

Perform the following for initial indexing:

1. Log in to the Informatica Identity Resolution (IIR) Host machine.

2. Enter cd <PROV.TOP>/InformaticaIR/bin.

3. Run setfusionEnv.sh.

4. Start the Informatica IR Console using ./idsconc -a option.

5. On the launched console, select Rulebase Type as SSA and Alias as rtunitrb.

6. Click OK.

7. Select Yes for a new Rulebase.

8. In Informatica IR Console, navigate to System - New - Create a system from SDF.

   Enter the following information:

   • System Name: FusionDQRealtime.

   • System Definition File: <FULLPATH>/InformaticaIR/ids/FusionDQRealtime.sdf.

   • DB Type: SSA.

   • Alias: fusion_s01.

9. Go to System and select System Name as FusionDQRealtime.

10. Click OK.

11. Go to System - Load IDT.

    Use Loader Definition list to load the following ID tables one by one:

    • load_location.

    • load_organization.

    • load_org_address.

    • load_person.

    • load_per_address.

    • load_per_phone.

12. Click OK for each ID table.

The IIR load jobs launched from the Informatica IR Console pull the data from the Oracle Fusion Applications database and create keys for them. It then prepares the data in the IIR Server and uses SQL loader to load the data back into the Oracle Fusion Applications database. During this process, if any load job fails and a fix has been applied, you must delete the corresponding .dat file from the PROV.TOP//InformaticaIR/ids directory and then refresh the applicable ID table.

To refresh an ID table:

1. Go to System - Refresh.

2. Select Refresh Selected Objects.

3. Choose the ID table name to refresh.

4. Click OK.

Index Synchronization

Once initial indexing is done, you can continue with adding or editing records, but you must synchronize the index as follows:

1. Start the Update Synchronizer on IIR.

   Note

   Refer to Starting Up and Shutting Down Update Synchronizer section of this help topic.

2. Start the Oracle Fusion Synchronization Oracle Enterprise Scheduler job.

   Note

   Refer to Running the Schedule Synchronization Process section of the following help topic Synchronizing Trading Community Registry and Data Quality Engine Repository Data: Worked Example.

Starting Up and Shutting Down Update Synchronizer

The Update Synchronizer is a batch job that runs in the IIR Server. Primary function of an Update Synchronizer is to take records in the no source access (NSA) table periodically, create the keys for them, and synchronize these to identity tables (IDTs) and identity indexes (IDXs). The records in NSA are created by the Oracle Fusion Synchronization Oracle Enterprise Scheduler job. Once the Update Synchronizer has completed the job, it would clear the records from NSA.

Starting Up Update Synchronizer: You can start the Update Synchronizer from the Informatica IR Console.

1. Log in to Informatica IR Console.

2. Go to System and select System Name as FusionDQRealtime.

3. Go to Tools - Synchronizer - Run Synchronizer.

4. Click OK.

   Select the All option for IDT Name and retain the rest of the defaults.

5. Click OK.

Shutting Down Update Synchronizer: Once started, the Update Synchronizer can be left running for the lifecycle of the IIR Server unless there is a need to shut it down.

1. Log in to Informatica IR Console.

2. Double click Update Synchronizer under Launched Jobs to open the Synchronize window.

3. Select Yes. The Synchronizer terminates within 60 seconds.

4. Close the Synchronize window after shutdown.

When there is loss of connectivity with the database, Update Synchronizer stops functioning. You must then restart it.

Extending Predefined IIR Matching Configurations: Procedures

This topic describes how to extend predefined Informatica Identity Resolution (IIR) matching configurations to overcome the skewness of matching results when fields or attributes of the records being matched are null.

When a record is sent for matching to Informatica Identity Resolution (IIR) , the engine returns the final set of matches, by performing a two-step process. The consecutive steps are listed below:

1. Search or Candidate Selection: As part of this step, IIR searches and shortlists candidate records from among the repository records (also called file records).

2. Matching or Scoring: During this step, IIR does a field by field level comparison of the candidate record against the corresponding field in the record being matched (also called the searched record). The individual score of a field is: weight * score. The total score is the sum of all individual scores.

Since the total score is the sum of all individual scores, scoring produces skewed results if an attribute or field in either the searched record (the record being matched) or in the candidate record (the file record) is null, because the weight contribution of such a filed would be 0.

The following table provides an example of how scoring results can be skewed, if an attribute or field in either the searched record (the record being matched) or in the candidate record (the file record) is null.

In this example the score is 100 percent even when the address field is missing, because predefined IIR matching configurations ignore weight contributions for any null attribute or field in either the searched record (the record being matched) or in the candidate record (the file record).

To overcome the skewness of matching results when fields or attributes of the records being matched are null, Oracle Fusion Data Quality ships a set of custom rulebase population, which when used, ensures that the weight for any attribute is 0, only if that attribute is null for the searched record (the record being matched).

The following table provides an example of scoring done using the custom rulebase population that ensure that the weight for any attribute is 0, only if attribute is null for the searched record (the record being matched).

Procedure for Extending Predefined IIR Matching Configuration

Use this procedure to extend predefined Informatica Identity Resolution (IIR) matching configurations.

1. Log in to IIR Admin Console and select FusionDQRealtime system.

2. Stop the Update Synchronizer if it is running.

3. Start System Editor.

4. Select Edit and select Yes, this time only or Yes, do not ask me again for this session as appropriate.

5. Select Org-dup (under Search) in the System Editor.

6. Select the Score Logic tab, and on the Controls field add Fusion_ right after the Purpose= In other words, after the change, the Match Purpose should be Fusion_Organization, as opposed to Organization.

7. Click Load. Close the Edit System pop up once you see the message Job completed, and repeat Step 5 for all the remaining 8 searches from location_dup through person_dupe in the System Editor.

8. (Recommended) Restart the IIR to avoid caching and to ensure that the new scoring mechanism is used.

   Note

   • The out of the box predefined configurations use the US population: usa.ycp. To create other custom populations, select the relevant population out of the 64 populations from the zipped file OracleCustomPopulations.zip in the InformaticaIR/pr/default directory and customize it.

   • To revert to the out of the box predefined population, undo the steps above, by removing Fusion_ from the Match Purpose, from all the nine searches in the System Editor and by doing a load using the Step 7.

Manage Matching Configurations

Matching Configurations: Explained

Matching configurations are predefined configurations used for real-time and batch matching of party entities with the intention of preventing and identifying duplicate entries in the trading community registry.

Real-time and batch matching are available for the following trading community entities:

• Organization

• Person

• Location

There are six predefined matching configurations, three each for real-time and batch matching.

These configurations include both Oracle Fusion Trading Community Data Quality parameters and the parameters of the embedded data quality engine, Informatica Identity Resolution (IIR). While some of the parameters, such as MatchTolerance, are single valued, others, such as Manage Search Definition, are multi-valued.

You can search, review, and edit these seeded matching configurations.

Real-time Matching Configurations

The following are the predefined real-time matching configurations:

• Real Time Location Duplicate Prevention

• Real Time Organization Duplicate Prevention

• Real Time Person Duplicate Prevention

Real-time matching prevents individual entry of duplicate trading community entities, such as organization, person, or location, through calling touch point applications, such as Oracle Fusion Sales and Oracle Fusion Customer Center into the trading community registry. Real-time matching finds all possible duplicate records that may exist in the registry for an entered record, and assigns a match score to each potential duplicate identified. Based on the match score returned by the service and the threshold settings in the configuration, the calling application can provide the option to either select an existing duplicate record or continue to create a new record.

Batch Matching Configurations

The following are the predefined batch matching configurations:

• Batch Location Basic Duplicate Identification

• Batch Organization Basic Duplicate Identification

• Batch Person Basic Duplicate Identification

Batch matching leads to the identification of duplicate entries in the trading community registry, between trading community registry and sets of data, such as import batches, or within sets of data to resolve them by merging or linking. While real-time matching provides duplicate prevention for only one record and returns potential matches for the record being entered, the batch matching service takes a set of records of the same type, such as person, organizations, or locations and identifies all possible matches within these sets of records. The duplicate data is presented in sets of possible matches with a score associated with each individual record in the set.

IIR Matching Process

Based on the matching configurations provided by Oracle Fusion Trading Community Data Quality, the embedded data quality engine, Informatica Identity Resolution (IIR), returns the final set of matches by performing a two-step process comprising candidate selection and scoring.

These steps are described below:

1. Candidate Selection: This step requires that the matched-against records are stored in the IIR repository and indexed. IIR uses search definitions to search and shortlist candidate records from among the repository records.

2. Scoring: In this step, IIR does a field by field level comparison of the candidate record against the corresponding fields in the record being matched. The matching fields and the scoring are also defined in the search definition.

Defining Indexes and Index Synchronization

Matching using the configurations provided by Oracle Fusion Trading Community Data Quality requires both defining indexes, or initial indexing, and index synchronization of the Informatica Identity Resolution (IIR) repository with the trading community registry.

A prerequisite to defining indexes or initial indexing is creation of a new system on IIR using the system definition file, FusionDQRealtime.sdf, shipped with the application that uses US population and contains information about IIR match rules and indexes.

Before defining indexes, review the index information in the out of the box system definition file FusionDQRealtime.sdf to verify that it is uptodate and make any modifications required to suite your specific business needs.

Staging Tables

IIR staging tables, also called identity tables (IDTs), are used to achieve the following:

• Stage Oracle Fusion Applications data.

• Partition the data based on trading community entities and their attributes.

Identity tables (IDTs) are also used for periodic index synchronization of the third party data quality engine repository with the Oracle Fusion Trading Community Hub registry to account for the continual updates made to the registry.

The following table describes the different staging or identity (IDT) tables.

Search Definitions

IIR uses search definitions to search and shortlist candidate records from among the repository records.

The following table describes the different search definitions

Match Options Behavior

When finding out duplicate organization and person parties, some users might want to match potential duplicate records using multiple addresses and phones. However, indexing multiple records with multiple addresses and phones can adversely affect performance. Oracle Fusion Trading Community Data Quality tries to strike a balance between the accuracy and speed of duplicate identification by taking the following optimal approach:

1. Partitioning the Oracle Fusion Applications data based on trading community entities and their attributes in staging tables before loading the data into the IIR repository.

2. Providing appropriate match options on the configuration page.

The following table describes real time matching behavior for the different available match options.

The following table describes batch matching behavior for the different available match options.

Real-Time Duplicate Prevention Components: How They Work Together

Real-time duplicate prevention enables you to prevent the individual entry of duplicate trading community entities, such as organization, person, or location, in the trading community registry through Oracle Fusion Trading Community Data Quality matching services consuming applications, such as Oracle Fusion Customer Center.

Real-time duplicate prevention comprises the following components:

• Real-Time Matching Service

• Data quality service consuming applications

• Matching configurations

• Server configurations

This figure shows the real-time duplicate prevention components in action.

Real-Time Matching Service

During the data entry process, the Real-Time Matching Service finds all possible duplicate records that may exist in the trading community registry for an entered record, and assigns a match score to each potential duplicate identified.

Consuming Applications

Real-time duplicate prevention finds use in data quality service consuming applications such as Oracle Fusion Receivables and Oracle Fusion Customer Center. When users try to enter a new person, organization, or location record through their UI into the Oracle Fusion trading community registry, the service finds all possible duplicate records that may exist in the registry for an entered record, and assigns a match score to each potential duplicate identified. Based on the match score returned by the service and the threshold settings in the configuration, the calling application can provide the option to either select an existing duplicate record or continue to create a new record.

Matching Configurations

Matching configurations are predefined configurations used for real-time and batch matching of party entities with a view to preventing and identifying duplicate entries in the trading community registry. Oracle Fusion Trading Community Data Quality has three predefined real-time matching configurations:

• Real Time Location Duplicate Prevention

• Real Time Organization Duplicate Prevention

• Real Time Person Duplicate Prevention

You can search, review, and edit these seeded matching configurations. While you cannot add or delete a configuration parameter, you can change configuration name and update the parameter values to suite your requirements.

Server Configurations

Real-time duplicate prevention makes use of the Real-Time and Batch Basic Match Server.

Matching server configurations provide the address and port of the third party server to which the match request should be sent for processing. Server configurations show all the parameters that can be set at either the matching configuration level or the server configuration level and provide the ability to modify the values of the server configuration level parameters. The parameters that are set at the server level are applicable to all the matching configurations.

Batch Duplicate Identification Components: How They Work Together

Batch duplicate identification enables you to identify duplicate entries in the trading community registry, between trading community registry and sets of data, such as import batches, or within sets of data to resolve them by merging or linking.

Batch duplicate identification comprises the following components:

• Batch Matching Service

• Data quality service consuming applications

• Matching configurations

• Server configurations

This figure shows the batch duplicate identification components in action.

Batch Matching Service

The Batch Matching Service is used for identification of potential duplicates for trading community entities such as persons, organizations, and locations.

Consuming Applications

The batch duplicate identification capability finds use in master data management applications such as Oracle Fusion Trading Community Hub, and other data quality service consuming applications that import data in batches. The capability takes a set of records of the same type, such as persons, organizations, or locations and identifies all possible matches within these sets of records. The duplicate data is presented in sets of possible matches with a score associated with each individual record in the set. These sets of potential duplicates can then be resolved by merging or linking.

Matching Configurations

Matching configurations are predefined configurations used for batch and real-time matching of party entities with a view to identifying and preventing duplicate entries in the trading community registry. Oracle Fusion Trading Community Data Quality has three predefined batch matching configurations:

• Batch Location Basic Duplicate Identification

• Batch Organization Basic Duplicate Identification

• Batch Person Basic Duplicate Identification

You can search, review, and edit these seeded matching configurations. While you cannot add or delete a configuration parameter, you can change configuration name and update the parameter values to suite your requirements.

Server Configurations

Batch duplicate prevention makes use of the Real-Time and Batch Basic Match Server.

Matching server configurations provide the address and port of the third party server to which the match request should be sent for processing. Server configurations show all the parameters that can be set at either the matching configuration level or the server configuration level and provide the ability to modify the values of the server configuration level parameters. The parameters that are set at the server level are applicable to all the matching configurations.

Matching Configuration Parameters

Matching configuration parameters are system-level parameters that control aspects of the Oracle Fusion Trading Community Data Quality matching services. The Oracle Fusion Trading Community Data Quality matching services read values from the ZCQ_CONFIG_PARAM_VALUES and ZCQ_SO_PARAM_VALUES tables.

Matching configurations are predefined configurations that include parameters from both Oracle Fusion applications and the integrated third-party data quality engine. Although you cannot add or delete a configuration parameter, you can change configuration name and update the parameter values to suite your requirements. The text describes only the generic Oracle Fusion Trading Community Data Quality parameters and their values. For third-party data quality engine specific parameters and their values, see relevant third-party documentation.

Real Time Location, Organization, and Person Duplicate Prevention Parameters

The following Oracle Fusion Trading Community Data Quality parameters control matching operations for preventing individual entry of duplicate trading community entities, such as location, organization, and person through calling touch point applications, such as Oracle Fusion Sales and Oracle Fusion Customer Center into the trading community registry.

Parameter Value: 1 or more. Default Value: 10

Parameter Description: Controls the maximum number of matched records returned by the data quality real-time matching service.

Parameter Value: Between 0 and 100. Default Value: 90

Parameter Description: Determines the score above which the matched records are returned by the matching service. Records equal to or greater than the score are considered as matches and the records with scores less than the threshold are rejected.

Batch Location, Organization, and Person Basic Duplicate Identification Parameters

The following Oracle Fusion Trading Community Data Quality parameters control matching operations for identification of duplicate entries in the trading community registry, between trading community registry and sets of data, such as import batches, or within sets of data to resolve them by merging or linking.

Parameter Value: Optimized or Exhaustive Default Value: Optimized

Parameter Description: Determines how the records in the batch are matched during batch matching process. Select Exhaustive to include in the batch match process even the records already showing up in previously matched groups. Select Optimized to skip such records.

Parameter Value: 1 or more. Default Value: 2

Parameter Description: Determines the number of child requests spawned for a batch matching request. The child requests are useful when there is a need to process data in parallel.

Parameter Description: As described earlier.

Manage Data Quality Engine Cleansing Setup

Informatica Identity Resolution Address Cleansing Setup: Procedures

Oracle Fusion Applications Installer installs a demo version of AddressDoctor postal reference data and product license keys that you can use to test address cleansing functionality; however, this demo is restrictive and provides you with a small subset of the complete functionality. For using the complete functionality, you must request for production license and postal reference data.

Using Demo License and Demo Postal Reference Data

If you are using demo keys and data, no specific setup is required for address cleansing server. You can quickly verify the setup using PROV.TOP/InformaticaIR/bin > asmcli -b. When successful, it launches the Address Standardization Module (ASM) client.

Using Production License and Postal Reference Data

AddressDoctor postal reference data and product license keys are not sold or distributed by Oracle. To acquire a license key and postal reference data, contact Informatica/AddressDoctor by sending an e-mail to OracleAV@informatica.com. The AddressDoctor license key restricts the use of address validation to the purchased countries or territories and represents a twelve (12) month subscription to the postal reference data. Once AddressDoctor receives the e-mail request through OracleAV@informatica.com, an AddressDoctor representative will contact you to define the requirements and complete the transaction. Once finalized, AddressDoctor will provide the license key and download credentials/instructions for accessing the postal reference data. Notification of regular updates to the postal reference data will be provided through e-mail.

Once the production license key and postal reference data are obtained, perform the following:

• PROV.TOP/InformaticaIR/bin > idsdown.

• PROV.TOP/InformaticaIR/bin > cd PROV.TOP/InformaticaIR/ssaas/ad5/ad/db.

• PROV.TOP/InformaticaIR/ssaas/ad5/ad/db > cp mylocation/key. Here, Key is a text file that contains the license provided by AddressDoctor.

• PROV.TOP/InformaticaIR/ssaas/ad5/ad/db > cp mylocation/[*.MD]. Here, [*.MD] stands for the postal reference data file. AddressDoctor supports 248 countries and each MD file is per country or a group of countries. Each of these files should be copied to this directory.

Manage Cleansing Configurations

Cleansing Configurations: Explained

Cleansing configurations are predefined configurations used for real-time and batch cleansing of the location entity.

There are two predefined cleansing configurations, one each for real-time and batch matching:

• Real Time Data Quality Location Cleanse

• Batch Data Quality Location Cleanse

You can search, review, and edit these seeded matching configurations. Although you cannot add or delete a configuration parameter, you can change configuration name and update the parameter values to suite your requirements.

These configurations include parameters from both Oracle Fusion applications and the integrated address cleansing engine. While some of the parameters are single valued others are multi-valued.

Real-Time Cleansing

Real-time cleansing endows Oracle Fusion applications with an online, interactive service to cleanse, standardize, and validate addresses during the data entry process either through a UI or any other service creating address data into the Oracle Fusion Trading Community Hub registry.

Batch Cleansing

Batch cleansing enables you to perform address cleansing, standardization, and validation for a subset or entirety of the location records in the registry, or as part of a data import process. It also enables you to ensure data accuracy of the Oracle Fusion Trading Community Hub registry. The need to cleanse the registry data arises owing to data decay over time and the need to resolve inherited issues from consolidated data in the registry. For example, postal codes and city boundaries change over time and require regular address cleansing to ensure that the addresses in the registry are correct, validated, and standardized at all times. Besides, historic incoming address data may have originated from multiple sources with each source system following different data storage formats and norms and the addresses might not have been cleansed during the import or consolidation process.

Real-Time Address Cleansing Components: How They Work Together

Real-time cleansing provides consuming applications an online, interactive service to cleanse, standardize, and validate addresses during the data entry process.

Real-time address cleansing comprises the following components:

• Real-Time Cleansing Service

• Data quality service consuming applications

• Cleansing configurations

• Server configurations

This figure shows the real-time address cleansing components in action.

Real-Time Cleansing Service

The Real-Time Cleansing Service perform validation, standardization, and cleansing of addresses during data entry into the trading community registry.

Consuming Applications

Real-time address cleansing finds use in data quality service consuming applications such as Oracle Sales and Oracle Fusion Customer Center. When a user tries to enter a new address record through the UI of these applications or through any other service creating address data into the Oracle Fusion trading community registry, the service validates the entered address data against country-specific postal service list, such as United States Postal Service. If there are any issues with the entered address data, the service returns a list of possibilities from which the consuming application user can select an appropriate one or continue to create a new address record.

Cleansing Configurations

Cleansing configurations are predefined configurations used for real-time and batch cleansing of the location entity.

Oracle Fusion Trading Community Data Quality has a predefined real-time cleansing configuration named Real Time Data Quality Location Cleanse. The real-time address cleansing service uses this cleansing configuration to derive the default country to be used to perform validation when address parsing fails to find a valid country within the address.

You can review and edit this predefined cleansing configuration. While you cannot add or delete a configuration parameter, you can change the configuration name and update the parameter values to suite your requirements.

Server Configurations

Real-time cleansing makes use of the Real-Time Cleanse Server configuration.

Cleansing server configurations provide the address and port of the third party data quality server to which the cleanse request should be sent for processing. There are no server configurations level parameters for cleansing.

Batch Address Cleansing Components: How They Work Together

Batch cleansing enables you to perform address cleansing, standardization, and validation for a subset or entirety of the location records in the Oracle Fusion Trading Community Hub registry, or as part of a data import process.

Batch address cleansing comprises the following components:

• Batch Cleansing Service

• Data quality service consuming applications

• Cleansing configurations

• Server configurations

This figure shows the batch address cleansing components in action.

Batch Cleansing Service

The Batch Cleansing Service performs validation, standardization, and cleansing of addresses to ensure data accuracy during the import of addresses in batches, to reduce decay and obsolescence of existing address data in the trading community registry , and to resolve inherited issues from consolidated data in the registry.

Consuming Applications

Batch address cleansing finds use in master data management applications such as Oracle Fusion Trading Community Hub, and other data quality service consuming applications that import data in batches. Unlike real-time cleansing that validates addresses one by one and runs in suggest cleansing mode, batch cleansing allows for validation and correction of multiple addresses through a single call.

Cleansing Configurations

Cleansing configurations are predefined configurations used for batch and real-time cleansing of the location entity.

Oracle Fusion Trading Community Data Quality has a predefined batch cleansing configuration named Batch Data Quality Location Cleanse. The batch address cleansing service uses this cleansing configuration to derive the default country to be used to perform validation when address parsing fails to find a valid country within the address.

You can review and edit this predefined cleansing configuration. While you cannot add or delete a configuration parameter, you can change the configuration name and update the parameter values to suite your requirements.

Server Configurations

Batch address cleansing makes use of the Batch Data Quality Location Cleanse server configuration.

Cleansing server configurations provide the address and port of the third party data quality server to which the cleanse request should be sent for processing. There are no server configurations level parameters for cleansing.

Cleansing Configuration Parameters

Cleansing configuration parameters are system-level parameters that control aspects of the Oracle Fusion Trading Community Data Quality cleansing services. The Oracle Fusion Trading Community Data Quality cleansing services read values from the ZCQ_CONFIG_PARAM_VALUES and ZCQ_SO_PARAM_VALUES tables.

Cleansing configurations are predefined configurations that include parameters from both Oracle Fusion applications and the integrated third-party data quality engine. Although you cannot add or delete a configuration parameter, you can change configuration name and update the parameter values to suite your requirements. The text describes only the generic Oracle Fusion Trading Community Data Quality parameters and their values. For third-party data quality engine specific parameters and their values, see relevant third-party documentation.

Real Time Data Quality Location Cleanse Parameters

The following parameters control real-time data cleansing operations that happen at touch point applications, such as Oracle Fusion Sales and Oracle Fusion Customer Center.

TRUE or FALSE TRUE

Determines if the real-time cleansing service should use the attribute mapping defined between Oracle Fusion Trading Community Data Quality attributes and the third-party data quality engine. If the value is set to FALSE, the data quality real-time service will pass through attributes as they are between Oracle Fusion Trading Community Data Quality and the third party cleansing engine.

Batch Data Quality Location Cleanse Parameters

The following parameters control address cleansing, standardization, and validation operations for a subset or entirety of the location records in the registry, or as part of a data import process.

1 or more 100

Controls the transaction batch size for the address cleansing process which in turn determines how often the cleansing results are committed. Set this value based on available system resources for optimum performance. If the value is too low, the data is committed often, which may cause slow performance. In contrast setting it to too high a value may require higher memory for processing.

1 or more 2

Determines the number of child requests spawned for a batch matching request. The child requests are useful when there is a need to process data in parallel.

Manage Data Synchronization

Data Synchronization: Explained

Real-time duplicate prevention during data entry and batch duplicate identification of trading community entities in the Oracle Fusion Trading Community Hub registry and during the data import process require both initial indexing and index synchronization of the integrated third party data quality engine repository with the registry.

Periodic index synchronization of the third party data quality engine repository with the Oracle Fusion Trading Community Hub registry lets you account for the continual updates made to the registry.

Some of the entities that need to be synchronized to the matching engine repository are organization, person, and location. The synchronization should be done when these entities are created or updated.

However, no data synchronization is required for advanced batch match configuration and real-time and batch cleanse operations because of the following reasons:

• Advanced configuration is used only for batch matching such as finding duplicates within a set of interface tables records before running a bulk import process to load the records in the registry.

• Data synchronization is not needed for real-time address cleansing functions as the address is checked against the country specific postal address files and not against the existing address in the registry. Note that the postal reference files need to be updated periodically.

• During the batch cleanse operation, records in a batch are sent to the data quality server for cleansing one at a time and the data quality engine returns the cleansed record to the registry likewise, one at a time, thus completing the loop.

Synchronizing Trading Community Registry and Data Quality Engine Repository Data: Worked Example

This example demonstrates the index synchronization of the integrated third party data quality engine repository with the trading community registry. Index synchronization facilitates accounting for the changes made to the registry as part of creating new and updating existing organization, person, and location records since initial indexing. This example focuses on the index synchronization of person party records for the third-party data quality engine Informatica Identity Resolution (IIR).

Index synchronization for the Informatica Identity Resolution data quality engine involves the following tasks:

• Scheduling the synchronization process: Schedule this task to run periodically to account for the continual updates to the Oracle Fusion Trading Community Hub registry. While running the synchronization process you can select the entities for which you want to synchronize updates and specify the date and time from which to synchronize the updates. A synchronization request performs index synchronization from the last synchronized date and time until the date and time it is submitted.

• Starting Informatica Identity Resolution (IIR) Update Synchronizer: Administrators and integrators typically perform this task. Once started the synchronizer can be left running, for the life cycle of the Informatica Identity Resolution server, unless there is a need to bring it down as part of a maintenance window. However, whenever there is a loss of connectivity with the database Update Synchronizer stops functioning and needs to be manually restarted.

Running the Schedule Synchronization Process

1. Navigate to Setup and Maintenance from the Tools menu.
2. Search for the Manage Data Synchronization task.
3. Click the Go to Task icon.
4. Select Refresh Identity Table Information option from the Actions menu on the Manage Data Synchronization page.
5. Enable all the relevant identity tables (for this example PER_PRIMARY_IDT, PER_ADDRESS_IDT, PER_PHONE_IDT) by selecting Enable for Sync, check box.
6. Enter the following Synchronization Options for each identity table:

   Field	Value
   Country	Leave blank when using the predefined system, FusionDQRealtime, for all countries. If using country specific system, enter the country, such as US.
   Last Synchronized Time	Select Date and Time: 3/23/11 9:30:15 AM

   
   
7. Click Save.
8. Click the Schedule Synchronization Process button.
9. Click Advanced.
10. Select Using a Schedule. From the Frequency drop-down list, select Hourly/Minute and provide a value for the frequency. For example, 5 minutes.

    Note

    The frequency needs to be determined by the business requirement.

11. From the Calendar, select the End Date.

    Note

    The end date needs to be determined by the business requirement.

12. Submit the scheduled Sync ESS Job.
13. Click OK to return to the Manage Data Synchronization page.
14. Hover on the Process Status field corresponding to each relevant identity table to know the status of the child synchronization request spawned for that table.
15. Click Save and Close.

Starting Informatica Identity Resolution Update Synchronizer

1. Sign in the Informatica Identity Resolution (IIR) host machine.
2. Enter cd <PROV.TOP>/InformaticaIR/bin
3. Enter setfusionEnv.sh
4. Start the IIR console client using the admin option, ./idsconc -a
5. Select Run Synchronizer on the Tools menu to launch the synchronizer.
6. In the Update Synchronizer dialog, select All as the value for IDT Name, use the default values for the rest of the fields, and click OK.
7. Verify that the updated and newly created person records are available in IIR, by searching for persons in the Per-dup tab of IIR Web Search Client.
8. Sign out of the Informatica Identity Resolution (IIR) user interface.

Troubleshooting Oracle Fusion Data Quality Services and IIR Servers

Troubleshooting Data Quality Services and Informatica Identity Resolution (IIR) Servers: Overview

This overview contains various troubleshooting methods pertaining to the Informatica Identity Resolution (IIR) and Data Quality (DQ), which help an administrator examine the symptoms, identify possible root causes, and take necessary steps to restore their normal functionality.

The log files (ids.dbg) in IIR or iirlog contain useful information that can help in diagnosing the root cause of the functional problems.

The troubleshooting process involves the following scenario checks:

• Matching Service

• Matching Server Administration (including Synchronizer)

• Cleansing Service

• Cleansing Server Administration

The troubleshooting steps for each scenario are grouped, and each group forms a tier. Since different root causes may share the same symptoms, the tiers are arranged in the ascending order of complexity. For effective resolution of the problem, you need to go through these tiers in the same order as presented here. Proceed to the next tier only when you are unable to confirm the root cause in the current tier.

Matching Service Troubleshooting: Explained

The Matching Service troubleshooting is spread across six tiers. Each tier indicates certain symptoms, lists possible root causes, contains the log descriptions, and prescribes the recovery procedure. While following the troubleshooting process, ensure that as part of the recovery procedure, you check for UPD locks on the Update Synchronizer before bringing up IIR.

Tier 1

Tier 2

Tier 3

[SEVERE] [IirSocket] handleSSAException()> Bad rc -408040403 for ids_search_start
    > SSA Exception Code: (-408040403)
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] ssasrsv > It is now 20110525145629
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] ssasesi.c    5870 rc   3   14080404*100
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] ssasesi.c    2060 rc   4     140804*100
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] ssasesi.c    1571 rc   4       1408*100
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] open search 'person-dup' failed. System 'FusionDQRealtime' Rulebase 'ssa:rtunitrb' Function 'host="rws65344fwks.us.oracle.com:1668",d:/temp'
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] apic.c       3446 rc   1       1407*1
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] closeUser: rc=-1407
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] apic.c       3340 rc   7         14*100
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] apic.c       3030 rc  14
[SEVERE] [IirSocket] SSAErrorStack: [525145629   6] Unknown Keyword 'd:/temp'

Tier 4

[518135036 ssasrsv  22/ 12] errmsg_put 'SQLConnect: OCIInitialize failed 1804'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaoci.c     2646 rc   2'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssa_odbc_connect: cannot connect to Data Source'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaodbc.c    1436 rc   8          1*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'db_connect_user: Cannot connect to service 'rws65311' with uid 'fusion_dq''
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaodbc.c    4112 rc   9        108*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssadb8_db_opn failed'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaodbc.c    4441 rc  10      10809*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'dbops.c      1561 rc   4    1080910*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'dbldr.c      1203 rc   9  108091004*1000'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssarbnl_rulebase_open: 'odb:0:fusion_dq/@rws65311' db open failed -91004009'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssarbn.c     3026 rc   7   91004009*100'
[518135036 ssasrsv  22/ 12] ssarbn.c(2841) ssarbnl_rulebase_destroy: rbh=0
[518135036 ssasrsv  22/ 12] ssarbn.c(2909) ssarbnl_rulebase_destroy: 'odb:0:fusion_dq/@rws65311' RULEBASE CLOSE

Tier 5

[518143012 ssasrsv  25/ 12] errmsg_put 'ssadb8_l_file_add: FileId 3 (inuse) already exists'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssaodbc.c    8245 rc   5'
[518143012 ssasrsv  25/ 12] errmsg_put 'dbops.c      4363 rc   3          5*100'
[518143012 ssasrsv  25/ 12] errmsg_put 'dbldr.c      3912 rc   9        503*1000'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbnl_inuse_add: Cannot create RB INUSE table'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbn.c     2543 rc   2     503009*100'
[518143012 ssasrsv  25/ 12] errmsg_put 'IS ANOTHER RULEBASE SERVER RUNNING?'
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase 'odb:0:fusion_dq/@rws65311' in use by rws65311fwks.us.oracle.com IP=130.35.116.108 on port=1668, SSA_RB_RESTART_ID=726050355'
[518143012 ssasrsv  25/ 12] errmsg_put 'Server   started at 'Wed May 18 14:21:31 2011''
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase opened  at 'Wed May 18 14:23:31 2011''
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase opened  as 'odb:0:fusion_dq/@rws65311''
[518143012 ssasrsv  25/ 12] errmsg_put 'env has SSA_RB_RESTART_ID=0'
[518143012 ssasrsv  25/ 12] errmsg_put 'Owner information: ip=130.35.116.108 pid=1236 host='rws65311fwks.us.oracle.com' ps='260152864 /scratch/<username>/InformaticaIR/bin/ssasrsv-n1666-m1668-x1670-H1671-v-1/scratch/<username>/InformaticaIR/iirlog/idssrsv.''
[518143012 ssasrsv  25/ 12] errmsg_put 'Owner is running'
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase is locked'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbnl_inuse_create: inuse_add failed -50300902'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbn.c     2583 rc   1'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbn.c     3031 rc   8          1*100'
[518143012 ssasrsv  25/ 12] ssarbn.c(2841) ssarbnl_rulebase_destroy: rbh=0
[518143012 ssasrsv  25/ 12] ssarbn.c(2909) ssarbnl_rulebase_destroy: 'odb:0:fusion_dq/@rws65311' RULEBASE CLOSE

Tier 6

IIR Matching Server Administration Troubleshooting: Explained

The Matching Server Administration troubleshooting is spread across four tiers. Each tier indicates certain symptoms, lists possible root causes, contains the log descriptions, and prescribes the recovery procedure. While following the troubleshooting process, ensure that as part of the recovery procedure, you check for UPD locks on the Update Synchronizer before bringing up IIR.

Tier 1

[518135036 ssasrsv  22/ 12] errmsg_put 'SQLConnect: OCIInitialize failed 1804'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaoci.c     2646 rc   2'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssa_odbc_connect: cannot connect to Data Source'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaodbc.c    1436 rc   8          1*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'db_connect_user: Cannot connect to service 'rws65311' with uid 'fusion_dq''
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaodbc.c    4112 rc   9        108*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssadb8_db_opn failed'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssaodbc.c    4441 rc  10      10809*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'dbops.c      1561 rc   4    1080910*100'
[518135036 ssasrsv  22/ 12] errmsg_put 'dbldr.c      1203 rc   9  108091004*1000'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssarbnl_rulebase_open: 'odb:0:fusion_dq/@rws65311' db open failed -91004009'
[518135036 ssasrsv  22/ 12] errmsg_put 'ssarbn.c     3026 rc   7   91004009*100'
[518135036 ssasrsv  22/ 12] ssarbn.c(2841) ssarbnl_rulebase_destroy: rbh=0
[518135036 ssasrsv  22/ 12] ssarbn.c(2909) ssarbnl_rulebase_destroy: 'odb:0:fusion_dq/@rws65311' RULEBASE CLOSE

Tier 2

[518143012 ssasrsv  25/ 12] errmsg_put 'ssadb8_l_file_add: FileId 3 (inuse) already exists'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssaodbc.c    8245 rc   5'
[518143012 ssasrsv  25/ 12] errmsg_put 'dbops.c      4363 rc   3          5*100'
[518143012 ssasrsv  25/ 12] errmsg_put 'dbldr.c      3912 rc   9        503*1000'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbnl_inuse_add: Cannot create RB INUSE table'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbn.c     2543 rc   2     503009*100'
[518143012 ssasrsv  25/ 12] errmsg_put 'IS ANOTHER RULEBASE SERVER RUNNING?'
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase 'odb:0:fusion_dq/@rws65311' in use by rws65311fwks.us.oracle.com IP=130.35.116.108 on port=1668, SSA_RB_RESTART_ID=726050355'
[518143012 ssasrsv  25/ 12] errmsg_put 'Server   started at 'Wed May 18 14:21:31 2011''
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase opened  at 'Wed May 18 14:23:31 2011''
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase opened  as 'odb:0:fusion_dq/@rws65311''
[518143012 ssasrsv  25/ 12] errmsg_put 'env has SSA_RB_RESTART_ID=0'
[518143012 ssasrsv  25/ 12] errmsg_put 'Owner information: ip=130.35.116.108 pid=1236 host='rws65311fwks.us.oracle.com' ps='260152864 /scratch/<username>/InformaticaIR/bin/ssasrsv-n1666-m1668-x1670-H1671-v-1/scratch/<username>/InformaticaIR/iirlog/idssrsv.''
[518143012 ssasrsv  25/ 12] errmsg_put 'Owner is running'
[518143012 ssasrsv  25/ 12] errmsg_put 'Rulebase is locked'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbnl_inuse_create: inuse_add failed -50300902'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbn.c     2583 rc   1'
[518143012 ssasrsv  25/ 12] errmsg_put 'ssarbn.c     3031 rc   8          1*100'
[518143012 ssasrsv  25/ 12] ssarbn.c(2841) ssarbnl_rulebase_destroy: rbh=0
[518143012 ssasrsv  25/ 12] ssarbn.c(2909) ssarbnl_rulebase_destroy: 'odb:0:fusion_dq/@rws65311' RULEBASE CLOSE

Tier 3

[517153446 ssasrsv   0/  5] 31344/xm> server started: Tue May 17 15:34:46 2011
[517153447 ssacssv   4/  5] errmsg_put 'send(h=2, os=9) failed: Reason: Broken pipe'
[517153447 ssacssv   4/  5] errmsg_put 'socket.c     1096 rc  11'
[517153447 ssacssv   4/  5] errmsg_put 'socket.c     2559 rc   4         11*100'
[517153447 ssacssv   4/  5] errmsg_put 'ssarbc1.c     693 rc   3       1104*100'
[517153447 ssacssv   4/  5] errmsg_put 'cssys.c      2185 rc   3  502020401*100'
[517153447 ssacssv   4/  5] errmsg_put 'ssacssi.c    2125 rc   1  202040103*100'
[517153448 ssacssv   4/  5] errmsg_put 'send(h=2, os=9) failed: Reason: Broken pipe'
[517153448 ssacssv   4/  5] errmsg_put 'socket.c     1096 rc  11'
[517153448 ssacssv   4/  5] errmsg_put 'socket.c     2559 rc   4         11*100'
[517153448 ssacssv   4/  5] errmsg_put 'ssarbc1.c    7725 rc   3       1104*100'

Tier 4

[414132606 updsync  13/  2] errmsg_put 'send(h=1, os=17) failed: Reason: Broken pipe'
[414132606 updsync  13/  2] errmsg_put 'socket.c     1096 rc  11'
[414132606 updsync  13/  2] errmsg_put 'socket.c     2559 rc   4         11*100'
[414132606 updsync  13/  2] errmsg_put 'ssarbc1.c    7725 rc   3       1104*100'
[414132606 updsync  13/  2] errmsg_put 'SQLEndTran: commit failed -1'
[414132606 updsync  13/  2] errmsg_put 'ssaoci.c     3128 rc   4'
[414132606 updsync  13/  2] errmsg_put 'ssadb8_db_commit: [01] SQLEndTran ssaodbc.c 19388 failed SQLRET=-1 SQLSTATE='     ' NATIVE_ERR=0'
[414132606 updsync  13/  2] errmsg_put 'ssadb8_db_commit: [02] Reason: [SSAOCI,1] OCITransCommit ssaoci.c 3124 failed 'ORA-03114: not connected to ORACLE''
[414132606 updsync  13/  2] errmsg_put 'SQLEndTran: rollback failed -1'
[414132606 updsync  13/  2] errmsg_put 'ssaoci.c     3121 rc   3'
[414132606 updsync  13/  2] errmsg_put 'ssadb8_db_commit: Commit failed'
[414132606 updsync  13/  2] errmsg_put 'ssaodbc.c   19390 rc   1          1*100'
[414132606 updsync  13/  2] errmsg_put 'ssaodbc.c    5065 rc  14        101*100'
[414132606 updsync  13/  2] errmsg_put 'dbops.c      1605 rc   3      10114*100'
[414132606 updsync  13/  2] errmsg_put 'dbldr.c      1253 rc   9    1011403*1000'
[414132606 updsync  13/  2] errmsg_put 'db_close(@2420) failed -11403009'
[414132606 updsync  13/  2] errmsg_put 'utils.c      1739 rc   1'
[414132606 updsync  13/  2] errmsg_put 'utils.c      2420 rc   7          1*100'
[414132607 updsync  13/  2] errmsg_put 'send(h=1, os=17) failed: Reason: Broken pipe'
[414132607 updsync  13/  2] errmsg_put 'socket.c     1096 rc  11'
[414132607 updsync  13/  2] errmsg_put 'socket.c     2559 rc   4         11*100'
[414132607 updsync  13/  2] errmsg_put 'ssarbc1.c    2248 rc   6       1104*100'
[414132608 updsync  13/  2] errmsg_put 'send(h=1, os=17) failed: Reason: Broken pipe'
[414132608 updsync  13/  2] errmsg_put 'socket.c     1096 rc  11'
[414132608 updsync  13/  2] errmsg_put 'socket.c     2559 rc   4         11*100'
[414132608 updsync  13/  2] errmsg_put 'ssarbc1.c     693 rc   3       1104*100'
[414132609 updsync  13/  2] errmsg_put 'send(h=1, os=17) failed: Reason: Broken pipe'
[414132609 updsync  13/  2] errmsg_put 'socket.c     1096 rc  11'
[414132609 updsync  13/  2] errmsg_put 'socket.c     2559 rc   4         11*100'
[414132609 updsync  13/  2] errmsg_put 'ssarbc1.c    7725 rc   3       1104*100'
[414132610 updsync  13/  2] errmsg_put 'send(h=1, os=17) failed: Reason: Broken pipe'
[414132610 updsync  13/  2] errmsg_put 'socket.c     1096 rc  11'
[414132610 updsync  13/  2] errmsg_put 'socket.c     2559 rc   4         11*100'
[414132610 updsync  13/  2] errmsg_put 'sockapi.c     592 rc   2       1104*100'
[414132610 updsync  13/  2] errmsg_put 'CloseAll failed -107'

Update Synchronizer Troubleshooting: Explained

The root cause of Update Synchronizer (UPD) locks is either an incorrect shut down where the Search Server was shut down while UPD was still running followed by ending the UPD process or an abrupt loss in DB connectivity when UPD was processing rows to be synchronized. To restore normal functioning of IIR, you need to delete the UPD locks.

To detect UPD locks, if there are any, run the command ./lockmgr list uq -rssa:<rulebase alias> -h<IIR RB Host>:<IIR RB Port> -l in <PROV.TOP>/InformaticaIR/bin. For example, if you run the following command:

./lockmgr list uq -rssa:rtunitrb -haufsn4ayf04:1668 -l

it returns the following details:

sorted locks: 
uq: updsync:1302896463:6826         
  obj: idtsyncsystem                   
    id: system=fusiondqrealtime         
      type: w 
      lock: ip=144.23.252.42 pid=31928 
host='aufsn4agf04.oracleoutsourcing.com' ps='80154501 
/u01/APPLTOP/fusionapps/InformaticaIR/bin/updsync-t60-m100-haufsn4agf04.oracle 
outsourcing.com:1668-rssa:rtunitrb-vus-pf'

To delete the locks, run the command ./lockmgr del uq -rssa:<rulebase alias> -h<IIR RB Host>:<IIR RB Port> in <PROV.TOP>/InformaticaIR/bin. For example,

./lockmgr del  updsync:1302896463:6826 -rssa:rtunitrb -haufsn4ayf04:1668

Cleansing Service Troubleshooting: Explained

The Cleansing Service troubleshooting is spread across five tiers. Each tier indicates certain symptoms, lists possible root causes, contains the log descriptions, and prescribes the recovery procedure.

Tier 1

Tier 2

Tier 3

 [523163408 ssasrsv  14/ 12] errmsg_put 'as_init: Object init failed: (-1601) Critical Error: The engine usage period has expired'
[523163408 ssasrsv  14/ 12] errmsg_put 'ssaas5.c     1338 rc   4'
[523163408 ssasrsv  14/ 12] errmsg_put 'ssaas5.c     1390 rc   1          4*100'
[523163408 ssasrsv  14/ 12] errmsg_put 'ssaas5.c     3097 rc   2        401*100'
[523163408 ssasrsv  14/ 12] errmsg_put 'ssasesi_addr_init: Error -40102 initializing Addr Std module'
[523163408 ssasrsv  14/ 12] errmsg_put 'ssasesi.c   13477 rc   9      40102*100'

Tier 4

// junk or error ASM key error
[523163604 ssasrsv  14/ 12] errmsg_put 'as_init: Object init failed: (-1600) Critical Error: No valid unlock code was given'
[523163604 ssasrsv  14/ 12] errmsg_put 'ssaas5.c     1338 rc   4'
[523163604 ssasrsv  14/ 12] errmsg_put 'ssaas5.c     1390 rc   1          4*100'
[523163605 ssasrsv  14/ 12] errmsg_put 'ssaas5.c     3097 rc   2        401*100'
[523163605 ssasrsv  14/ 12] errmsg_put 'ssasesi_addr_init: Error -40102 initializing Addr Std module'
[523163605 ssasrsv  14/ 12] errmsg_put 'ssasesi.c   13477 rc   9      40102*100'

Tier 5

 [523163811 ssasrsv  14/ 12] errmsg_put 'fopen('/slot/ems4517/appmgr/InformaticaIR/ssaas/ad5/ad/db/key', 'r') failed 16: No such file or directory'
[523163811 ssasrsv  14/ 12] errmsg_put 'fopen.c       985 rc  19'
[523163811 ssasrsv  14/ 12] errmsg_put 'fopen.c      1070 rc   3         19*100'
[523163811 ssasrsv  14/ 12] errmsg_put 'fopen.c      1141 rc   2'
[523163811 ssasrsv  14/ 12] errmsg_put 'ssasesil_addr_get_key_and_workdir: open Addr Std license key file '/slot/ems4517/appmgr/InformaticaIR/ssaas/ad5/ad/db/key' failed'
[523163811 ssasrsv  14/ 12] errmsg_put 'ssasesi.c   13293 rc   6'
[523163811 ssasrsv  14/ 12] errmsg_put 'ssasesi.c   13443 rc   6          6*100'

IIR Cleansing Server Administration Troubleshooting: Explained

The Cleansing Server Administration troubleshooting process indicates certain symptoms, lists possible root causes, contains the log descriptions, and prescribes the recovery procedure.

FAQs for Define Data Quality

What's the difference between different matching configurations and matching server configurations?

Matching configurations are used for real-time and batch matching of party entities with a view to preventing and identifying duplicate entries in the trading community registry. The matching configuration includes the parameters that can be set at the matching configuration level and can be modified depending on matching strategy, data, and result requirements. Use the matching configuration to view or change the values of the matching configuration level parameters.

Matching server configurations provide the address and port of the third party server to which the match request should be sent for processing. Server configurations show all the parameters that can be set at either the matching configuration level or the server configuration level along with the parameter type (third party data quality engine or Oracle Fusion Trading Community Data Quality) and the cardinality of the parameter. The parameters that are set at the server level are applicable to all the matching configurations. Use the server configuration to view or change the values of the server configuration level parameters.

What's the difference between different cleansing configurations and cleansing server configurations?

Cleansing configurations are used for real-time and batch cleansing of addresses during data entry and on a periodical basis to cleanse, standardize, and validate existing addresses to ensure data accuracy. The cleansing configuration includes the parameters that can be set at the cleansing configuration level and can be modified depending on cleansing strategy, data, and result requirements.

Cleansing server configurations provide the address and port of the third party data quality server to which the cleanse request should be sent for processing. There are no server configurations level parameters for cleansing.

What's the difference between real-time duplicate prevention and duplicate identification of trading community entities?

Real-time duplicate prevention involves identification of all possible duplicate records that may exist in the trading community registry for an entered record. This enables prevention of individual entry of duplicate trading community entities, such as organization, person, or location, through calling touch point applications, such as Oracle Fusion Sales and Oracle Fusion Customer Center in the registry.

Duplicate identification of trading community entities is achieved by batch matching. The objective is to identify potential duplicate entities already existing in the trading community registry, and then resolve the duplicates by merging or linking.

What's the difference between basic duplicate identification and advanced duplicate identification of trading community entities?

The objective of basic duplicate identification is to resolve the duplicate entities in the Oracle Fusion Trading Community Hub registry by merging or linking.

Advanced duplicate identification is mainly done to find duplicates in a group of records before uploading them to the Oracle Fusion Trading Community Hub registry. For example, an acquiring company may do an advanced duplicate identification of the legacy data of the acquired company before uploading the data to the registry.

What's the difference between real-time address cleansing and batch address cleansing?

Real-time address cleansing is an online, interactive service to cleanse, standardize, and validate addresses during the data entry process.

Batch address cleansing enables you to cleanse, standardize, and validate addresses that are either existing in the Oracle Fusion Trading Community Hub registry or are being imported into it.

Previous Next

Copyright ©  2011, Oracle and/or its affiliates. All rights reserved. Legal Notices

Contents Contact Us