Skip to Content

Hi all,

As in my blogs before I’m a fan of the counting things. Today I want to share my experience in an area I’m a heavy user. I develop a lot of forms in my career as an ABAPer and I also worked through a lot of it. Unfortunaly I also see a lot of things, which make a form very hard to understand and out of that, form-programming is one of the things a lot of developers do not like that much.

In my case, I’m very into it, because I like the output in the end. Sometimes I get a paper in my hand, I developed before and now I’m one of the “aimed” which the company wants to provide information.

Ok, there are also some, I do not love to get in my hand, bills and stuff like that 😆

Back to the topic, what I wanted to say before is, that forms doesn’t have to be complicated and difficult to debug if you follow some rules and with this blog I want to share some of the main rules you should really set a focus at.

I’m not saying that there is for every special case a solution in, but I’m absolutely convinced that 95 percent will be getting easier to handle by one of the guidelines here.

First point: Give your smartform a name, which is readable


This is an easy point to archive, but why are names out there, nobody can understand. I mean, is it really necessary to name a form WLF_INVLI01?  You got enough letters left, to provide a readable easy to find name to your form… I think there are the 2KB left on the disk

2nd point: Name your nodes, use the description field


Another easy enemy to fight. I know it is always a messie work to go through the tree and give everything a name. But be sure, as in another blog I published, your work will return one time and be sure, a form will return a lot earlier than the rest 😛

You will love the minutes, you invested in this point.

3rd point: Use folders in your main-window


Add folders as much as you can, it is a fantastic thing to get a clear view in your form, it makes the life a lot easier and you will find the correct spots to enhance something a lot faster than before

4th point: Mark your special things in the form


Everybody who ever developed a form came once to the point thinking about saving a coding for later. Customer called, say something is to replace and you, as a developer, know right in that moment, this coding returns and you do not want to trash the output before.  There are two ways to fight a thing like that: First is you save your form with all data, you just download it or create a copy in the system. That works most of the times not that good, because it is just a little spot you want to save for further developing. That’s the point I refer to point three again, if you use folders you can deactivate it by adding a condition 0 = 1 (you know, code inspector do not like 1 = 2 that much 😈 ) and give a clue to it.

Perhaps as shown below.

5th point: Create easy Conditions if you really need some


Most of the conditions in a form I see are really not necessary. It would be a lot easier if the content would be passed to the form in way, it is printed. But if you really need to develop conditions, create easy conditions. Do not double your conditions, just because you need to hide two or more fields at once… again point three cross our street ❗

6th point: Do not hide coding-nodes in your form


We all know, it is a really easy thing in a smartform to add some values to an output. Developers might know sentences like “Add me additional customer-number right at that place.” Doesn’t take long, am I right? Yeah, but that is a returning thing in a way, nobody wants to face. It is fast and easy to create a coding-node in the depth of your smartform, but does your younger colleague next to you find it again. Or better, do you remember that node in three month again? Exact that is the point, you dig a grave and waste a lot of time in future, just because you save right now 15 to 30 minutes to do it in a good way.

7th point: Do not use the coding-nodes

Right before we talked about creating the nodes and now I’m saying do not use it at all? Are you crazy? No, I’m not (at least I think that 🙂 ) and why I’m adding this as an extra point. I’m adding this as an extra point, because there are a lot of disadvantages. You know, the editor in the smartform itself is a joke, isn’t it? Not big, hard to read and if you write a few lines, you aren’t able to see everything. You have to add every import and export parameter extra and if you delete or rename one, you can easily waste 20 minutes with searching your form. Why don’t do things like that in your driver program. Big editor with all advantages, don’t have to say anything more here, do I?

It is all stuff which could be passed to the interface as well or at least done in one coding-node.

8th point: Name your global and local variables in a good way


As mentioned in my intro, I work through a lot of forms and I’m always asking me, why people think, that a form is not restricted by the guidelines at all? Every developing is related to the guidelines, name conventions and stuff like that, globals start with GV_, locals with LV_ but having a look into a form brings names like SF_ which might be standfor smartform( if you found the transaction code I think you know where you are) or even things like nothing before…

I can just say, take a look in your guidelines and use the guidelines also here, just because it is a generated coding and it doesn’t look like developing a program it is Coding and so your guidelines take also care of this part of the project.

9th point: SELECT from database is not a good solution at all!


It doesn’t matter in what context you are working, but I see a lot of SELECTS in the form-programming and I ask me every time the same question. Why do people think, that a form does not also get a count on the performance side. I mean, nobody would just program select without thinking twice in order confirmation or price-routines. But in a form it doesn’t matter? I know, nobody is perfect, sometimes it has to be fast and however you didn’t recognize it afterwards and it’s gone.  Just a example, there is a form with  30 SELECT-Statements in there, whoever work through all of that to see if it is required? Yeah, we all know the answer. There are a lot of companies out there and earn their money with performance-tuning. Here we got an easy way to bring our part in. But you have to remember it during you develop it. Spend now 20 minutes longer will save you in the future hours of refactoring and junk searching through junk forms. I know that feeling very well 😥

10th point: Use the interface


And here it is my major point. Most of the other points hit in that direction. Use the interface. If you do not know why, just go to point one again and start reading again 😀

Thank you for reading to the end. I know, smartforms and all the form stuff aren’t that popular, but you know, in the end of each project and each single step in every company there is an invoice.

Feel free to add additional points or leave me a comment. I’m very interested to learn something new everyday, as you perhaps know.

Cheers

Florian

BTW: Most of the points are also the same if you use Adobe-Forms. It is the mass of javascript to avoid there 😉

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Tammy Powlas

    Great work!

    I haven’t had to develop in Smart Forms in a long time but if I get the opportunity I will check out your tips.

    Smart Forms are everywhere inside SAP ERP.

    (0) 
  2. Suhas Saha

    Hello,

    First of all, i hate developing forms! I hate them because of the hours you waste designing it but at the end of the day the business team is never satisfied. I hate those cosmetic changes 😡

    Sometimes i create a code-block(Program lines) and add comment about what the subsequent nodes are doing.

    For e.g., most-of-times you build a form for a standard SAP application & in this case the interface is fixed, in that case you have to do certain calculations, DB selects etc. In case of “table” calculations (e.g., sub-totals), i insert a code-line before the “table” and comment about what i am doing in the “table” loop. I think this is quite useful for the developer who has to maintain the form.

    BR,

    Suhas

    (0) 
    1. Florian Henninger Post author

      Yes of course, there are some situations left, which make a coding-node inside a good solution.

      The cosmetic changes are always a lot of work. But if you do it as much as I do you get a own view to this small details and in my case it is more me saying that we have to change things, not the business 🙂

      ~Florian

      (0) 

Leave a Reply