What standard classes can customers use and how to find them?

[Jelena]

This started as a specific task but then evolved into a bigger question, so let me explain where this is coming from.

We had function modules before, some of them were not released but, of course, everyone still used them. And there were BAPIs (also FMs technically) that were kosher and even documented somewhat.

Now since everyone is saying OOP is like the best thing since sliced bread I'm trying to use more classes in our programs. Of course, I'm lazy and also don't want to create ZSAP, so for some basic needs that I believe most customers would have I'm trying to find some standard global class.

Let's say we have a need for the whole bunch of file extracts. These are all cookie-cutter programs: read data from SAP tables, put it in an itab with the required structure and then write itab into a file (either on app server or presentation server for testing). Nothing fancy other than some files can be fixed-width and some separated (comma or another separator).

We already have a nice custom FM that takes internal table, filename, flag for local file and it creates a file. But now I'm thinking about re-doing it as a class and adding the separator part as well, so the programs would only need to read and shuffle the data.

Writing a local file is easy since as there is a GUI class. The app server - I used Google and searched in SE80 for *file* but could not find anything more suitable than CL_RSAN_UT_APPSERV_FILE_WRITER. Now is this a good class to use? How can I know?

Adding separators also would seem a common task but all the methods I could find were from some funky-named classes and seemed to serve only very specific purposes. There is CL_RSDA_CSV_CONVERTER->STRUCTURE_TO_CSV but it only does comma-separated and, as I found, doesn't add quotation marks as I was expecting.

Is there some kind of repository of the standard ABAP classes that are OK to be used by the customers? Otherwise how do we search (other than wild-guessing in SE80) and how do we know which classes are "good" and won't be suddenly changed by SAP?

For some reason I find that even Google is not as helpful in finding classes as it was with FMs.

[raghug]

Jelena,

I think this is more a philosophical discussion where you are going to see a lot of emotion and also "book" knowledge thrown at it. I have had similar general discussions about the entire philosophy of common routines / documentation / knowledge transfer many times. I can't wait till there is a real solution - something like artificial intelligence that will read my mind and tell me exactly what I should use. But, at that point I think we will out of jobs!

Here is a little background of my experience in my own little world (and will also explain why I don't know to link quantity fields to units ;)). I work in a very narrow niche of Warehouse Management and RF barcode scanners and getting them to work. Because I work with a client for a short amount of time and then move on to the next client, I have an entire library of functions and classes that help my write these RF Dynpro programs in both an efficient way and in a manner that is specific for SAPConsole (least common denominator of RF interfaces). At the end of each gig, I usually go through a couple of weeks of knowledge transfer to the client's internal programmers. This includes handing over documentation and describing all my common routines (FMs, Classes, etc) in class room sessions, making sure there is online help, comments in code, explain why I don't use numeric fields or any field with a conversion exit that could raise a status bar message - basically anything I can think of to make it easy for the next person.

Invariably the next person to go in, even the same programmer that I gave all the "knowledge" (just feel the force Luke) to will ignore all that, try writing a program on their own and then I get a call a few weeks later that they screwed up. I find that even if they are in my code, sometimes they don't understand why have a "Z_RF_POPUP_TEXT' and just change it to the SAP provided 'POPUP_TO_DISPLAY_TEXT' and gloat to their bosses that they went back to standard. This is despite classroom sessions, documentation, etc, etc. Then I get a call saying "your **** doesn't work".

Jelena, what you have described is what a diligent person does in trying to keep a good tight system. Unfortunately, people like you are few and far between. I think the answer to your question lies somewhere between a system to make it happen and human nature. As long as the average human nature is like I described above, I think we are going to have a hard time with common code bases. They work in the short term... but they get messy as time goes on.

[raghug]

PS - About your comment of "even Google is not as helpful in finding classes as it was with FMs", I think it will just take time for the classes to catch up - until then people, including SAP themselves will be busy writing new versions of the same old stuff. For example in SE24 just do a search for *_DATE_* and based on a quick look there seem to be several classes that do relatively generic date and time functions. When I was looking it took me forever to reach to CL_ABAP_DATFM and CL_ABAP_TIMEFM.

Or another great example of where Google does work, is SALV classes. If it wasn't for Naimesh Patel's blogs, I wouldn't have had a clue where to begin.

[horst_keller]

My five cents: Around release 4.6 SAP Basis started a project "Reuse Library". Well, it was a complete failure. And that is a symptom of the dilemma. At SAP, there simply is no department that provides general classes for everybody's need. We have framework classes like SALV, system classes like CL_ABAP_..., ... but not such general service classes you are looking for. Those are specific for their applications, as it was with FMs before. Of course, you can go and search for specific names and try to reuse what you've found. But as a rule, they are not released for general purposes.

[Sandra_Rossi]

I guess we'll have as many answers as there are developers.

My global strategy, by priority:

• Use ABAP statements preferrably (OPEN DATASET)
• Otherwise use SAP documented/supported objects or ways to do things (but we have to search for them, and we even discover the right ones too late; ask experienced people to avoid this)
• Otherwise use any of them (and of course never copy them, prefer doing a smart modification)
• If they are later modified by SAP, then cry and adapt your code 🙂

[SimoneMilesi]

I think Jelena's dilemma is: how can i find the right class and if it's released for customer's use or only internal one.

It seems, but it's just my feeling, that the difference we had (and still have) in FMs between released for customer/internal use only no longer exists in classes.

But i can be pretty wrong 🙂

As both Horst and Raghu pointed out, it seems that classes are a open, wide, space still to be explored and shared 🙂

[Sandra_Rossi]

Yep I forgot to say it clearly

[SuhaSaha]

I would like to throw in the term "Package Interfaces" here:

There's a blog series from tobias.trapp -

• https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/
• https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packa...

I tried to activate "package" check in our landscape but TPTB were not so amused about it and the idea had to be dropped.

I work in a SAP module where "released" FMs are far & between. Even the BAPIs are not released o_O

[raghug]

Is it time for a curated open source library of these kinds of functions? Who wants to host?

[Sandra_Rossi]

Unfortunately, according to me, it won't work. By far, search the web or do it yourself (if you can) are the best solutions.

[Jelena]

OK, so there is no library or any organized repository, it seems. But, as Horst noted, there are still some framework etc. classes that kind of need to be used (it wouldn't be effective or even legal for the customers to start inventing ZALV). So this still leaves the question - how can the customers tell those classes from the others?

As I mentioned, there is no "released" flag. Documentation doesn't seem to be maintained consistently. E.g. BCALV_GRID_DEMO report in our system is using CL_GUI_CFW class. It has no documentation and a whole bunch of methods that have "do not use!" or "internal use!" in description. CL_GUI_FRONTEND_SERVICES does have a documentation but CL_BCS does not.

I understand the concept of separation by application and yes, in some cases it is better to have some overlap to keep things in their own packages for different reasons. But this does not negate reusability. E.g. in our system as soon as we realize something gets used repeatedly we check if we can put it in a separate object and reuse it. Otherwise you end up with the whole bunch of modules where each has its own "find first date" class that does the same thing. But I digress.

[horst_keller]

So this still leaves the question - how can the customers tell those classes from the others?

A generally available framework must be documented. If there is no class documentation of a class that forms part of an API, the framework documentation must describe its usage. Ideally the class documentation points there. If there is no documentation at all for a class that is clearly part of a generally available API, this is an error according to the product standards.

E.g., the SALV and CFW classes are documented in the portal, the ABAP system classes are mentioned in the ABAP documentation. And as I said, alas, we don't have a reuse lib for general purpose classes.

Sometimes quasi standards might emerge by mouth to mouth propaganda. The (documented) CL_ABAP_BROWSER is an example. I've written that for usage in the ABAP documentation alone, but chosen a (maybe much too) general name ...

[Jelena]

Thanks, Horst. I guess this answers it as much as possible. 🙂 Since this is posted as a comment I'll have to pick the actual answer above. New SCN is confusing...

[kiran_k8]

Gone through the series of blogs on ABAP Package Interfaces by Tobias,but I was not able to comprehend on how this concept can be used in our day to day development activities.Moreover,creating a Package is mostly considered as a Basis activity so I am still trying to understand......

Is this just limited to group commonly used FMs or Classes so that they can be found easily in the form of a repository or there is more to it from the coding point of view.

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packa.../

"If you want to use these functions in a package you should define a use access in your application"- Quoted from the above series of blogs

When we can call the FM or Class without bothering about under which package it is,Can anyone here please let us know what is the advantage of defining a package interface ?

Thanks,

K.Kiran.