DronaBlog

Sunday, October 15, 2023

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



Sunday, September 24, 2023

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



Tuesday, September 19, 2023

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. 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.

            • 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.

            • 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



            Saturday, September 16, 2023

            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



            Tuesday, September 12, 2023

            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



            Sunday, September 3, 2023

            Org, Secure Agent, and Chicklets in Informatica IDMC

            Org

            In Informatica IDMC, an org is a logical grouping of users, resources, and data. It is used to manage access to data and applications, and to ensure that data is secure. Each org has its own set of permissions, which define who can access what data and applications.





            Secure Agent

            The Secure Agent is a software component that runs on a physical or virtual machine in the customer's environment. It is responsible for connecting to the Informatica Cloud and running tasks. The Secure Agent also provides security features, such as encryption and authentication, to protect data in transit and at rest.

            Chiclets

            Chiclets are small, rectangular icons that represent tasks or applications in Informatica IDMC. They are displayed in the IDMC user interface, and can be used to launch tasks, view data, and manage resources.

            How do Orgs, Secure Agents, and Chicklets work together?

            Orgs, Secure Agents, and Chicklets work together to provide a secure and scalable environment for data integration.

            • Orgs are used to manage access to data and applications. Each org has its own set of permissions, which define who can access what data and applications.
            • Secure Agents are used to connect to the Informatica Cloud and run tasks. The Secure Agent also provides security features, such as encryption and authentication, to protect data in transit and at rest.
            • Chicklets are used to launch tasks, view data, and manage resources. They are displayed in the IDMC user interface, and can be easily customized to meet the needs of the user.





            Benefits of using Orgs, Secure Agents, and Chicklets

            There are many benefits to using Orgs, Secure Agents, and Chicklets in Informatica IDMC. These include:

            • Improved security: Orgs and Secure Agents help to protect data by providing a secure environment for data integration.
            • Increased scalability: Chicklets can be used to launch tasks and view data, which can help to improve the scalability of data integration workflows.
            • Improved usability: The IDMC user interface is easy to use and navigate, and chicklets can be customized to meet the needs of the user.

            Orgs, Secure Agents, and Chicklets are essential components of Informatica IDMC. They work together to provide a secure and scalable environment for data integration. By using these components, organizations can improve the security, scalability, and usability of their data integration workflows.



            Learn more about Informatica MDM Cloud (SaaS) here



            Understanding Survivorship in Informatica IDMC - Customer 360 SaaS

              In Informatica IDMC - Customer 360 SaaS, survivorship is a critical concept that determines which data from multiple sources should be ret...