Documenting source code of Web Dynpro for ABAP

[martin_lehmann4]

Hello all,

after having finished our first WD4A application I wonder how to document it. Although the application is quite small (it has only 4 dropdown fields) there are already 10 new methods... How do you maintain such an application? Are there any templates for offline documentation in word? Or any experience with a tool like this one: [ZICDOC - HTML documentation generator for ABAP programs|https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8528] [original link is broken] [original link is broken] [original link is broken]; ? Are there any standards?

I'm curious about your answers, best regards

Martin

[Former Member]

Interesting question - and it goes for most other development work too. My preference is to have most of the documentation within the ABAP environment as there's where you will probably start looking (System status -> Tech details, and into the code...) - although with SolMan, you can now at least have Word documents stored centrally and not scattered across various LAN drives. We're very spoilt in the ABAP world that we have an integrated development environment, with good active "where-used" functionality plus code hierachies in SE80, integrated data dictionary, and the like... which negates the need for some to the tomes of documentation that I used to churn out 15 years ago - e.g. pre SAP, we used to have to document where a DB table was used, what called what etc, but this is no longer needed.

Anyhow, when doing maintenance work on programs others have built the best I hope for is is that there will be some clear narrative at the start of the code that gives you an overview of the business purpose to the development, and then useful commentaries throughout the logic, particularly at the start of forms and methods (but after the form statement, not before, so it's easy to see when you drill into the perform)... some years back I wrote a bit of code that stripped all the comments and performs etc out of a program to make pretty Word documents for one lot of auditors, but it's rarely asked for.

So my opinion would be you put together an "Owners Manual" for the development with screen shots and explanations of any quirks and integration points, plus background jobs, table maintenance routines and such things that support the system - everything else is available online in the ABAP environment, and is always up-to-date.. unlike printed doco.

Jonathan

[martin_lehmann4]

Hello Jonathan,

re-reading your post I wonder what would you do in our case: the Webdynpro relates to BEx variables, TVARVC variables and function modules depending on the variable exit - I couldn't find another solution than to document this in a word document which resides in our SolMan. What you said about inline docu is also important of course!

You wrote:

you will probably start looking (System status -> Tech details, and into the code...) 

Is this also true for Webdynpro? I couldn't find this feature there (like in fm's or reports...)

Many thanks for your input,

regards Martin

[Former Member]

That's a fair comment - and probably applies to anything non-SAPGui based such as ITS, BSP, and RFCs, so you'd first have to track down a start point to head into SE80 with... but once you have the start point, my experience is that SAP's development environment and active data dictionary tools, et al, mean that the formal doco should concentrate on (a) painting a broad picture of the functionality and (b) identifying the hard-to-find types of things you mentioned which wouldn't be obvious to the newcomer e.g. that there is a batch job that updates the TVARVC variables at 00:05 each morning, or that there is an associated BTE exit implemented in function Z_BTE_STORE_XYZ_DATA that extends BKPF data etc etc. And I especially like commentary running through the source code - I know I'm always grateful to find SAP logic that has little chunks of "chat" that explains what is happening and why.

Jonathan

[Former Member]

Hi there...

My preference is to have most of the documentation within the ABAP environment as there's where you will probably start looking (System status -> Tech details, and into the code...) - although with SolMan, you can now at least have Word documents stored centrally and not scattered across various LAN drives. We're very spoilt in the ABAP world that we have an integrated development environment, with good active "where-used" functionality plus code hierachies in SE80, integrated data dictionary, and the like... which negates the need for some to the tomes of documentation that I used to churn out 15 years ago - e.g. pre SAP, we used to have to document where a DB table was used, what called what etc, but this is no longer needed.Anyhow, when doing maintenance work on programs others have built the best I hope for is is that there will be some clear narrative at the start of the code that gives you an overview of the business purpose to the development, and then useful commentaries throughout the logic, particularly at the start of forms and methods (but after the form statement, not before, so it's easy to see when you drill into the perform)... some years back I wrote a bit of code that stripped all the comments and performs etc out of a program to make pretty Word documents for one lot of auditors, but it's rarely asked for. So my opinion would be you put together an "Owners Manual" for the development with screen shots and explanations of any quirks and integration points, plus background jobs, table maintenance routines and such things that support the system - everything else is available online in the ABAP environment, and is always up-to-date.. unlike printed doco.

Do reward if helpful