"You must unlearn what you have learned.",Yoda (Star Wars)

Heeding Yoda's advice, I'm currently in the process of unlearning some (but by far not all!) of the skills I've acquired over the years as SAP Development Consultant. During the past 11+ years, I've developed a lot of my applications within the ABAP stack, mostly for use within SAP GUI, sometimes within a browser.

Now, to some of you this might sound a bit pretentious, but I wanted to do something new and different! SAP ERP products are great but not perfect. I spent over a decade performing ABAP and config work in order to mold SAP ERP systems into a shape so they do exactly what a business wants. Make no mistake, these years were very valuable for me and my backend expertise is going to come in very handy in my new job. But I wanted to get out and explore, see what's beyond and discover pastures new.

Over the years I've brought a lot of help and value to businesses with my ABAPs and web apps, but it always entailed changes or enhancements within the ERP core system. Sometimes these changes were not easy to make, as end users wanted to keep their system as free of customisation as possible, fearing problems and endless regression tests further down the line.

Moreover, before ABAP OO came along, reusability of development components (DCs) was merely restricted to INCLUDEs and Function Modules. Thankfully this has all changed now. But let's face it: adoption of ABAP OO based development principles is still not a reality in every SAP development team. Things have definitely improved, but it's far from being fully adopted.

Enter Composition Environment, Netweaver Developer Studio, Composite Application Framework, Visual Composer, Guided Procedures, Enterprise Services Builder and all these other tools & repositories of a new service-oriented world that is Enterprise SOA. My new world. "The other side of the pond", as I call it.


"Rest, Neo. The answers are coming.", Morpheus (The Matrix)

However all these new tools can be quite daunting for a SAP Development Consultant who in the past usually spent most of his time using one single development workbench: SE80. In addition to new tooling and code syntax (Java), a CE development consultant also needs to understand the landscape far better than an ABAPer. It comes with the territory: if you want to build apps that link systems and leverage services then you surely have to know your backend from your Java stack from your Dev Studio. Simple as that.

If you're an experienced ABAPer then you must expect to be out of your comfort zone (aka ABAP Development Workbench) once in a while. Books, TechEd videos, Tutorials, SAP help and helpful colleagues are hopefully at the ready to make the transition easier for you. Benefits you can reap from the learning process are more DC reusability, agile and flexible development, modern development tools and many, many more  (at least that's what I hope for!). Imagine to cut down development time and deliver solutions to end users at a much faster pace than what you're used to in SAP Land. Isn't that worth the effort?

At this point I would also like to divert your attention to my CompriseIT colleague Tom Scaysbrook's blog "Journey into SAP", another great read in the CE arena and beyond.


So what are my observations so far?

• I think that my background in SAP's web app offerings and ALE/IDOC are a distinct advantage when it comes to understanding services, protocols, MVC paradigm, Object Orientation and parts of the new tooling. So if that's your background, great.
• Here's the frustrating bit: most CE tutorials on SDN are out of date. Details in the tooling have changed in CE, disadvantage being that screenshots and descriptions have you got your head scratching more than once. It sometimes happens to me that I spend more time looking for a button or a tab than I actually need to complete the tutorial. CE consultant Thorsten Franz has also emphasized this on SDN some time back in 2008 in more detail.
• diggin deeper: I was curious and had a look at the ABAP coding behind a web service for "sales order management" and was surprised. I guess my expectation was to see a lot of wrapped BAPI calls, but instead I found a lot of usage of the MV45A screen modules (even FCODEs). Very interesting to see how it was done though. Learning how to use BAdIs to enance web services is high on my agenda.
• another perspective: another thing that I find fascinating is the Composite Application Framework. It is integrated into the NW Developer Studio and enables you to write your own CAF services but also define your own structures and data tables. Storage of data (or "persistence" as it is called) is all dealt with by the framework (which is nice!). The topic of "data storage in backend or CAF - pros and cons" will surely tempt me to a blog post in the future.

 

TO BE CONTINUED !