Many times, I come across lot of Design Issues in Smart Forms. So, thought of compiling a list o best practices.
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.
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
- 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 naming, nodes would be like:
Properly documented node will help you and others to understand the purpose of the 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:
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.
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.
SmartForms Error Handling
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.
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.