Some Simple Innovative Ways – Program Documentations

One of the best practices I believe in programming is to ease the effort of fellow programmers and oneselves by creating some simple generic objects or tools, so to fall inline I planned to get by hands dirty and made use of my active grey cells to come up with some what crude tools which turned out to be quite useful. Pleased and satisified with my self-proclaimed achievments I planned to put those programs in a common server so that anyone can pick it up. So I used the wonderful saplink tool and uploaded the programs.

Things dont stop here, as only I know how those can be used and what it can or what it cannot do. So where do I convey that, I did not want to enquires to be directed towards  me, so perhaps some good documentation explaining the functionality and usage will do a lot of help. Now, I look at what are the options available to me to make this documentation easily accessible.

1. Inline code documentation, this only helps the programmers and no one would want to peruse my thousands of lines of code to understand the ways and means to use it
2. What else, ofcourse I can maintain the program documentation from the program itself that brings up an [i], but that one is too restricted and does not allow comphrensive explanation.
3. Create some word docs and put it up in share folder or share point, or may be even SOLMAN, but again he user needs to have access to those servers, so that is again a pain point
4. I was just wondering if had I left any stone unturned, and then this idea popped in my mind, why not store the documents in SAP and bring it up on a click of button in the selection screen, so I freezed on this idea and went ahead with some more development, and this how it went.

As the first step, I had to decide where to store the documents. I had three options in my hand, one is to store those documents as binary in Ztables, another second one is to have it on the content repository server, and the third one is to have it on the app server.

To make my life easier, I chose to go with the first one. so here we go,

a. Create a Z table with fields as in the screen shot, the objname should be the name of the program. the content field will store the binary content.

As a second step, we need to create a document upload program.So I built a simple document load program which basicall reads the document in binary and then zip and store it as binary string. Store the file names against the object names and also the file/mime type.

As the next step, build a small web dynpro component with a view with an ALV with a hyperlink to click on the document. Am limiting to the scope of the document and not going about explaining how to create web dynpro component. Ensure you pass the object name and the URL parameter and trigger search function automatically in the component. Ideally, you would not want the search buttons in the component, but this component was developed generically to search for documentation.

And Finally, we come to the last step. A bit of coding in  the actual program.

a. Create a function button on the selection screen of the program using the selection screen commands.

   SELECTION-SCREEN FUNCTION KEY 1.

b. then at the selection screen event just call the web dynpro component to open up the web dynpro listing the documents

   AT SELECTION-SCREEN.
   if sy–ucomm eq ‘FC01’.

   CALL FUNCTION ‘CALL_BROWSER’

so this is how it looks and works

On the click of help doc icon, the web dynpro launches with documents already searched from the table we loaded using the load program.

And then on the click of the hyperlink you have the document popin up.

This is a simple approach to have documenation available on screen, nothing geeky about it. Hope you liked this innovative way.

Your comments/ratings are an inspiration to innovate more 🙂 .