Project Objectify – continued
Hi SCN community!
If you’re not familiar with Matthew Billingham‘s Project Objectify, please read it before you continue.
The idea is simple… let’s build a set of highly reusable, flexible and helpful abap classes that we share and collaborate on.
Who hasn’t had the feeling to be writing the same code over and over again? To get some document flow, pricing conditions, etc. Wouldn’t it make more sense to have a set of powerful abap classes, properly designed and coded, that you can easily export/import for reuse?
The idea was coined in 2009 by Matthew, and I was surprised to see no one had actually picked it up, so I’ve created a github repository for this, and I’ve started by sharing a few very simple classes, that I hope will set the template for future development.
Here is the link for it: https://github.com/EsperancaB/sap_project_object
Hope to see you there.
All the best,
Bruno
As a "template" for the classes my idea was simple. Each class has a static method for returning an object, like a sort of "factory pattern". This allows you to change this method easily in the future should you want to return a sub-class of this class.
The attributes contain basically the table structure to which the object refers to, and this is populated in the constructor.
I'm open to (better) suggestions 🙂
Best,
Bruno
I just want to elaborate on what I was saying earlier about classifying things in the "hexagon" format i.e. FI / CO / SD / MM. The difference between SD and "order to cash" might seem a meaningless semantic quibbling, so I will got into more detail, and get really heated up about it.
I like to use analogies so I will use the example that when you are writing an ABAP program the language is a mixture of English for the language itself and German abbrievations.for the database elements e.g. WERKS, VKORG etc..
Even in the UK I would not say to a business person VKORG, I would say "sales organisation", in non-English speaking countries the problem is even more pronounced (if you forgive the pun). The reason we have VKORG is purely down to the technical way the system was created.
Now, prior to 1999 it was common to see large IT organisations organise themselves based on the SAP technical model e.g. SD department, MM department etc
Then in the year 2000 the light bulb went on at SAP and they recommended not doing this, but organising yourselves based on the actual business which it is your sole purpose in life to support.
Take an inbound delivery for example. I have seen huge fights about this in an orgnisation with the CO/Fi department structure - MM did not want to touch inbound deliveries because deliveries were the property of SD they use the LIKP structure, therefore they are SD. The SD department on the other hand did not want to touch them because they were created with reference to schedule agreements, which is EKKO, and that is the property of MM.
What s silly argument to have and all based on abstarct technical constructs. If you were to look at it from a real world point of view you would see that an inbound delivery is a delivery of something you have bought, something you have purchased, so it goes into the "purchase to pay" process.
Processes are things that happen in the real world, something business people can relate to. Purchase to Pay includes accounts payable, which is seen as FI technically.
It drive me nuts when you pay ten billion dollars for a PM consultant, and you ask them who does a work order integrate with purchasing or accounting, and they don't know because "it's a different module". The whole point of SAP, it's entire reason for existence is that it is an INTEGRATED system, as opposed to the siloed systems that came before.
Anyway, that's enough on that subject.
@Mr.Bruno - I will "follow" you on SCN, and then you have to "follow" me, then I can send you a direct message with my email address.
Cheersy Cheers
Paul
I've just dowloaded your sales order and delivery classes and will look at them in some detail before commenting, I have equivalent classes I have created, hopefully we can build a "Frankenstiens Monster" from the best aspects of both. Even better, maybe some of the thousand people who have done the exact same thing can also contribute.
Also I would like to bring up the old "people who don't study history repeat the mistakes of the past, those who do study history invent new mistakes" quote.
In this case the history is SAP's BAPI concept, which did not work as well as they hoped. I think we should bear in mind why this did not work so well, which I think boils down to:-
- they broke during upgrades (e.g. from 4.5 to 4.7 the PO BAPI stopped working until I did assorted things, amazingly most BDC's did NOT break, though of course you could not do a BDC on a PO screen as it used "controls" but anyway the whole point of BAPIS were that an upgrade should not have broken them)
- the documentation was simply not there, with one or two notable exceptions e.g. the supplier invoice BAPI was very well documented but most of the time Google was the way to go to learn how to use these things.
- they didn't do everything the actual transaction does. For example I often call the sales order BAPI to do what it can do, and then call a BDC directly aftewards to do the things the BAPI cannot do. Our Z class can hide this from the user, and if the BAPI ever gets better (ha ha ha) then we can change the innards of the Z class and the user will never know.
- the naming conventions were all over the place e.g. CREATE / CREATEFROMDATA / REPLICA / NEW etc... Bruce Eckel said that in the Java "swing" fraemwork you could guess what a method would be called because everything was so consistent. That is the target, we need to look at what SAP did and do the opposite e.g. the term CRUD is widely used CREATE / READ / UPDATE / DELETE. That might not be my first choice, but if that concept is in widespread use then it may be better to follow it than re-invent the wheel.
My wife is calling me, I have to go now!
Hi Paul!
That's very interesting about the BDCs! I always praise BAPIs saying that they are "future proof", because that's what they told me (I haven't been around so long as to have first hand experience of what breaks and what doesn't in an upgrade). Knowing that BDCs are actually more "robust" baffles me.
Anyways, I think a good idea to guarantee a common naming convention would be to create an interface with the standard methods you mentioned, create, read, update and delete, and whatever we might think that could be useful. Even if, for the classes I've created, I've chosen the "get_instance" method to read the initial object instance. I still haven't thought of how it should work when we want to create a new object, but I should eventually.
If you already have a clear structure on how to do it, please share 🙂
Best,
Bruno
Has any attempt been made to take use of the BOL layer available in the higher EHP of ERP that was brought over from SAP CRM. BOL seems like a natural fit, because you have a true layer that abstracts everything for you and then can be consumed elsewhere(i.e gateway, web dynpro, etc).
You no longer then worry about method naming etc, as BOL provides a natural operations on the objects for which you implement the supporting code. Another benefit is that you could technically switch out the db and ui layers out surrounding the Genil/BOL independently without losing the logical business model of your application.
Take care,
Stephen
Hello
Firstly I would be interested to know what enhancement pack that comes with. I am on EHP5 and just had a quick look at the dormant business functions and could not find any likely candidates. Unless this has come in as already active and is part of the normal BASIS / ABAP system.
I find it interesting that SAP are migrating features from "new dimension" products like CRM into the core ERP system, e.g. SEM used to be a separate product but now lives in the core.
I aslo wonder what the logic is (if indeed there is any logic) to having lots of different sorts of business objects framework in the same system:-
Workflow SWO1 objects
Classes for use in workflow as business objects
Persistent Objects
Business Object Processing Framework
BOL
I am going to be doing a lot of investigation into the BOPF thus year so I will see if this is a good underlying framework - once again in that framework there is a place for ervything so you don;t have to guess where to put things.
Often in SAP world I wish there was not ten billion ways to do the same thing .. still it makes life interesting....
Cheersy Cheers
Paul
I found the BOL framework hiding in my system in plain sight in package CRM_BOL. It sneaked in when I was not looking.
It looks like their has been some work done on trying to integrate the BOL (Business Objects Layer) with the Web Dypro Floorplan manager, just like the BOPF (Business Object Processing Framework).
I wonder if next year SAP will come out with another Business Object Framework, there are clearly not enough yet, SAP have what could be described as a "BO Problem" and I think that stinks.
How about "Business Object New Framework in Relational Entities" orto be known as BONFIRE. They could release it in England next November the 5th.
Or "Business Object New Komputational Entity Relationship System" to be known as BONKERS.
Or they could take over a company called Business Objects if they wanted, oh hang on....
I vaguely remember that the BOL was over in ERP, because Thorsten Franz wrote a blog once about it several years ago. I even remember listening to teched/inside track session where WebDynpro ABAP consumed BOL objects on a non CRM system.
No matter what technology SAP chooses for Business Object representation it would have been nice if they would have completed all the needed API's for one set on ERP. For CRM we have no issues in terms of having API's(using them is another problem 😉 ).
Take care,
Stephen
As Paul already mentioned.... Long time ago I wanted to publish a blog about the overlaping of Object frameworks in SAP (Which never was published because the moderator said "is too CRM specific..." so I got mad and I never insisted in this topic again)
The thing is, a couple of SAP rockstars like Thomas Jung, Rich Heilman, Thorsten Franz/Tobias Trapp tried to lead us to the marvelous world of the Persisten Objects, few years later WebUI was ported to the ERP and some questions raised, Why I should go to persistence objects if I had the BOL/GENIL? The business is prepared to assume the time/costs of a good object modeling when they are used to Custom table + Report + Select approach?
Now we have BOL, BOR, Persistence Objects, and who knows what more is under the carpet... So I think is quite difficult to choose a Model approach/technology when each team in SAP move on their own...nice modeling + crappy integration = guess what ? 😉
I come from the CRM world too, INMHO BOL is the best modeling option I've seen in SAP for years, I encourage people who doesn't know it take a quick look to see how awesome can be...some times 😈
Cheers!
Luis
Hi Luis,
Thanks for chiming in.
Feel free to share your experience with BOL!
Actually, there is no need to reinvent the wheel. Like Paul said, that's the beauty of this project. We can "isolate the user" from whatever is running underneath, be it BDC, BAPIs, or BOL, we can use whatever works best for each scenario and provide one consistent framework across the board.
Am I being too ambitious? 😀
Kind regards,
Bruno
Actually BOL actually does this in CRM fully. It's the true logical model that you are looking for, with standard operations designed on all objects(you just implement those operations in your genil/model class). Another wonderful part of about BOL regardless of whether I have business partner or business transaction(aka sales order), I can consume those objects in unified fashion. It's a logical model so you dont' have to worry about what changes above or below.
SAP also extended the gateway to consume BOL objects. So you can actually build REST services on top of these objects in gateway. In standard CRM they have a webservices tool that consumed the objects and built webservices via a wizard.
Take care,
Stephen
Well from the creator of "Persistence objects forever" and from the producer "BOL travels to ECC" we are happy to introduce "BOPF, it comes to kick your a**es"
I guess you would like to check Why BOPF is a strategic part of our application architecture
You know what is the problem in BOPF? It has nothing to do with BOPF itself, but has everything to do with the fact that we have so many BO* framework that the cost of learning starts to take it's toll, and there goes the efficiency.
totally agree, I just pointed the blog because I think may be of some interest, specially the disucussion 😉
And I just remembered one thing, how does BOPF and ABAP in Eclipse go together? I'm sure SAP provided the tools to use BOPF in AiE 😉
yup, are in the same package as the WebUI 😀
Now seriously, if the solution is good enough will be ported to AiE, but to see this...we will need to wait a lot of time with a lot of options to see this not happen, because a new kickass BO* is released, but I really hope this time this model persist and we finally start to have a nice architecture to work with.
Well, it seems it's already in Eclipse! BOPF Modelling in Eclipse
wow, I didn't realized! maybe this time, this time...it worth to invest some time to learn a new BO*
Thanks for taking the initiative in this, Bruno! I hope to add a few of my small helpers for reading HR data and start looking at what else is out there. For now I have at least started following the project.
Hi Eric,
Great! Thanks for your interest and welcome to the team!
I added you as a collaborator (let's see what'll happen!) so if you feel you have something to add to the project feel free 🙂
Thanks!
Kind regards,
Bruno
Hey Bruno,
It's been a while since I made any new contribution to my website's repository, but maybe you can get some ideas there:
https://github.com/abapzombie/ABAP-Toolbox
abapzombie/ABAPZombie-Code-Library · GitHub
I'm following your repo, will take a look when I got a chance.
Regards!
Hi Mauricio!
I have heard about your abap blog (mainly through abapinho), but I haven't ever taken a close look at it. I promise I will soon 🙂
I'm honored for your interest in this project, however, for the time being, there's not much to look at, I'm afraid you'll only be disappointed 😛
I will take a look at your repository soon though. I don't know if I would be able to "fork" some if your stuff into my repository? I need to learn more about how github works 🙂
Abraço!
Bruno
To borrow idea, you just have to copy the snippets, manually or git clone or something else.
Fork is done when you want to improve Mauricio's project. In that case you fork his repo, make changes, and ask him to merge the changes if contribution is good enough.
So, others will fork your project in order to contribute.
Hello Bruno
This project is just for ECC, if not i would be interested in contributing something from CRM Service side.
Naresh
Tommorow I am off to Melbourne for the Mastering SAP Technology 2014 conference.
It will be chock full of ABAP programmers and I will mention this project to all of them that I get talking to.
I don't care if the underlying framework is BOL or WOL or EYEORE or whatever framewrok SAP comes out with next. As mentioned we are trying to abstract things so that even if the (say) BOL is the best framework yet, when SAP comes out next year with soemthing different (and don't tell me they won't) and that actually turns out to be better, it can be swopped in and no-one notices.
Also, I joined GITHUB, and now I am looking for a button to download the NUGG file. I must be a complete idiot, it must be obvious but I haven't spotted it yet.
The nugg files can be reached using folder navigation.
Or you can download the master zip file that has all the nugg and read me files.
Here is the link master zip file.
https://github.com/EsperancaB/sap_project_object/archive/master.zip
Hello Paul,
If you don't want to checkout (clone) the repository, navigate to folder sap_project_object/, at bottom of the menu content on the right is Download ZIP button.
https://github.com/EsperancaB/sap_project_object/archive/master.zip
Cheers!
Hi Paul!
Wishing you a happy and safe journey 🙂
You can download the files like that, or the easiest way would be, like Manish mentioned, to clone the github. You'll need to install the client (I don't know if you use win or mac) and a folder in your system will "mirror" the github. Then, when you make changes, you can sync it to the repository using the client again.
Let me know who you are in github, I'll add you to the collaborators 🙂
All the best,
Bruno
I see it's like that "Dropbox" thing where you install a client on your PC. In my case it would be the windows version. We have two development teams at work, the ABAP team and the "pink shirters" who do all Microsoft type things. As might be imagined our SAP system is about as integrated with Microsoft as can be, all done in-house, with leave requestsa nd even plat maintenance work orders appearing on calendars automatically.
Anyway, I'll download the GITHUB thing when the cnference is over.
One thing Australia has a lot of is SAP conferences, and they are great. The Eventful Group does about seven a year, one for each area e.g. procurement, supply chain, HR. I am at the technology one. It's all real people telling horror stories as opposed to SAP trying to sell you things.
There are people from all round the world here for this conference, I spotted Marilyn Pratt in the bar last night, she is a bigwig in SCN circles as I understand it.
From 1pm to 5pm this afternoon is :Inside Track" which is free to anyone on SCN, and then I have a speaker briefing, and then it is the "demo jam" where people demonstrate their new SAP innovations and try to win.
Then it's drinky time.
Tommorow the conference proper starts, I am talking at 2:2p in the afternoon, luckily I am not in the "graveyard" slot where you are all that stands between people and the free evening drinks. In such situtaions you don;t have their total undivided attention!
Hi Bruno,
I'm with you and I will try to share some.
I just worked through a part of the coding and I'm just thought would it be useful to have some guidelines for naming the variables and stuff like that.
I mean not a big thing Guideline-Catalog, moreover a readme-file with such the basics everybody should use. method-names, variable-declarations and things like that. What do you think about that?
~Florian
Hey again Florian,
I came across something the other day that I think meets what you are talking about almost perfectly:
Naming Conventions in ABAP Objects - ABAP Workbench Tools - SAP Library
Sorry for the delay but my free time has been very limited lately 🙁
I was hoping maybe Paul Hardy could chime in as well but I guess he's been having as much free time as me lately 🙂
Nonetheless, every and any classes that I might need in my day-to-day work I will be sharing them 🙂
Cheers,
Bruno
That's hits exact the stuff in my mind. So in my opinion that should be the very basic for each shared object. It is not that much "guidelining" and I think it will make a lot of coding shareable and similar in reading.
I'm looking forward.. seems to get a big thing and it is now starting with a little delay 🙂
~Florian
Hi all!
I have updated the nugget for the sales order class (NUGG_SALES_ORDER) with the first method that is actually "useful"... SET_DELIVERY_BLOCK.
I also have a class for sales order item with another useful method, but I need to create a folder for it. I'll do that soon.
I'd like you to take a look at it and let me know if this is how you would do it or if you would improve it somehow.
Thank you!
Best regards,
Bruno
Awesome,
I will have a look this week. 🙂
~Florian
Hi Florian!
Have you had a chance to take a look at it?
Let me know 🙂
Thanks!
Bruno
Hi Bruno,
the funny thing is, that I just at the moment I'm taking my time for it 🙂
~Florian
Hi Bruno,
one thing. Do I not see the exception-class in github or is it missing?
ZCX_BATCH_INPUT_ERROR
~Florian
Hi Florian!
That was developed by http://scn.sap.com/people/engswee.yeoh, you have to ask him!
Best regards,
Bruno
Ok, that means we have to wait 🙂
~Florian
But you can check the method "SET_DELIVERY_BLOCK" in ZCL_SALES_ORDER and let me know what you think of it 🙂
Thanks,
Bruno
Yeah, I will. Just fight with the nugget 😆
Hi Florian
The exception class is included in the nugget file NUGG_BDC_MODEL.nugg.
I don't have it as a TXT file as I can't switch to Source-Code mode in ABAP workbench to extract the whole content.
Rgds
Eng Swee
Hello Eng Swee,
you can use Ok-code SHOW_CLIF in transaction SE24. You can download all source-code or separate sections from there.
Best regards, Tapio
Hi Bruno,
used your ITAB class today. Very handy and good to use. I like the "eep it simple but perfect". Thank you. I'm working on my first tool, but I want to deliver the ui as Webdynpro. So I have to do some homework before 🙂
~Florian
Hi!
I'm glad you find it useful 🙂
If you have suggestions to make it better please share 🙂
Best,
Bruno
PS: By the way, what I would be really interested in is knowing what you think of the "SET" method in the sales order class 😛
I'm using the popular sales order BAPI to set the value, however, there is a fundamental difference between the BAPI approach and the object approach... the BAPI is meant to be used to change everything you want "in one go", but, in my opinion, using the object approach, that doesn't really make sense.
I think this will have a noticeable negative impact on performance. Let me know your thoughts.
Cheers!
Bruno
To come back to your SET-method I think we need to have a beer around. It looks very nice to me and I think it is the smooth way to program it.
I would only refactor hard-coded values with constants (Maybe as class-attributes 😕 ).
For example here:
~Florian
Hi Florian, how are ya? 🙂
Did you watch the fireworks last night? Not too bad imo... but I think you wrote the reply above *while* I was watching the fireworks, so I'm guessing you didn't!
But yes, I think eventually we should discuss about the classes, over a beer or equivalent 🙂 Could you add me as a connection (follow me) so that we can send pm to each other? Thanks!
Regarding the hard-coding... I hate hard-coded stuff as much as the next guy... however, I am not a *fanatic* about them. I've seen in many places constants declared like "gc_zero" or "gc_x". This, for me, is non-sense. We have to remember *WHY* using constants is better than having hard-coded values. Which will, in my opinion, also tell us that sometimes there's no added value in declaring a constant instead of using a hard-coded value.
Take a look at Paul Hardy's blog post here. More specifically, the "Constantly Amazed" topic.
In the situation you show in specific, imo there's no added value from using a declared constant. What would you name it? "GC_ZERO"? SAP decided that the header partners in table VBPA are the partners for "item zero". Do you think that will ever change? If it won't, is there added value in declaring a constant, or is it just by force of habit?
Cheers!
Bruno
Hi Bruno,
don't I follow you... Shame on me.
Your right, I didn't watch the fireworks yesterday, because I was too tired. Anyway, I'm absolutely with you. My suggestion would be gc_posnr type posnr value is initial.
gc_x and all this stuff is not necessary, because there is the booleans available (abap_true / abap_false).
In my opinion this is a better way, because if (I know, in this case maybe never happens) the db-initial value will be switched by SAP all of our stuff will work without any hands-on session.
~Florian
Hi Florian 🙂
I still have some reluctance regarding the added value of this constant 😕
If I had to name it something, I would name it something like gc_sap_db_value_for_header, if that makes any sense. And, if by any chance, SAP would change this "rule" from zero to something else, not only would they themselves have to change the standard code everywhere, "we" would also have to go and change this everywhere, unless we put it in some "super global" class...
Again, I hate hardcoded stuff as much as the next guy... I go crazy when I see "vkorg = 'XXXX'" or something like that... but I also go crazy when I see "vkorg = gc_xxxx", if you know what I mean.
Anyhow, I'll change it next time I have work to do on it, only because it's you 😛
Cheers!
Bruno
Hi all,
I added a few classes today. Feel free to take a look.
In the meantime... we're starting to have a lot of dependency between the classes... I'm starting to think it might be better to just have one huge nugget with everything, like the abap2xlsx guys do... Hmm...
Best,
Bruno
Hello,
I come from a non-ABAP background where it's kind of a normal to replicate classes. I have different classes for Delivery in each package/application because in the end it's easier to maintain/test the particular application without breaking another one.
Anyway the idea is interesting but shouldn't the GitHub repository contain the actual code so we can make a fork, and then make pull requests? I only found the Nugg files.
Hi João!
I'm not sure if I follow regarding your first paragraph. I don't see any good reasons to have the same functionality programmed multiple times in different classes (or different packages, etc). If you find a bug in the logic, you will have to go "hunting" around fixing the functionality everywhere...
I would say, if you something specific for your context, create a sub-class and redefine something, but wouldn't you say keeping stuff as centralized as possible is a good idea, even if there's some added effort to maintain and test?
Regarding the nugg files, just click on them. You will see they are nothing but XML files, and the code is inside. Also, I'm using class based exceptions pretty much everywhere, I don't think it is possible to share code-only for these, is it?
Thanks,
Bruno
The main reason is decoupling. You can change one class in the context of one application, without having to worry about other applications.
In APIs there is a lot of reusage (that's their purpose), but that makes it much more dificult to maintain. Changes require a lot more testing, deprecation management, something that a large software house can do, but a small developer will have dificulty managing.
It's easier to fix bugs, but it is also easier to create them.
That's the downside yes, but do you remember any times where a small functionality took weeks to get into production because of all the dependencies that existed? Decoupling leads to more a agile response from the development team.
What you are suggesting is building an API, and that's fine, reusage makes perfect sense. I was just discussing other scenarios.
Class based exceptions are just classes like any other.
EDIT: Slink files would probably be easier to manage, since they contain only one class. If you look at Java or Objective-C projects in Github you will see one file per class (well actually two in Obj-C), that's the industry standard.
Hi again João!
Yes, I think we agree in pretty much everything 🙂
The idea behind this project is building reusable stuff that should cover most common requirements, so I think it's heading in the right direction. If you have other suggestions just let us know!
Have you used abap2xlsx? Can you imagine importing abap2xlsx with slinkee files? I can't.
Best,
Bruno
For installation of course Nugg is better, but Github (and other VCS) is mainly used for collaborative development purposes. For collaborative development, it much better to manage the files separatly.
Think of the Nugg as a binary that you regenerate perodicaly.
Hi again João,
I think it's a very valid point you're raising.
Does that mean that it's not possible for multiple collaborators to work on the same file at the same time? There's no smart merging feature?
And, in your point of view, a user would use a nugget with the entire "project", as in abap2xlsx, but collaborators would use slinkees and one person would only work on one slinkee at the same time, is that it?
And if, for example, a new collaborator would want to change something somewhere, he/she would install everything with the nugget, change the objects, upload the slinkees and generate a new nugget and upload it? Which means, if another person was working on another objects, this person would have to import the new slinkees, and generate a new nugget on top of it?
This sounds like a nightmare already 😀
Best,
Bruno
BTW, a pull request, does it mean "blocking" a file for modifications? I'm not a big expert on github (or on anything else, for that matter 😀 ).
If that's what it means, then having one single file for the entire project would mean the project would be blocked each time someone was doing something, yes?
That is a check out 🙂 .
In Open Source Development pull request works like this:
After some checking I've come to believe that the ABAP for Eclipse isn't ready for external VCS support unfortunately...
Oh ok.
So, according to my semantics, a pull request would actually be a "check in".
And, correct me if I'm wrong, if another developer "forks" the same file, and both of you submit pull requests at the same time for the same file, I guess the maintainers would have to analyze both changes and merge both "manually"?
Regardless, what you say does make sense... I just don't have the time right now to really put my head around it and "formalize" the process. However, if you feel like doing so, you are very welcome 🙂
Cheers,
Bruno
A "check in" is not the same. A "check-in" is when you release the file on your own VCS. A pull request is different, it merges code across repositories, and there has to be change approval from the owner.
The forks work as independent repositories. That's the main concept of FOSS, I can fork your code and go in a completly different (and independent) direction, or I can collaborate with you by submitting "pull requests".
The fact is my approach assumed ABAP could work like Java or Objective-C but I don't think it can. I don't see VCS support anywhere in ABAP for Eclipse, you would basically have to export and manually add each slink file to Git.... Very annoying.
I will make some experiments with EGit but I'm not very optimistic....
Hi again João!
Yes, I had understood the concept, nevertheless thanks for explaining it in detail, now it's perfectly clear.
Indeed, I think we are reaching the conclusion that collaboration will not be easy with ABAP.
But please, if you can, do your research and let us know if you find something helpful!
Also, I'd be more than happy to add you as a collaborator to the github project, should you be interested!
Thanks again,
Bruno
Hello, in regard to having multiple delivery classes in different packages, I have been reading lots of computer textbooks in recent years (many years after starting to write programs in SAP) and though the various authors all disagree on many things they tend to agree on one thing "duplicate code sucks".
Some have even said that the sole purpose of frameworks such as OO programming, are indeed any software framework, is to promote re-use.
As an example we had the same piece of code to create a production order properly in about ten different places, and when the outside world changes, as it has a alarming tendency to do, it took a very long time to track down those ten different places to make the same change in each one.
My understanding is that the aim of OO programming is to seprarate the "things that change from the things that remain the same".
If you had the exact same code in twenty different classes and found a bug, then the right thing to do would be to correct the code in all twenty classes. Then the risk would be that in each class you could make a mistake. Naturally if you were re-using the same code you would only have to make the change once.
If you had the same code being used by each class then when you fixed the bug the problem would be propogated to all twenty classes but the result would be just the same, except that with the twenty different versions of the same code some would be fixed, some not, some made worse.
If you had an actual change, not a bug fix but an enhancement or logic change, just to be applied to one package, then maybe the way to go would be to have the same base code in each class - then create a subclass in the affected package with different code thus ensuring the other packages ae unaffected?
You talk about dependencies being killers for getting small changes into production and how right you are. I presume that is why the OO books constantly talk about breaking dependencies which mostly seems to revolve around the Open-Closed principle - don't change existing code that works (in case it breaks), just add new code only in the exact places it is needed.
Of course then the exact same authors talk about constantly changing existing code to refactor it, so you end up not knowing if you are coming or going.
Yours, very confused, Paul
I agree it's confusing, and there's not a clean answer to this. Part of the reason that SAP's API is such a mess, is that they keep adding new methods/fm since they can't adapt the old ones without risk.
For me it's all about choice. Either your philosophy is to create a clean API which demands huge tests everytime somethings changes (instead of going the easy way, which is to create yet another method with similar functionality), or you go the decoupled route, with code duplication.
I think the code duplications makes more sense when you have focused teams developing each applications, and that specific team becomes responsible for the maintenance. You have a decoupling at both the code, and maintenance level. This is not very normal in a SAP shop, more often then not, you have a package called ZSD......
From my experience, SAP programming landscape could benefit greatly from having programmers from other backgrounds, since the way programming is done in SAP is often archaic.
I looked at it in the past, but it looked so complicated that I basically said "whatever".
If I could expect some stability... and some assurance that this was to be used in the next 5-6 years, but we don't/can't.
Hi Bruno,
Finally I've taken a look on what you are trying to do here... I like it!
This is a project that takes time. And a system to develop and test.
I think that there are some issues in your approach. I would use a CRUD interface just like Paul suggested. It would make it easier to interact to.
Also, I think it misses a "contract": a group of interfaces that describes how all Objects should behave.
I will try to get the time to put my ideas "on paper" and draw some UML schemas. Please don't let me forget about this one.
Cheers,
Carlos