Many times, I come across lot of Design Issues in Smart Forms. So, thought of compiling a list o best practices.

Introduction

Majority of clients where I have consulted so far, I have seen many Smart Forms in Production system. Adobe Forms are there which gives more advantages, but Developers are more comfortable with Smart Forms so they are investing in Smart Forms. As part of my QA review responsibility, I come across Smart Forms which would work fine but have lot of “design” related issues.

Best Practices

Here are few of DOs and DONTs when working and designing a Smart Forms.

Don’t slam Code lines

Many times, Code lines are slammed with lot of code.

Few reasons, you should NOT slam code lines node within the Smart Forms.

• Very small Editor: When you open the ABAP Editor to maintain the Code Lines, you would notice a very small window. If you are using a “normal” screen, you would run into double scrollbar issue as well. Since it is having double scroll bar and small editor, it would be difficult to write a code within it.

• Difficult to find: Since Code lines can exist at any node level, it would be very difficult to navigate when required to find a specific code lines
• Commented Code: Commented code in the beginning of the program lines, makes it more difficult to determine if there is any code or not.

Instead, you should think about alternative approaches:

• Code Lines Node Usage: Use it only to do formatting on the data Code lines should be used for very few lines of code.
• Segregation of the Logic: Try to wrap the logic in an Object or a FM which can be easily called in more than one places. This would give you an opportunity to re-factor your code, write an ABAP Unit test case, Inherit existing functionality (if ABAP Objects is used)

Rename each and every Node and its description

Justifications to rename every node

• Unclear Purpose: If you don’t rename difficult to navigate and understand the purpose of the node. Its difficult to find relevant node and locate it. You can search the text in the FM by if the node is not renamed properly it won’t find it

Without proper naming, nodes would be like:





Properly documented node will help you and others to understand the purpose of the node:


• Translation in SE63: Without proper name of the text node, it will appear like a TEXT01 TEXT02 etc. You would need to pay lot of extra attention to make sure you put the correct translation to correct node.

Without proper name, you will see this in SE63 while translating the SmartForms



With Proper Name, you would see nicely named text symbols in SE63:

Inactive Nodes

Many a times developers use 1=2 in condition to make that element “Inactive” from the form. This technique is fine as you want to retain that node and relevant logic within it. But, not maintaining proper documentation would make maintenance difficult. So, Make sure you update the description with phrase like COMMENTED, NOT USED, INACTIVE, etc.

Eventually in subsequent changes, these inactive nodes must be removed from the form. Too many inactive nodes will take long time for From to process.

Without Properly commented node, would be lost in the node tree of the Smartforms:

With proper comments, easy to find Inactive nodes:

Avoid Using Templates

Template needs definite space on the form. If you have many templates in single window which are conditionally printed on the form, Form will not complaint about the height of the window at time of Syntax check. This error will occur at run time and would be difficult to track.

Try to use LOOP with TABLE LINE. This will make sure that you don’t need definite space when you are printing dynamically.

Error Handling

After each generated FM call, make sure you get the errors as well whenever there is any exception. Call FM SSF_READ_ERRORS to retrieve the error message. Pass these message back to the NAST protocol if the SmartForm is being called from the Output control.

 
 
CALL FUNCTION lf_fm_name
     EXPORTING
                archive_index        = toa_dara
                archive_parameters   = arc_params
                control_parameters   = ls_control_param
                mail_recipient       = ls_recipient
                mail_sender          = ls_sender
                output_options       = ls_composer_param
                user_settings        = space
 
     importing  job_output_info      = ls_job_info
     EXCEPTIONS formatting_error     = 1
                internal_error       = 2
                send_error           = 3
                user_canceled        = 4
                OTHERS               = 5.
IF sy-subrc <> 0.
*
  DATA: LT_ERRORTAB             TYPE TSFERROR.
  FIELD-SYMBOLS: <FS_ERRORTAB>  TYPE LINE OF TSFERROR.
*
* get smart form protocoll
  CALL FUNCTION 'SSF_READ_ERRORS'
    IMPORTING
      ERRORTAB = LT_ERRORTAB.
*
* add smartform protocoll to nast protocoll
  LOOP AT LT_ERRORTAB ASSIGNING <FS_ERRORTAB>.
    CALL FUNCTION 'NAST_PROTOCOL_UPDATE'
         EXPORTING
              MSG_ARBGB = <FS_ERRORTAB>-MSGID
              MSG_NR    = <FS_ERRORTAB>-MSGNO
              MSG_TY    = <FS_ERRORTAB>-MSGTY
              MSG_V1    = <FS_ERRORTAB>-MSGV1
              MSG_V2    = <FS_ERRORTAB>-MSGV2
              MSG_V3    = <FS_ERRORTAB>-MSGV3
              MSG_V4    = <FS_ERRORTAB>-MSGV4
         EXCEPTIONS
              OTHERS    = 1.
  ENDLOOP.
ELSE.
*
*    
ENDIF.
 

Breakpoints

Since many of the developers feel comfortable putting break point in the code lines for debugging purpose even though you can achieve Smartforms: Dynamic Breakpoints. If you have hard coded break point it would make it difficult for you to debug the same form in Quality system, where you don’t have access to remove the form. You would think, “Oh man, Why didn’t I remove this?”

Do you follow any other Best Practice?

Please let me know, if there is any other best practice, you are following.