The Loop

Picture the scene: Im sat in my chair, working away and then I get a fairly crazed phone call from a co-worker in sales – he apparently has this stunning new idea about how to leverage twitter as a marketing platform…

As most of my readers are technical (yes, thats you there) I wont labour the marketing peice, but if your interested, David wrote a really nice article explaining his concept about what happens when social media meets cross-media; find it over here

A cunning scheme indeed

So, from the off, this was going to be an interesting campaign to put together because there were numerous issues, including:

• Lots of concurrent (and asynchronous) read / write ops to Twitter API
• Backend communication to XMPie cluster
• Push production status back down to the browser
• Downloading of avatar images automatically from twitter and insert into XMPie asset source
• Doing any of this in the given time frame!?

This project was going to have a sizeable set of works attached no doubt to manage the interplay between XMPie systems and the Twitter API.

Technology Sandwich

To implement this campaign, I ended up using a whole bunch of different technologies… The implementing stack eventually ended up utilising the following:

• Lift
• Dispatch
• Scala Actors
• XMPie uProduce
• XMPie ICP
• Microsoft SQL Server

In earlier drafts of this article I tried to explain the interplay between components, but simply could not find a good way to articulate the meaning. To that end, I hope diagram gets the structure across sufficiently!:

As you can see – quite a number of software components here! I’ve been working with Scala and XMPie uProduce for quite a while now and have built up some very nice abstractions that completely hide calling of services under the hood.

This entire campaign was implemented based on top of ICP, using my Scala abstraction along with the awesome power of Scala Actors, scheduling and some generally very cool libraries like Dispatch

Questions

A few people asked me to write this post, but as im not sure what specifically you might have been interested in, if you want to know more about how its put together, what does what etc then I would gladly take questions! Just leave a comment at the bottom and i’ll get back to you…

Its been a long time since I posted my original application for iPhone – iDashboard – to control XMPie uProduce on the move. I’ve been busy with a bunch of other cool stuff and in the run up to the annual XMPie Users Group meeting in Las Vegas decided to make Marketing Console for iPhone!

The application syndicates reporting and analysis information about your campaigns and lets you see the latest up-to-date charting / figures wherever you are. Currently, the application is using an internal R&D build of Marketing Console; so right now you’ll have to wait before you can monitor your own campaigns on the move!

If you have feedback, just leave a comment at the bottom of the article. Enjoy…

I have recently been working on some API automation for XMPie uProduce and after some head scratching, realized that the username paramater has now changed format.

Previously, you only needed to provide a username and password on api methods, however, in the new version it is important to include your customer name in a windows AD format. For example, if your credentials were:

Customer Name: ABC
User Name: badger
Password: 123456

You would need to present the username in your API call like so:

ABC\badger

I hope this save someone, somewhere, some time!

Readers of my blog will know that I love macs. Absolutely anything to do with Apple interests me; to that end, it will not surprise you that I have been doing some iPhone development.

For kicks I decided to write a mobile XMPie Dashboard application which would let you control XMPie uProduce whilst out and about. Whilst this is a sheer technology demonstration, its fairly functional and a great example of how with the right knowledge and skill, absolutly anything is possible within the XMPie toolset.

Below is a quick screencast demonstrating the application in all its glory!....

Im interested in your thoughts, so please comment below if you feel so inclined…

As a number of you are aware, I have spent quite a bit of time wrestling with XMPie uProduce SOAP API with the CXF service framework in Java. I finally (and with quite a lot of disappointment on my part) gave up trying to get that to work. CXF just does not want to play nice and I cant seem to make the XJB bindings work correctly with it and the mish-mash WSDL coming from uProduce

Anyway… with that rant over, I tried to be objective and switched to using Metro – ok, out of the box I still had a whole heap of problems, exactly as I did with CXF. However, I have managed to wangle it!

Step 1

You will need access to an XMPie server with the API’s installed and working. For the sake of this example i just wget’d the WSDL file so the generation code was not so bloated.

Step 2

You’ll need an XSD XJB binding file which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" 
          xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
          version="2.0">

  <globalBindings>
    <xjc:simple />
  </globalBindings>

  <bindings scd="~xsd:complexType">
    <class name="ComplexTypeType"/>
  </bindings>

  <bindings scd="~xsd:simpleType">
    <class name="SimpleTypeType"/>
  </bindings>

  <bindings scd="~xsd:group">
    <class name="GroupType"/>
  </bindings>

  <bindings scd="~xsd:attributeGroup">
    <class name="AttributeGroupType"/>
  </bindings>

  <bindings scd="~xsd:element">
    <class name="ElementType"/>
  </bindings>

  <bindings scd="~xsd:attribute">
    <class name="attributeType"/>
  </bindings>
</bindings>

Save this as xsd.xjb (or whatever you like, just make sure the name is reflected in the command below)

Step 3

Actually generate the code! Your command might look different, but heres mine:

  wsimport -b http://www.w3.org/2001/XMLSchema.xsd \
    -b src/xjb/xsd.xjb \
    -keep \
    -s src/java \
    -d target \
    -p com.xmpie.wsapi.icp \
    src/wsdl/InteractiveCampaign_SSP.wsdl

You should then see something like the following in your finder (or other OS file browser if not on mac):

These are the class files created for the InteractiveCampaign WSDL – all 128 of them!

Anyway, I have run out of time for today, but will try and get another blog up soon about how to use this in a client application from a java CLI.

Whilst at Drupa I was lucky enough to get a back room showing of what Creo will be releasing in Q4 of 2008 and into 2009.

The first impressions are really great – the native UI (Cocoa on OSX and .NET windowing on WinTel) means that no matter what your platform you get widgets that you are familiar with and work seamlessly with the operating system. That really is quite a differentiator when compared to competing products, and one that I am sure a lot of people would welcome as even from personal experience, quite a number of other solutions are using SWNG, or, god forbid, AWT in Java which are clunky and just not up to the modern users expectations.

Plugins

One of the things that really is very good about Darwin is the plugin system they have devised. Whilst I currently have no information on what inner complexities one might face with implementing your own plugin, the architecture I was shown looked very open, and very friendly – which is a massive plus point in my eyes.

Performance

Darwin was awesomely quick too – speed and beauty in the same package! Eliot Harper has blogged some very nice performance testing between XMPie uDirect and Creo Darwin which can be found here

Integration

Creo have changed the way in which the Darwin working environment is persisted – its now a separate DVJ file. This means that when working with InSite, the system can automagically create the darwin files for you. I’d go out on a limb and say that if InSite is able to create those files, then any other system you might want to write would also be able to generate DVJ files – this could really create some interesting options for mash-up style workflows!

What About The Cons?

Ok, so all products have there cons – thats life – at the moment Darwin only supports flat file data-sources. Perhaps that will change over time, but we’ll see I guess. Release is quite some time off so who knows what those guys might come up with!

Kudos Creo , this really is great work.

Another interesting article about Darwin and InSite can be found here

Just a quick note that I have refactored the code base for the XMPie ICP extension for Merb 0.9.2 and added some extra cool things that are inherited by the ICP subclasses.

Now, its possible to add validation into the model subclass. Lets say we have a feild defined in our uPlan called ‘email’ and ‘user_name’. I need the ‘user_name’ field to be required, which you can now do like so:

class Visitor < Xmpie::Icp::Base
  validates_presence_of :user_name
end

# in your controller...
@visitor.valid? # => true if has a user_name, otherwise false

All exciting stuff! When XMPie make ICP a more viable persistance tier, then this will no doubt be the quickest and slickest way to implement front ends in. Furthermore, with the Engine Yard team working on mod_rubinus then we should see ruby web application performance finally get where it needs to be.

I think that pretty much all the ‘Personalised URL’ jobs that I have ever needed to do have always been of the directory style, e.g:

www.domain.com/mylovelyusername

However, it strikes me that a better and more programatically favourable format is the sub-domain pattern, e.g:

mylovelyusername.domain.com

In this instance you don’t have to worry about holding information in sessions, or setting up anything else complicated to make sure that they visit that URL first – it doesn’t matter with the sub-domain pattern as you always have there unique identifier to hand in the URL. Im not wholly sure why it is that more people don’t see the benefit of doing this – if you ask me it ‘feels’ more personal that a one time visit to a directory style URL.

Check out these awesome personalized video's which its now possible to produce using XMPie version 4!

Kudos to Eliot as he has been talking about personalized video for some time now and its finally been brought into the core version 4 product.

Check these awesome samples from the recent XUG meet in Vegas...

Well, after a long stint of having no decent MySQL support (as uProduce only supports up to version 4 out of the box. Other than my ODBC monkey patch there has been no version 5 support), I have managed to find a working, and critically viable, solution for using MySQL 5 with XMPie uProduce.

cherrycitysoftware.com sell (not that you can even call it that, its only $10) a little mysql driver that with a little bit of work you can make work with uProduce and uPlan – its nice to have MySQL back!

You can use a DSN with generic DB like this:

Provider=OleMySql.MySqlSource.1;Password=YOURPASSWORD;Persist 
SecurityInfo=True;User ID=YOURUSERNAME;Data Source=YOURDBHOST;
Location=YOURDBHOST;Mode=Read;Trace="";Initial Catalog=INITIALDATABASE

Initial results are great – its working cleanly and quickly – good times with MySQL!