Why Do We Need Data Integrations?

If you're familiar with data integrations, you're probably impressed by the number of different integrations that ProfileSync can handle, and by the fact that ProfileSync can handle these integrations so seamlessly. If you're not familiar with data integrations, then maybe you aren't as impressed. After all, at heart, a data integration involves copying data from one data store to another. How hard could that be?

In theory, maybe not hard at all. In practice, however, copying data from one system to another runs headlong into a major problem: there is no universal standard for storing user data. Consider a simple example. An Identity Cloud user profile includes these attributes:

Attribute Value
givenName Bob
familyName Jones
displayName Bob Jones

Now suppose that your target API includes these database fields:

Field Value

Admittedly, most people have little trouble figuring out what needs to be copied and to where; for example, the Akamai givenName attribute seems to correspond to the first_name field in the target API. Computers, however, need some help in a situation like this: computers need to know how to map Akamai attributes to target API database fields. That's where ProfileSync comes in. When a user profile is changed, Akamai notifies ProfileSync that a change has been made. ProfileSync determines what exactly has been changed; for example, ProfileSync might determine that user Bob Jones has changed his givenName to Robert and his displayName to Robert Jones. ProfileSync consults its data map for your backend system, then contacts the target API and uses standard API calls to update the first_name and the full_name.

That's known as a "simple transform," because there's a simple one-to-one correspondence between Akamai attributes and target API database fields: the givenName attribute equals the first_name database field. But that's not all that ProfileSync can do; the application can also carry out more-complex transforms. For example, suppose your user profile formats the displayName attribute like this:

Bob Jones

Meanwhile, the full_name field formats data like this:

Jones, Bob

As you can see, there's no simple one-to-one correspondence here: you can't just copy the givenName attribute and paste it into the first_name database field. Instead, you must do a more complex data transformation; for example:

familyName + ", " + givenName

Can ProfileSync handle complex transformations such as this? Do you even need to ask? That's the kind of capability that makes ProfileSync so flexible. And so useful.