Highlighted
Contributor.. Contributor..
Contributor..
209 views

Function library support without use of a network share

Jump to solution

My first post, hello.

I'm in the very early stages of moving from LR 11.03 (on-site) to LRE 2020. Script migration is very much my focus right now. The current scripts have always been structured to make use of a function library, merely a C file in some relative path. The .usr file of every script requiring the library was edited to include a non-recordable Action referencing the function library. I'm talking about 30 scripts. This has worked for more than ten years.

Until now, with LRE. The problem starts with VuGen, which fails in compilation because the relative path is dropped in combined_Script.c.  Removing the function-library Action and instead using a #include in globals.h works fine in VuGen, but this doesn't translate to LRE because the function library isn't in any uploaded script.

I've used JMeter, Gatling, and OATS, and in different ways, they provide inherent support for a function library. Please, someone, tell me there's a solution in LRE that doesn't involve a network share.

0 Likes
1 Solution

Accepted Solutions
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

@TheRedAndTheBlue 

You might try the following; I did this in the past with a solution (number of scripts) when using Controller to run tests, but I think it might work also with PC / LRE:

Put your library files inside on of the scripts that are part of your solution: e.g. script1/include/....

Use in your C-scripts and *.usr files forward slashes iso backward. E.g. #include "../script1/include/my_lib.h"

You might even consider to make a dedicated script containing the libraries and add that script to each solution that you run and let 1 vuser execute the script.

You might run into issues when you use/need multiple LG to run your solution. In that case just make a batch file that patches/updates the library into each and every script and just use #include "./include/my_lib.h". This is close to the solution 2 of @GilKedem. You can combine this with a build script of source repository.

Note: this is just out of my head. I did not validated this for you.

Signature:
Reward community members who take time to respond and help.

View solution in original post

5 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Hello,

You might have a few options:

1. Use a copy on each load generator

2. Use a copy with each script

3. Use a network share that all load generators can access

Regards,

Gil

Tags (1)
0 Likes
Highlighted
Contributor.. Contributor..
Contributor..

G'day, Gil, and thanks for responding.

None of those are remotely palatable here and now, I'm afraid.  They entail (IMHO) unnecessary maintenance overheads compared with our current operational model. (Admittedly, this is going to have to change a little in moving to LRE, but the fewer changes, the better). This is:

  1. on the Controller host, (git) checkout the appropriate branch of scripts (and function library) 
  2. launch automating script that performs checks, deployments, then test execution, and finally a tidy-up. Importantly, the Controller manages delivery of the function library to the remote LGs

I want to stress that I'm very-much a novice in the world of LRE. I'm having difficulty getting my head around the 'upload a zip-file' model it uses for scripts; inherently, this seems to me to remove support for packaging, and ultimately accessing, supplementary items, like a single, shared function library located at some relative path.

Further, for now, I'd like to treat a LRE load generator as a black-box resource.  It's possible that I won't be given permission to log-in to any of them (in future - none currently exist).

Cheers,

R&B

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

@TheRedAndTheBlue 

You might try the following; I did this in the past with a solution (number of scripts) when using Controller to run tests, but I think it might work also with PC / LRE:

Put your library files inside on of the scripts that are part of your solution: e.g. script1/include/....

Use in your C-scripts and *.usr files forward slashes iso backward. E.g. #include "../script1/include/my_lib.h"

You might even consider to make a dedicated script containing the libraries and add that script to each solution that you run and let 1 vuser execute the script.

You might run into issues when you use/need multiple LG to run your solution. In that case just make a batch file that patches/updates the library into each and every script and just use #include "./include/my_lib.h". This is close to the solution 2 of @GilKedem. You can combine this with a build script of source repository.

Note: this is just out of my head. I did not validated this for you.

Signature:
Reward community members who take time to respond and help.

View solution in original post

Highlighted
Contributor.. Contributor..
Contributor..

Greetings, @JHF Remmelzwaal.

I attempted a hack the other week using a separate script housing only the library, unfortunately to no avail.

>add that script to each solution...

Solution...? Hmmm, I've seen this in the VuGen menus, but until just now, haven't found a description of what it is/offers. I hope the notion of a multiple-script container transposes directly into LRE.

https://admhelp.microfocus.com/lr/en/2020/help/WebHelp/Content/VuGen/UI/solution_explorer_pane.htm#mt-item-0

Extra FilesStoring extra files that are used by the script.

The data contained in extra files can include:

  • Common utility functions used by the script (for example, code)

Hope, yet?!

You've activated the neurons - when time permits, I'll resume this effort. Thanks again, I greatly appreciate your response.

0 Likes
Highlighted
Contributor.. Contributor..
Contributor..

I've come to the realisation that VuGen Solutions aren't (or don't seem to be) all I hoped them to be, in that they may be beneficial only with VuGen.

Be that as it may... I now have something simple that's functional. I've packaged my (dummy) function library as a separate VuGen script, with the library present as an Extra File. Both (dummy) VuGen scripts reference the function library from globals.h, via an #include. An important point to highlight here is that the scripts are all in the same directory, something which our legacy setup certainly does not possess.

These three, uploaded to LRE, assembled in a defined Test, and executed as a Run, produced an outcome I'm happy with. A relatively minor downside is that the function-library must be included in the Test definition with one virtual user allocated to it.

A further matter I've seen in getting to this point is that the scripts, periodically changed, uploaded with overwrite permitted, were not actually being updated in LRE, despite their modified date suggesting they had been. Viewing the scripts (in LRE) showed no code changes were evident. I found I had to delete the scripts and recreate the Test definition every time. Very annoying. 

Anyway... no network shared in sight, here. Thanks, all.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.