I recently implemented an Audience Manager integration in a Web 8 DD4T (.NET) project. I was scratching my head for a long time about an error message that didn’t seem to make sense:
Unable to determine the current Publication. Please make sure the Ambient Data Framework is running, or configure a DefaultPublicationId in the cd_audience_manager_conf.xml configuration file
All I wanted to do was retrieve and update Audience Manager Contact details, which are not related to publications, so it didn’t make any sense why I was getting this message. Some digging around in log files showed me that Audience Manager was executing GetPageMetaByUrl using a claim in the ADF containing the current request URL (taf:request:full_url) – then I started to realise what was going on…
In my MVC web application we remove the file extension (and sometimes filename) from the URLs, so /news/cat-bites-dog.html becomes /news/cat-bites-dog and /news/index.html becomes /news/. As these URLs do not correspond to actual pages in the CMS, Audience Manager cannot get the page meta, and then cannot proceed with processing the request.
Why is this? you ask… Well I don’t have a really good answer to that, suffice to say that it uses the page metadata to determine a publication Id, and then uses this publication id to determine the Audience Manager service endpoint to connect to (Peter Kjaer explains it in this Trex answer).
I guess this is a point for improvement in the next release, but in the meantime, all you need to know is that to get this working, you just need to override the taf:request:full_url claim in the ADF with a valid page URL – we used the homepage (as this will never be changed/unpublished).
The following code snippet shows how you can do this (the _configuration and _publicationResolver are DD4T-based objects to get the homepage URL – you can replace them with whatever you need, or simply hardcode a known URL).
That’s really nice know. Thanks Will, Peter and I recently had a lot of brainstorming with AM configurations.
This will indeed work, but you might run into other issues as that claim is added by the ADF itself and is expected to always point to the current URL. So if you always set that to a fixed location, anything that reads it will be affected.
For that reason, I think simply specifying the Publication URI in the AM configuration would be a safer in this case.
I agree that this has been a stumbling block for some people and so needs a bit of attention in the future. One such improvement might be to update the GetPageMetaByUrl method to work with partial URLs.
As for the reason why AM suddenly needs to know the Publication, that is because it now supports having multiple web applications on the same CD environment that are pointing to different subscription databases. For that, we thought it would be convenient if it used the already-selected Synchronization Target from CM rather than introducing additional configuration on the CD side. In hindsight we probably should have made that a more advanced scenario rather than the default, given the problems that people have experienced with this new approach.
Thanks for the insights Peter – the problem with using the publication uri in the AM config is that the web application serves content from multiple publications, so indeed the best solution would be to work with partial URLs (I think there is an API already for this in CD – as this is how DD4T/DXA do publication resolving from the context URL)
That’s really awesome blog. Thanks Will for this great article