Works in Object studio, but not when run

[ZoltanBALINT1]

Hello team, I'm new to BluePrism development, and I'm facing a very bizarre issue.
I created a business object that interacts with a simple web application using Internet Explorer.
The app is supposed to be launched from the control room regularly, so it does not always log in and out; merely attaches to the open application; nothing special so far.

Except that it tends to work when I create the object in Object Studio, and it tends not to work when run from Process Studio and the IE interactions part NEVER works when ran from the control room.

Spying, highlighting basic things, like the URL bar of the work. The 'attach' operation works against the top level item in the application tree.
But then mostly nothing else works when the application wasn't launched but has been pre-existing, even though the process attached.

Most astonishingly, the basic 'Navigate' operation doesn't work after a successful 'Attach' operation, and it does test positively for a IsConnected test.

Highlighting tends to confirm the same. If I launched the app from the Object Studio app modeler, it highlights items. If I ran step by step the object, attached by activity, and then open the application modeler, then suddenly it cannot highlight the same thing that it has highlighted just a minute ago.

I have re-built the object from scratch just to avoid an object internal error that could have been caused by a paste operation. I have also tried every spying operation; tried also to navigate by sending Alt+D first then type URL; tried spying the address bar; NOTHING works when not run from the Object Studio.

We're on BP 6.5. 
Any suggestions/advice please?


------------------------------
Zoltan BALINT
------------------------------

[JamesMan]

Hello,
This is a common issue and the main culprit is that of execution speed.  

Executing a process from the Control Room runs at a much higher speed than even the highest speed setting inside the Object or Process editor.  This can lead to timing issues.  Things will work when "debugging" because the application has enough time to load the necessary elements on the screen, for processing to occur etc.  In the Control Room often fails because the Objects run faster than the application can keep up with.

The main way to tackle this is to have Wait stages with conditions that wait for the presence of elements to appear on the screen before continuing.  It may also be necessary to selectively add throttles to areas of an object to slow it down.

An example of using waits can be seen from the Development Best Practice guide in the "Object Layer" Section https://portal.blueprism.com/system/files/2018-01/Blue%20Prism%20-%20Development%20Best%20Practice.pdf


------------------------------
James Man
Professional Services
Blue Prism
Asia/Hong_Kong
------------------------------

[ZoltanBALINT1]

James, as I was trying to explain, the application window is up. This has nothing to do with execution speed.
Before I posted my question, I did place two wait-for states around the step that used to fail, and it still failed exactly on the same step (which is normal: the browser window was pre-loaded, so the navigate stage should not have failed; maybe the step thereafter).
After posting my support question I have re-designed my workflow to always launch and always kill the browser window, and that that navigate step works now fine without any wait states (as it should). I can afford this crude design change because the application remains 'logged in' even if I close the window, so a fresh browser instance can still talk to the app.

I cannot take this path with the other web application (Netcool 8.1) that my bot is going to talk to, as that one will not allows me the same shortcut.

Essentially: logic works fine as long as the bot launched the IE browser window. It fails miserably when the browser window was up and the bot tried to attach (from control room always, and from the 'process studio debugger' for most spying modes; not all). I'm happy to be proven otherwise, as my application will need to use pre-existing browser windows with live login session otherwise my cycle time goes up.


------------------------------
Zoltan BALINT
------------------------------

[JesperHededam1]

Hi Zoltan (cool name).

Try to look into doing dynamic thread attachment. We've ourselves experienced that, due to the way modern tabs in browsers work, we had to make a dynamic thread attachment method where we fetch current processes in windows and look for the parameters of the current active window.
Thread IDs have a tendency to shift, and doing the built in simple attach bugged for us often and proved to be unstable. After we've done the dynamic thread attach we've never had any issues attaching since, and we also can attach fine to an already existing open browser session, which was also an issue in the past.

This is on IE though, but perhaps the same apply.

------------------------------
Jesper Hededam
Developer
Codan
Europe/Copenhagen
------------------------------

[ZoltanBALINT1]

Hello Jesper, thanks for your suggestion.
I have taken a detour in my design, as BluePrism could not read the Netcool tables either, so my alternative using VB.net scripting is functional.
For my next steps I will need again attachment either to IE or to Chrome.

I did search for 'dynamic thread management' for attaching to IE to no avail. The only work instructions I could find used a method that listed processes (enhancement to the 'Read Memory Stats' method of the 'Utility Environment VBO'). That does not work for me. Whether I have one browser tab or 5, it only returns two processes.

So .. is there some detailed guidance, publicly available information or Blue Prism app note that I can study for implementing dynamic thread attachment please?

------------------------------
Zoltan BALINT
------------------------------

[PeterLacken]

Hi,

just to check you have the basic parameters correct for the IE attach stage to avoid attaching to any other application, including Blue Prism!, when running in debug.

1. Title - use wild cards around a unique name in the title, "*<your title>*"
2. Process Name - set to "iexplore"
3. Child Index - set to 0

There is no issues I have encountered with re-attach to an open browser that can not be solved with correct use of the Attach and Detach. That goes for v4,5 and 6.

good luck, Peter

------------------------------
PeterLacken
Ren Røros Intelligent Automation
Peter.Lacken@rria.no
http://www.rria.no
------------------------------

[JesperHededam1]

Hi Zoltan.

There might not be anything already pre-packaged for such a use. We wrote our own code block to extract all process threads of iexplore. Look for a code-bit that does that. I suggest stack overflow or some such.

------------------------------
Jesper Hededam
Developer
Codan
Europe/Copenhagen
------------------------------

[SharazKM]

Try setting tapprocgrowth value as 0 and just see whether this resolves your problem . How to set tapproc growth is 

Go to registry Editor 
Navigate to HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/Main
If there is a value called TabProcGrowth , set this to 0 , if the value does not exist, create it as a REG_DWORD type with a value of 0.

Not sure whether this will help you . But good to give a try based on your provided details

Also if you are not familiar with what TabProcGrowth does - if the value set to 0 , it wont create multiple instances in IE even if you open multiple tabs 

------------------------------
Sharaz KM
Associate
EY
Europe/London
------------------------------