Monthly Archives: April 2012

Two tools for Gateway trial host nplhost

The SAP NetWeaver Gateway trial system is a great way to get your hands on all that OData and HTTP goodness. There are a couple of tools that I find myself re-installing when I build a new copy of the VM + trial – multitail and screen.

Multitail is something I mentioned on my Enterprise Geeks slot with Craig Cmehil and allows you to tail more than one file at once. Very useful for keeping an eye on all those log files in the instance work directory!

And screen is one of those great utilities that I put in the same class as putty and vim: absolutely essential. It allows you to maintain multiple persistent sessions on a remote *nix host. Great for disconnecting and reconnecting (especially on dodgy ‘net connections) and being able to continue exactly where you left off.

I realised that people might benefit from these too, so I thought I’d offer them for you to download in binary form, so you can avoid going through the hassle of firing up the package manager and wrestling with repositories and dependencies, or building from source. I built them from source on an 64bit SUSE Linux VM ‘nplhost’ straight from SAP, so they should work if you’re using the same as the standard VM recommended for the trial. If you’ve decided on a Windows VM to run Gateway, then you’re out of luck, in more ways than one :-)

They’re available here:

Download them to npladm’s home directory to run them from there. Don’t forget to (a) chmod +x each of the binaries, and (b) rename the _ to .  for each of the dotfiles.

Share and enjoy!

On Enterprise Geeks Podcast

Last month at SAP DKOM, where I rediscovered SAP’s Developer Connection, I bumped into an old friend, Craig Cmehil. Craig is one part of the Enterprise Geeks, a loose collective of geeks and hackers whose friendships were formed in the SAP space. The Enterprise Geeks are famous for their podcasts, and I was very honoured to be a guest on that very show.

Here’s the post: “DJ Adams and a trip down technology lane“. If you’re after the audio file directly, it’s here.

I had a lot of fun. Thanks Craig!

Firebase and SAPUI5

I took a look at Firebase this weekend, approaching it within the context of the relatively new concept of “backend as a service” (BaaS) as exemplified by Parse and others. Add server-side storage to your HTML application. Parse has a focus on the mobile app platform, whereas Firebase is a more generalised service. But that’s not the only difference.

Everything is a resource

There’s an idea that has been a long time in gestation – the idea of a loose coupling of data storage, front end apps, and backend command line environments. Firebase, an offering still in beta, with some features pending, has come along and seems to be delivering that. With style. Style not only in the actual UX, but in the design approach. In a recent talk on SAP NetWeaver Gateway at the SAP Developers Kick-Off Meeting (DKOM) in Karlsruhe, I had a slide that simply said:

Everything is a resource

This is a key tenet that underpins the values of REST and related directions in information architecture: that if a piece of data (or, indirectly, a business function, for that matter) is important, you should give it a name, an address – make it a first class citizen on the web. From there, everything else follows. You can manipulate it, you can describe it, and you can link to it.

With Firebase, each piece of JSON data you store in the backend gets its own URL. Each object, array, element and attribute is automatically given an address, as you create them. You can manipulate the data via the Javascript library, through a REST API and also through a lovely graphical debugger that looks like this:

Firebase Graphical Debugger

Firebase Graphical Debugger

With the debugger you can manipulate the data directly too. What I’m guessing, through the way that the Debugger operates, is that the Debugger itself is powered by Firebase. When data in the data set that you’re viewing is changed – whether that change is initiated via the REST API or activity in a Firebase-powered application, the view in the debugger is automatically updated to show that change.

Event system

Which brings me on to the other part of Firebase that’s important – the event system. Reading data from Firebase in your Javascript application is done by attaching asynchronous callbacks to a data location. These callbacks are triggered on data events like ‘value’, ‘child_added’, ‘child_changed’ and so on. So a very simple setup to be able to show when a new record was added to a dataset would be as simple as:

  • Instantiating a new Firebase object, pointing to the URL of the data set
  • Associating a callback function to the ‘child_added’ event, to receive, unpack and use the new record

Like this:

var dataRef = new Firebase('[...]299148/[...]QULZ4snBB/');
dataRef.on('child_added', function(snapshot) {
  var data = snapshot.val();
  // ...

Screencast: Stupid Firebase and SAPUI5 Tricks

On Saturday evening I had a little hack around, and found developing with Firebase fun as well as interesting. I put together a little screencast “Stupid Firebase and SAPUI5 tricks“. I have been investigating the SAP UI Development Toolkit for HTML5 (aka SAPUI5) for a short while now, and thought it would be an interesting exercise to hook up some data events powered by Firebase with an SAPUI5 DataTable. And throw my favourite environment – the Unix command line – into the mix too.

As I didn’t speak over the screencast, I thought I’d provide an annotation here.

  1. We start out with a view of the Firebase Graphical Debugger showing a data set at a given URL. The data set contains a number of nodes, each node has an identifier which is used in forming that node’s unique URL
  2. On the Unix command line, I use cURL – a great command line HTTP client – to effectively remove the data, by making an HTTP PUT to the data set’s URL, supplying an empty JSON stucture as the payload. As you can see, the data disappeared immediately in the Graphical Debugger, as the event triggered the Javascript function to remove the data from the display to reflect the snapshot stored at the backend
  3. A simple SAPUI5 DataTable is revealed in another window, empty, with three columns for some data we’re going to see appear there; data based on the standard Apache access log (source IP address, relative path of URL requested, and status code)
  4. We go back to the Unix command line, and use a combination of tail, perl and some core bash shell features to pull some data out of my web server’s access log, turn it into JSON, and make HTTP POST requests to the data set stored by Firebase
  5. Before we actually complete and execute that command pipeline, we have a quick look at the SAPUI5 and Firebase Javascript behind the DataTable, showing the relationship between the DataTable fields and what we’re expecting in the ‘child_added’ Firebase data event
  6. Finally we execute the command pipeline and see immediately that not only the Graphical Debugger is updated to show the records that were added to the data set at that URL, but also the DataTable receives the data as intended.

There really is little merit in this experiment; what was important for me was to see Firebase in action, and to learn something about the philosophy of the framework. I really liked what I’ve seen so far.

As I mentioned at the start, there are some features still missing from Firebase – most notably security. So you’re completely at liberty right now to read those URLs from the screencast and start hacking with my demo data. But why do that? Better to get yourself down to the Firebase tutorial pages and build some samples for yourself.

Share and enjoy!


The Developer Connection: Connect Like Never Before

At SAP TechEd Madrid (November last year) I wrote about the Developer Renaissance, covering my interview with Aiaz Kazi from the Technology & Innovation Platform, and SAP’s re-focus on developers.

This week I had the great honour of being invited to, and speaking at SAP DKOM (Development Kick-Off Meeting) in Karlsruhe. It was a truly great event – thousands of SAP developers attending many tracks and sessions on everything from Analytics, through Database & Technology, to Cloud, and more besides. As I sit here in Frankfurt airport on my way home, I’ve been reflecting on perhaps the best single takeaway from this event. Yes the content of the talks was great (and I enjoyed giving my session on SAP NetWeaver Gateway too). Yes the venue and organisation was second to none. Yes it was great to see the SAP Mentor wolfpack and our illustrious leader Mark Finnern.

But most of all, I saw, felt, and experienced something that I last remember from over 20 years ago in my SAP career: The Developer Connection.

Back in the day, when I was (more) innocent, certainly a lot younger, and waist-deep in IBM mainframe tech, I moved around implementing and supporting R/2 installations in the UK and Europe. Esso Petroleum in London, Deutsche Telekom in Euskirchen, and so on. In those days you could catch up with all the OSS notes on your favourite topics over a couple of coffees. Most importantly however, you had connections to the developers at SAP who were building and shipping the code that you were implementing. We knew each other’s names, and in many cases, shared phone numbers or email addresses too. There was a strong bond between customers and developers – and we worked together to make the software better.

That connection lost its way over the next few years, when SAP (consciously or unconsiously) built barriers between us. It became almost impossible in some cases to even find out the name of the developer or team responsible, let alone contact them directly.

Well – that connection is back. And better than ever before. Both at SAP TechEd Madrid, and this week at DKOM, developers were coming and saying hello. Developers who are building the great stuff we’re exploring and using, like SAPUI5 and NetWeaver Gateway. People like you and me. We are connecting again. I think there are a number of reasons for this.

First, there’s the amazing community called the SAP Community Network (SCN – although for me it will always be the SAP Developer Network – SDN) that brings together developers from all sources. Then there’s SAP’s re-focus on developers, and the corresponding coupling of empowerment and responsibility that SAP is giving directly to those developers. Further, there’s the inexorable turning inside out manoeuvre that SAP began a few years ago now, moving cautiously at first but now gathering pace as more and more technology directions that SAP are following are from outside the SAP universe, not inside. SAP developers naturally are connecting with the wider development community in general.

Whatever the reason, it’s a great sign that the future looks exciting for SAP development as a whole. Connections, collaboration and cooperation is returning. The Developer Connection is here again.