How do I wait for screen to refresh without using pauses, in mainframe?
Currently, we are automating in the mainframe (QWS3270) using the GenericWinHllapi adapter.
We are using pauses to wait for the screen to refresh and then check the status line for specific texts and then progress to the next steps from there. (See attachment for details).
We currently wait/pause 1 second before checking the status. Is there another method(s), without using pauses, to wait for the screen to refresh, and then grab the change? We tried using the TextChanged WaitForEvent, but that doesn't work (we have submitted a defect ticket against that, already).
One concern was that, what if the mainframe takes 3 seconds to refresh, or 10 seconds, or x number of seconds. So, instead of using explicit waits/pauses, is there another way to do this?
Accepted Solution
Pegasystems Inc.
US
WaitForInputAllowed functionality changed in build 8.0.1045. Starting in this version you can simply put in the timeout and the method will wait.
Prior to this version, WaitForInputAllowed would throw an exception if input was not allowed. This required a loop with a try..catch around the WaitForInputAllowed. You would wait until the method did not throw an exception - break the loop on no exception.
The event you really want is NewScreenShowing. Do a wait for event on NewScreenShowing. Execute your keypress from the Setup of the wait for event.
UnitedHealthcare
US
I'd create a function that waits for entryResultRegion to have one of the desired values. I included an example of a function that will check infinitely until the text is matched or there is an error. You might want to add a timer or counter that breaks the loop after a certain amount of time.
Bank of America
US
Typically, I would do this, however, it is a workaround that the client has said they are wanting to avoid.
Also, it wouldn't work since the same status message from the previous message can also appear after inputting data and submitting it into the mainframe. For example, from account 1, if it was processed successfully, it would show "REQUEST PROCESSED." If I input for account 2, and the status message is "REQUEST PROCESSED," the logic shown above would not recognize that the new account was processed. And if the response took a few seconds, it would be processed as "REQUEST PROCESSED" because the response would come in at a later time, as an error or another status message.
We tried a 1 second wait, and it works fine, however, when the mainframe is bogged down and works slowly, in the afternoon, it processes the statuses incorrectly. We have seen this happening in real time.
We also tried TextChanged WaitForEvent, but it doesn't work, as the text change is not recognized, even when it does change. We have submitted an issue ticket against this, already.
What the client wants, pretty much, is a WaitForScreenRefresh method, where Pega recognizes that the screen has actually refreshed, so if the status message is the same, we are ok to process it.
UnitedHealthcare
US
Is there any text on the screen that is guaranteed to change? You could wait for that text to change using the same function above. Then after that text changed, check the area of the screen where you really want the value.
Bank of America
US
Thanks JarrettC,
As stated above, the thing to worry about is what if the previous account was successful and the next one was successful. There would be no difference in text. There is a refresh on the screen that happens really quick, but the text remains the same. This is the problem with checking again if the text has changed.
Pegasystems Inc.
US
I would use the WaitForInputAllowed method. This method is for Text Adapters Screen. the WaitForInputAllowed method will wait until the screen is ready for input, up to the timeout interval you specified using this method.
Bank of America
US
Vegam,
We used to use that all over the place, however, it is causing crashes. We have submitted a ticket and the bug is said to be resolved at a later version. We are using 8.0.1030.
PEG
US
There are actually 3 different operations taking place here:
- The response arrives back from the Server. Server and network load can affect this time dramatically.
- The Browser digests the response. This is typically what one creates an "OnDOMReady" event to catch. This again can take several seconds.
- Finally, after the response is loaded, there can be an indefinite number of JavaScript methods that run which massage and change lots of things in the UI. This last step is totally unpredictable insofar as it is completely dependent upon how you/Pega have coded the Application. And if you interrupt before it is done, you can get undesirable results.
The only guaranteed-to-work way that I know of is to poll for some value in some field (it could be hidden) which knowledge or experience tells you is the last field to finally render before all settles down. If the only real unknown in the 3 bullets above is the time spent on the server, then some variation of an onDOMReady, followed by a fixed delay (which might be different for each screen), might also serve you well.
Accepted Solution
Pegasystems Inc.
US
WaitForInputAllowed functionality changed in build 8.0.1045. Starting in this version you can simply put in the timeout and the method will wait.
Prior to this version, WaitForInputAllowed would throw an exception if input was not allowed. This required a loop with a try..catch around the WaitForInputAllowed. You would wait until the method did not throw an exception - break the loop on no exception.
The event you really want is NewScreenShowing. Do a wait for event on NewScreenShowing. Execute your keypress from the Setup of the wait for event.
Bank of America
US
The NewScreenShowing WaitForEvent did not work consistently.
The event did trigger, but sometimes it did not and would time out even though the record was processed into the mainframe system.
Pegasystems Inc.
US
The event will fire if (I believe) more then 1 character changes on screen. If it takes longer than 15000 ms (the timeout you are using in your screenshot), then I would expect a timeout.
Tata Consultancy Services (TCS)
CA
If you have already tried wait for event of Textchange, then you can use forloop to wait instead of giving wait time in Pause.
Bank of America
US
As stated above, you can't loop because if the previous account was successful, and the current one was successful, the status won't change, and thus, the check would be useless. The solution would be to do a wait for a new screen (screen refresh) and then check because even if the same status appears, the new screen would dictate when it is safe to check.