A failed web_find is not always an error


I’ve been working in Lithuania for the last 3 months. It’s cold over here. To keep warm (and paid), I’ve been writing some loadrunner scripts for a Scandinavian bank. One of them seeks to emulate a customer paying cash into their account. As you’d imagine, this is a high priority, high usage script so I’ve spent the last 3 weeks building this in the web protocol against a custom built CRM platform.

I’m not a huge fan of CRM platforms generally, I don’t like the way session id’s are implemented in them, it makes it difficult to record and capture and it’s impossible to add an extra request (for a new page, for example) in without re-recording. (Actually, it’s not impossible but it’s a mighty pain and re-recording is PROBABLY faster.)

Anyway, if the amount of cash paid in is over 10000 litas (the Lithuanian unit of currency) then an additional anti-money laundering screen appears. It also appears if the amount of cash paid into a specific account in a single day exceeds 10000.

One of the issues with test data is that we tend not to create enough of it, and we tend to re-use it, since the server response is what we care about, not the even distribution of funds throughout the customer database.

So I saw this AML page a lot, at unexpected times, and it caused the script execution to fail irrevocably until the following day.

I re-recorded, captured the page and attempted to build some “error”-handling in the script. It’s not an error, it’s part of the expected business process, but error-handling is what it feels like, just the same.


If (string of text on the AML page) is found AND (string of text on the expected page) is not found {
Process AML
}
...

Simple, right? Use a web_find, handle the result, no problems. And that’s entirely true, except:
A failure to find text with a web_find or a web_reg_find will always report as an error. We can (and I did) continue on error specifically at this section but every single iteration of my script reports a single error.
The two strings I’m looking for are mutually exclusive, but they are both part of a legitimate flow. The presence of neither of them = Error, the presence of both of them = BIG Error. The presence of either one or the other, absolutely fine. So why in the world of all things automatable, would Mercury (as the original implementers of this code) decide that this must be reported as an error?

Let me decide in code when an error has occurred, which is simple enough to do with an if and a return code from a web_find.

I like my scripts to emulate the reality of the process (because that’s what they have to do) but I also like them to run clean so I don’t have to explain to the client that the 10000 errors are irrelevant, misreported and not to be investigated. It just looks BAD.

I’ll write more on this when I find the solution (custom rebuilt web_find function?)…

Update

Well, I must’ve been having a senior moment, not least because the solution actually exists in the help for web_reg_find.

web_reg_find("Text=ABC", "SaveCount=abc_count", LAST );

web_url("Step", "URL=...", LAST );

if (strcmp(lr_eval_string("{abc_count}"), "0") == 0)

Action A

else

Action B

Simple as that, capture the counts and check that. D’oh

You can leave a response, or trackback from your own site.

Leave a Reply

Powered by WordPress and ThemeMag