Mapping Metadata

Transcript

Let’s take a look at how we can map metadata using the Adobe Workfront and Experience Manager Assets Essentials integration. And what this lets us do is select Workfront fields and map them to asset properties in Asset Essentials. So when a Workfront document is sent to Asset Essentials, the values for those met fields are sent along with the file itself. Let’s jump right into it. The first thing we need to do is make sure we’re logged in as a Workfront system administrator. And then in Workfront, we’ll head over to the main menu. Tap setup, and in setup, we’ll navigate to documents. And in that, Experience Manager. And this is where we set up the Workfront and AEM Asset Essential integration before. And as you can see, our active AEM Asset Essentials integration is listed. We can select it, and tap edit.

Scrolling down, we can see this is where the metadata mapping is defined. When we first configured this integration, we added these three fields. But now, let’s go through and do a deeper dive into metadata mapping. So the left column represents the Workfront field. And the corresponding right column is the Asset Essentials property name that the Workfront field is mapped to. So looking at the first row, which maps the project name. Anytime a Workfront document is sent to Asset Essentials, whatever value is in the project’s name field in Workfront will be synced into the WM:projectName property in Asset Essentials for that specific asset.

We have two other metadata mappings already defined. One for the document ID, and another for the document’s Campaign season, which happens to be a custom property. We can, of course, delete any existing mappings. So let’s go ahead and try that and delete the last two. And now you can see they’re gone. But let’s go through and add some more metadata mappings. And we’ll talk about some of the concerns and nuances as we do each one. First, let’s add the project description to sync over. So we can add a new field. And we can, of course, browse all available fields, even custom. Or what I find useful is to search for the field. So we can start typing a description, and the results will narrow down all fields in Workfront with description in the name. So let’s pick project description. And over on the right, we’ll pick the Experience Manager Asset Essentials target field. So this lists all the available fields that we can map to. And as we scroll down, you can see there are quite a number of these. You’ll notice the format of most of these Experience Manager fields is a namespace, colon, and a property name. A namespace is essentially a grouping of a well-defined set of properties. So there are common industry standard namespaces, such as DC, which stands for Dublin Core, which defines about 15 properties. And each of those properties have a well-defined semantic meaning by the Dublin Core spec. Likewise, there’s the XDM namespace, which is the Experience Data Model. Dam, which is a namespace defined by AEM assets. As well as WM, which is a namespace that represents Workfront metadata. As we scroll through this list, we come upon the set of WM namespace properties. And within this namespace, we see a property name project description. So that seems like a good candidate to store our Workfront project description into. So let’s go ahead and select that. Let’s add another mapping and this one for the Workfront document name. So again, we can simply search for name. Select name under document. And now again, we can select the corresponding field to map it to.

So let’s go ahead and just type in WM, which will jump us down to the WM namespace properties. Which, again, is a namespace that represents the commonly mapped Workfront fields. And let’s see if we have a document name in here. And sure enough, we do. So let’s go ahead and select that again.

Next, let’s add the Workfront document’s description. So again, we’ll go ahead and search for description. Select description under the document. And now let’s create a mapping. So let’s first check if the WM namespace has any options for us. And looking through the available properties, it doesn’t look like there’s a semantic mapping here. So this is where we can start looking at some of the other namespaces, to see if they seem viable to store our Workfront data. Let’s head up to DC or Dublin Core. And sure enough, there’s a DC description. So Dublin Core defines the semantics of the description property to be an account of the resource. And it may include, but is not limited to, an abstract, a table of contents, a graphical representation or a text based account of the resource. So this sounds like a pretty good fit for the Workfront document description. So let’s go ahead and map to that. So next let’s map the document owner. So we’ll search for owner. Select owner ID, and select the field to map to. Again, we’ll start with WM namespace. And you’ll see that we have a WM document owner name property, which seems pretty close. So we’ll go ahead and select that for now. And keep this mapping in mind, since what we did here was map the owner ID to something called document owner name. And usually, the ID and a name are not semantic equivalents. And we’ll see the effect of this at the end of the video. But for now, let’s move on and add a couple more properties. Next, let’s add the document type.

And again, this is a property that doesn’t have an equivalent under the WM namespace. So let’s go ahead and use dc_type to store this data.

Next, let’s map the document ID. And since we want to use our document ID as the canonical ID for this asset, let’s map it to the Dublin Core identifier, which is intended to act as an unambiguous reference.

Next up, let’s map two custom Workfront fields. So the first one will be a documents cost. And since it’s a custom Workfront field, it’s unlikely there are equivalents in the WM namespace. So here, I’ll use the cost of goods or cogs property under the XDM namespace. And lastly, let’s add our custom Campaign Season Workfront field. For this, let’s start typing in Campaign to filter our options.

And as you can see, the XDM namespace has a handful of options for us. Now, none of these options directly map to a Campaign season, but there’s certainly leeway when making a mapping. And it’s generally find to mapped properties that have the same conceptual meaning. So for our WKND brand, the Campaign season is roughly equivalent to the Campaign name. So let’s go ahead and select that field. Okay, I think that should be good and represent a reasonable sampling of Workfront fields that can be mapped to Asset Essentials assets. So before we leave this screen, I want to note that it will be very important to understand this mapping for when we configure Asset Essentials, as we’ll be specifying what metadata to display using the Experience Manager target field name.

Okay, let’s go ahead and save these changes real quick.

Before we jump over to Asset Essentials, to configure it to display this mapped metadata, I’m going to quickly send a Workfront document with existing metadata over to Asset Essentials so we have something to look at.

So let’s go ahead and push our Winter Campaign poster. And as you can see, we have a document description.

It has a custom form with our custom fields of cost, as well as Campaign season. And it has all of the system fields populated by Workfront as well. So let’s go ahead and send this Workfront document over to Asset Essentials.

Let’s put it in the Winter Campaign folder.

And there we go, we pushed it over. So now, let’s jump over to Asset Essentials.

Let’s double check that the Workfront document was sent over, and it looks like it was. So before we get into configuring the metadata forms in Asset Essentials, I want to call out the type of this asset. So down at the bottom, we can see that it is a jpeg image. And this is important to know because when we go into settings, metadata forms and create a new metadata form, that will display the mapped metadata. We have to name the new metadata form, based on the Asset Essentials asset’s MIME type. To understand how metadata forms are applied to assets, let’s jump over to our whiteboard. So the way Asset Essentials decides which metadata form to use for each asset, is by matching the asset’s MIME type to the metadata form names. So first, it’s important to understand that a MIME type is broken up into a type, followed by a subtype. So for example, a jpeg image’s MIME type is image/jpeg.

With image being the type and jpeg being the subtype. The way Asset Essential resolves which form to use, is by first looking at the asset’s subtype and seeing if there’s a metadata form with that same name. If there is, it’ll use that. If it can’t find a metadata form that matches the subtype, it will then try to find a metadata form with the same name as the asset’s type. And of course, if it can’t find that, it falls back to the system default. So let’s take a look at a couple of examples here. So first, let’s look at how assets with the MIME type of image/jpeg would resolve, based on our list of form names. So first, it would take the subtype of the asset, which is jpeg, and check if there’s a metadata form with that same name. And there is, so it would resolve to that. Now let’s look at image/png. This would attempt to resolve the same way. So it would look for any metadata forms with the name PNG, which is the subtype. And it wouldn’t be able to find any. So then I would check if there’s any metadata forms that match the type, which is image. And there is, so that’s the metadata form that would be used. The resolution of the application/PDF MIME type would happen the same way. Asset Essentials would check if there’s a metadata form with the name that matches the subtype, which is PDF. And there is, so that’s the form that would be used. So lastly, let’s look at the video MIME type. When resolving the form for this, Asset Essentials would first look for a form name mp4 . And since there is none, it would then check for a form named video. And again, based on our lists, there wouldn’t be a match. So in that case, it would fall back to the system default. So now that we know the logic behind naming metadata forms, let’s go back and create ours to apply to all image assets.

So we’ll name it image, so it matches using the image MIME type’s type. Let’s tap, use existing form structure as template. So this allows us to start our new form from an existing metadata form. We’ll build off the default template. But if you notice, you can see that the other available forms are named by either the MIME type type or MIME type subtype. But let’s select default and create our new metadata form.

This will take us to the metadata form editor. So let’s jump in and add our new mapped metadata fields. We can click through the existing tabs that we copied from the default template. So basic, advanced and tags. We could add our fields there, or what we can do is add a brand-new tab. Let’s do that.

We’ll name this Workfront.

And now we can start dragging and dropping components in. So let’s first add the project name. So we can drag a single line text component in, since the project name is a single line.

We can give it a label. And then we need to map to a property. And this is why, before we saved our amended data mappings, I said it was important to remember which Experience Manager fields we mapped Workfront fields into. Opening this drop down shows all the available properties or fields in Asset Essentials. So since we matched the Workfront project name to the WM:projectname property, we need to find and select that. Quite often for metadata mapped from Workfront, you’ll want Workfront to act as the canonical source for that metadata. So what we can do is check Read Only to ensure that no one’s changing this data in Asset Essentials on this asset. And this is typically a good idea for any mapped field. Okay, let’s go ahead and add our project description. And for that, we can select a multi-line text. Just like before, we’ll add the label.

And we need to find the property. Instead of scrolling through the big list, we can always use auto-complete. So we can start typing in project description. And there we go, we have our WM: project description property.

We’ll select that. And for all these Workfront metadata fields, we’re going to make them Read Only since we want Workfront to act as the canonical source for those values.

Okay next up, let’s add the document name and select WM: document name.

Again, make it Read Only.

And next up is the document description. And if you recall, this was the first mapping that didn’t have a semantic equivalent in the WM namespace. So we ended up using the Dublin Core’s DC: description. Now this one’s a little bit more interesting, because if we head over to the basic tab that was provided by the default template and select the description field, we can see that this metadata form component is already mapped to DC description. We could, of course, display this data on multiple tabs or we could pick one place to display it. So let’s make the choice to only display it, here on the basic tab. But because this is a mapped metadata field from Workfront, we don’t want anyone to change it. So let’s go ahead and make this Read Only.

Let’s avoid any confusion and add some placeholder text here in case it’s empty and someone tries to edit it. All right, let’s head back to the Workfront tab again. And we can go ahead and delete the document description component that we configured before.

All right, next up is the document owner.

Give it a label and select the map property.

We’ll make this Read Only. I’ll quickly go through and add document type, as well as document ID.

We can now display the values from the two custom Workfront fields, document costs as well as the Campaign season, which are both stored in properties under the XDM namespace.

All right, we’re almost done. Let’s take a look at one or two other things. The metadata form editor also has the Accordion Container, which allows us to group fields. So if we wanted to, we can make an accordion that represents project fields. And we can drag the project related components into that accordion.

We can always preview our form to see what it will look like.

Note that we only use the text components to display our metadata. However, there is a number component as well as a date component, if you’re mapping metadata that contain those data types.

And once we’re satisfied, we can save it.

All right, now with our new form saved, let’s head over to the asset we sent over from Workfront.

Opening its details, we have the metadata form on the right. As you can see, it as the Workfront tab in the top right. It also has the description of this asset. So it has the WKND Awaits verbiage. And if we click into the Workfront tab, you can see we have our project information in our accordion at the top.

As well as all the other mapped information down below.

So I do want to remind you that we originally mapped the document owner ID to the document owner name property. And as you can see when we actually display this, it is in fact displaying the owner’s ID, which probably isn’t particularly useful to users of Asset Essentials. And I just wanted to use this example to highlight the importance of understanding what data is flowing out of Workfront into AEM. As well as ensuring that the Workfront field and the Experience Manager fields are semantically equivalent. Since if they aren’t, it can often end in confusion when defining the metadata forms in Asset Essentials.

All right, I hope this gives you all the information you need to start mapping your Workfront fields to Experience Manager Asset Essentials properties. -