AEM Podcast: Adobe Target Demo Technical Issues

Adobe contracted with Axis41 to create a microsite (adobe-target.com) and a demo of the Adobe Target product (demo.adobe-target.com). We faced more than a few challenges to get this setup and working effectively. Peter and Joey sit down with the primary developer on the project, Adobe Certified Expert Nicholaus Chipping, to discuss some of the challenges faced with overlaying a step by step demo on top of the actual Adobe Target tool.

You can also check out a video spotlight that Stefan Hofmeister created that showcases the demo.

Transcript:

Welcome to Adobe Experience Manager Podcast, a weekly discussion regarding Adobe Experience Manager, formerly CQ and other marketing and technical issues. This podcast is presented by Axis41, your partner in Adobe Experience Manager Implementations. Your hosts for the podcast are Joey Smith and Peter Nash.

Peter Nash: Good afternoon everyone and welcome back, I am Peter.

Joey Smith: I am Joey. Today we’re going to jump into the topic of Adobe Target.

Peter Nash: Yeah, we wanted to share with everyone the work that we have done recently for Adobe on the Adobe Target product and to give some background, we were originally approached to create a microsite and a demo of the new Adobe Target tools. The microsite is adobe-target.com and is a typical one-paged site, it’s just marketing stuff that’s on there, and for the demo, originally we were asked to create something simple that took people through the steps of the new Target tool, that demo was really just a few screenshots, that had buttons overlayed to give the appearance of a real tool. This was because the real product wasn’t actually done yet, but eventually they did have a released version of it and they asked us to create a more realistic walkthrough. So, Adobe provided us a code based to work through and we began the task of overlaying our original simple demo to the actual real tool.

Joey Smith: Yeah, wiring it all up as it were.

Peter Nash: Right, this was a unique process and we had to update our demo a few times as they released new versions of the code base.

Joey Smith: Yeah, and it helped us talk about the work that Axis41 did for this; we are joined by the primary developer who worked on the project, Adobe Certified Expert, Nicholaus Chipping. Nicholaus, welcome to the podcast, glad to have you on.

Nicholaus Chipping: Thanks, Joey.

Joey Smith: Can you give us just a little bit background about yourself?

Nicholaus Chipping: Yeah, so I have been coding for about six years now. I have done a few different languages started with basic HTML and CSS and went on to PHP and JavaScript. Now I have worked primarily on Java and I have been working on the Adobe Experience Manager platform for about two years.

Peter Nash: Yeah, I had known Nicholaus for probably about four or five years now. He and I worked at the previous location so he and I are very familiar with each other, we have been doing this a long time so he is a good developer and I am glad that we have him on our team. One of our project managers here at Axis41, Stefan Hofmeister actually did a video spotlight of the demo system that you can find on our website aempodcast.com. We will actually include a link in the blog post for that and I would urge you guys to go and check that out because it actually just shows you the tool itself and how or what you can do inside of it. It is the front end user perspective rather than the developer perspective that I would like to get into today. So why don’t we actually jump into discussing some of the technical challenges that we faced on this particular project. Nicholaus, what would you say is the biggest difficulty that we faced?

Nicholaus Chipping: Probably the biggest difficulty was integrating with their system.

Peter Nash: Okay, so when you say integrating with their systems, what exactly do you mean?

Nicholaus Chipping: Basically, we had to go and look through all of their code and understand how their current systems were working because they had built on top of JavaScript library, already they had built their own system that had a lot of interconnecting parts, so then along with that we had to tie our code into it, so there is a lot of “figuring it out”, I guess that is what I would say.

Peter Nash: Yeah, and aside from what you mentioned I mean there was the initial, how can we get the code package from you guys and there are all sorts of hoop jumping that comes with working with a larger organization, I am sure we have all had to deal with that in the past, but then realistically was getting in there and saying how do they do things so that we can kind of strip it apart and overlay our portion on to it, right.

Nicholaus Chipping: Exactly.

Peter Nash: Now in this demo, we are actually inside the Target system, how did we manage to get in?

Nicholaus Chipping: So the Target system the difficulty with that…

Peter Nash: When I say Target system, I really should probably say the Target product.

Joey Smith: The product: Adobe Target.

Peter Nash: Yes.

Nicholaus Chipping: Yes. So, that product was difficult to allow a front end experience through because it’s meant to be in an author environment and for people who may not know about CQ or Adobe Experience Manager, an author environment is only meant for authors of the site.

Joey Smith: Kind of trusted users, right.

Nicholaus Chipping: Yeah, because they control a lot of things that go on in the site, they can potentially really screw something up if they don’t know what they are doing or if they are being malicious I guess, but we had to have an automatic login system and just do a lot of different security things in this instance.

Peter Nash: Right and I think the person we use was the Sally Social user, right?

Nicholaus Chipping: Correct.

Joey Smith: Is that just a demo user or is that…?

Nicholaus Chipping: That specific user has different group privileges to allow them to for instance: in the Target demo, they can create an activity and go through, put their website in and test different text on their website, different images and that user had those specific privileges which is why we use that user to auto login with.

Peter Nash: Right, because we are getting in authoring environment, so if you go to demo.adobe-target.com, this is where you will actually see that. The front end user, the person who is coming to the site isn’t actually having to log in as Sally Social themselves, that was one thing we were very reticent to make them have to log in as someone, we wanted that to just automatically get done, and so that’s what you did, right, you spent a lot of time getting that automated system to just log them in directly and not leave it open to anybody else to potentially come through and try and log in as something else.

Nicholaus Chipping: Yeah.

Peter Nash: So, with this being an actual authoring instance that people are messing around with its front-facing to the internet world and while I know that we are not going to get a ton of traffic to this particular site, we are effectively treating this like a normal website; Which means that there could be issues of load as well as security, so Joey how did we overcome that?

Joey Smith: It is not unusual in an Adobe Experience Manager author environment to put what they call “the dispatcher” in front of it. In fact, as you go through the Adobe documentation, there are specific options that would guide you through how to put the dispatcher, which is a caching proxy server, to put that in front of an author. But as we looked at that we said we don’t want to just follow that guideline because we want things really tightened down, we don’t want people for example to be able to sit there and try and guess usernames and passwords. We want to force them to use a given username and password, so there were components that we had to identify was: “Well, we need to lock down these additional paths.” One of the primary tasks that we did is, we worked very closely with Nicholaus as on the server administration team to define a very tightly defined whitelist of URLs that are allowed and anything not in that whitelist gets rejected. Normally, in an authoring environment you are a little more permissive with your filtering, because you kind of like: “Well, who knows what path they are going to create and going to need that they will be able to reach?” In this case, we wanted to keep those locked down, but we still had to allow all the different parts of what they called the WCM or the authoring environment to still filter down through so that the environment is still interactive for the user.

Peter Nash: Yeah, I remember that going through that process of trying to lock down those URLs because sometimes you may went little too far, sometimes….

Joey Smith: Yes, it was definitely what I call a highly iterative process because we said, “Oh, we are going to do to this.” and he [Nicholaus Chipping] would come back to us, “Hey, this other page way deep down in workflow broke all of a sudden.” “Okay, let’s open that… Oh, Uh oh, that opened up things we didn’t mean to open up!” We also leaned really heavily- this is deployed in our Amazon Web Services Environment- and we leaned really heavily on the security restrictions that AWS provide to us in order to say well we can create secure snapshots to this machine and we can roll back to this at any given point in time and things like that.

Peter Nash: Okay, cool, thanks for going through that. Nicholaus maybe you could take a minute or so and just kind of explain how the normal Target tool would work. I know we were kind of, I don’t want to say hijacking the system, but we kind of are in a certain way and I will have you explain that but how does Target normally work. What would someone have to do in order to have this Adobe Target product on their site with these new tools?

Nicholaus Chipping: Sure. As far as I understand, essentially people would obviously have to an account but then they create different pages, say A/B testing pages for their site and then they will get a snippet of code from Adobe and put that on their site and then that would call back to Adobe and based on different information it would serve up either A or B and then there is going to be analytics behind that that they can look at for that way they can see which is performing better, but that’s kind of a typical experience- What we did is a little different.

Peter Nash: Yeah, so I imagine we can’t just ask everybody on the internet to go ahead and put this piece of code on to their website, what would we end up doing to kind of circumvent those, how did we get this because this is a very real thing, the tool will allow you actually put in a URL and have that site load, how are you doing this?

Nicholaus Chipping: We built a scraping tool basically, so when someone comes to the demo they get to a point in the demo where it’s time to put in a URL and then they put in the website URL that hits a servlet of ours that goes out and gets all the HTML, CSS and JavaScript references and then provides that back to the renderer, so then it essentially renders whatever site they put in, in that frame and from there we can edit and change things and they can essentially see some A/B examples and do it on the fly right there.

Peter Nash: Yeah, and we should mention that it’s not 100 percent perfect, there are certain sites that aren’t going to work, a matter of fact Adobe came back to us that is rather interesting and said, hey, these are a couple of our customers, some of our big customers, their pages are not quite loading exactly right in your screen scrape, can you make some adjustments and so we did, we had you go through that but there are certain sites that just may not load very, very effectively off the top of my head I think some sites that are just pure flash, will have some issues although I know you worked on a site that had flash loading on it so it did eventually get working correctly for us, but it’s not 100 percent perfect. We are, I don’t want to say hijacking the system, but we are kind of circumventing a lot of things in order to get this to work, to give people the experience of how they would use the Adobe Target tool.

Nicholaus Chipping: Yes, exactly.

Peter Nash: All right, I happened to know because I have been working with the people over there at Adobe that they are not actually done with the new Target tools, they are adding more and more on to them. I was wondering maybe you could tell us what’s coming down the line a little bit for additional features, I know we can’t really release too much but maybe we can mention a couple of things.

Nicholaus Chipping: Sure, currently they just have A/B testing as part of the demo. One of the pieces that I have seen that’s coming is the experience targeting and multiple audience targeting, so in the current demo with the A/B testing you can only, say, okay we only want Chrome users to see this sort of thing but in parts of the new tool, they will be able to say Chrome users and IE users or they have all sorts of different audiences that you can select from or even make audiences that you want to approach with the demo.

Peter Nash: Yeah, it’s interesting that you mentioned the audiences because with this tool being front-facing anybody could go in there. I know there is some concern with the audience list that was in there and we had to do something special to that audience list, did we not?

Nicholaus Chipping: The audience list and even the primary list that shows up activities when….

Peter Nash: Right, so to say the activities that people do, right?

Nicholaus Chipping: Yes.

Peter Nash: There was a concern that those activities some “well-intentioned-troublemaker” out there could go through and create some names of words then that would end up showing on this Adobe themed website, what did you end at doing for that?

Nicholaus Chipping: Initially, we just created a different ordering so that I always ordered the list to always show the oldest first which when someone is creating a new one they have no control whatsoever to say that this was created at a past date. So that covered us there. We ran into issues later with just how many people are using it and it constantly growing that we also created a script in the backend with the help of Joey’s team to go through and delete old activities, or new activities -I should say, every so often so that it didn’t build up and also just to make sure that the sorting working quickly and effectively for people going to the site.

Peter Nash: Right, because what was happening is exactly filling up the disk on the server, right?

Joey Smith: We did have, in initial launch we had a couple of problems with disk getting full too fast.

Peter Nash: Yeah, so we were able to sort that out thankfully, and it’s been a much smoother process now that we’ve made all those adjustments, we don’t see any of the awkward words that might get used on the internet and it looks very, very good.

Joey Smith: Okay, I think that’s it for our discussion at the demo.adobe-target.com website. Nicholaus, thank you for joining us, and thank you for all the hard work on this project.

Nicholaus Chipping: You’re welcome.

Peter Nash: Thanks for listening to the Adobe Experience Manager Podcast brought to you by, Axis41, your premier partner in AEM Implementation. If you have questions, comments or something you would like us to cover send an email to info@aempodcast.com