What are difference between Cloud Data Integration and Cloud API Integration in Informatica IDMC?

 The main difference between Cloud Data Integration and Cloud API Integration in Informatica IDMC is the focus of each platform. Cloud Data Integration is designed to help organizations integrate data from multiple sources, including cloud and on-premises systems. Cloud API Integration is designed to help organizations integrate applications and data using APIs.

Cloud Data Integration

Informatica Cloud Data Integration (CDI) is a cloud-native data integration platform that enables organizations to automate, scale, and govern their data integration processes. CDI supports a wide range of data sources and targets, including cloud and on-premises databases, files, and streaming data sources. CDI also provides a variety of features to help organizations improve their data quality, including data profiling, cleansing, and transformation capabilities.

Cloud API Integration

Informatica Cloud API Integration (CAI) is a cloud-native API integration platform that enables organizations to connect applications and data using APIs. CAI provides a variety of features to help organizations design, develop, manage, and deploy APIs, including:

• API design and development tools
• API management and lifecycle management capabilities
• API security and governance features
• API monitoring and analytics capabilities

Key Differences

The following table summarizes the key differences between Cloud Data Integration and Cloud API Integration in Informatica IDMC:

Feature	Cloud Data Integration	Cloud API Integration
Focus	Data integration	API integration
Supported data sources and targets	Databases, files, and streaming data sources (cloud and on-premises)	APIs (cloud and on-premises)
Key features	Data profiling, cleansing, and transformation	API design, development, management, deployment, security, governance, monitoring, and analytics
Use cases	Data warehousing, data lakes, data analytics, and business intelligence	API-driven applications, B2B integration, and microservices architectures

Which Platform to Choose?

The best platform for your organization will depend on your specific needs and requirements. If you need to integrate data from multiple sources, including cloud and on-premises systems, then Cloud Data Integration is a good choice. If you need to integrate applications and data using APIs, then Cloud API Integration is a good choice.

Many organizations use both Cloud Data Integration and Cloud API Integration together to create a comprehensive data integration and API management solution. For example, an organization might use Cloud Data Integration to integrate data from their on-premises CRM system and their cloud-based marketing automation system into a data warehouse. They might then use Cloud API Integration to expose the data in the data warehouse to their sales and marketing teams through APIs.

Cloud Data Integration and Cloud API Integration are both powerful platforms that can help organizations integrate data and applications. The best platform for your organization will depend on your specific needs and requirements. If you are unsure which platform is right for you, then Informatica offers a variety of resources to help you make a decision, including free trials, demos, and consultations.

Learn more about Informatica IDMC here

How to import CSV data in Reference 360 using REST Call.

 To import CSV data in Reference 360 using REST Call in Informatica IDMC, you can follow these steps:

1. Prepare your CSV file. The CSV file must start with two header rows, followed by the data rows. The first header row must contain the names of the columns in the CSV file. The second header row must contain the following values:

   • System Reference Data Value - The key value for the system reference data value that you want to assign.
   • Code Value - The code value for the system reference data value.

2. Upload the CSV file to a cloud storage location, such as Amazon S3 or Google Cloud Storage.

3. Send a POST request to the following endpoint:

   https://XXX-mdm.dm-us.informaticacloud.com/rdm-service/external/v2/import
   

4. In the request body, include the following information:

   • file - The name of the CSV file that you uploaded to cloud storage.

   • importSettings - A JSON object that specifies the import settings. The following import settings are required:

     • delimiter - The delimiter that is used in the CSV file.
     • textQualifier - The text qualifier that is used in the CSV file.
     • codepage - The codepage that is used in the CSV file.
     • dateFormat - The date format that is used in the CSV file.
     • containerType - The type of container to which you want to import the data. For example, to import code values, you would specify CODELIST.
     • containerId - The ID of the container to which you want to import the data.

5. In the request headers, include the following information:

   • Authorization - Your Informatica IDMC API token.
   • IDS-SESSION-ID - Your Informatica IDMC session ID.

6. Send the request.

If the request is successful, Informatica IDMC will start importing the data from the CSV file. You can check the status of the import job by sending a GET request to the following endpoint:

https://XXX-mdm.dm-us.informaticacloud.com/rdm-service/external/v2/import/{jobId}

Where {jobId} is the ID of the import job.

Once the import job is complete, you can view the imported data in Reference 360.

Here is an example of a POST request to import code values from a CSV file:

POST https://XXX-mdm.dm-us.informaticacloud.com/rdm-service/external/v2/import HTTP/1.1
Authorization: Bearer YOUR_API_TOKEN
IDS-SESSION-ID: YOUR_SESSION_ID
Content-Type: multipart/form-data; boundary=YUWTQUEYJADH673476Ix1zInP11uCfbm

--YUWTQUEYJADH673476Ix1zInP11uCfbm
Content-Disposition: form-data; name=file; filename=import-code-values.csv

--YUWTQUEYJADH673476Ix1zInP11uCfbm
Content-Disposition: form-data; name=importSettings
Content-Type: application/json;charset=UTF-8

{
  "delimiter": ",",
  "textQualifier": "\"",
  "codepage": "UTF8",
  "dateFormat": "ISO",
  "containerType": "CODELIST",
  "containerId": "676SJ1990a54dcdc86f54cf",
  "startingRow": null
}

--YUWTQUEYJADH673476Ix1zInP11uCfbm--

Replace YOUR_API_TOKEN with your Informatica IDMC API token and YOUR_SESSION_ID with your Informatica IDMC session ID. Replace import-code-values.csv with the name of your CSV file and 676SJ1990a54dcdc86f54cf with the ID of the code list to which you want to import the data.

Learn more about Importing CSV Data in Reference 360 in IDMC

What is consolidation process in Informatica MDM?

In Informatica MDM (Master Data Management), the consolidation process is a fundamental and crucial step in managing and maintaining master data. The consolidation process aims to identify and merge duplicate or redundant records within a master data domain, such as customer, product, or supplier data. This process is essential for ensuring data accuracy, consistency, and reliability across an organization's various systems and applications.

Here are the key aspects and steps involved in the consolidation process in Informatica MDM:

• Data Source Integration: The consolidation process begins with the integration of data from various source systems into the MDM hub. These source systems might have their own data structures and formats.

• Data Matching: Once data is integrated into the MDM hub, the system performs data matching to identify potential duplicate records. Data matching algorithms and rules are used to compare and evaluate data attributes to determine if records are similar enough to be considered duplicates.
• Data Survivorship Rules: Data survivorship rules are defined to specify which data values should be retained or prioritized during the consolidation process. These rules help determine which data elements from duplicate records should be merged into the final, consolidated record.
• Record Linking: The consolidation process creates links between duplicate or related records, essentially establishing relationships between them. This linkage allows the system to group similar records together for consolidation.
• Conflict Resolution: In cases where conflicting data exists between duplicate records, conflict resolution rules come into play. These rules specify how conflicts should be resolved. For example, a conflict resolution rule might prioritize data from a certain source system or use predefined business rules.
• Data Merge: Once the system identifies duplicate records, resolves conflicts, and determines the survivorship rules, it consolidates the data from duplicate records into a single, golden record. This golden record represents the best and most accurate version of the data.
• Data Enrichment: During consolidation, the system may also enrich the data by incorporating additional information or attributes from related records, ensuring that the consolidated record is as complete as possible.
• Data Validation: After consolidation, the data is subject to validation to ensure it adheres to data quality and business rules. This step helps maintain the integrity of the consolidated data.
• History and Audit Trail: It is essential to keep a history of consolidation activities and changes made to the data. An audit trail is maintained to track who made changes and when.
• Data Distribution: Once consolidation is complete, the cleansed and consolidated master data is made available for distribution to downstream systems and applications through the use of provisioning tools or integration processes.

The consolidation process is a continuous and iterative process in Informatica MDM because new data is constantly being added and existing data may change. Regularly scheduled consolidation activities help ensure that the master data remains accurate and up-to-date, providing a single source of truth for the organization's critical data.

By implementing a robust consolidation process, organizations can reduce data duplication, improve data quality, and enhance their ability to make informed decisions based on accurate and consistent master data.

 

Learn more about Informatica MDM consolidation process here

Troubleshooting the "No Supported Authentication Methods Available" Error in SSH

 Introduction:

Encountering the "No supported authentication methods available server sent public key" error when connecting to an EC2 instance via SSH is a common frustration. This error can prevent you from accessing your remote server. In this article, we'll explore the causes of this error and provide solutions to resolve it.

Understanding the Error: The "no supported authentication methods available (server sent public key)" error message occurs when your SSH client cannot successfully authenticate with the remote EC2 instance. Several factors can contribute to this issue:

• Incorrect Login Credentials: Entering an incorrect username or password during the SSH connection attempt will result in failed authentication.
• Incorrect SSH Key: If you're using SSH keys for authentication, an invalid or incorrect key can prevent successful connection to the remote server.
• Server Configuration: If the remote server is not properly configured to allow the chosen authentication method, you won't be able to authenticate.

Solving the Problem: Let's explore steps to resolve the "no supported authentication methods available server sent public key" error:

1. Address SSH Public Key Issues:

   • Edit the /etc/ssh/sshd_config file.
   • Set PasswordAuthentication and ChallengeResponseAuthentication to 'yes'.
   • Restart SSH:
     • Option 1: sudo /etc/init.d/ssh restart
     • 
       
       
       
       
       Option 2: sudo service sshd restart
     • 


2. Refer to AWS Documentation:

   • AWS provides comprehensive documentation on connecting to EC2 instances using various SSH clients. You can find detailed instructions here: AWS EC2 SSH Documentation.

3. 
   

4. Verify Correct Logins for Specific AMIs:

   • Depending on the Amazon Machine Image (AMI) you're using, the login usernames may vary. Use the following logins based on your AMI:
   • Ubuntu or root for Ubuntu AMIs
   • ec2-user for Amazon Linux AMIs
   • centos for CentOS AMIs
   • debian or root for Debian AMIs
   • ec2-user or fedora for Fedora AMIs
• ec2-user or root for RHEL AMIs, SUSE AMIs, and others.
5. 
   

6. Using SSH on Different Operating Systems:

   • For Windows:
     • Obtain the PEM key from the AWS website and generate a PPK file using PuttyGen. Then, use Putty for SSH, selecting the PPK file under "Connection -> SSH -> Auth" for authorization.
   • For Linux:
     • Run the following command: ssh -i your-ssh-key.pem login@IP-or-DNS.
     • 
       

7. Accessing Your EC2 Instance:

   • Open an SSH client or refer to PuTTY for Windows users.
   • Locate your private key file (e.g., test_key.pem), ensuring it has the appropriate permissions (use chmod 400 if needed).
   • Connect to your EC2 instance using its Public DNS, e.g., ssh -i "test_key.pem" ubuntu@xxx-yyy-100-10-100.us-east-2.compute.amazonaws.com.

Conclusion: While the "no supported authentication methods available server sent public key" error can be frustrating, it is often resolvable. By double-checking your login credentials, SSH key, and trying different authentication methods, you can usually overcome this issue. If problems persist, it's advisable to investigate the server's configuration and consult server logs or contact the server administrator for assistance.

Learn more about Oracle here

What is SSA Name3 Fuzzy Match Engine in Informatica MDM?

 

SSA Name3 Fuzzy Match Engine in Informatica MDM

SSA Name3 is a fuzzy match engine that is used in Informatica Master Data Management (MDM) to match records that contain names, addresses, and other identification data. SSA Name3 is a powerful engine that can match records even when there are errors or inconsistencies in the data.

SSA Name3 uses a variety of techniques to match records, including:

• Phonetic matching: SSA Name3 can match records based on the phonetic similarity of the data. This is useful for matching records that contain different spellings of the same name or that are in different languages. Some of the phonetic matching algorithms used in SSA Name3 include:
  • Soundex
  • Double Metaphone
  • Cologne Phonetic
  • Metaphone 3
  • NYSIIS
  • Refined Soundex
• Exact matching: SSA Name3 can also match records based on the exact match of the data. This is useful for matching records that contain the same data, such as the same name and address.
• Fuzzy matching: SSA Name3 can also match records based on a fuzzy match of the data. This is useful for matching records that contain similar data, but not the same data. For example, SSA Name3 can match records that contain the names "John Smith" and "Jon Smith." Fuzzy match algorithms are:
• Jaro-Winkler
• Levenshtein distance
• Dice coefficient
• Needleman-Wunsch algorithm

SSA Name3 is a very flexible engine, and it can be configured to meet the specific needs of your organization. You can configure SSA Name3 to match records based on different criteria, such as the type of data, the match thresholds, and the match weights.

To use SSA Name3 in Informatica MDM, you need to create a fuzzy match rule. A fuzzy match rule specifies the criteria that SSA Name3 will use to match records. You can create a fuzzy match rule to match any type of data, such as names, addresses, or product numbers.

Once you have created a fuzzy match rule, you can use it to match records in Informatica MDM. You can match records in a variety of ways, such as matching records in a batch or matching records in real time.

SSA Name3 is a powerful and flexible fuzzy match engine that can be used to improve the accuracy and efficiency of data matching in Informatica MDM.

Here are some examples of how SSA Name3 can be used in Informatica MDM:

• Matching customer records: SSA Name3 can be used to match customer records from different sources, such as CRM systems and ERP systems. This can help to create a single, unified view of each customer.
• Matching product records: SSA Name3 can be used to match product records from different sources, such as e-commerce systems and supply chain management systems. This can help to improve the accuracy of product data and reduce the risk of errors.
• Matching employee records: SSA Name3 can be used to match employee records from different sources, such as HR systems and payroll systems. This can help to create a single, unified view of each employee.

SSA Name3 is a valuable tool for any organization that needs to match data from different sources. It can help to improve the accuracy and efficiency of data matching and reduce the risk of errors.

Phonetic matching in Informatica MDM:

• Matching records with different spellings of the same name, such as "John Smith" and "Jon Smith."
• Matching records with names in different languages, such as "Juan Pérez" and "John Perez."
• Matching records with names that contain common abbreviations or nicknames, such as "Bill" and "William."
• Matching records with names that contain typos or other errors, such as "Michale" and "Michael."

SSA Name3, the phonetic matching engine used in Informatica MDM, uses a variety of techniques to match records, including:

• Soundex: Soundex is a phonetic algorithm that converts words into a four-digit code based on the pronunciation of the word. For example, the words "John Smith" and "Jon Smith" would both convert to the Soundex code "J523."
• Double Metaphone: Double Metaphone is a phonetic algorithm that converts words into a two-digit code based on the pronunciation of the word. For example, the words "John Smith" and "Jon Smith" would both convert to the Double Metaphone code "JN."
• Cologne Phonetic: Cologne Phonetic is a phonetic algorithm that converts words into a two-digit code based on the pronunciation of the word in German. For example, the words "John Smith" and "Jon Smith" would both convert to the Cologne Phonetic code "JN."

SSA Name3 also supports a number of other phonetic algorithms, such as Metaphone 3, NYSIIS, and Refined Soundex. The algorithm that is best for you will depend on the specific type of data that you are trying to match.

To use SSA Name3 for phonetic matching in Informatica MDM, you need to create a fuzzy match rule. A fuzzy match rule specifies the criteria that SSA Name3 will use to match records. You can configure a fuzzy match rule to use phonetic matching by selecting the appropriate phonetic algorithm in the match rule settings.

Once you have created a fuzzy match rule, you can use it to match records in Informatica MDM. You can match records in a variety of ways, such as matching records in a batch or matching records in real time.

Phonetic matching can be a very effective way to improve the accuracy and efficiency of data matching in Informatica MDM. It can help to match records that would not be matched using other methods, such as exact matching.

Learn more about Informatica MDM here

What are STRP and MTCH tables in Informatica MDM?

The STRP and MTCH tables are two important tables in Informatica MDM. They are used to store data related to the matching process.

STRP Table

The STRP table stores the SSA_KEYS generated by SSA Name3 for a given record. The keys are used for finding like records from similar keys.

The STRP table is an IOT table in Oracle. This means that it is an index that contains all the data as well. This makes it very efficient for searching the table.

The STRP table contains the following columns:

• SSA_KEY: This is the primary key of the table. It is a unique identifier for each record.
• ROWID_OBJECT: This is the ROWID of the base object record that the SSA_KEY belongs to.
• DATA_ROW: This is the row number of the SSA_DATA column in the STRP record.
• DATA_COUNT: This is the number of rows in the SSA_DATA column.
• SSA_DATA: This is the compressed data for the match columns.

MTCH Table

The MTCH table stores the match results for a given record. The results include the match score, the match path, and the match rules that were used.

The MTCH table is a relational table. This means that it is a table that is made up of rows and columns.

The MTCH table contains the following columns:

• SSA_KEY: This is the primary key of the table. It is a foreign key to the STRP table.
• MATCH_SCORE: This is the score for the match. It is a number that indicates how similar the two records are.
• MATCH_PATH: This is the path that was used to match the two records.
• MATCH_RULES: This is the list of match rules that were used.

How STRP and MTCH Tables Work Together?

The STRP and MTCH tables work together to provide the matching functionality in Informatica MDM. The STRP table is used to find similar records, and the MTCH table is used to store the match results.

When a new record is loaded into Informatica MDM, the STRP table is updated with the SSA_KEY for the new record. The SSA_KEY is then used to search the MTCH table for any existing matches.

If there are any matches, the match results are stored in the MTCH table. The match results can then be used to consolidate the two records.

Conclusion

The STRP and MTCH tables are two important tables in Informatica MDM. They are used to store data related to the matching process. By understanding how these tables work together, you can better understand how the matching functionality in Informatica MDM works.

Learn more about Informatica MDM here