In our brave new cloud-based world a lot of integration happens over the web via HTTP; for a lot of scenarios, a full WS stack that uses SOAP+UDDI+WSDL is complete overkill and a timesink. Sometimes you just want to send some data around and get a response; this is where the adapter can fit into your integration landscape and help you get things done¹.

In celebration of International Women’s Day (8th March 2013), I think a reference to computing pioneer Admiral Grace Hopper is in order. I believe she said that programming was like planning a dinner; that’s a neat way of mapping the act of programming into something everyday. After all, as a programmer, most of the time you aren’t inventing new algorithms¹ you’re just joining up existing third party libraries and API’s in a different way; making a new recipe out of the same ingredients.

Integration is much the same.

So, this is yet another blog post about executing BAPI functions in SAP using the Adapter Framework; one day I will get bored with writing about SAP, but right now, it’s on the top of the heap. Today’s post is around error handling and reporting; any monkey can make something work, but handling error conditions gracefully is often a stumbling block that can trip you up during integration.

I re-watched groundhog day quite recently; it is still a work of genius but it got me to thinking about the subtext of the film and how it relates to software development.

Last time I wrote about how easy it was to execute an arbitrary BAPI using the adapter framework and get meaningful results back as XML. At the simplest level, that’s pretty much all you really need to integrate with SAP. Unless…