One of the things that often catches new users of SAP Enable Now by surprise is that there is effectively only one environment. Content creators are often more familiar with a ‘Development → Acceptance → Production‘ system topology, where content is progressed through these three environments, and the Production environment is the only one seen by end-users. With SAP Enable Now, content is often developed, reviewed, QA’d, and finally consumed, all within the same, single Workarea.
What are Version Tags?
So how do you ensure that the user sees only the ‘published’ version of content objects, and not any draft versions of “objects, ‘or updates of previously-published objects that have not yet been finalized? The answer is ingeniously simple. When you publish a content object, you are effectively publishing the current version of the object. So even if that object is subsequently changed – which creates a new version – users will not see those changes, because the version containing the changes has not been published – only the previous version has. This gives us a simple rule: Users will only ever see the ‘published version’ of a content object, even if this is not the latest version.
Technically, SAP Enable Now achieves this by ‘tagging’ the current version of the object with the value published when you publish it. You can actually see this tag in the [Version] Tags metadata property, as shown below:
{Confusingly, there are actually two metadata properties named Tags – we are concerned with the one in the Protocol category, and we will refer to this as the Version Tags property, to distinguish it from the other (which is in the Basic Properties category).}
So, if this (published) content object is changed, a new version is created (automatically), and the published tag will disappear from the Version Tags property – because this new version has not been published. But the previous version has been published – and is still tagged as such. There are a few places you can see this, but the easiest is
in the Manager. Select the object, then click on the drop-down arrow to the right of the version information, and select Versions / Tags from the drop-down menu. A dialog box similar to the one shown below is displayed.
Note that version 3 is tagged as published. This is the version that users will see – even though there is a more recent version (4) on the server.
To complete the story, Learners typically only have the permissions to “View published content” (see the blog post Understanding Permissions for more information), and this is hard-coded to show only content objects tagged as published. You may also be familiar with using URLs that include the string “/~tag/published/” – this is specifically telling SAP Enable Now to “show only content tagged as published“.
Custom Version Tags
So far so much “internal to SAP Enable Now”, and normally you don’t need to concern yourself with the published tag – it is set and referenced by SAP Enable Now automatically. Thankfully, SAP is never one to keep a good feature to itself, and allows you to define your own tags that will work in exactly the same way. Before getting into how to do this, lets look at why you would want to.
One of the defining characteristics of Version Tags. is that each tag can only be applied to one specific version of a given content object. This is why you can only have one ‘published’ version of an object (see the example above). What this tag is effectively doing is identifying a specific version of a content object – or to put it another way, how a content object looked at a specific point in time – in this case, the point at which it was published – regardless of what may have been done to the object since.
Now, consider a scenario where you have staggered roll-outs of a software system. Say you roll out Release 1 of the system to your European users, and have built your training material to support this. The developers then update the software to Release 2 and roll this version out to North America. You want to update the training material to match this new release, but Europe isn’t being immediately upgraded to Release 2. Instead, they will stay on Release 1 for a while, and therefore still need access to the Release 1 version of the training material. You effectively need to keep two versions of the training material available to different groups of users.
Now let’s return to Version Tags, and see how they can help here. When you publish the training content for Release 1, you can tag it as being applicable to Release 1 (tag= r1). Then, even if the content objects are updated, users in Europe can still see the training material – and specifically at the update level that applies to them – by accessing it from a URL that contains the string “/~tag/r1/“. When you update the material for Release 2, similarly, you can tag the newly-published version for Release 2 (tag=r2), and users in the Americas can by access it using a URL that contains the string “/~tag/r2/“. Let’s look at how this works in practice.
Let’s say we have developed our content object above (Displaying a Sales Order) for Release 1, tagged it for Release 1, and published it (Version 3, below). We then changed changed it for Release 2, tagged it for Release 2 and re-published it (Version 5, below). Our Versions / Tags dialog box in Manager now shows the following:
Note that each ‘tag’ (Release 1, Release 2, published) is only used once – although, as you can see for Version 5, a single version of a content object can have multiple tags.
So now let’s see how this would look to users from the two implementations. First, here’s how our Library would look to our European users, who are using the ‘Release 1’ URL:
Note the /~tag/r1/ in the URL, and the Version History, which shows (only) Version 1, from 17 August 2020.
Now let’s see how the same object appears to users in the Americas who are using the ‘Release 2’ URL:
In this example, note the /~tag/r2/ in the URL, and the Version History, which now shows Version 1 and Version 2.
The important thing to understand here is that the content object (Displaying a Sales Order) has not changed between these two screenshots being taken – all that changed was the URL used to access it.
There are a couple of caveats with this approach. First, it’s important that only content objects that have been ‘published’ (at some stage, even if this has been superseded by a later version being published) should be tagged for display for a specific release. This is because you can only have one tag in the URL, and if we have a ‘release tag’ we can’t have the published tag in the URL as well. Second, all of the resources and other assets used by the content objects also needs to have the same tag – because the URL is specifically stating “show only content with this tag. (This is also true for the published tag. A common error for new Authors is forgetting to Publish the Resources folder, resulting in a ‘404 error’).
Defining custom Version Tags
So now we have seen what Version Tags can do, how do we define and set them? Interestingly, Version Tags are defined at the Workarea level. In Manager, go to Administration > Workareas / Tags, and click the Add Tag link. (You can change existing tags from the same screen. You can even change which version is tagged as published – that’s a useful trick to know!)
In the Add/Edit Tag dialog box, the ID is what will be used in the URL (so don’t use spaces or special characters), the Name is what the Author will select, and the Description is a short explanation of the tag. (Note: You can’t define a custom Version Tag with an ID of published because this is reserved and already used.)
Tagging content objects
There are a few different ways to set tags for a content object (version). You can do it via Manager in the Versions / Tags dialog box (see the first two screenshots above), but it is easiest done in Producer via the Change Workflow option (per content object or for an entire Group and its contents).
Click on the Edit button (pencil) to the right of the Set/clear tags field, and then select or clear the available tags, as necessary. Again, note that each tag can only be applied to a single version, so if you set a given tag for version 4 of a content object, the same tag will automatically be removed from any other versions of this content object for which it was previously set. You can see that it is also easy to remove tags if they are no longer needed.
Summary
Version Tags may not necessarily be functionality you will always use, but it is worthwhile at least being aware of its potential, in case you come across a scenarios where Version Tags could be helpful (in addition to the simple example given in this article).
