Impulse Dev Manual
HomePricingContact Us
  • Understanding Impulse Sync
  • Understanding how Impulse diffs content
  • Understanding Job Scheduling
  • Motation
    • Content Motation
    • Definition Motation
    • Domain Motation
    • Folder Motation
    • Language Motation
    • Relationship Motation
    • Tag Motation
  • Connectors
    • Source Connector
    • Destination Connector
    • Go Code
    • IDs
    • ID Mapping
    • Testing Controller
      • Implementation
  • Motators Binary
    • Implementation
    • Go Code
  • Services
    • Connector Depot
    • Motator Binary Depot
    • Job Depot
    • Endpoint Depot
    • Sync Manager
    • Content Diffuser
    • Pickup Taxi
    • Dropoff Taxi
    • Pipeliner
    • Scheduler
    • Motator
    • Motator Service
  • Watchdog Process
    • Watchdog flow
  • Impulse License
  • Troubleshooting
    • Job Config
    • Transaction Audit Trail
  • gRPC
    • Protocol buffer compiler
  • Test Commands
  • Glossary
Powered by GitBook
On this page
  • What is ID Mapping
  • ID Map Tag
  • Parent ID Map
  • Using ID Maps
  • ID Maps During Sync Process
  • Replacing IDs
  • Returning ID Maps
  • Diff Reporting

Was this helpful?

  1. Connectors

ID Mapping

What is ID Mapping

ID Mapping is a term used to refer to how Impulse handles changing an ID from system A to the appropriate ID in system B.

ID Map Tag

In the Motation structs, ID attribute require the idMap tag to use content diffuser’s ID maps. The ID map tag is formatted using json dot value notation. I.e.,

idMap:"content.version.field.value.relations.childIds,parent=content.id"

Parent ID Map

When an ID attribute matches another ID attribute, such as a relationship to a content ID, the ID map tag requires a parent value. In the above example, the childIds attribute has a parent ID of content.id. The parent ID is the ID map that should be used to replace this ID attribute.

Using ID Maps

The Motator service is the gateway to using ID maps. GRPC is used to communicate with the monitor service to upload or download Motation. This will save initial ID maps for a source system (upload Motation) or replace ID values using ID maps for a destination system (download Motation).

ID maps are stored by content diffuser. The Motator service requests and sends ID maps to the diffuser to handle. Taxi dropoff also returns ID Maps to diffuser to update ID maps after an object is synced.

ID Maps During Sync Process

Replacing IDs

During the sync process ID maps are used before the transformer out connector binary is called. This way all ID values in motation are replaced with the appropriate ID. Then the motation is transformed into raw data with the replaced IDs.

Returning ID Maps

ID maps between systems are created by returning the IDs after syncing an object. In the adapter write, each function to sync an object returns specific IDs related to that object. Each returned ID map should include the previous ID, the ID that was passed into the transformer out connector binary, and the current ID, the ID that is saved into the system. If no ID maps are returned then nothing changed.

Diff Reporting

For diff reporting to work properly, the id map returned, must match the id sent to the content diffuser. Meaning, if a unique ID was generated by combining content type and content ID, that same ID must be returned as the ID by the adapter write.

For examples, view Strapi 3 or Strapi 4 connectors or Contentstack connector.

PreviousIDsNextTesting Controller

Last updated 2 years ago

Was this helpful?