Bug only in PRD, fine in QAS & DEV

[Former Member]

Mods,

Please move this to the right forum if needed.

Thanks

Hi all,

we are stuck here with a difficult issue.

In our business, a user creates an Engineering Change Order (ECO) through a ztcode. A workflow is then triggered which takes care of mails to be sent to the respective users for approvals. Once all the approvals are there. The workflow changes the satus code of the ECO as needed. (This can be checked through a zreport and CC03).

Once all the approvals are there, 4 things need to happen.

1. The ECO status changes from 6 to 7 (Final).

In the next step, 3 things are happening.

2. A txt file gets created on a UNIX server with the ECO data.

3. The long text field of CC03 has the ECO data appended to it.

4. The ECO data gets deleted from SAP.( I think this data is stored in Z tables to begin with so they are cleared)

Our issue is in some cases, everything works, in some cases, 1 or 2 or 3 or 4 or all or any fail.

The failing so far has been random, we couldnt establish any pattern for failing.

In DEV and QAS, it is working absolutely fine. In PRD however it is a concern.

To begin with, this is the code for the status updation, the code is written in Z- FM and is called in a backgroud task in the workflow. This FM is called repeatedly in the workflow 7 to 8 times.

Its function in brief is, we pass a status code(1 to 10) then we get the associated text for that status code.

We then update the 'change master' AENR-AENST (table-field) with this text.

The FM works fine when called the first 6 times. When it is called in the seventh instance, i.e, PAENST = 7.

We believe the UPDATE statment on AENR fails. This is reflected in CC03.

The status doesnt change to 7, stays at 6.

Split into two posts

Edited by: Rob Burbank on Apr 7, 2010 11:53 AM

[former_member185167]

Hello,

I'm not sure if this is particularly a workflow problem but we can give it a shot.

When this happens in Prod, do you try to replicate the circumstances exactly in Dev and Test? Try to use exactly the same values.

Could it be a question of locking? Could there be other processes, or even other runs of the same process, that are trying to update the same rows of the same tables?

"We believe the UPDATE statment on AENR fails"

Can you find out more about this? Is there an error in the workflow log? Can you build in a test of the success of the fail?

regards

Rick Bakker

Hanabi Technology

[Former Member]

No, unfortunately we cannot replicate the test data in DEV and QA. I have did many runs of the transaction with many test cases but none of my attempts have failed.

Any inputs are welcome. Do you think there are some system settings on the basis side causing the random failure in PRD system.

Thanks

-saplogs

[Former Member]

Hi mods, can you please move this thread to workflow forum as I havent received any suggestions. Moving it may prove beneficial.

Thanks

[Former Member]

Moderator message - Moved Rob

[Former Member]

Hi Rob,

Thanks for formatting my post.

[Former Member]

Rest of the original:

FUNCTION XXXXX
*"----------------------------------------------------------------------
*"*"Local interface:
*"       IMPORTING
*"             VALUE(PAENNR) LIKE  ZBO-ZAENNR
*"             VALUE(PAENST) LIKE  AENR-AENST
*"       EXPORTING
*"             VALUE(ECOSTATUS) LIKE  ZBO-ZECO_STATUS
*"----------------------------------------------------------------------

SELECT SINGLE AENST AESTX INTO (CURRENT_AENST, CURRENT_AESTX)
FROM T419T WHERE AENST = PAENST AND SPRAS = SY-LANGU.

IF SY-SUBRC EQ 0.
UPDATE AENR SET AENST = CURRENT_AENST WHERE AENNR = PAENNR.  " This is reflected in CC03.

UPDATE ZBO SET STATUSCODE = CURRENT_AENST
                         ZECO_STATUS = CURRENT_AESTX
WHERE ZAENNR = PAENNR.

ECOSTATUS = CURRENT_AESTX+0(20).  
" This is a workflow container variable and this has the correct variable, we checked
"   this later in workflow log.
ENDIF.

ENDFUNCTION.

The commit and wait may not exactly be the issue here as it is able to update the statuses in other cases.

This is not my team's development. The program has been in Production for a long time now. We are only trying to identify the bug.

The current code/workflow are fine DEV and QAS so the outcome of any changes we make may reflect only in PRD, which is a real botheration for us.

Thanks for reading.

Any help is greatly appriciated. Let me know if you need more info.

-Kumar