I have taught beginners in my company how to create Adobe forms (and some of them are very lazy at the beginning… and at the end as well). I have helped some people in the SDN forums (which are new to Adobe forms as well, or were asked to repair “a little bug or two” and they don´t do Adobe for their living). And I have continued the development of the forms originally created by other people. I have found what dirty stuff people do in a hurry or just because of the mentioned laziness. This blog article is not a brand new idea but continues the idea presented by Bernhard Escherich in his blog post “Damaging your SAP Interactive Forms by Adobe project effectively”: Damaging your SAP Interactive Forms by Adobe project effectively. The only reason is that his blog post was non-technical and mine is about the planning and development.
I am known for my extreme opinions so maybe you will read about things you do “every day” in your Adobe forms or you don´t consider them to be bad. In that case we can expect a nice discussion :))
What people do and should be doing in Adobe forms: (bad or causing errors).
- Start the development immediately! – I have posted a blog called “Adobe forms: Use your imagination (first!)” (can be found here: Adobe forms: Use your imagination (first!)). A developer can avoid most of the problems using the proper/ suitable design (like when you use table of tables instead of a plain table to use sub-headers etc.) . It helps with the formatting of the form, form behavior through scripting etc. Mostly people are in a hurry or are used to design forms in one way and do not think about the consequences before they actually start the development.
- Change SAP standard forms although you need like 5% of the standard features – this is my favorite advice and based on m personal experience. If you would like to share the feeling, please find the MEDRUCK form in your ERP and check the form layout and the interface/context. You will find quite a complicated layout with a lot of scripting (especially what is seen based on which variable tec.) and of course a lot of data. I was asked to create a MM form for PO and the given problem was quite far from what the standard MEDRUCK does, but a colleague of mine recommended me (very much beginner at that time) to use the standard form and adapt it. I spent days trying to change it the way I needed. At the end I created a brand new form in a day and satisfy my customer.
- Try to implement the scenario these forms are not made for: My favorite questions in the forum are about things that cannot be done or you grow old first. Forms are a super-cool GUI technology but they are expected to be simple/ straightforward/ easily maintainable etc. Use Adobe forms as “forms”, not as a brand-new-portal technology, much-better-than-bugzilla technology or super-secure-hidden-secrets-whatever. For example do not try to do actions which you don´t want the user to confirm. I call these “silent actions” and they´re a (1) security risk (2) not possible at all or need weird workarounds. Yes, printing without confirmation can be useful. But to send/ receive something without the user’s knowledge is not a good idea (just an example). Do not try to make your form send himself somewhere. If you have recognized some of your ideas, go write sci-fi, not Adobe forms.
- Always start from scratch: do not share any parts between your forms. Do not write reusable scripts. Especially do not create custom library components!! (for everybody who is interested, I have written a blog about it: Adobe forms: About the custom components). Be careful and always make sure your forms headers are all different (very good with business and HCM forms, your customers and employees find that very amusing…). Secret: Do not use variables and scripting objects! Never!
- All form variants should share a single SFP/ form object: Sometimes you need to create the variants of the basic form. For example for various departments. Or for the process roles. Try to keep all the variants within one form. Do not write a word about these variants nowhere in the backend coding or in the form. Use a lot of coding to change the form appearance and behavior based on these variants (do not use variant codes, use only form fields values combination for your long if clauses). Tell everybody that you´re a hero and you´ve spared a license or two because you´ve created a super-combo-multi-purpose form.
- Use obscure options how to do things:
- Use interface coding whenever it is possible. It is always fun to continue the form development where there are some ghost friends (data extraction/ transformation coding can be found on various places, combination with in-form scripting helps a lot).
- Use hardcoded values in your scripts, it is always fun to guess what they mean.
- Use tables (I mean the element table, like the MS Word table, not a table created from subforms and fields), they have so many features you cannot get any other way.
- Use positioned subforms. It is so good to slide the elements there and back every time you need to change the caption to re-fit the form. And they look so good. I would say… precise!!
Yes! It can be done! But that does not mean you should do that.
In the following days and weeks I am sure I will find some more pieces of advice about how write the messy forms. So this is probably not the last post on this topic. Remember Einstein and his legen-wait for it-dary quote: “Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.”
P.s.: I hope this post won´t get misunderstood.:)))