Integrate your App

This chapter aims to present Carol's main services for building an integration for sending data to Carol. It also covers the process of consuming data and understanding how to extract data from Golden Records.

1. Swagger

The swagger is a framework that allows developers to design, build, document and consume REST API

29982998

Carol: Services before authentication

Carol provides access to Swagger through two URLs:

https://app.carol.ai/swagger-ui/
https://app.carol.ai/swagger-admin/

The difference between the two URLs:

https://app.carol.ai/swagger-ui/

It provides access to the services necessary for any application to integrate with Carol, making the most of processes such as authentication, data ingestion and data consumption.

https://app.carol.ai/swagger-admin/

It provides access to the necessary services so that advanced features in the integration with Carol are possible. Here there are services related to Carol Apps, data processing, security, data privacy, among others. Much of the services available in this section are already available on the Carol platform through UI streams.

2. Authentication

You can access the documentation related to Authentication flow on this link:
https://tdn.totvs.com/pages/releaseview.action?pageId=552107176

Next steps

Once authentication has taken place, we will have access_token available. This value must be inserted in the swagger in the " Access Token " attribute (top center).

21682168

Subsequent requests are authenticated according to the following request:

curl -X GET "https://clockin.carol.ai/api/v1/users?pageSize=10&sortOrder=ASC" -H "accept: application/json" -H "Authorization: 1e2fe288fa3a4ca38257294008081317"

If authentication occurred via the Connector Token (as described above), the request (curl command) above will look like this:

curl -X GET "https://clockin.carol.ai/api/v1/users?pageSize=10&sortOrder=ASC" -H "accept: application/json" -H "X-Auth-ConnectorId: 90d7bcd37c424d85a733a42117528792" -H "X-Auth-Key: 5b91c933da644082ab69810b9d8a11b6"

3. Sending Data

Carol has OAuth authentication, and API Key authentication (also known as API Token or Connector Token) can be exploited.

Overview

Below is a flow demonstrating the process of sending data to Carol:

751751

The main services related to the staging area flow are listed below:

14481448

These services allow the definition of the data structure (schema), the sending of data by the SYNC process and the ASYNC process, as well as the elimination of data in Carol.

Defining the staging table schema

All data sent to Carol must have a schema, which is basically the definition of the structure that will be stored in Carol. The concept of the schema follows the same principle as the schema of tables in relational databases.

The following schema is an example of how the definition occurs on the Carol platform:

{
   "mdmFlexible":"false",
   "mdmExportData":"false",
   "mdmStagingMapping":{
      "properties":{
         "cod-emitente":{
            "type":"integer"
         },
         "cgc":{
            "type":"string"
         },
         "nome-emit":{
            "type":"string"
         }
      }
   },
   "mdmCrosswalkTemplate":{
      "mdmCrossreference":{
         "emitente":[
            "cod-emitente"
         ]
      }
   }
}

The identifier (also called a crosswalk) is the definition of the primary key of a staging table. The identifier at Carol works to update a record in the staging area, causing an existing record to be updated by new values. The identifier is also used in the process of deleting records, as we will see a little later.

The Carol platform has the necessary services to create, update and delete the table schema, as follows:

Create a staging table:

12871287

Update the schema of a staging table:

12901290

Drop a staging table:

12861286

Maintenance of a staging table schema

In addition to the endpoints described above, operations for maintaining a staging table and dropping a staging table are available through Carol's UI. When accessing a connector in Carol (left side menu) we can access the staging tables belonging to the connector.

14031403

By clicking on a staging table and in the sequence "View Sample Data" (or "View Data" for staging tables marked as Lookup table) we can access the menu below, which allows accessing the " Manage Fields " option:

12951295

The "Manage Fields" option will open the screen below, which allows you to add, remove or change the attributes belonging to the staging table identifier:

14021402

At the end of the adjustments, the button "Save Changes" will update the schema of the staging table, in the same way as the PUT service described above.

Sending data to a staging table

The staging table has the purpose of storing data (records / documents) in its structure. The service below is responsible for receiving a data set (array of JSON documents). As defined in the previous chapter, the Identifier attribute will determine whether records will be added to Carol or whether they will update existing data.

12861286

πŸ“˜

Immutable data

The Carol platform stores data in the Carol Data Storage (CDS) layer. This layer has the characteristic of being immutable, which makes Carol store all the versions that the data had. In other words, when a data is changed the platform will preserve both versions (before the update and the most recent version).

The platform has the consolidation process so that previous versions of the record are discarded. This process can be scheduled for frequent and automatic execution.

The service described above allows the sending of data following RFC1952 which allows the sending of compressed data. It is highly recommended that the data be sent in this way, thus reducing the latency time in the request.

πŸ“˜

Request Parameters Sending data

The request for sending data allows the use of the connector name in the " connectorId " parameter, making the application simpler and less dependent on the customer's environment. The connector name can be obtained from Carol's " Connectors " screen .

The table name must contain characters and numbers, and it is mandatory to start with a character. Special characters are not allowed.

The " body " must be an array of Json objects following the " schema " defined for the " staging table " in the previous step.

Once the data has been entered through this service, it can be viewed on Carol's UI. Staging tables have a percentage for viewing sample data - so it is expected that not all data will be viewed by the UI.

πŸ“˜

Lookup Staging Table

By default, the Lookup Staging Table has all the data available in the real-time layer, the layer used to optimize performance during data processing. Staging tables that are not marked as Lookup will only have a percentage available, as a sample of the data from the staging table.

It is worth mentioning that this service sends the data through an asynchronous request. This means that when the service responds to code 200, the data will not be available in the staging table or in the data model (explore). A few seconds may be necessary for this to occur.

The next chapter will describe the same service, however, synchronous, which will return 200 when the data is in the staging table or if it is available as a golden record.

Sending data to a staging table using the synchronous method

This service has the same objective as the service detailed in the previous chapter, however, it will return code 200 in the http request when data is available from Carol. The data being available means being on the staging table (if the staging table is not mapped) or being available as a Golden Record if the staging table has a mapping for a Data Model.

This service has a limitation in the number of records for sending, and it cannot be used for a large number of records because the request may take seconds to return.

12911291

This service has the same features as the asynchronous service.

Eliminating data through the staging area

This service has the objective of eliminating data in Carol, through the values ​​of the attributes defined as Identifier for the staging table.

12891289

The parameters are as follows:

Parameterdescription
bodyJson with the list of IDs that should be deleted. An example of this parameter is:

[{"issuer": {"cod-issente": "33"}}, {"issente": {"cod-emitente": "44"}}]
connectorIdThe connector code that the staging table above belongs to.
propagateCleanupParameter indicating whether the elimination of the records should be propagated to the Golden Record and rejected records, thus completely eliminating this record from Carol.
tableThe name of the staging table being deleted from the records.

This way, external processes can effect the elimination of records in Carol.

Next steps

Now that the processes for sending the data have been presented, it is possible to carry out a complete data synchronization process with the Carol platform. These steps described in this section are the same as those used by Carol Connect (2C).

The next steps are to obtain (consume) this data, as described in the next chapter.

4. Consuming Data

Carol has some ways to consume data by third party applications. The most conventional format is through " filters " or " named queries ".

Overview

Below is a flow demonstrating Carol's data consumption process through filter or named queries:

843843

The main services related to the data consumption flow are listed below:

23242324

These services allow data consumption through queries (filter / queries) or through named queries (named-queries). Both features will be detailed in the following chapters.

Filter/Queries

The most conventional way of consuming data at Carol is through queries (filter / queries) and named queries (named queries). These features allow the consumption of data considering the data structure defined in the data model.

Carol has a series of resources related to queries for data consumption. To search for details of the services, you can consult the following link: https://docs.carol.ai/docs/querying-data

The print-screen below shows the service used to run the filters / queries:

12851285

This service returns a list of golden records, which will be detailed in the next chapter.

Named Queries

Another way to work with queries at Carol is through named queries. Named queries allow you to store the filter / query in Carol, thus allowing more agile maintenance of the named query.

The named query has the same resources available in the documentation shared above ( https://docs.carol.ai/docs/querying-data ), the difference being that the filter is stored in Carol and the external application (consumer) will only refer to the query stored in Carol. The benefits linked to this resource are:

Data cache.
Better maintainability of the query.
Easy reuse and propagation of the same query for all consumer applications.

Below is the service responsible for executing a named query:

12881288

The following is an example of a " Filter ":

{
   "excludeMergePending":false,
   "filtering":true,
   "minimumShouldMatch":1,
   "mustList":[
      {
         "mdmFilterType":"TYPE_FILTER",
         "mdmValue":"deviceGolden"
      },
      {
         "mdmFilterType":"TERM_FILTER",
         "mdmKey":"mdmGoldenFieldAndValues.integraterm",
         "mdmValue":true
      },
      {
         "mdmFilterType":"WILDCARD_FILTER",
         "mdmKey":"mdmGoldenFieldAndValues.devicedescription",
         "mdmValue":"{{deviceDescription}}"
      }
   ],
   "resolveRelationships":false
}

Creating / Updating a named query

Named queries are filters inside an envelope (Json structure), stored in Carol. The filters are encapsulated as follows:

{
  "mdmCacheRevalidationTimeInSeconds": 0,
  "mdmCacheTimeInSeconds": 0,
  "mdmFilterQuery": {
    "excludeMergePending": false,
    "filtering": true,
    "minimumShouldMatch": 1,
    "mustList": [
      {
        "mdmFilterType": "TYPE_FILTER",
        "mdmValue": "deviceGolden"
      },
      {
        "mdmFilterType": "TERM_FILTER",
        "mdmKey": "mdmGoldenFieldAndValues.integraterm",
        "mdmValue": true
      },
      {
        "mdmFilterType": "WILDCARD_FILTER",
        "mdmKey": "mdmGoldenFieldAndValues.devicedescription",
        "mdmValue": "{{deviceDescription}}"
      }
    ],
    "resolveRelationships": false
  },
  "mdmQueryDescription": "Retorna a lista de dispositivos",
  "mdmQueryName": "deviceList",
  "mdmQueryPaid": false,
  "mdmQueryParams": [
    {
      "mdmDescription": {},
      "mdmEditable": true,
      "mdmInherited": false,
      "mdmLabel": {},
      "mdmName": "deviceDescription",
      "mdmRequired": false,
      "mdmValueType": "string"
    }
  ],
  "mdmReturnFields": [],
  "mdmTimeoutInSeconds": 55,
  "mdmType": "deviceGolden"
}

A highlight for the " mdmFilterQuery" attribute that has the filter that will be executed when the named query " deviceList " is executed.

The print-screen displays which service is responsible for adding the named query:

12891289

After saving the named query, a code ( mdmId ) is returned for the named query. This code is used to update and delete the named query. The service below is responsible for updating the named query:

12881288

The following service returns the list of existing named queries, making it possible to retrieve all named queries that are currently in the environment:

12881288

Eliminating a named query

After adding a named query (and obtaining the mdmId code ) it is possible to delete the named query with the service below:

12911291

The " force " parameter indicates whether the named query should be deleted even if I have reference to other resources, such as an Insight or Carol App.

Next steps

The next chapter details the meta information available on Golden Records.

5. Golden Record Details

Carol has OAuth authentication, and API Key authentication (also known as API Token or Connector Token) can be exploited.

Overview

This chapter details the data existing within a Golden Record.

Information available in a Golden Record

The Golden Record document stores all the data necessary to understand the formation of a Golden Record. Because the Golden Record is the combination of the same data from various data sources, the original data from the staging area, the result of the processing of the staging area (also called the master record) and the final golden record, after the rules of survival are preserved and stored in the Golden Record.

When a data model is defined, it is possible to determine that the Data Model is " Evict ", this means that the Data Model will not store the meta information of the staging area of ​​master records. The final golden record will be leaner, using less storage final (and consequently responding more quickly to queries).

Other than that, the golden records of this data model cannot be reprocessed in Explore (reprocessing will occur only through the staging area - for the entire volume of data in the staging table).

πŸ“˜

Evict

Even if the Golden Records of a Data Model marked as Evict (true) are not possible to be reprocessed by Explore, the rejected records will still be possible to be reprocessed by the Explore module. This is due to the fact that the rejected records preserve all the original content of the Staging Area for reprocessing operations.

The following screen of a Data Model demonstrates how to enable / disable the Evict configurationy:

14041404

Important attributes in a Golden Record document:

Attributedescription
mdmApplicationIdMasterRecordSpecifies all connectors that have a mapping and staging record contributing to this Golden Record. The structuring of this attribute takes place by master records, and for each master record the original data of the staging area is specified.
mdmApplicationIdMasterRecord.mdmCrosswalkTest area record identifier.
mdmApplicationIdMasterRecord.mdmStagingRecordOriginal record of the staging table - record as inserted in Carol.
mdmApplicationIdMasterRecord.mdmMasterFieldAndValuesValues ​​for the attributes of the staging table processed with the mapping / cleaning rules defined in the mapping.
mdmGoldenFieldAndValuesValues ​​for the attributes of the data model considering the rules of survival for all master records.
mdmEntityTypeName of the data model that this golden record refers to.

The following is an example of a Golden Record document (some parts have been omitted to make it leaner):

{
   "mdmApplicationIdMasterRecord":{
      "08d8618b6833437f99e8032ec08b9e54":[
         {
            "mdmApplicationId":"08d8618b6833437f99e8032ec08b9e54",
            "mdmConnectorId":"08d8618b6833437f99e8032ec08b9e54",
            "mdmCounterForEntity":1592588017473000,
            "mdmCreated":"2020-06-10T21:41:24.157Z",
            "mdmCreatedUser":"",
            "mdmCrosswalk":{
               "mdmApplicationId":"33dd1190ff2c11e8858be609736e2a59",
               "mdmConnectorId":"33dd1190ff2c11e8858be609736e2a59",
               "mdmCrossreference":{
                  "clockinprocessed":{
                     "clockinDatetime":"2020-04-11T19:39:50.695Z",
                     "deviceCode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
                     "employeePersonId":"03642947956"
                  }
               },
               "mdmStagingType":"clockinprocessed"
            },
            "mdmCrosswalkString":null,
            "mdmEntityTemplateId":"1e328c60fd8f11e8a4dce609736e2a59",
            "mdmEntityType":"clockinrecordsMaster",
            "mdmErrors":[

            ],
            "mdmFlaggedFieldIds":[

            ],
            "mdmGoldenRecordId":null,
            "mdmId":"48f217ef4c0256a655e15e3fc3fb34f4",
            "mdmLastUpdated":"2020-06-10T21:41:24.157Z",
            "mdmMasterFieldAndValues":{
               "appname":"clockinweb",
               "clockinmode":"1",
               "coordinatesaccuracy":0,
               "devicecode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
               "devicedescription":"REP 99 Robson Poffo",
               "empty_mdmeventdate":false,
               "empty_smssent":true,
               "eventdatestr":"2020-04-11T16:39:50.695-0300",
               "fakegpslocation":false,
               "gmt":"",
               "has_image":false,
               "has_receiptimage":true,
               "imagehash":"",
               "locationcode":"1",
               "locationdescription":"TOTVS Labs",
               "mdmemailaddress":"[email protected]",
               "mdmeventdate":"2020-04-11T19:39:50.695Z",
               "mdmname":"Robson Poffo",
               "mdmpersonid":"03642947956",
               "mdmphonenumber":"+14085079761",
               "mdmtaxid":"5311379100012",
               "nsrcode":1447,
               "piscode":"03642947956",
               "readphonestateenabled":false,
               "receiptimage":"BASE64_IMAGE",
               "receiptsentmode":"Nothing",
               "score":0,
               "selfclockin":false,
               "supervisorcode":"fe115382754247d883d9a11b88b3d96e",
               "supervisorname":"fe115382754247d883d9a11b88b3d96e",
               "updatedatetimeautomatically":false
            },
            "mdmMasterFieldAndValuesString":null,
            "mdmSkippedFieldIds":[

            ],
            "mdmSourceType":"PROCESSING_ENGINE",
            "mdmStagingEntityName":"33dd1190ff2c11e8858be609736e2a59_clockinprocessed",
            "mdmStagingRecord":{
               "clockinDatetime":"2020-04-11T19:39:50.695Z",
               "clockinImage":"BASE64_IMAGE",
               "clockinNSRNumber":1447,
               "deviceCode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
               "employeePersonId":"03642947956",
               "mdmConnectorId":"33dd1190ff2c11e8858be609736e2a59",
               "mdmCounterForEntity":58171,
               "mdmCreated":"2020-06-10T21:41:17.731Z",
               "mdmEntityType":"33dd1190ff2c11e8858be609736e2a59_clockinprocessed",
               "mdmId":"373c4cd5918ac598cd55a948a59bef56",
               "mdmLastUpdated":"2020-06-10T21:41:17.731Z",
               "mdmTenantId":"4c2c9090e7c611e893bf0e900682978b",
               "supervisorcode":"fe115382754247d883d9a11b88b3d96e"
            },
            "mdmStagingRecordString":null,
            "mdmTenantId":"4c2c9090e7c611e893bf0e900682978b",
            "mdmUpdatedUser":"",
            "score":null
         }
      ],
      "33dd1190ff2c11e8858be609736e2a59":[
         {
            "mdmApplicationId":"33dd1190ff2c11e8858be609736e2a59",
            "mdmConnectorId":"33dd1190ff2c11e8858be609736e2a59",
            "mdmCounterForEntity":1592588674244000,
            "mdmCreated":"2020-06-19T17:39:56.500Z",
            "mdmCreatedUser":"",
            "mdmCrosswalk":{
               "mdmApplicationId":"33dd1190ff2c11e8858be609736e2a59",
               "mdmConnectorId":"33dd1190ff2c11e8858be609736e2a59",
               "mdmCrossreference":{
                  "clockinprocessed":{
                     "clockinDatetime":"2020-04-11T19:39:50.695Z",
                     "deviceCode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
                     "employeePersonId":"03642947956"
                  }
               },
               "mdmStagingType":"clockinprocessed"
            },
            "mdmCrosswalkString":null,
            "mdmEntityTemplateId":"1e328c60fd8f11e8a4dce609736e2a59",
            "mdmEntityType":"clockinrecordsMaster",
            "mdmErrors":[

            ],
            "mdmFlaggedFieldIds":[

            ],
            "mdmGoldenRecordId":null,
            "mdmId":"6debe01c26ada1667b1dc5139a04998e",
            "mdmLastUpdated":"2020-06-19T17:39:56.500Z",
            "mdmMasterFieldAndValues":{
               "devicecode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
               "empty_mdmeventdate":false,
               "empty_smssent":true,
               "has_receiptimage":true,
               "locationcode":"1",
               "mdmeventdate":"2020-04-11T19:39:50.695Z",
               "mdmpersonid":"03642947956",
               "nsrcode":1447,
               "receiptimage":"BASE64_IMAGE",
               "receiptsentmode":"Nothing",
               "supervisorcode":"fe115382754247d883d9a11b88b3d96e"
            },
            "mdmMasterFieldAndValuesString":null,
            "mdmSkippedFieldIds":[

            ],
            "mdmSourceType":"PROCESSING_ENGINE",
            "mdmStagingEntityName":"33dd1190ff2c11e8858be609736e2a59_clockinprocessed",
            "mdmStagingRecord":{
               "clockinDatetime_date":"2020-04-11T19:39:50.695Z",
               "clockinImage_base64":"BASE64_IMAGE",
               "clockinNSRNumber_long":1447,
               "deviceCode_string":"55ef232c3221fbfd6d7c3cfb0ecf221f",
               "employeePersonId_string":"03642947956",
               "mdmConnectorId":"33dd1190ff2c11e8858be609736e2a59",
               "mdmCounterForEntity":58171,
               "mdmCreated":"2020-06-10T21:41:17.731Z",
               "mdmEntityType":"33dd1190ff2c11e8858be609736e2a59_clockinprocessed",
               "mdmId":"373c4cd5918ac598cd55a948a59bef56",
               "mdmLastUpdated":"2020-06-10T21:41:17.731Z",
               "mdmTenantId":"4c2c9090e7c611e893bf0e900682978b",
               "supervisorcode_string":"fe115382754247d883d9a11b88b3d96e"
            },
            "mdmStagingRecordString":null,
            "mdmTenantId":"4c2c9090e7c611e893bf0e900682978b",
            "mdmUpdatedUser":"",
            "score":null
         }
      ]
   },
   "mdmApplicationIdMasterRecordId":{
      "08d8618b6833437f99e8032ec08b9e54":[
         "48f217ef4c0256a655e15e3fc3fb34f4"
      ],
      "33dd1190ff2c11e8858be609736e2a59":[
         "6debe01c26ada1667b1dc5139a04998e"
      ]
   },
   "mdmApplicationIdStagingTypeMasterRecordId":{
      "33dd1190ff2c11e8858be609736e2a59_clockinprocessed":[
         "48f217ef4c0256a655e15e3fc3fb34f4",
         "6debe01c26ada1667b1dc5139a04998e"
      ]
   },
   "mdmCounterForEntity":1592599481019000,
   "mdmCreated":"2020-06-10T21:41:24.157Z",
   "mdmCreatedUser":"",
   "mdmCrosswalk":[
      {
         "mdmApplicationId":"33dd1190ff2c11e8858be609736e2a59",
         "mdmConnectorId":"33dd1190ff2c11e8858be609736e2a59",
         "mdmCrossreference":{
            "clockinprocessed":{
               "clockinDatetime":"2020-04-11T19:39:50.695Z",
               "deviceCode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
               "employeePersonId":"03642947956"
            }
         },
         "mdmStagingType":"clockinprocessed"
      }
   ],
   "mdmEntityTemplateId":"1e328c60fd8f11e8a4dce609736e2a59",
   "mdmEntityType":"clockinrecordsGolden",
   "mdmErrors":[

   ],
   "mdmFlaggedFieldIds":[

   ],
   "mdmGoldenFieldAndValues":{
      "appname":"clockinweb",
      "clockinmode":"1",
      "coordinatesaccuracy":0,
      "costcenters":[

      ],
      "devicecode":"55ef232c3221fbfd6d7c3cfb0ecf221f",
      "devicedescription":"REP 99 Robson Poffo",
      "empty_mdmeventdate":false,
      "empty_smssent":true,
      "eventdatestr":"2020-04-11T16:39:50.695-0300",
      "fakegpslocation":false,
      "gmt":"",
      "has_image":false,
      "has_receiptimage":true,
      "imagehash":"",
      "locationcode":"1",
      "locationdescription":"TOTVS Labs",
      "mdmemailaddress":"[email protected]",
      "mdmeventdate":"2020-04-11T19:39:50.695Z",
      "mdmname":"Robson Poffo",
      "mdmpersonid":"03642947956",
      "mdmphonenumber":"+14085079761",
      "mdmtaxid":"5311379100012",
      "nsrcode":1447,
      "piscode":"03642947956",
      "readphonestateenabled":false,
      "receiptimage":"BASE64_IMAGE",
      "receiptsentmode":"Nothing",
      "score":0,
      "selfclockin":false,
      "supervisorcode":"fe115382754247d883d9a11b88b3d96e",
      "supervisorname":"fe115382754247d883d9a11b88b3d96e",
      "updatedatetimeautomatically":false
   },
   "mdmGoldenFieldDetails":{

   },
   "mdmHasCdsMaster":true,
   "mdmHasCdsMerge":true,
   "mdmId":"d894e39df9c14771a102ce5cad80e54a",
   "mdmInheritedTenantIds":null,
   "mdmLastUpdated":"2020-06-19T20:44:41.021Z",
   "mdmMasterCount":2,
   "mdmMergePending":false,
   "mdmParentId":null,
   "mdmParentTenantId":null,
   "mdmPotentialMergePending":false,
   "mdmPreviousIds":[
      "44e6023ae3cc8e5b902ff454c912799e",
      "df824e658d3c378305217eee64ecfc3a",
      "b90008de1ee14e81a513481f82305a2b",
      "30b2358085584543b5067489efb511c0",
      "d7388a8fd78b4f51ae1dce84cfa24c02",
      "a2149ae483e4443da3e699d86529ce97"
   ],
   "mdmProfileTitle":"Robson Poffo 55ef232c3221fbfd6d7c3cfb0ecf221f 1447",
   "mdmRawCdsIds":[
      "df824e658d3c378305217eee64ecfc3a",
      "b90008de1ee14e81a513481f82305a2b",
      "d7388a8fd78b4f51ae1dce84cfa24c02"
   ],
   "mdmRelationshipPending":false,
   "mdmSourceEntityNames":[
      "33dd1190ff2c11e8858be609736e2a59_clockinprocessed"
   ],
   "mdmSourceOperation":"FETCH",
   "mdmSourceOperationTaskId":"9f6d95f87afd478995224ad6d80ed3c5",
   "mdmSourceType":"CDS",
   "mdmStagingCounter":null,
   "mdmStagingRecord":null,
   "mdmStagingRecordIds":[

   ],
   "mdmStamp":null,
   "mdmStampAttestationDate":null,
   "mdmStampAttestationHeight":null,
   "mdmTenantId":"4c2c9090e7c611e893bf0e900682978b",
   "mdmUpdatedUser":"",
   "score":5.752755
}