Let me give you an update on my journey onto pastures greener that are the SAP Netweaver Composition Environment (CE). If you’ve missed the first part of this series, go, go, go and catch up now!

“I find your lack of faith disturbing.”, Darth Vader (Star Wars)

Over the past 2 weeks, I’ve spent a lot of time in SAP’s own Enterprise Services Workplace on SDN, which is a pretty good resource to look through SAP’s latest enterprise service offerings. It’s actually more than that: it’s THE place where you can find up-to-date info on documentation for services which you deem appropriate for consumption or exposure in your own landscapes. On their SDN website, the ESW is described as follows: “The ES Workplace is the central place to view consolidated information about all available Enterprise Services delivered by SAP.”. Fair dos.

You can install an ES Repository yourself, but chances are you’re not always on the latest release, so checking the ESW is always a good way to see what’s around the corner.

Now you would think that the ESW gives you an easy overview of the services on offer, describing to you exactly what each service does (especially when you compare them to each other). You would probably also think that the ESW gives you a nifty little search engine which enables you to sieve through the 2000+ services and get what you want quickly.

Well, things have definitely improved and especially the testing part of the service (against SAP’s own Discovery System, ie an ECC app stack) is much better now. However much is still left to be desired as far as documentation, search facilities and test harness is concerned. Oh, and while I’m at it: don’t even think about opening up the ESW in browsers such as Firefox, Safari or Opera.

It simply looks to me as if these services have been arranged in such a way so they fit well together with SAP’s module documentation and education plans. This doesn’t always sit in line how other consultants look for services.

In contrast, here is the way how I approach a service from a developer’s perspective: I know I want to create a sales order in a backend system. From my old BAPI days I remember that I need a few parameters to feed the service in order to get order processing going without those elusive error messages. You can find the “Sales Orders Create” service easily enough, but of course that’s only part of what’s needed. If you’re looking around for services to find sales organisations, sales groups, divisions et cetera, you’ll be surprised how difficult it can be to get the information out of the backend that you’re looking for. Bottom line for me is: finding the services you require and testing them is still far from easy.

“Once you start down the dark path, forever will it dominate your destiny”, Yoda (Star Wars)

Now as a developer there is an underlying danger in all this. Let me tell you what this is: The more time you spend looking for those services and collecting your data, the more you’re inclined to log into the backend using SAP GUI, enter the letters “S-E-8-0” into the top left of the screen and create a little remote-enabled function module, expose it as a web service (using a wizard) and get those pesky sales order related details out of the ERP system. Even worse, you’re even contemplating copying a SAP standard function module to extend it so it does what you want it to do. Do not give in to the powers of the dark side….

Now can I just say one thing here: I bet there are other ways to retrieve data out of the backend system. Whilst I love to hear about them, all I want to illustrate here is that I’m currently on a long journey during which I will learn how to find the services I require quicker and get the backend to do what I want it to do. The benefits will be that the customer I work for have systems that need less support and testing after an upgrade, because services to external systems are provided via standard services which are constantly updated and maintained by SAP.

However a little help from SAP by making the ESW easier to use wouldn’t go amiss!

TO BE CONTINUED!

SAP Mentor Yoda

“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 !