Tim Perrett Interview

Interview with Tim Perrett, an XMPie Scala Developer

Timothy Perrett is a Technical Specialist for Europe, Middle East and Africa at XMPie, a business unit of Xerox Corporation. [1] XMPie offers a full range of software solutions for variable-data publishing including the award-winning product PersonalEffect. [2] In his ‘spare’ time Tim is also a committer to the Scala based “Lift” web framework [3]. He talked to us about the Xerox ICE project; using XMPie and Scala to improve the Xerox (UK) customer experience.

The objective of the ICE project was to provide a full cross-media invitation experience for visitors to the Xerox UK showrooms. Customers who agree to visit get HTML email communications driving them via a personalised URL to a dynamic web application with information about their visit. Offline communications including a personalised printed brochure pack and personalised video are also generated.

What was the business problem you were trying to solve?

Tim: Xerox (UK) has a large number of customer showrooms throughout the UK. These are used for customer meetings and machine and/or software demonstrations. As you may know, XMPie is a provider of software solutions in and around direct cross media marketing. The Xerox UK team saw a way to improve the customer experience for every visitor while at the same time demonstrating the power of one of XMPie’s own products, namely PersonalEffect.

Can you tell us a little about PersonalEffect?

Tim: It’s a sophisticated system and quite popular for running cross-media marketing campaigns. You can, for example, extract a target recipient list from almost any available datasource, be it Excel, Oracle, or any other OLEDB/ODBC compliant database. You can use that to communicate with customers over a variety of media, all based on centralized campaign logic. Each of these communications is monitored by uProduce, as are customer responses and actions – this could be clicking through a response URL, opening an email or responding to an SMS short code etc.

How did you get involved?

Tim: I am part of the XMPie EMEA technical team. The Xerox UK team asked us to look at building a layer to automate the systems construction process for the business analyst community using the PersonalEffect API. They wanted a system that could be maintained with minimal resource, yet give maximum flexibility to the Xerox UK analysts to aid in delivering an impressive and effective experience to visiting customers.

A visiting customer likes to see our systems in action; this was a large driving factor in the ICE project as a whole - using our own systems in our own customer communications. Not only is this a great sales story, it’s a great technical one that is demonstrated to every visitor to a Xerox customer showroom.

Before ICE this used to be a completely manual process, building bespoke communications for each customer; now they just cut and paste some xml and the Scala application does the rest.

What did this mean technically?

Tim: XMPie uProduce, a part of the PersonalEffect suite, it is a sophisticated product with an extensive SOAP API that allows you to control all facets of the system. One part governs job management and queue processing. A large print job, for example, could be split by the system into recipient records that run as many parallel and different “jobs”. We needed to construct a system that could submit and track the resulting “jobs” through the production process. These jobs could be running on any node of the XMPie uProduce cluster. We needed to track these multiple concurrent jobs simultaneously during the automated production process - making sure that what the analyst planned actually happened.

What was your approach?

Tim: It was important to choose a platform that would play well with lots of concurrent operations in a succinct and usable way. Scala was the obvious choice with its powerful Actor library.

The project was implemented as a Scala standalone application, one-jar wrapped with a windows executable. As far as the analysts are concerned it’s just another native windows application. It is a seamless integration, using all the productivity of Scala to drive Java JAX-WS code for talking to the SOAP API endpoints. A good deal of the Java code is object marshalling JAX-WS generated stubs and the rest is a neat Scala SOAP abstraction I wrote for communication with our API.

What IDE did you use?

Tim: No IDE – I coded with TextMate and a Scala compiler window. I personally find IDE’s just get in the way of my coding and prefer to use Maven et al in the terminal.

Did you have any internal resistance to using Scala?

Tim: Actually no – we have products based on Java so the jump to Scala was a small one with regards to platform / environment.

What was it like to learn Scala?

Tim: Having already had 2 years experience with Scala I am not really a newcomer to Scala anymore. For the last 18 months I have been a committer on the open source Scala web framework “Lift”. This has given me a great insight into what Scala can do and what is possible.

So for me, for the ICE project, the choice was obvious. I knew Scala could deliver what we needed concisely and was confident it could be done in the short time-frame needed. The ICE strategy and specification evolved over some 6 months of team work. The automation application however, was designed, written and deployed in just 14 very intense days, start to finish.

What would you advise other people learning Scala?

Tim: Rome was not built in a day! After 2 years of Scala coding there is still the occasional thing that catches me out or I find out something can be accomplished with more concise code. Some people may find the change in approach and thinking a barrier, but hang in there because the overall productivity gains are a more than a sufficient pay off for the learning investment. A project like ICE is a really big win for everyone and, most importantly, has been really well received by our customers and visitors to the customer showrooms.