Getting adventurous – planning to switch a function module from using forms to using methods
Those of you who have been following my blog posts and reading my questions are well aware that I’m having a hard time wrapping my head around anything ABAP-OO. Over the last months, I’ve however taken the first tentative steps and at least written a couple of report programs utilising local classes and methods instead of doing everything with forms. Of course, these were nothing fancy, just some data retrieval, processing and generating ALV-lists or output files, learning about and using some neat RTTS classes while doing that to quickly get things like field descriptors for column headers.
Fair warning of what’s to come
This blog-post is perhaps a bit unusual in that I first describe what I already have and will then ask for help to – potentially – switch my working form-based code to making use of a local class with relevant methods instead.
So, I recently created a new function group and module, well knowing that I perhaps shouldn’t have – but old habits die hard and my first goal was to get “something” working out there instead of having to simultaneously deal with the logic itself plus not really knowing what I needed to do where with ABAP OO. The gist of what the function module does is to apply several checks on an entered but not yet saved transport title when a transport is newly created. It will eventually be called from Badi CL_IM_CTS_REQUEST_CHECK in method if_ex_cts_request_check~check_before_creation but at the moment I still have it just as a standalone function module for ease of testing via SE37 and at the same time not annoying my colleagues while testing stuff. That’ll come soon enough!
What I already have developed
Here is the gist of what the function module does and uses to do its stuff:
- A Z-table to define the developer type based on the username (we can tell via the username if it’s a regular user or one used for special purposes like e.g. data dictionary activities)
- A Z-table to define which component is expected to be included in the transport title (change-identifier, country-identifier, developername)
- A Z-table to define allowed identifiers, either as plain text (e.g. “Basis”, “ProjextXYZ”) or a REGEX pattern (e.g. “1\d-\d\d\d\d-C for a change-ID looking like “18-0815-C”)
- Incoming parameters are just the username and entered transport title (AS4TEXT) plus the transport-type with “K” for “Workbench” being the default. I’ll most likely start with just calling the FM for workbench-transports and ignore customizing ones which usually aren’t tackled by developers. Not to mention that trying to enforce dev-guidelines for customizing activities is a completely different kettle of fish!
- To begin with, I get the needed information from the Z-tables so that I know what needs to be looked for in the transport title as combinations of IDENTIFIER, COUNTRY and DEVNAME are possible dependent on determined usertype
- In a loop, the expected identifiers are tackled and the title gets queried for each of them in turn in its own form-routine (yeah, I know, the “f-word”!)
- If an identifier is missing, an entry is added to the table eventually used when function module POP_UP_TO_GET_VALUES gets called to ask for any missing identifiers in, well, a pop-up!
- When the user gets the pop-up it’s only asking for the missing values and also shows the incoming transport title
- The pop-up cannot be exited without providing valid input, which means that the earlier checks are done again, just based on different fields
- Error messages with long explanations are provided to make it clear what is expected for each field
- Once all checks are satisfied, the title is accepted and the function module has done its task
Where to go from here
Apart from some fine-tuning, the function module is basically good to go into the Badi and that would obviously be the easy way out for me. It would however most likely also not be the best way out and I’m well aware that some options available with ABAP OO – like unit testing – would have come in handy for at least some of the on the spot testing while putting the code together. And no, I wasn’t even contemplating TDD for this as I actually wanted to get something done fairly quickly and not having to deal with one more complication on top of everything else.
Sooo, long story not so short, what I’d like to do next is to somehow introduce a local class in the function module and to then – step-by-step – switch one form routine after the other to a method. I’m even contemplating leaving the tested and working form-logic in the code for now and to temporarily introduce a flag via which I can make the function module either go the existing form- or the new method-route. That way, I’ll for one be able to do side-by-side testing and for another really see and thereby learn where things stay the same and what needs to or should be changed. This may be way over the top for many of you reading this but it’s the way I learn best.
What I already saw in the function group’s main program is a commented out line for INCLUDE <fg-name>P… with a tentalizing comment next to it indicating that it’s for “Local class implement”. So this to me looks as if what I’d like to do is possible, even more so as the help for function modules also mentions to use calls to methods instead of forms in order to follow the ABAP OO guidelines. My problem is, that I haven’t found an example of what I actually need to do where and in which sequence.
Anybody interested to help me with this? Mind you, I’m not asking for done and dusted code, just some guidance of what I need to add where, how to call things and how to properly copy my code from form-routines to identically working local methods. I don’t necessarily plan to go all-in, meaning that my main goal is to move things somewhat in the right direction but it doesn’t have to be picture-perfect by dotting all the i’s and crossing all the t’s for “pure ABAP OO” unless it’s easy to do and understand for me.
Once this is done and dusted, I’m fairly certain that a follow-up blog post will see the light of day, potentially with some side by side code. That’s at least what I’d like to get from this exercise for future reference.