cancel
Showing results for 
Search instead for 
Did you mean: 

How to debug the WWI workprocess ?

christoph_bergemann
Active Contributor
691

Dear all

for one WWI layout we have identfied a very interesting issue. If we use the WWI layout using "Report from template" we can not generate the issue. The issue seems to happen only in a "mass" generation using "Create report" using generation server farm.

E.g. For Switzerland in most cases you need to support in Safety Data Sheet "DE, "IT" and "FR" as a language. Using CG02 you can generate the three reports in "one run".

The strange effect is now that for one customer WWI symbol the "first" report ist "ok" but the next reports not (we could see this as well by looking on the "time" of the generation of the corresponding WWI report)

We have identified the corresponding WWI report symbol; we can "debug" the "Create from report" process etc. But here; anything is fine and we can not reproduce the issue

Any idea on your side for an "effective" debugging of the Work Processes?

We will create a "test specification" with a "simpler WWI" layout and we still hope to find some approach for debugging..

We assume that some relevant "flag" is not reset. As a consequence: a phrase, which should show up, is not showing up (the phrase text should be passed back using "EN" as a language; and the phrase does have a "EN" phrase position)

In our case: the return value is "space" (empty) and therefore no text is shown in WWI. In value file we can find as well the symbol but without any assigned text.

The issue is clearly on "ABAP side" and not WWI side. So from my point of view. It would not help to use "WWI log" on gen server (but we will check this again)

So any idea would help.

C.B.

Accepted Solutions (1)

Accepted Solutions (1)

Mark-Pfister
Active Contributor
0 Kudos

Hello Christoph,

I found this way the easiest to be done:
In the function module that you want to debug add an endless loop with an exit condition like:

data: lv_exit type boolean value false.
while lv_exit = false.
endwhile.

This will force the background job for the WWI generation into an endless loop.

Go to SM50 and located the work process that is hanging in the endless loop.

Select the job and in the menu choose:

--> The debugger opens at the endless loop. Change the lv_exit to true and start debugging.

There plenty of other ways to do this - this is my preferred way if I can debug on a development system.

Best


Mark

christoph_bergemann
Active Contributor
0 Kudos

Dear Mark

thanks. Very simple approach... in the meantime we can see some results. During the read of phrase text the internal buffers for "phrase reading" seems to get cleared. We do no unerstand currently why it does not happen in the first run; but now we know much better the issue and in which place it is located.

C.B.

PS: for those who are interested: issue is related to chapter 14 and the "languages" used there; we need to look "deeper" as we are using very special WWI logic there. Interesting is only. Nobody realized the issue before andespecially in this area: No OSS etc. was implemented

Mark-Pfister
Active Contributor
0 Kudos

Dear christoph.bergemann,

Glad I could help!

I recently run into an issue with phrase languages as well - not WWI Related by it was a special C14K_PHRASE_CHECK FM.
Basically the issue came down to this:
When calling a specific phrase language FM from SAP (C1F0... I think it was) without languages it reads and buffers all phrase languages (Call 1).
And coding that would read with a specific phrase language would work just fine (a bit impermanent as the first call read and buffered to many languages) (Call 2).
Then a call of (another?) phrase read FM was added in between Call1 and Call2 - that read with a specific phrase language. That somehow re-set the buffer and Call 2 didn't work anymore.
I could imagine you have a similar issue with the phrase buffer.

Happy debugging 🙂

Mark

christoph_bergemann
Active Contributor

Dear Mark

with your last feedback you have nearly hit the issue/ problem. We have identified now (during debug session) that the problem comes up in the "phrase read"

It is quite strange; but this piece of code is quite old; never heard about a problem

But yes: it is a clear problem in the code with the use of the phrase "buffer"

We will start an OSS dialog as we could prepare a simple WWI test layout with simple data to retrieve and we can reproduce the problem.

C.B.

Answers (0)