How to modify SMQ2 queue data without debugging

[Former Member]

Hi,

As per subject, Want to edit and save buttons are available in the SMQ2 transaction when displayed the queue data.

For example user enter into the SMQ2 transaction and execute all queues are available in the queue log.

One of the queue is selected and click on the display button. Data is displayed as having in the queue.

Now come to my requirement is when click on the queue, the system will be displayed data in the non editable mode.

Here Queue data will display in the editable mode and system is allowed to edit and updated in the standard table (TRFCDATA).

Is any enhancement points or need to develop custom programs.

Please give me any ideas or solution.

Regards,

Kittu

[Former Member]

Hi Kittu

...I'm curious to know what your auditors would think of you modifying data in this fashion.

What is the issue that you're trying to resolve? I'm not convinced your approach here is in line with best practice for SAP Processing.

Regards

Arden

[michael_kozlowski]

Hi Kittu,

maybe transaction/screen variants are a good starting-point for your requirement.

Br

Michael

[former_member210541]

Why do you want to do that?

[Former Member]

Hi,

User didn't have any debugging knowledge thats why we are trying to modify data on the smq2 transaction.

Regards,

Kittu

[former_member210541]

Q monitoring is always done by people properly trained.

[Former Member]

Let me rephrase...

This is so totally not the right thing to do in SMQ2.

The debugging of anything which results in the modification to "Fix" something is not an acceptable practice.

The correct approach would be.

* Delete existing entries from SMQ2

* Have the correct data resent

Regards

Arden

[SujeetMishra]

Kittu,

You can not modify inbound queue data in SMQ2, this transaction code we have only to Monitor the qRFC, if you still want to change the data, then only way is to do it in debugger, just set break-point in respective function and execute the LUW.

best way is to receive corrected data from source.

Thanks,

Sujeet

[paul_bakker2]

You shouldn't be changing incoming data to a Production system, using debug or otherwise.

I wouldn't be building any enhancements like those suggested above. Unless you want to risk someone changing an incoming $10 amount to $1M.... using trapdoor code that YOU supplied.

cheers

Paul

[SujeetMishra]

Hi Paul,

I am not encouraging him to change the data on production system of course.. .. my suggestion is based on assumption that he is performing these stuff on Dev or QA.. No one ever get authorization of these queue to debug and change on production environment..

Thanks,

Sujeet

[paul_bakker2]

Sujeet Mishra wrote:

No one ever get authorization of these queue to debug and change on production environment..

Big call! It's certainly not common, but I have seen it - and I've even done it myself.

It's usually found in chaotic Production environments where all is lost and the only 'band-aid' left is to modify data using debug & change.

Sad but true. We can only hope that the system mentioned above (by the original poster) has not reached that stage.

cheers

Paul

[Jelena_Perfiljeva]

Under what circumstances could this possibly be ever needed? This data is coming from somewhere, so that's where it should be changed (for testing purposes, I assume). In Production this would be borderline illegal, as already pointed out.

[agnihotro_sinha2]

Hi,

Before going to a small example on "how to debug", I would like to put forward here some scenarios where it might be needed to debug SMQ2 even in PRD - yes, in production. And that is not illegal if you have good reason to do it.

There can be posting date issues and material lock issues which can happen due to geographic location of servers and slow system data update. In these cases, I dont see any any other go than "debugging/recreating" queue instead of processing 1000s of locked Qs. And that should be definitely handled by VERY trained professional in Production.

Coming to debugging, you can find out the related standard FM which is processing the data lets say Material movement data will be processed by "MB_CREATE_GOODS_MOVEMENT". Put a session breakpoint there.

In SMQ2, get inside the Queue levels untill you get the "Debug LUW" button beside EXecute button. Also, you can go to menu-Edit-Debug LUW.

regards,

ags

[Former Member]

"And that is not illegal if you have good reason to do it."

The perfect Axe Murderers excuse

[agnihotro_sinha2]

I am not trying to give any excuses here but we cannot impose the restrictions of IT on our business process, isnt it?

And we literally found out that there was no solution for some of the reasons I stated above except debugging by some SMEs.

As per the original issue in the thread is concerned, let me know if you were able to resolve it.

[Jelena_Perfiljeva]

Sorry, but from this explanation I still don't see any valid reason to do what you are asking. What I see is a bad interface design. It's not "restrictions of IT on our business process", it's IT shooting themselves in a foot by implementing an interface without proper error handling and re-processing capabilities.

We have a relatively small SAP implementation but even in our environment every time we implement an interface one of the first things we consider is how would we handle errors and how would we re-process transactions in error or re-send data. If necessary, we build custom programs to handle this. Needless to say, all this is tested, including failure scenarios, in QA system before implementing in PRD.

I believe that instead of a "band aid", as Paul correctly called it, a "surgery" is needed to resolve the core issue here. I.e. a proper tool is needed to re-process errors / re-send data without resorting to some kind of funny business.

[logistique_highwaystream]

just for info I found this doc that shows, even if not recomended, how to enable editing, as least from ECC side from what I understand with transaction /SPE/MQWL_CUS

https://kupdf.net/download/how-to-qrfc-queue-editing_59d4b6b208bbc58853687245_pdf