wrong qid being obtained

[Former Member]

Hallo,

I am starting some job using the events and obtaining the qid of the job during runtime but sometimes the qid being obained is wrong and hence not the right job being started.

The query/Logic to obtain the Qid is as follows.

   SELECT * INTO TABLE lt_qid
                    FROM apqi
                    WHERE groupid  = gc_jobname  AND
                          creator  = sy-uname    AND
                          credate  = sy-datum.
  SORT lt_qid DESCENDING BY cretime.
  LOOP AT lt_qid INTO ls_qid.
    IF ls_qid-qstate IS INITIAL.
      lv_qid = ls_qid-qid.
      EXIT.
    ENDIF.
  ENDLOOP.

Here i am considering that the job which is newly created is having the status as Initial and hence taking that for further processing.

sometimes this logic is getting me the qid of the previous job which is already finished and having the status as Finsihed (F).

Any Hints please !

Thanks

[Former Member]

I'm afraid that I'm not clear on what type of Job you are talking about.  Are we talking about background jobs you can see in SM37?

Neal

[arindam_m]

Hi,

Just a bit confused.. are you saying you look fro sessions then your Table is right its APQI. And sessions have status:

F  = session is processed
E = session contains errors
R = session is in processing

For jobs you may have to look into tables TBTCO and TBTCP.

Cheers,

Arindam

[Former Member]

I would guess then that you want the most recent one.  You must be getting two in your itab.  How about using CREDATE, CRETIME or PUTDATE, PUTTIME to pick the most recent one.

Neal

[Former Member]

Hi,

The Program does the following

1)creates a session, that we see in sm35

2)then it finds the qid of the session using the logic explained above

3)then this qid is then updated in the variant of the program RSBDCCTU

4)then the program starts the event which further starts a job and hence the program RSBSCCTU with the updated QID.

Now when i see the log of the job sometimes the job is having the qid of some previously finished job, so that means there is some problem with the logic to obtain the QID.

@neal: the time in both the fields puttime and cretime is same .

Thanks

[Former Member]

Is your itab getting multiple records or only 1?

Neal

[Former Member]

Hi Linda,

Check the below code, you need to add client, since this table brings all the clients sessions, so you may be missing that. Not sure if this helps.

select * from  apqi
        where groupid like groupid
        and   mandant  eq sy-mandt
        and   datatyp  eq 'BDC '
        and   credate eq sy-datum

[Former Member]

Hi Neal,

Yes multiple records for that date and then it find the latest one with state initial which means newly created.

Hi Raja,

I can update the logik with this addition that wont harm for sure but i think that wont be very helpful because there is only one client. The failure case i am analyzing is in the productive system where the qid of the previously finshed session was passed again to the job and not of the new session.

Thanks

[Former Member]

Linda,

What method (fm, ...) are you using to create them?

Thought 2:  Do you get two records with the same QID?

Thought 3: Could you put a:

wait up to 5 seconds

just before your select to make sure that the previous processes have had time to complete their work?

Neal

[Former Member]

Hi Neal,

to create the session i am simply using the open group close group , dynpro etc methods.

Definitely every session have the different qid.

The user is already instructed to execute the program only if the previous job is finished also before creating the new session the program checks if there already exists one whch is not completed and dont let the user to create a new one.

I checked the jobs and i can see that the first job completed before the second started but the second job still got the qid of the session of the first job according to the logik explained before.

1)     09:44:04             170

2)     09:48:30             110

Thanks

[Former Member]

So let's try some basics.

  LOOP AT lt_qid INTO ls_qid.
    IF ls_qid-qstate IS INITIAL.
      lv_qid = ls_qid-qid.
      EXIT.
    ENDIF.
  ENDLOOP.

Suppose that ls_qid-qstate IS never INITIAL.  You drop out of the loop and
lv_qid = ls_qid-qid has the last qid found, doesn't it?

Neal

[Former Member]

Hi Neal,

Everytime a new session has to be created the program has to be executed again. so there is no question that the lv_qid will have the previous qid.

secondly the program reaches this step only if the session is created and when a session is created it does have the state initial.

Thanks

[Former Member]

Last thought and then I'll shutup.  We all know what ideal states are.  We all know what SAP claims will always be true.  Having done this long enough, you stop listening to them.

So, sometimes the end result is delayed longer than SAP would have you believe.  Sometimes caches are corrupt.  Sometimes commits that are supposed to be committed are not yet.  And so on...

Neal

PS: I have this great story about the impossible happening in SAP if you ever want to hear it...

[Former Member]

Neal ,

You know you are quite right.

I had just given a delay of 2 secs after the commit and before the raise of the event to start the job.

Currently testing this in QA but i am quite hopeful that should work.

Thanks for all your help.

I hope i will be closing this thread soon.

Thanks.