Author Archives: Jelena Perfiljeva

To borrow from Dickens, last week in ABAP “it was the best of times, it was the worst of times”.

Let’s start with the worst. SAP ABAP Developer Edition got gone officially. This is extremely disappointing, especially for those who are stuck with old versions of ABAP at work. From what I see, this leaves ABAP enthusiasts with either very limited Cloud trial option (used in the openSAP classes, for example) or free-not-free systems in SAP CAL. I hope more information from SAP is forthcoming, ideally before TechEd.

On a more positive note, Devtoberfest is now in full swing and there are some interesting ABAP sessions. My recommendations so far:

• ABAP on Exercism? Demo and Presentation from Lars ‘The Legend’ Hvam. One might look at this and think “oh, hey, this looks like a replacement for ABAP Developer Edition!” and I wish it was that simple.
• Developer Extensibility and Business Events with RAP on SAP S/4HANA Cloud: ABAP RAP with Event Mesh, oh my!

There will be more coverage of Devtoberfest content in our next issue(s), stay tuned! JP

This story was originally published in Issue 25 of The Boring Enterprise Nerdletter.

Don’t miss our latest issue!

ZSAP is how we jokingly describe an SAP ERP system that has been customized up to eyeballs (“Z” is the prefix for custom objects). ZSAP crimes are typically blamed on the stubborn, “that’s how we’ve always done it” customers and clueless consultants. But there is another, unusual suspect: SAP SE.

To do stuff in SAP, customers must use standard functions/APIs: BAPIs, global classes, web APIs, etc. Sadly, these APIs are sometimes missing features or just plain don’t exist. SAP’s approach seems to be “we give you what we think you need and, if anything is missing, just enhance or create your own”. However, SAP notoriously underestimates the customer needs and then thousands of customers are creating the same Z-things. Examples? 14 years of editable SALV, the crusade for a Purchasing Organization API, missing associations in standard CDS views, and many more. 

While this might look like the perfect case for an open-source project, not all customers are open to open-source (no pun intended). It also raises the 1 million USD question of who would be responsible for maintenance of such software?

There ought to be a better way for SAP to identify what customers need and deliver it as standard functionality instead of becoming a ZSAP crime accomplice.

Don’t miss our latest issue!

Data mesh has been generating buzz as a “hot topic in enterprise software” and “more than just hype”. But what even is “data mesh”?

The term’s creator Zhamak Dehghani defines it as “socio-technological concept”. Her 2020 article describes 4 main principles that I think can be interpreted in simple terms with… a grilled cheese sandwich. Hear me out on this.

1) “Domain-oriented decentralized data ownership and architecture.” It makes sense for the bread data to be owned by the bakers and cheese data by the dairy folks. In the real world, this can be a tricky architecture and “ownership” of anything in big enterprises is a minefield.

2) “Data as a product”. Imagine ordering a grilled cheese sandwich and getting a loaf of bread and a hunk of cheese? But that’s exactly how data delivery works in many enterprises. Wouldn’t you prefer to get what you ordered?

3) “Self-serve data infrastructure as a platform” – since the self-order kiosks got installed at Panera Bread, I haven’t spoken to a single person there (an introvert’s dream!). Being self-sufficient is empowering.

4) “Federated computational governance” – there should be a general agreement on what a grilled cheese sandwich consists of. Not an easy task since many people are super passionate about their regional recipes. And governance is where projects go to die.

Overall, I think data mesh is an interesting concept that goes well with tomato soup… err… event-based and microservice architecture. It might not be for everyone but is worth considering.

Don’t miss our latest issue!

After covering the “EDI vs API” controversy in the last issue, I didn’t expect to write about the APIs so soon. But this SAP Community post asking to “comment your views on using an API over IDOCs or BAPIs” made me think oh boy, here we go again. 

In common parlance, API means a piece of code that does certain thing(s). APIs typically have some input/output parameters but “what happens in API, stays in API”. One could think of an ATM machine as an API: we put our bank card in and get money out. What exactly happens inside the machine, we don’t know or even care.

In SAP, the earliest implementations of APIs were the function modules. And BAPIs (“business API”) are just a special type of function module. Later, global classes came around, then the SOAP / REST APIs. The latter are now commonly referred to as “APIs” and are exposed on SAP API Hub.

Based on the development context, the choice is obvious. If you’re building a web application or an external interface, then use the APIs. If for any reason it’s not feasible, then look for other options, which might include eventually using a BAPI (either via RFC or wrapped in an OData service). But if you are working “within SAP”, then web APIs are not going to be very helpful in ABAP code, wouldn’t they? So there is simply no scenario in which the thought “hmm, should I go with BAPI or API” would be relevant. JP

Traditional product development methodologies rely on the “big bang” delivery process. Sadly, this tends to cause the “oh, hamburgers!” moments when it turns out that the customers don’t like what they got after waiting 6 months for the product.

Agile was supposed to solve that by working in iterations, to “fail fast”, get frequent feedback, and adjust. Wash, rinse, repeat. This is a great idea on paper but, as usual, reality ruins everything.

YouTube is full of the videos making fun of Agile, Agile is Dead talks, and even the Agile Manifesto creators “disowning” it. Twitter is full of posts like “you’re doing it wrong!”, “there are many flavors of Agile”, “Agile is waterfall with micromanagement”. So, is Agile a good or a bad thing and are you doing it “right”?

The article Agile / Scrum is a failure by Richi Jennings points the main problem that matches my own experience as well:

The Agile Manifesto paints an alluring picture. … The problem is, it’s almost always implemented in workplaces devoted to the bottom line, not to workers’ well-being[…]

[…]Taken to heart [it] means that anything larger than a developer can do in two weeks is infeasible. This often happens when the team building the software is not considered [as] stakeholders.

No wonder developers end up with “post traumatic scrum syndrome” when instead of creativity the process becomes all about the story points.

Main benefit of Agile is the product focus. When this is forgotten, the methodology doesn’t matter anymore. If your vision of “Agile” is a development sweatshop, then sorry, its failure is on you. JP

No, this is not about a bot that prevents the monthly “extract Excel from ABAP” blog posts and redirects to ABAP2XLSX instead, sorry!

We’ve written about the SAP Community calls before (e.g. Event Mesh and SAP CAP). These are usually covering cutting-edgy subjects with less marketing speak and are very helpful. But lately I’ve not heard of any calls and was wondering what’s up.

Turns out that instead of visiting the SAP Community page, now we need to sign up for the upcoming calls on YouTube channel. Community calls are listed as ‘Upcoming live streams’ (look for the pink-orange background). The upcoming call on August 31st will be about AI-Powered Personalized Recommendation Service, which sounds pretty cool.

Continuing AI theme, there are also 2-minute videos about different SAP AI offerings. I find the Document Information Extraction service particularly interesting and recommend exploring it at your leisure. JP

Check out this issue for more!

Enterprise software development is not just about algorithms and programming languages. It’s also about business processes. And for every enterprise, this means accounting. 

It’s always weird hearing the accountants talk. “Clearly, this chargeback goes to a revenue recognition account. – Indeed. But we need to offset tax liability for asset depreciation. – Quite!” I imagine that’s also how accountants feel when developers are discussing OData filters.

One does not need to go back to college though to learn just enough about accounting to understand that the dialog above is pure nonsense. Recent article Accounting for Developers explains accounting basics very clearly and is reasonably short for the volume of information it covers. I highly recommend it to all the SAP developers in particular. (As we know, all roads in SAP lead to FI.)

And for those partial to YT 10-minute video format (no judgment!), there is an excellent video Accounting Basics Explained Through a Story and more on Leila Gharani’s channel. JP

Check out this issue for more!