Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Custom Screen data after PAI

Former Member
0 Likes
632

Hi all,

I have a Custom Screen that displays Service Notification Data in format that is specifically designed for a high volume business process.

The Custom Screen has functionality that creates PDF files from the Notification data in the form of letters to the Customer (that is why it is required).

I have included a PAI process that allows the users to change the Notification data in IW52 if required. These might be Partner data or just description changes.

Now for the problem, if a user changes the Notification data the custom screen requires the latest information after the change.

The PAI is as follows:

SET PARAMETER ID 'IQM' FIELD /powercor/dbyd_ptw_list-qmnum.

CALL TRANSACTION 'IW52' AND SKIP FIRST SCREEN.

WAIT UP TO 2 SECONDS.

LEAVE TO SCREEN 0200.

The Screen PBO reads the database directly and I have found that it is only correctly reflecting the change if I include a WAIT UP TO 2 SECONDS step in the PAI.

This is only in development environment at the moment….

Naturally I don’t like it….

I have tried using the BAPI_SERVNOT_GET_DETAIL assuming non committed buffer stuff might be read…but it doesn't seem to make a difference.

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
540

Hi,

A better solution is to add a button to refresh the data after user click. In this cas, you don't need the selection in PBO anymore and it's very important for performance reason... don't forget that PBO will be executed after every user interaction ! a Select in PBO is not recommended.

Another way would be to re-read the data and check if it has changed. If not, then use enque_sleep to wait a second and then try again until the data does change, or, if you're not locking the record youself you could possibly try and lock the record, only continuing when you have locked the record (don't forget to unlock it.....)

Reward if helpfull...

Cheers,

Deepanker.

Hi all,

I have a Custom Screen that displays Service Notification Data in format that is specifically designed for a high volume business process.

The Custom Screen has functionality that creates PDF files from the Notification data in the form of letters to the Customer (that is why it is required).

I have included a PAI process that allows the users to change the Notification data in IW52 if required. These might be Partner data or just description changes.

Now for the problem, if a user changes the Notification data the custom screen requires the latest information after the change.

The PAI is as follows:

SET PARAMETER ID 'IQM' FIELD /powercor/dbyd_ptw_list-qmnum.

CALL TRANSACTION 'IW52' AND SKIP FIRST SCREEN.

WAIT UP TO 2 SECONDS.

LEAVE TO SCREEN 0200.

The Screen PBO reads the database directly and I have found that it is only correctly reflecting the change if I include a WAIT UP TO 2 SECONDS step in the PAI.

This is only in development environment at the moment….

Naturally I don’t like it….

I have tried using the BAPI_SERVNOT_GET_DETAIL assuming non committed buffer stuff might be read…but it doesn't seem to make a difference.

1 REPLY 1
Read only

Former Member
0 Likes
541

Hi,

A better solution is to add a button to refresh the data after user click. In this cas, you don't need the selection in PBO anymore and it's very important for performance reason... don't forget that PBO will be executed after every user interaction ! a Select in PBO is not recommended.

Another way would be to re-read the data and check if it has changed. If not, then use enque_sleep to wait a second and then try again until the data does change, or, if you're not locking the record youself you could possibly try and lock the record, only continuing when you have locked the record (don't forget to unlock it.....)

Reward if helpfull...

Cheers,

Deepanker.