Skip to Content
Author's profile photo Oliver Jaegle

ABAP to the future – my version of the BOPF chapters – Part 1: general structural aspects

ABAP 2 the Future – my version of the BOPF chapters

It rarely happens that I’m really looking forward to a release of a book. The announcement of “ABAP to the future” by Paul Hardy was such an occasion. Reading the TOC, I was 100% positive that Paul picked the right topics which were needed in order to fulfil the promises of the title.

Particularly I was excited about the BOPF chapter: I have given a couple of trainings, been to TechEd with the topic, promoted it to management as well as fellows and all the time, the same questions are being raised: “Why have I not heard about it before?”, “Is there an official training at SAP?” and “Is there a book about it?”. While I still can’t answer the first one, the answer to the second one is “yes, WDEBOF at least gives a rough overview”. I always answered “not yet” to the book-question and was excited to be able to answer it with “yes, and the title of the book is very appealing to management as well: “ABAP to the future” (A2tF, to find an abbreviation).

I finally started to read it and have to admit that I don’t agree to a lot I read. Sharing this opinion with fellows, I was encouraged to write my comments on SCN so that we can discuss them.

Preface: This is my opinion based upon my experience and architectural as well as programming style. @Paul: You have done a great job collecting and preparing those topics. Thanks for including BOPF in it. I hope you don’t mind my criticism and the style I chose. I would love to read your comments on my writing and discuss on the each and every aspect. Often, there’s no “right” solution, so I guess that other readers joining the discussion would also benefit from it.

Instead of picking all the small pieces which I would like to comment on, I chose to write a partially alternative version. This is of course more challenging and exposes my poor writing (I can’t keep up with Pauls entertainment for sure, I’m German), but I hope that third persons can understand it more easily. Still I will not repeat parts which I agree with. You’ll have to read the chapters yourself and create your own picture which suits your experience and architectural style. Anyway, it’s worth buying the book ;)

So here we go:

8.1 Defining a Business Object

A BOPF model is a representation of a real-world object. With a very low representational gap, the model which is designed in a dedicated modeling environment in the ABAP backend (in fact, there are multiple designtimes based upon the same model, we’ll come to that later). This so-called “outside-in” approach doesn’t only make it easier to consume the model, but also to discuss as a developer with domain-experts with the same vocabulary. But be careful: The business object is agnostic to the consumer (e. g. doesn’t know anything about the UI). Deriving a model from a UI can render your model inflexible or in-appropriate for other consumers. Modeling a business object is very similar to modeling a UML class diagram: You think about how the things work and use your brain and methodology in order to derive classifiers (classes) and behavior (methods) – if you don’t have a methodology which helps you to decide what makes an entity, I highly recommend reading Craig Larman.

8.1.1 Creating the Object

Before we head to the system, let’s make a plan. How does a monster look like? A monster is composed of many parts (UML: classes) which are interconnected (UML: by associations). Those which are connected with a dependency that the parts can’t exist without the monster itself (UML: composition associations) will form our monster business object. An analysis of our usecases has resulted in the monster itself needing a name and a creator. It has a head, it can even have multiple heads. About the legs and arms we might bit a bit uncertain: When is an arm an arm, what makes the difference to a leg? We might decide for an entity “extremity” instead. All these questions might not occur when deriving the monster from a UI. We might instead have come up with a model where we’ve got only one head (as an attribute of the monster) and six attributes leg1..6. Now let’s move to the modelling environment. I recommend to directly utilize the BOPF Expert tool (transaction BOBX) unless you’re got EhP7, SP8 and are happy to be able to utilize the BOPF in Eclipse plug-in. The BO Builder (BOB) is less powerful and should be used only when extending business objects.

Preface: About addressing model parts

All entities of a model are technically encoded as GUIDs. When programming with BOPF, we technically pass the GUID in order to address an aspect of a business object which we’re talking to. This is necessary, as the command pattern and the service layer pattern are fundamentals of the BOPF architecture (we’ll talk about this in more detail later). Just one word upfront: In the beginning it might feel a bit cumbersome, after but you get used to it very easily as the pattern is ubiquitous. In order to make the code more readable (and writable) for the human, BOPF generates a so-called constant-interface which has a human-readable constant containing the GUID. During debugging however, you are confronted with the GUIDs.
Hint: There are various ways in order to translate the GUID back to the model-entity. The easiest one is to press control+F in the BOPF designtime and paste the GUID. The UI will navigate to the corresponding model-entity (at least in the SAP-GUI-based tools). When debugging, you might not want to leave your debugging environment and can utilize the debugger script

8.1.2 Creating the root node

The wizard guides you through the creation in BOB, you basically have to select proper names. If you started in BOBX, a root node with name “ROOT” will be created immediately. The so-called root node is the topmost entity upon which existence all other nodes depend on (as Paul wrote comparable to the top level of an XML document).

I recommend you not to choose any other name than ROOT, as the ROOT kind of represents the object itself. Naming it like the object (e. g. MONSTER) is redundant (as all node-names are unique only in the context of the BO) and giving it a name (e. g. HEADER) makes it more difficult to identify as top-level node. BOPF also creates associations for all lower level nodes to the top-level-node which are called “TO_ROOT”, so it would be nice in my opinion if TO_ROOT also found the ROOT node.

The structure of each node contains two major parts which are modeled for each node: One for the persistent structure and one for the transient structure. The persistent structure will be included into the database table which BOPF will generate for you. The Transient structure contains information which can be derived at runtime.


Figure 1 – The different structures and types modeled for each node

The combined structure is the one used at runtime (the one you code to). It includes the persistent structure as well as the transient structure (if transient attributes exist on the node).


Figure 2 – The root-node’s combined structure used at runtime

It’s a bit tricky to distinguish between transient attributes and UI-control-information. I recommend to include attributes into the transient structure which are relevant to the business (and don’t think about the UI). For a monster, it is necessary how many heads it’s got, as it can bite once with each head (assuming only one mouth per head). Thus, we should have an attribute “number of heads” on our ROOT node. However, this can be easily derived by counting the number of HEAD-instances for each monster. It doesn’t need to be persisted, but it could be also stored if updated after each head-creation or deletion. Whether an attribute is transient or persistent is transparent to the consumer, as both structures are included into the “combined node structure” which is being used for consumption. You can even move attributes between the two structures without disruption. Information which is solely necessary for the consumption by a human (via a user interface) like language-dependent texts to a coded value should never be part of the model, but should be added on an architectural layer closer to the UI (I call this layer upon which the UI-controller is based upon “service adaptation”, but this aspect is not part of this chapter). My recommendation: If you can derive an attribute but want to search (the database) for it or if the derivation is very expensive, include it in the persistent structure. Else, give the transient structure a try.

The names for the runtime structures will be proposed by some funky algorithm which resides in BOPF. I recommend to just keep the prefixes and suffixes as they are (and only change the semantical part if necessary), as it is very beneficial if the naming is the same within your development team. And there’s always a lazy team member which just goes for the proposal 😉

If you’ve got a deviating naming convention in your company, feel free to extend the BOPF code which does the proposal. Doing this will help you tremendously to learn how BOPF itself works – and might open your eyes a wide.


Figure 3 – Don’t waste time thinking about the technical names…


Figure 4 – The almighty name-proposal.

Enter the entity names (such as node names) and let BOPF propose the technical names

After you got the structure names proposed, use forward navigation to SE11 (by double-clicking on the structure names) in order to model the persistent and transient information.

Finally, generate the runtime artifacts from the “Extras”-menu:


Figure 5 – Result of the DDIC generation

8.1.3 Creating the subnodes

Our monster shall be able to feature heads and extremities. As the heads depend on the existence of the monster itself, this will be a subnode to the ROOT node (in contrast to “FINGER” which depends on the existence of the node “EXTREMITY” and would be a subnode of the subnode, if we modeled it, which we don’t for the sake of simplicity). Also note that the node-name is in singular! How many heads a monster may have is a property of the association between ROOT and HEAD (its cardinality) and might even change as the system evolves (usually from one to many 😉 ). Also, we don’t prefix the node-name with the business object name itself, as the node is anyway context-dependent on the BO.


Figure 6 – The monster’s node structure.

The composition associations are “model elements of the root-node”.

As I wrote above, a BOPF Business Object comprises all the entities (as nodes) which are connected by compositions. As we create the subnode, BOPF implicitly also creates a composition association along with it. All associations in BOPF are directional. The composition, which usually has the same name as the target node leads from ROOT to HEAD. As all associations are directional, another association which leads from HEAD to ROOT is also created implicitly: it is called “TO_PARENT”. This association exists for all the subnodes of our model, just like “TO_ROOT” which always associates the ROOT node from the subnode. While TO_PARENT and TO_ROOT always have a cardinality of 1, the compositions’ cardinalities have to be modeled.

Note that – just like in the UML – nodes and associations are different entities of the metamodel. In the constant-interface, you can also experience this easily: There are separate constants for zif_monster=>sc_node-head and zif_monster=>sc_association-root-head. Also, there can be multiple associations between the same nodes: E. g. we can imagine one head being a preferred one (which takes most of the tasks). or a relationship between the monster (root) and the heads with hats.

> Find more alternative versions of chapters in my blogs.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Oliver Jaegle
      Oliver Jaegle
      Blog Post Author

      Unfortunately, I currently don't have a system from which I can take proper screenshots. I might add them later on or would be very happy if a fellow reader could help me out.

      Author's profile photo Christian Drumm
      Christian Drumm

      Hi Oliver,

      for which parts would you like to have screen shots? I could certainly provide some from one of our dev systems.


      Author's profile photo Oliver Jaegle
      Oliver Jaegle
      Blog Post Author

      Hi Christian,

      I could use some screenshots of the composition, the to_root and to_parent and an Se 24 methods of the service manager interface for the core services. And of course of every part which you think would be useful 😉

      Is there any chance of allowing others to edit a post on SCN?

      Thanks and cheers,


      Author's profile photo Christian Guenter
      Christian Guenter

      Hi Oliver,

      great insights to the BOPF framework.

      Information which is solely necessary for the consumption by a human (via a user interface) like language-dependent texts to a coded value should never be part of the model, but should be added on an architectural layer closer to the UI (I call this layer upon which the UI-controller is based upon “service adaptation”

      I must admit i'm guilty. I always thought that is of one main use case of transient structures (and it has worked very well).

      It would be great if you can elaborate a bit further how such an UI-controller based upon "service adaption" would look like? 🙂

      Regards Christian

      Author's profile photo Oliver Jaegle
      Oliver Jaegle
      Blog Post Author

      Dear Christian,

      Thanks for admitting your guilt! I hope to be able to shed some light on what I meant with service adaptation.
      Models as they suit the processing are rarely available in the exact way in which particularly a human would like to consume it. Code values need to be translated to texts (sometimes even formatted, such as 01 - Dragon) or data of related instances shall be displayed as if it was part of the node's data (de-normalized, particularly when master data is associated). Often this enriched information depends on the target device or the user's needs.
      In order to optimize data transfer, it makes good sense to add this not in the model which would affect every consume, but in a layer closer to the UI which adapts the services of the model.
      In the SAP-world, based on BOPF there is FBI, the floor plan manager BOPF integration. Among other features, it offers an entity which kind of encapsulates and adapts a BO node: the FBI view. At runtime, the FBI view is represented by a structure  which includes the BOPF combined structure and allows to add fields for exposing e.g. texts to the UI. You may want to search the posts by Matann Taranto for further Information ob FBI or head directly to Holger Polch's TM enhancement guide: chapter 5.2.1 gives you an idea of what can be adapted with the help of an FBI view.



      Author's profile photo Florian Henninger
      Florian Henninger

      Hi Oliver,

      good read...thank you. Craig Larman is a must read if your a software developer at all.

      It is on my worklist to go trough this chapter and get my hands dirty. So I try to collect some screens, but I won't find time for it the next few weeks. So if someone else is faster, go on 😉


      Author's profile photo Fred Verheul
      Fred Verheul

      Hi Oliver,

      Like I already said on twitter: thanks for adding this valuable insight to scn , where it benefits everyone.

      I haven't gone through Paul Hardy 's bopf  chapter yet, but I'm happy to see your blog post makes sense on its own.

      It's also food for thought, and I'll have to dive into it soon. Luckily I'm at the moment working for a customer that is on 7.40 already 🙂 .

      Looking forward to the next instalment!

      Author's profile photo Paul Hardy
      Paul Hardy


      First off just to set your mind at rest I am not bothered at all by your "criticism". In fact I don't even see it as criticism really - if you have a team of five developers they are going to have five different ways of achieving the same goal.

      This is the same in other areas - I work with a team of five gentlemen who design concrete mixes, and they all have widely different opinions on every subject relating to that area.

      I know what real unfounded criticism is when I see it - I had two and half years of being bombarded by it all day every day - and your blog is nothing of the sort, it is just a slightly different way of looking at the same topic.

      You mention a few tips and tricks I just didn't know about e.g. when it comes to debugging, so that's new knowledge for me which can only be a good thing.

      I am not even 100% sure we are in opposition - a lot of what you write above does not seem to contradict what was in my chapter.

      As far as I can see there are a few areas where I appear to be doing something you disagree with. I am not going to talk about naming, as no two people ever agree on that!

      The first is that you are worried I am linking the model and the view (UI) i.e. tying them together, which is naturally a big no-no. My aim was always to have a UI layer that can be swapped and the model neither knows nor cares.

      You don't often get example of the reverse i.e. the same UI layer suddenly getting a different model, but there was a great example in the "Head First Design patterns" where they had a UI which displayed the results of a heart monitor, and they swapped the heart monitor model with a model that monitored the drumbeats in a disco, and the UI remained exactly the same.

      Anyway I thought I was fairly safe here as in the book I used my model class in a classical DYNPRO application (which you don't see in the book) and in three executable programs - using REUSE_GUI_ALV_GRID function module, CL_GUI_ALV_GRID and CL_SALV_TABLE, and in a Web Dynpro application and in a UI5 application. Each of these used the exact same model class but with a different UI technology.

      You are saying that what happens on the screen in front of the user should not influence the design of the model, but I find the specifications I get (such as they are) in my day job tend to start from a mock up of a screen with descriptions of what sort of things the users will be doing and what the intended result should be.

      My specification says the user will sometimes instruct the monster to howl at the moon. So I was thinking that based on this my model should have some sort of head attribute, and a command to "howl" and a validation which checks that the monster has a head before trying to make it howl. What the screen looks like in front of the user does not matter, the user could even have no screen and give the command by telepathy into the SAP ESP module, but in the end it is a user interface with a howl command and my model has to include that facility - influenced by the UI requirement.

      I have always agonised over where the database reads to get text names for fields such as VKORG or MONSTER_TYPE should reside. On the one hand as you say this inherently feels like a view task as such text fields are purely for the benefit of someone looking at a screen (or hearing the text names via some sort of screen reader). On the other hand putting the logic in the UI layer seems to be tying to the UI to the data structure of the model. So I was torn between the two and did not know which way to turn.

      So when I first encountered the BOPF I was of the same opinion as Christian above - when I saw that there was a structure for transient nodes I had thought this was a clear guideline from SAP that the language dependent texts should go into the model.

      Next comes the debate about whether to have a separate model class. I had the model class and the BOPF specific code split into two different classes and you say this is just not needed.

      I will try to explain my thinking here and then you can tell me if I am a madman or not. At the start of my BOPF chapter was a few pages (which were cut out of the book, but which I then posted as a blog) summarising all the different attempts SAP had made through the years to represent Business Objects inside SAP e.g. SWO1, BAPIS, the BOL and so forth. Now, not wishing to disparage the guys at SAP but when they say "this is it, the BOPF is the be-all and end-all, the final answer to the business object dilemma" that they are not going to turn around six months later and come out with yet another framework? Say the "objects of business encapsulation information structure collection" or OBELISK for short.

      If they did, and I thought the new one was better, I could use the adapter pattern to wrap up the new framework with the same interface as I was wrapping the old framework in, and not have to change my model class at all. The good old "open-closed" thing.

      That leads my on to the last point about wrapping up the BOPF in my custom Z classes. I just said one of the reasons why I did this, but I have t make a confession here, I am most likely far too gung ho with the DRY principle, and am physically incapable of having the same chunk of code in two places, when I can extract it to a central place and parameterise it

      I recall "Uncle Bob" wrote an article about "extracting till you drop" and there were some very emotional responses both for and against. It made perfect sense to me and so I am strongly for this position, but I understand I may be taking things too far. As you say, it is a choice for the individual programmer.

      Personally I love the tool in ABAP in Eclipse that lets you extract chunks of code into their own method. Some people have written their own ATC checks to seek out duplicate (or very similar) chunks of code, and I have that on my list of things to investigate.

      To summarise - I hope I have understood the points where you disagreed, and in each case tried to explain my reasoning. I like to think I have a very open mind and am quite prepared to be convinced that I am wrong about something, I just want to make certain that you understand I did not just pick my design at random, but actually thought about it, even if the conclusions I drew might not be everyone's cup of tea.

      Next it is quite probably I missed something else that you disagreed with from the text of your blog above, in which case please let me know what it is.

      Secondly, I am sure you will write more blogs about this - as this blog is "part 1".- and I am looking forward to the subsequent parts.

      Lastly, thank you for buying my book in the first place and recommending it to other people!

      Cheersy Cheers


      P.S. "Process After Input" - the input is an instruction of some sort from a human, or from a remote sensor, or from outer space, not always from a UI. The model has to respond to this based upon it's business logic. To my mind the BOPF handles this wonderfully, with clear areas for handling commands, and checking the newly provided information for consistency and so forth,

      Author's profile photo Oliver Jaegle
      Oliver Jaegle
      Blog Post Author

      Hi Paul,

      You're right, in the first sub-chapter there's not too much I disagreed with in the proper send of the word. I just added a short section on the use of the configuration object - and a second part where there's more real contradiction 😉 We're surely not in opposition (yet), as I too agree that BOPF is a wonderful thing to know which can anyway make your head spin.

      I did not want to just point out those aspects I did not agree with, but also wanted to add some things I missed (which is majorly the transition from a "well-known" UML-class-model and the service layer pattern).

      When reading the book, I was having the impression that your approach of comparing the dynpro-events to BOPF parts does set a wrong expectation of what a model shall contain. Texts for codes are something like this. I have seen dozens of models where node-data contained UI-information (apart from texts even a (transient) flag whether the subnode-instance was selected). Transient data in a BO node should be relevant to a business process. Texts are not. Some samples for transient data which I have seen in real life: Totals, Count of subnodes, converted currencies, age (derived from a key-date, teporal information is tricky to persist 😉 , serialized form of other node-attribute. In (almost) every case, you could as well persist the attribute and in many cases, a node attribute which was transient in the first step got persisted after some time (due to performance or since some user wanted to search for it).

      One major aspect I really don't like at all is the model-class. If you are implementing an adapter, you implement an existing interface. In your sample, the wrapper - well - wraps the service manager without adapting to another signature. I have seen plenty of those encapsulations and I wanted to express that there is no need for it. It will make things worse with respect to maintenance and performance.

      If you already have an existing model class, then of course feel free to adapt to it. But I'm quite sure that in this case, you are likely to have an adapter for each object (e., g. the monster_adapter and not a generic one). So there should not be any need for RTTI using the configuration object or untyped data references. Simply use the combined data types and the constant interface. Avoiding unnecessary generic programming is something I'm fighting for.

      Btw: OBELISK is for sure already in the wild. I'm just not sure wheter SAP has named it CDS or SADL.

      Looking forward to reading your comments on part 2 as well!

      Cheers, Oliver

      Author's profile photo Michelle Crapo
      Michelle Crapo

      And now I can't wait to read the book.  Not now as I am not on the right release.   But in the future.    Great blog.   I like that you detailed things out in SCN.   It helps everyone!

      Author's profile photo Oliver Jaegle
      Oliver Jaegle
      Blog Post Author

      I was not too happy with the quality of the my own writing and did a complete update. Particularly, I added screenshots which I could not do until recently due to a missing dev. system.

      Still, the SCN editor gives me trouble. formatting in Word is much better, I might publish it in another way which gives a better reading experience...

      Author's profile photo Paul Hardy
      Paul Hardy

      This is one thing we are in complete agreement with.

      The SCN editor regularly mangles everything I publish, usually removing the spaces between the paragraphs and not letting me put them back.

      There seems to be some sort of moral objection to letting us paste in things prepared to word, I would love to know what it is. I thought that it might be to stop people pasting in large chunks copied directly from SAP Help, but if that is the reason it doesn't work, people somehow manage to do that anyway, and hopefully get slapped about by the moderators for doing so.

      And back to the point at hand I agree that an "adapter" that wraps a target interface with the exact same interface is lunacy. There are plenty of methods in standard SAP that wrap a function module in the same interface, with the same names.

      I think people were getting paid by the amount of OO code they wrote, but did not know how to do it, so they wrote a function module and put a method around it.

      Anyway, what I was trying to - and this could be lunacy as well - was although I kept all the data objects in the signature the same, I renamed the exterior signature with more meaningful names. Names that I thought were crystal clear as to what they did as opposed to SAP cryptic abbreviations.

      So it is down to naming again. I am well aware that some people would think the original names were better than the ones I chose. Some people even still like names like X and Z for signature parameters, you see enough examples on the internet, and that's the way they still names things in academic papers about computer programming. And indeed in a lot of the examples about the changes in the 7.40 language.

      Cheersy Cheers


      P.S. Are you in Las Vegas next month for TECHED? If so you can argue with me in person, hopefully over a drink.

      Author's profile photo Oliver Jaegle
      Oliver Jaegle
      Blog Post Author

      Hi Paul,

      at last something in common: The wish for a better editor and a drink in Las Vegas.

      With respect to the "adapter" (this actually refers to the model class, for those who are not able to follow the discussion since I move my rant on it to a separate post): It's not about naming: Your model class wraps the BOPF model without decoupling from it as it uses the BOPF node types (see page 296, figure 8.10). This means, that the consumer also may e. g. provide KEY and PARENT_KEY. Most probably the consumer's getting confused as he expects to pass pointers to header and item objects. So to me it's still lunacy. I have been explaining service layer and command pattern to JAVA developers who had done plenty of domain-model-thinking and neither myself nor them had found a nice to consume and well performing way of encapsulating the service layer on ABAP (and I believe there is none).



      P.s.: Unfortunately, I will not make it to any TechEd this year, so we need to have a drink another time. You are not accidentally checking in around Walldorf in near future?

      Author's profile photo Paul Hardy
      Paul Hardy


      My companies head office is in Heidelberg, I lived there for 2.5 years, and my wife's best friend lives in a nearby village. I even speak German a bit, albeit appallingly - so you never know when I might be around that next of the woods again be it for work or pleasure. I'll be sure to let you know!

      I had a quick look at my model class again and was aghast to find it riddled with BOPF specific structures and exceptions and what have you. That sort of coupling was not the droids I was looking for.

      Even if we never agree on certain things in 3 years time if I am asked to write a second edition of the book I will do a lot of things in the BOPF chapter differently. In addition I will have had 3 extra years of using the BOPF for real, and one thing I do know is that whenever I look at a piece of code I wrote any longer than about six months ago I think "What in the world was I thinking?". We never stop learning and the best way is learning by doing.

      The proof of the pudding is how my approach will stand up to the constant barrage of demands for change from the user community. The idea is to constantly adapt one's approach to make things easer to change and more stable in the face of change - the good old anti-fragile approach.

      And of course in 3 years time, I imagine SAP will have changed the BOPF somewhat dramatically, as is always the case with new technology. It might even be obsolete. I would not be shocked if in the next version of my book half the existing chapters will go, to be replaced by new SAP technologies that have not come out as yet.

      Cheersy Cheers


      Author's profile photo Paul Hardy
      Paul Hardy

      As it turns out the book is selling so well they have asked me to start looking at writing a second edition already.

      I went through my model class and took out all references to anything remotely related to BOPF. The models persistency layer uses BOPF but the model class itself has no idea there is such a thing now, so the model class can live in a pure netweaver system (which does not have BOPF until ABAP 7.5) and use a persistency layer class with the same interface that uses a different framework to get the data.

      What I was always after was to be able to replace the BOPF with whatever it gets replaced with, provided that the new framework is better in some sense, without having to change heaps of existing programs i.e. the good old "open-closed" principle.

      So what I have just been doing involves lots of lovely decoupling, a very enjoyable task, and not that difficult. One of the best articles I ever read about OO design was all to do with writing a program to run a coffee maker, where there was a high level abstract class or set of interfaces which just described the general process and ignored the specifics, and then some other classes which ONLY cared about the specifics. The higher level interfaces would never change, but the lower level classes would change with every new make of coffee maker. It's like driving an electric car after having driven a traditional ICE one, you don't need to know there is now hardly anything inside the engine as all the controls that you see/use look the same.

      In the high level interface you could also cater for things that the current framework does NOT do but it should, and you start off using the framework to implement the 95% of things it does handle, and workarounds for the rest, and as the framework gets better you can replace the workarounds with the new features of the framework.

      Of course the irony is that I am going to have to generate the BOPF model out of a CDS view if I am going to be demonstrating SAP's new programming model, so all that separation will go right out of the window, as SAP seem to be wanting the CDS view to be the data model, business object, and UI view and controller all in one.

      Cheersy Cheers


      Author's profile photo Paul Hardy
      Paul Hardy

      Hello, a bit late (3 years) but I am now once again based in Heidelberg, and will be until at least September 2019.

      So if you are still based in the Walldorf area we can finally meet for a beer.

      In a not unexpected twist the BOPF is now in maintenance mode, having being superceded by the euqivalent concept in the RAP, so we may have to argue about that instead.

      Cheersy Cheers


      Author's profile photo Former Member
      Former Member

      Paul Hardy wrote:

      And back to the point at hand I agree that an "adapter" that wraps a target interface with the exact same interface is lunacy. There are plenty of methods in standard SAP that wrap a function module in the same interface, with the same names.

      Unless... what you are wrapping is an "internal" API you "shouldn't be using in the first place"... Then it's *ahem* prudence, which doesn't cost all that much, but will spare some of the pain when that API changes or disappears altogether.



      Author's profile photo Paul Hardy
      Paul Hardy

      We use heaps of "unreleased" function modules - I suspect a lot of companies do.

      When we upgraded from 4.5 to 4.7 function modules and all sorts of other things vanished all over the place.

      Moving from 4.7 to ECC 6.0 I was expecting the same again but in comparison hardly anything vanished. All that happened was a lot of function modules getting flagged as obsolete rather than actually vanishing.

      The question I would ask - because I do not know the answer - when you install an enhancement pack, does anything vanish from the standard SAP code base like what happens in an upgrade?

      If so, fair enough, if not then the next time I have to worry is when ECC 6.0 goes out of support (the only possible way my company will upgrade) in 2025.

      Cheersy Cheers


      Author's profile photo Former Member
      Former Member

      We mostly use IS-U (Utilities) internal stuff and FI-CA stuff, so my field of view is rather narrow. We don't actually have a process in place to check what's going and coming... ERP 6.0 EHP5 to EHP7 - I have not gotten to extended syntax check yet, so I just don't know. In EHP5 upgrade there was nothing major which alone would justify 15-30 min investment needed to wrap a FM.

      I like, however, the possibility of clarifying the interface (I've seen plenty of "creative" stuff involving TABLES parameters that makes you stop and "analyse" just how to pass input and what is being changed or exported), mapping to "proper" exceptions (we wrap in static methods, one class per function group; only the stuff in use), and the sense of security - now this function is called in one place in our code. That is of course not 1 to 1 wrap, but still close enough.

      Author's profile photo Valentin Huber
      Valentin Huber

      In addition to recommending "Applying UML and Patterns" by Craig Larman I would recommend reading everything related to domain-driven design which you can lay your hands on.