This tutorial teaches you how to load data in Semarchy xDM using the REST API. You will learn to update existing golden records and create a new record simulating a source system sending in a new record. This tutorial is based on the Customer B2C demo application, so you will get experience dealing with emails, phone number, and address data when learning how the REST API works.

What you'll learn

The following tutorial videos assume you have already setup Semarchy xDM and completed the Customer B2C Demo tutorial. If you do not have these two prerequisites, please return to the tutorials main menu to complete the required tutorials so that you can begin with Customer B2C data loaded in your environment.

GO TO TUTORIALS

Enjoy this tutorial!

Before you start

Before following this tutorial, it is advisable to complete the first four tutorials in Integration track. In particular, you should complete the "Configuring Jobs and Loading Data" and the "Retrieve Data via the REST API" because you will need to have an integration job and Postman already set up.

These two integration tutorials are not only required for understanding core integration concepts but you will also need them to implement the persist functions via the REST API. You can find these tutorials from the main menu.

GO TO TUTORIALS

If you have not already done so, you can click on the DOWNLOAD TUTORIAL RESOURCES button to download resources, such as the payload samples you will use to persist data via the REST API in this tutorial.

DOWNLOAD TUTORIAL RESOURCES

The estimated duration of this unit is about 1 hour.

Watch video: Load Data via the REST API

In each section of this tutorial, you will find links that take you directly to the part of the video that demonstrates a step you will take. Even though the videos jump to the pertinent section, the video will continue playing to the end. Stop the video after each segment to avoid running to the end of the video.

As mentioned in the Before you start section of this tutorial, you must have an integration job and Postman set up to complete this tutorial. Let's check that you have all the requirements before proceeding.

What you'll check

Check integration job

In this tutorial, you will use the Load and Submit Data function in the REST API. To use this function, you have to have an integration job set up in your model. If you completed the "Configuring Jobs and Loading Data" tutorial in the Integration track, then the INTEGRATE_ALL job should already exist in your model.

To check that you have an integration job correctly set up:

  1. In the Application Builder, go to the CustomerB2CDemo model.
  2. Under Model Design, go to the Jobs node.
  3. Confirm that you have the integration job INTEGRATE_ALL that contains all of the entities in the CustomerB2CDemo model.

If you do not have the INTEGRATE_ALL job correctly set up, please review the "Configuring Jobs and Loading Data" tutorial in the Integration track. You can access the tutorial by clicking the link below and look for the "Create an integration job" section.

GO TO CONFIGURING JOBS AND LOADING DATA TUTORIAL

Watch video: Check integration job

Check Postman

You will use the Postman application to load and update data in xDM via the REST API. If you don't have Postman set up yet, refer to the "Retrieve Data via the REST API" tutorial in the Integration track.

GO TO RETRIEVE DATA VIA THE REST API TUTORIAL

You can use the following template request to retrieve all the golden records from the Person entity:

http://<host>:<port>/semarchy/api/rest/query/CustomerB2CDemo/Person/GD

You need to modify the sample request above to use your host and port. Again, refer to the "Retrieve Data via the REST API" tutorial for details. Throughout this tutorial, we will share examples of the REST API requests using the public IP address from our environment.

For example, from our environment, we can run the following query to retrieve all the golden records from the Person entity:

http://54.215.241.96/semarchy/api/rest/query/CustomerB2CDemo/Person/GD

To test that Postman is working:

  1. Open up the Postman application.
  2. Check your Postman authentication credentials are correct.


  1. Substitute your public IP address or public DNS address in this request URL: http://54.215.241.96/semarchy/api/rest/query/CustomerB2CDemo/Person/GD


  1. Run this simple GET query to retrieve data from xDM.

If your Postman application is working correctly, then you're ready to proceed to the next section. If you are not able to connect or if your request fails, refer to the "Retrieve Data via the REST API" tutorial for step-by-step guidance for setting up Postman.

Watch video: Check Postman

Congratulations

Now that you have confirmed that Postman can access the data in xDM, in the next section you will use the REST API documentation to begin constructing your payload to update data in xDM.

Before we begin constructing REST calls to load data, let's look at the REST API documentation that Semarchy xDM generates for you. This is a fantastic resource that will help you construct your REST URLs to reduce the risks of typos and other human errors.

The "Retrieve Data via the REST API" tutorial provides additional guidance on the REST API documentation. Review the tutorial if you want more information:

GO TO RETRIEVE DATA VIA THE REST API TUTORIAL

REST API documentation overview

You can find the REST API documentation at the URL:

[public_dns_or_ip_address]/semarchy/api/rest/api-ui/index.html

In our environment, the REST documentation URL is:

http://54.215.241.96/semarchy/api/rest/api-ui/index.html

In this tutorial, you will use the CREATE_LOAD_AND_SUBMIT action to load data in one step. This action is equivalent to the continuous loads feature when loading data via SQL where xDM handles getting a load ID and submitting the load for you. You can learn how to use continuous loads in the "Load Data via SQL" tutorial.

GO TO LOAD DATA VIA SQL

Get the sample payload

Let's dive into the REST API documentation to grab the sample CREATE_LOAD_AND_SUBMIT request so we can load data.

To begin:

  1. Go to the REST API documentation URL. Remember to substitute your public ID address or public DNS address instead of using our server's information: http://54.215.241.96/semarchy/api/rest/api-ui/index.html?domain=data&data-location=CustomerB2CDemo
  2. Click on PUBLISH DATA in the left menu.
  3. Click on the Create a load option in the left menu. (This URL will jump you directly to the section of the documentation: http://54.215.241.96/semarchy/api/rest/api-ui/index.html?domain=data&data-location=CustomerB2CDemo#operation/createLoad)


  1. In the action drop-down menu, choose CREATE_LOAD_AND_SUBMIT.

    You will see a lot of helpful resources to guide you on how to build the request payload. For example, if you drill into persistOptions all the way down to validations to see ValidationType, you can see all the possible values for ValidationType.

  1. Scroll down further to find the Responses heading. These are sample responses to help you understand the possible responses you may receive when you load data. If your load fails, look up the response for troubleshooting clues.
  2. Look for the Request Samples. Open the POST caret drop-down menu. You will need this URL for the request in Postman later. Under Payload, click on the CREATE_LOAD_AND_SUBMIT button.


  1. The sample payload has placeholder values to give you examples of values you need to substitute from your environment.

This payload sample is the recommended starting point for loading data later in this tutorial. You will return to this sample payload when we build the request in Postman.

Watch video: Get the sample payload

Congratulations

You learned how the REST API documentation works. Let's summarize:

In the next step, you will customize the payload and make a POST request to load data via the REST API in Postman.

The ability to load data into xDM in near real-time is critical to delivering value to the business. For example, if your organization has a call center application that needs to retrieve up-to-date golden data from Semarchy xDM, the REST API is the way to integrate these two applications.

When customers call into the call center, the customer often updates contact information or asks to make changes to her account. The REST API is the most common way to achieve near real-time updates in Semarchy xDM.

In the rest of this tutorial, we will focus on loading customer information via the REST API as well as triggering data enrichments and validations to ensure the new information meets your organization's data quality standards.

What you'll learn

Let's construct your first load request.

Background

Imagine the scenario where a customer calls into the customer service center to update her information. This section will guide you through how to check the customer's information for data quality issues before persisting it in xDM.

Let's begin by pulling up the golden customer record of Nola Girvan. To find her information:

  1. Open the Customer B2C application.
  2. Go to the Customers business view.
  3. Use the search filter to search on "nola".


  1. Open the record for Nola Girvan. Go to the CONTACT INFO tab. Notice that the Valid Email Domain field for this customer shows NO.

When Nola Girvan's record was first loaded, xDM enriched her email address using the Semarchy Email Enricher. The enricher flagged Nola Girvan's email as invalid.

Nola received a postcard in the mail asking her to call the customer service center to update her information to ensure she receives the latest promotions by email.

Nola calls the customer service center to update her email address from nola@girvan.com to nola.girvan@gmail.com. When the customer service representative attempts to update her record in the system, the information can first flow through to Semarchy xDM to check the data quality before saving this information permanently. This maintains high data quality standards, which can be a challenge in typical CRM, marketing, and call center systems.

In the Customer B2C Demo model, there is a validation rule, InvalidEmail, that checks whether an email address is valid. This validation rule uses the Semarchy Email Validator, which accepts an email address as an input and returns a boolean value to indicate whether the email is valid. The validator performs syntax checks. It is also configured to perform MX records lookup to check the domain.

Watch video: Background

Set up Postman

Navigate to your Postman application. As you build your request in Postman, you will learn how to use the POST method for loading and where to edit the payload.

To check whether Nola's new email is valid using the validation rule, InvalidEmail:

  1. Paste the request URL that you copied from the REST API documentation into Postman. Remember to substitute your public IP address or public DNS address instead of using our server's information, 54.215.241.96: http://54.215.241.96/semarchy/api/rest/loads/CustomerB2CDemo
  2. Change the method from GET to POST. This change should cause the Body tab to become enabled.
  3. Click the Body tab. Click the "raw" radio button. This should give you a text editor panel. Paste your sample payload from the REST API documentation.

Watch video: Set up Postman

Try a validation check with an invalid email

  1. In the Postman's text editor panel, you will provide the payload to send to Semarchy xDM. When you develop your own REST requests, we recommend you begin by modifying the sample payload from the REST API documentation.

    For your convenience, we modified the sample payload for you. Copy the payload below or from the GitHub resources and paste it into the Postman text editor:

4-check-1-check-email-invalid.json

{
    "action":"CREATE_LOAD_AND_SUBMIT",
    "programName":"UPDATE_DATA_REST_API",
    "loadDescription":"Update customer information reported through call center",
    "jobName":"INTEGRATE_ALL",
    "persistOptions":{
        "defaultPublisherId":"MKT",
        "optionsPerEntity":{
            "Person":{
                "enrichers":[],
                "validations":[
                                {
                                        "validationName": "InvalidEmail",
                                        "validationType": "PLUGIN"
                                }
                                        ],
                "queryPotentialMatches":false
            }
        },
        "missingIdBehavior":"GENERATE",
        "persistMode":"NEVER"
    },
    "persistRecords":{
        "Person":[
            {
                "SourceID":"1368178",
                "SourceEmail":"nola.girvan@gmail.co"
            }
        ]
    }
}

Note the following points of interest:

  1. The "programName":"UPDATE_DATA_REST_API" is informational. You should come up with your own descriptive programName for your REST API environment.
  2. For "jobName":"INTEGRATE_ALL", you should use the same job name from your model.
  3. We set "persistMode":"NEVER" which performs a dry-run to test your records and cancels the job so the records are not saved.
  4. We are loading the source record "SourceID":"1368178" from MKT, not the golden record. This master record shows up as MKT.1368178:

  1. We deliberately introduced a typo to the email where the trailing m is missing in "SourceEmail":"nola.girvan@gmail.co". It is common for humans to make errors, such as typos. Luckily, xDM can catch these errors to improve data quality.
  1. The response you receive from Semarchy xDM should look like the following:
{
    "status": "PERSIST_CANCELLED",
    "load": {
        "loadId": 99,
        "loadStatus": "CANCELED",
        "loadCreator": "semadmin",
        "loadCreationDate": "2018-11-17T01:40:55.317Z",
        "programName": "UPDATE_DATA_REST_API",
        "loadDescription": "Update customer information reported through call center",
        "numberOfJobExecutions": 0,
        "submitInterval": -1,
        "submittable": true,
        "loadType": "EXTERNAL_LOAD"
    },
    "records": {
        "Person": [
            {
                "entityName": "Person",
                "recordValues": {
                    "CleansedEmail": "nola.girvan@gmail.com",
                    "Address.Country": "US",
                    "ValidEmailDomain": "1",
                    "NormalizedFirstName": "NOLA",
                    "PersonType": "CUSTOMER",
                    "NormalizedLastName": "GIRVAN",
                    "SourceEmail": "nola.girvan@gmail.co",
                    "Address.Street": "1620 Paonia Ave",
                    "DeleteOperation": null,
                    "StandardizedPhone": "(719) 574-6245",
                    "Address.State": "CO",
                    "Address.PostalCode": "80915",
                    "ValueStatus": "NORMAL",
                    "Nickname": "nola",
                    "DateOfBirth": "1980-04-10",
                    "DeleteAuthor": null,
                    "FirstName": "Nola",
                    "Address.City": "Colorado Springs",
                    "SourceID": "1368178",
                    "DeletePath": null,
                    "DeleteDate": null,
                    "PhoneticFirstName": "NL",
                    "PhoneticLastName": "JRFN",
                    "SourcePhone": "719-574-6245",
                    "PublisherID": "MKT",
                    "PhoneGeocodingData": "Colorado Springs, CO",
                    "LastName": "Girvan"
                },
                "failedValidations": [
                    {
                        "validationType": "PLUGIN",
                        "validationName": "InvalidEmail"
                    }
                ],
                "potentialMatches": []
            }
        ]
    }
}

Look for the failedValidations object. This response from xDM shows that the email address failed the InvalidEmail enricher. This is expected. If there is no error, meaning the email address if valid, then the failedValidations object would be empty.

You now know how to tell if the data you are loading has violated a validation rule via the REST API. In the next section, you will load Nola's valid email address (meaning the typo is fixed). Then you will be able to compare how the response differs when the email is valid.

Watch video: Try a validation check

Congratulations

You successfully check where an email address is valid via the Semarchy Email Validator using a REST call. Let's summarize what you achieved:

In the previous section, you learned how to check whether an email address is valid. Now that the customer service representative discovered the email address typo and has corrected it to be nola.girvan@gmail.com, you are ready to load this new email address into xDM.

What you'll learn

Load data into xDM

Imagine that the customer service representative wants to update Nola's email address to nola.girvan@gmail.com. To try the request again to see how the results differ:

  1. Modify the payload. First, fix the email by adding the trailing m to SourceEmail so that it reads: "SourceEmail":"nola.girvan@gmail.com"
  2. Next, fix the persistMode from NEVER to IF_NO_ERROR_OR_MATCH so that it reads: "persistMode":"IF_NO_ERROR_OR_MATCH". You should have a payload that looks like the following:


5-check-1-update-email.json

{
    "action":"CREATE_LOAD_AND_SUBMIT",
    "programName":"UPDATE_DATA_REST_API",
    "loadDescription":"Update customer information reported through call center",
    "jobName":"INTEGRATE_ALL",
    "persistOptions":{
        "defaultPublisherId":"MKT",
        "optionsPerEntity":{
            "Person":{
                "enrichers":[],
                "validations":[
                                {
                                        "validationName": "InvalidEmail",
                                        "validationType": "PLUGIN"
                                }
                                        ],
                "queryPotentialMatches":false
            }
        },
        "missingIdBehavior":"GENERATE",
        "persistMode":"IF_NO_ERROR_OR_MATCH"
    },
    "persistRecords":{
        "Person":[
            {
                "SourceID":"1368178",
                "SourceEmail":"nola.girvan@gmail.com"
            }
        ]
    }
}
  1. The response you receive from Semarchy xDM should look like the following:
{
    "status": "PERSISTED",
    "load": {
        "loadId": 100,
        "loadStatus": "PENDING",
        "loadCreator": "semadmin",
        "loadCreationDate": "2018-11-17T01:42:05.504Z",
        "programName": "UPDATE_DATA_REST_API",
        "loadDescription": "Update customer information reported through call center",
        "loadSubmitDate": "2018-11-17T01:42:05.561Z",
        "batchSubmitter": "semadmin",
        "batchId": 66,
        "integrationJobName": "INTEGRATE_ALL",
        "integrationJobQueueName": "Default",
        "numberOfJobExecutions": 0,
        "submitInterval": -1,
        "submittable": true,
        "loadType": "EXTERNAL_LOAD"
    },
    "records": {
        "Person": [
            {
                "entityName": "Person",
                "recordValues": {
                    "CleansedEmail": "nola.girvan@gmail.com",
                    "Address.Country": "US",
                    "ValidEmailDomain": "1",
                    "NormalizedFirstName": "NOLA",
                    "PersonType": "CUSTOMER",
                    "NormalizedLastName": "GIRVAN",
                    "SourceEmail": "nola.girvan@gmail.com",
                    "Address.Street": "1620 Paonia Ave",
                    "DeleteOperation": null,
                    "StandardizedPhone": "(719) 574-6245",
                    "Address.State": "CO",
                    "Address.PostalCode": "80915",
                    "ValueStatus": "NORMAL",
                    "Nickname": "nola",
                    "DateOfBirth": "1980-04-10",
                    "DeleteAuthor": null,
                    "FirstName": "Nola",
                    "Address.City": "Colorado Springs",
                    "SourceID": "1368178",
                    "DeletePath": null,
                    "DeleteDate": null,
                    "PhoneticFirstName": "NL",
                    "PhoneticLastName": "JRFN",
                    "SourcePhone": "719-574-6245",
                    "PublisherID": "MKT",
                    "PhoneGeocodingData": "Colorado Springs, CO",
                    "LastName": "Girvan"
                },
                "failedValidations": [],
                "potentialMatches": []
            }
        ]
    }
}

You will know that the job succeeded if you see the status indicates the record was persisted: "status": "PERSISTED"

  1. Check the status of the job in the Application Builder, under the Management tab where you can see each data location and the status of jobs. You can identify the job using the loadID in the REST response (in our example, it is 100).

Watch video: Load data into xDM

Check the data location logs

Load 100 succeeded but notice that loads 92-94 show canceled because the we set the persistMode to NEVER.

  1. Find the integration job that corresponds to the load ID of 95. You can find it in the REST response under the key batchID. We see that Batch ID 66 is finished without any errors.

  1. Let's check the Customer B2C application to confirm that Nola's email successfully updated.

Great job! You successfully updated Nola's email and fixed it from an invalid to a valid email address.

You that you know how to load data via the REST API, in the next section, you will try another data quality check. Instead of performing a dry run of a validation rule, you will perform a dry run of an enricher and then eventually persist the data.

Watch video: Check the data location logs

Congratulations

You successfully loaded data by updating an email address via using a REST call. Let's summarize what you achieved:

In the previous two sections, you learned how to validate incoming data to boost data quality. You did it by first checking data against a validation rule and then persisting the data when the updated information had no errors.

Another way that you can improve data quality is by enriching data. In this section, you will focus on enriching customer information via the REST API to ensure the new information meets your organization's data quality standards. Then you will load this record via the REST API.

What you'll learn

Background

Imagine in this second scenario, a customer calls into the customer service center to update her phone number. This section will guide you through how to check the customer's information for data quality issues before persisting it in xDM.

Let's begin by pulling up the golden customer record of Gail Taulman. To find her information:

  1. Open the Customer B2C application.
  2. Go to the Customers business view.
  3. Use the search filter to search on "gail".


  1. Open the record for Gail Taulman. Go to the CONTACT INFO tab. Notice that the Source Phone field for this customer shows the phone number is missing the area code. As a result, the Phone Geocoding Data field is empty.

When Gail Taulman's record was first loaded, xDM tried to enriched her phone number using the Semarchy Phone Enricher. The enricher was not able to geocode the phone number because Gail's phone number was missing the area code. This is not acceptable for most national or even regional organizations because a missing area code means the organization won't be able to reach the customer.

As a result, Gail received a postcard in the mail asking her to call the customer service center to update her information to ensure that she receives calls if there are ever any issues with her account.

Gail calls the customer service center to update her phone number's area code to 770. When the customer service representative attempts to update her record in the system, the information can first flow through to Semarchy xDM to check the data quality before saving this information permanently. This maintains high data quality standards, which can be a challenge in typical CRM, marketing, and call center systems.

In the Customer B2C Demo model, there is an enricher, StandardizePhone.

This enricher rule uses the Semarchy Phone Enricher, which accepts a phone number as an input and returns many different outputs, including a standardized version (supporting different international formatting standards) of the phone number, the region code, the status, the line type (mobile, landline, etc.), and many other possible outputs.

Watch video: Background

Use the email enricher

The Customer B2C demo model already contains the enricher, StandardizePhone. This enricher standardizes the phone number to the NATIONAL format, e.g. (123) 456-7890 and provides geocoding data.

To check Gail's updated phone number, let's run the enricher via the REST API:

  1. Paste the request URL that you copied from the REST API documentation into Postman. Remember to substitute your public IP address or public DNS address instead of using our server's information, 54.215.241.96: http://54.215.241.96/semarchy/api/rest/loads/CustomerB2CDemo
  2. Double check the method is set to POST.
  3. In the Body tab, select the "raw" radio button. This should give you a text editor panel. Paste the following payload:

6-enrich-1-enrich-phone-number.json

{
    "action":"CREATE_LOAD_AND_SUBMIT",
    "programName":"UPDATE_DATA_REST_API",
    "loadDescription":"Update customer information reported through call center",
    "jobName":"INTEGRATE_ALL",
    "persistOptions":{
        "defaultPublisherId":"CRM",
        "optionsPerEntity":{
            "Person":{
                "enrichers":[
                    "StandardizePhone"
                ],
                "validations":[],
                "queryPotentialMatches":false
            }
        },
        "missingIdBehavior":"GENERATE",
        "persistMode":"IF_NO_ERROR_OR_MATCH"
    },
    "persistRecords":{
        "Person":[
            {
                "SourceID":"1418027",
                "SourcePhone":"7709694377"
            }
        ]
    }
}

Note the following points of interest:

  1. For "jobName":"INTEGRATE_ALL", you should use provide the name of the job that exists in your model.
  2. The optionsPerEntity specifies the enricher to run in the REST call:
"optionsPerEntity":{
            "Person":{
                "enrichers":[
                    "StandardizePhone"
                ]
  1. We set "persistMode":"IF_NO_ERROR_OR_MATCH" which saves the record to xDM if there are no errors.
  2. We are loading the source record "SourceID":"1418027" from CRM, not the golden record. This represents the source record from the CRM system.

  1. We input the phone number in the persistRecords section, "SourcePhone":"7709694377".
  1. The response you receive from Semarchy xDM should look like the following:
{
    "status": "PERSISTED",
    "load": {
        "loadId": 102,
        "loadStatus": "PENDING",
        "loadCreator": "semadmin",
        "loadCreationDate": "2018-11-19T20:37:33.981Z",
        "programName": "UPDATE_DATA_REST_API",
        "loadDescription": "Update customer information reported through call center",
        "loadSubmitDate": "2018-11-19T20:37:34.064Z",
        "batchSubmitter": "semadmin",
        "batchId": 67,
        "integrationJobName": "INTEGRATE_ALL",
        "integrationJobQueueName": "Default",
        "numberOfJobExecutions": 0,
        "submitInterval": -1,
        "submittable": true,
        "loadType": "EXTERNAL_LOAD"
    },
    "records": {
        "Person": [
            {
                "entityName": "Person",
                "recordValues": {
                    "CleansedEmail": "gail@taulman.com",
                    "Address.Country": "US",
                    "ValidEmailDomain": "1",
                    "NormalizedFirstName": "GAIL",
                    "PersonType": "PROSPECT",
                    "NormalizedLastName": "TAULMAN",
                    "SourceEmail": "gail@taulman.com",
                    "Address.Street": "5094 Westbrook Rd",
                    "DeleteOperation": null,
                    "StandardizedPhone": "(770) 969-4377",
                    "Address.State": "GA",
                    "Address.PostalCode": "30291",
                    "ValueStatus": null,
                    "Nickname": "gail",
                    "DateOfBirth": "1971-12-10",
                    "DeleteAuthor": null,
                    "FirstName": "Gail",
                    "Address.City": "Union City",
                    "SourceID": "1418027",
                    "DeletePath": null,
                    "DeleteDate": null,
                    "PhoneticFirstName": "KL",
                    "PhoneticLastName": "TLMN",
                    "SourcePhone": "7709694377",
                    "PublisherID": "CRM",
                    "PhoneGeocodingData": "Georgia",
                    "LastName": "Taulman"
                },
                "failedValidations": [],
                "potentialMatches": []
            }
        ]
    }
}
  1. Let's analyze the response. The "SourcePhone": "7709694377" shows you the input you sent to xDM via the REST API payload. The enricher updated the two fields "StandardizedPhone": "(770) 969-4377" and "PhoneGeocodingData": "Georgia". Not only has the enricher formatted the phone number it identified the phone as being from Georgia, which is consistent with Gail's address of Union City, GA.

You now know how to enrich data via the REST API. Furthermore, you know the difference between a validation rule and an enricher. You will now be able to compare which rule would be best for your organization's business requirements (or whether a combination would work best).

Watch video: Use the email enricher

Congratulations

You learned how to load data in xDM using the REST API while enriching a record. Let's summarize:

Great job going through this tutorial!

You will find more information about Integration jobs, such as how to query and load data using SQL as well as how to retrieve via the REST API in this Integration track.

Using the enricher is different from the validation rule.

Validation Rules

The validation rule returns a boolean value (true or false). If the record is valid, xDM will allow the record to go through the integration process and become a golden record. If the record fails validation, the record is put in the error queue.

You will know if a record failed validation because the REST response from xDM shows the validation rule under the failedValidations object and the validationType.

Enrichers

On the other hand, the enricher will run as long as you correctly set up the request payload. Whether you get your intended results depends on how you configured the enricher.

In contrast to the validation rule, an enricher does not reject any records as errors. The only times when an enrich could be linked to a rejected record is when the enricher adds new data that violates a validation rule or returns a different data type than the output field was expecting (e.g. a string instead of a number which fails the attribute's data type). Enrichers can also cause an integration job to fail outright when incorrectly configured.

Well done! You have run your first REST POST requests to load data into Semarchy xDM via the REST API.

In this tutorial, you learned:

You will find more Integration information, including how to load data using SQL and how to use the REST API in the Integration tutorial series.

There are also tutorials about how to design applications in the Data Authoring and Data Consolidation tutorial tracks.

Go back to the main menu to see more tutorials.

GO TO TUTORIALS

Go further with xDM

This tutorial taught you how to load data into xDM using SQL. xDM is capable of addressing all types of data, including customer data, location data, reference data, organization data, supplier data, and other domains.

Visit our website to learn about the different solutions we provide.