Manifest V2 Sunset: Ask Us Anything Q&A

[Kev_B]

We recently hosted an Ask Us Anything webinar to cover the topic of the impending Manifest v2 Sunset. The event prompted a lot of questions for our experts Robert Nicklin (Product Manager) and Carlos Correia (Solutions Consultant). You can rewatch the session in the embedded video or explore the questions and answers below. The session was hosted by Dominique Duquennoy (Head of Customer Success, EMEA).

Do you have any additional insight to the dates for Manifest v2 Sunset, outside what the Chromium team have published?

The short answer is no, we don't currently have any more insight into the plans than our customers. The announcement of the plan to move from Manifest v2 (MV2) to Manifest v3 (MV3) came at the same time for all of us. The latest update from the Chromium team postponed the proposed dates for deprecation of MV2 support. The latest update said that we would be expecting an updated timeline in March 2023, but we haven't seen that yet (as of the time of recording) so we are eagerly awaiting the revised dates for the MV2 Sunset.

Is the Browser Automation Agent latest version available for 6.10.2, and can it be installed in production?

We released the first version of the Browser Automation Agent (BAA) in October 2022, which was valid for use with Blue Prism version 6.5 through to 6.10. We have iterated upon that solution to produce version 2 of the BAA that is planned for release this month (March 2023).

We are working on migrating Chrome MV2 to MV3. We need to identify the list of objects and processes that are using Chrome, which is tedious to do manually. Does Blue Prism have any tool to provide the list of objects and dependency processes in an Excel file?

On the Digital Exchange we have our Manifest v3 Impact Assessment Utility that can be used to identify which business objects within your environment are using browser automation. There is also capability within that tool to identify anywhere that you are using ‘insert and invoke’ JavaScript functionality as well. Hopefully that tool will help you in identifying those objects.

How can I check if an existing robot is using JavaScript? Is there a tool available to check this from Blue Prism's side?

Changes in MV3 security standards mean the current functionality Blue Prism offers to insert and invoke JavaScript with a MV2 browser extension no longer performs the same. If you move to a MV3 browser extension such as the ones provided in 6.10.5 or 7.1, you'll find those are no longer able to insert and invoke JavaScript, which is where the BAA solution mentioned earlier comes in. In terms of the BAA specifically, if you're using inject and invoke, there's an additional dependency on the Selenium web driver that ships with each browser. That’s updated every time the web browser updates. That's something that you need to keep an eye on if you continue to invoke and insert JavaScript. Where we've worked with our clients, we've identified that many have used JavaScript purely because it's what they started with and what they've always done. When they take another look at the tool, especially when coming from an older version of Blue Prism, they were often able to overcome some of the original challenges with the new capabilities provided by web extensions. That's one to consider if you're looking at moving away from JavaScript, which also helps from a maintenance perspective.

Does the Browser Automation Agent (BAA) need to be installed manually on each machine? Is there a script or tool to bulk install?

It can be installed manually with an MSI file. We also provide a silent install as part of the MSI deployment. Effectively you can pass parameters in the command line through to the application. There are clients that we work with for example, that are using things like Puppet (or other available SCCM tools) to roll this out. Those tools can certainly be used to deploy this package as well.

Additionally, the BAA is a component that sits alongside Blue Prism. It doesn't necessarily need to be installed on every single machine in an environment simultaneously. It is possible to use the BAA on a subset of machines. For example, if want to evaluate moving from a MV2 to a MV3 browser extension, you don't need to simultaneously apply that solution to every runtime resource in your environment. It can be deployed to a subset. Alternatively, if you've only got a small number of resources that require the insert invoke JavaScript support, you could theoretically apply the browser automation agent to only those machines and leave the rest of the machines running their out of the box browser extensions, which (if MV3) don't support that capability.

Will elements spied in browser/HTML mode be impacted by MV3? Or will it only affect JavaScript invokes/injections?

The actual spying characteristics of the element shouldn’t be impacted by the move between MV2 and MV3 browser extensions. However, there are some behaviour changes introduced because of the MV2 to MV3 changes. You might be able to identify and highlight elements successfully, but there is an edge case we’re aware of if an element previously triggered the invocation of some JavaScript when interacted with. That will potentially no longer work with a MV3 browser extension. That's because the JavaScript that is built into the page is being invoked by the browser extension because it is blocked by MV3 changes.

However, there are alternatives to that functionality. Instead of using the click action in your process or object, you could instead use Global mouse click, or click the element using something like UIA spy mode, that would only impact the browser/HTML node. To summarise; there’s no significant impact to spying elements, but some other interactions with those elements may be affected by the MV3 changes.

If I do not have any development with JavaScript injection in Blue Prism, does this migration impact me?

Yes - the reason is that browser vendors will eventually remove support for MV2 browser extensions entirely. It hasn't been announced which version of Chrome or Edge will contain that update, but when updated you could be looking at a situation where your browser automations stop running because the browser extension is no longer responding in the way we expect it to.

We're expecting updates from browser vendors this month, but the previously announced date before they put everything under review was June for things to start being turned off. This was then followed by a six-month period where you could use group policies within the browser to extend support for MV2 browser extensions. That meant a hard cut-off date of January 2024 where MV2 browser extensions would no longer be supported and would be removed from the browser extension stores as well.

In summary - this migration to MV3 will impact you, even if you aren't using JavaScript insert and invoke. Every version of Blue Prism except for the 7.1 series and 6.10.5 were provided with an MV2 browser extension natively because that was the accepted standard at the time. So if you're on any of those versions then yes, you need to take action to prepare for this MV2 Sunset.

If we only use browser mode along with XPath in Chrome. Can we continue to use "old/MV2" browser extension

There's no way around the sunset of the MV2 browser extensions as far as we are aware. A change will come in the Chrome and Edge browsers themselves and that will turn off support for the MV2 browser extensions. There may be the ability to extend support for a limited amount of time after that policy is introduced. But in the long term the answer is no, you won't be able to continue to use that old MV2 browser extension perpetually.

If we are not on Blue Prism version 6.10.5 and above the only option for us post sunset of MV2 is to install Browser Automation Agent? Is my understanding correct? If we are not invoking/injecting JS would MV2 continue to work post sunset with default BP spying and other modes?

Your understanding is correct. If you are on a version of Blue Prism outside of 6.10.5 and one of the releases in the 7.1 series, then you've got two options: upgrading to one of the versions that is MV3 capable out of the box is one option; or the BAA. That will provide you with a MV3 browser extension which works with your current version of Blue Prism. It doesn't require a core system upgrade and you'll be able to migrate your processes using that MV3 browser extension to continue your operations.

For the second part, as in previous answers, there's going to be an initial switch-off of that support and there will be mechanism, we've been told, in which you can extend the support temporarily. After which the Sunset will become a lot more hard line and you won't be able to do anything about that. As far as we’re aware, there's no way around the coming MV2 Sunsets.

When using Manifest v2, how to ensure extensions are stable? Any recommendations? Would the same apply if migrating to MV3?

We expect released browser extensions to be stable so if unexpected behaviour is observed, please do raise a support ticket and highlight it in the community. Raising a support ticket means we can understand exactly what the problem is and try to solve it for you. In terms of the MV3 browser extensions, we shouldn't expect any further instability from the web extension in MV3 than we may have had in MV2.

One of the areas where we've seen some issues around browser extensions or stability is where we have people developing on a machine on multiple sessions. What we’ve found is that having multiple Chrome or Edge sessions across a multitude of instances on that VM does sometimes cause a bit of a challenge. Make sure you've got the expected number of processes when doing your build out to make sure that you're targeting the correct browser within the environment.

We are running BP V6.7.2 and currently have many processes interacting with Edge using the BP 6.10.1 extension. Due to the Manifest changes coming we are trying to find a way to keep our processes running as updating to V7+ isn't really an option for us. We don't have the option to update from 6.7.2 to anything but 7.x and we don't have the option to use an alternative Browser like Chrome. Unless we can get Browser mode working in an MV3 compatible extension with 6.7.2, we will have to rebuild all our objects to use UIA or AA mode and just accept any processes that cannot function without a Browser Mode element. Is there a workaround for this?

If you're on an older version of Blue Prism and you don't have the ability to upgrade to one of the versions that comes out of the box with an MV3 browser extension, the solution for you in that situation would be to look adopt the BAA.

The first version of the BAA is compatible with 6.5 through to 6.10 and the second version, which is going to be made available imminently will extend that support all the way out to 6.4.2 onwards all the way up to 7.1.2. However, the point around them being on 6.7.2 and needing to use Edge is a little bit of a question mark for me as we only support Edge automations from 6.7 onwards as I mentioned. So I can't speak to that in any more detail than that.

Is the extension which should work with Manifest v3 "Blue Prism BAA v2 Extension 6.8-6.10"? Is it enough to update to it from "Blue Prism 6.9 Browser Extension Blue Prism Ltd." If we are not using JavaScript invoke, is that enough for processes to continue to work? Our BP version is 6.9

It’s not possible to just install the MV3 browser extension that is provided with the BAA alongside existing releases of Blue Prism and expect this to operate – the BAA components are necessary to establish a connection between the browser and the core product.

Is JavaScript invoke not supported by Chrome and Edge browsers, or not supported by Blue Prism? Is there any other way we can invoke JavaScript to the browser?

To the second part - the answer is yes, by using the BAA. To answer that first part of the question - the way we used to insert and invoke JavaScript in browsers is no longer supported in the same way it was by Chrome or Edge. The Blue Prism capability that existed in the product before this Manifest announcement was recognized as an accepted way to insert and invoke custom sections of code in a web browser by those browser vendors, via an extension. Since the change is to MV3, effectively we can no longer use that same mechanism to insert and invoke JavaScript.

Can Blue Prism share some built-in features which can be used as an alternative solution of JavaScript invocation?

We’ve made various updates at different times in our release cycles to help users with a couple of problems related to different use cases for JavaScript invocation. When we've engaged with users, we've found that the majority are using JavaScript, because of processes which interact with a web application, and the application doesn't respond to an automation the same way that it would do to a human user. So, users are writing JavaScript to trigger those events. In Blue Prism 6.10.3 onwards and from 7.0.1 onwards we made changes to allow a right stage to trigger events when it posts information to an element on a web application. We've extended that capability even further with the upcoming Blue Prism 7.2 release so that you'll be able to natively trigger JavaScript events in the browser, without having to use the browser automation agent.

We need to extract data from local storage on a web application into our BP process. Currently we use a hack where we insert a JS fragment into the web app to read local storage and write the required items from local storage into the DOM of the page. Then we read the value with a plain old read stage. Are there plans for Blue Prism functionality that will allow us to read local storage data items more cleanly? Or alternatively - any suggestions for other hacks that might work?

If you were to continue down the path of extracting information out of local storage, your only recourse today is to leverage the BAA browser automation agent alongside the JavaScript injector capability provided by the Selenium driver. This will allow you to do what you're doing today but effectively following a different path. There's no material change as far as we’re aware, required when invoking JavaScript to the process, it should run as you would expect. In terms of the feature request to read from local storage, it's a really interesting one. It's not one that we've come across. We’ll have to defer the answer as to whether there are any hacks or any ways to achieve that under MV3, but we’ll reach out to the user to better understand the use case and see whether we can do anything with the product in the future.

Will Blue Prism team or respective Customer Success Managers start notifying the clients as soon as they hear back from Google/Microsoft regarding MV2 sunset? so that we are aware in advance

Short answer yes – what we’ve been doing the last year is working closely with Rob and the extended product team here so that when we can provide updates, we're doing it as fast as possible. We know that timeframes are quite tight, so once we have more clarity around updated dates in terms of MV2 Sunset, you'll receive a communication from us to be sure that you are able to plan as in advance as possible. We'll also continue to update our resources as appropriate as and when we receive those updates.

Do you know if objects based on "Edge on IE mode" (migrated from IE) will be affected by Google Manifest V3? Especially I mean actions like "Insert JS fragment" or "Invoke JS function".

No, the objects migrated from IE to Edge running in IE compatibility mode shouldn't be impacted by the MV3 changes. Those interactions with Edge running in IE mode are completely independent of the browser extension. So, the changes to MV3 shouldn't directly impact it. For transparency, it's probably going to be considered a legacy feature. Obviously, IE is now end of life, the Edge IE mode capability is allowing us to continue to run web applications which won't run in modern browsers, but we are probably going to be looking at a situation where if Microsoft decide to change the way that Edge IE capability works, they could theoretically remove that support for inserting and invoking in JavaScript even for those legacy applications. We've not seen anything in the guidance which indicates that's their plan, but they likely reserve the rights to do so in future.

Could we go step-by-step what is needed to be done to be safe after manifest will be active. Our version is BP6.9 and Browser is Edge. Could you mention the details on where to get any installation part (file) needed?

There are two routes to take. The first is to upgrade Blue Prism Enterprise to a version such as 6.10.5 or a release in the 7.1 series that come with MV3 compatibility. The other option if you’re on Blue Prism 6.9 and you're using Edge browser automation, would be to adopt the BAA solution to allow you to move to an MV3 browser extension without that core product upgrade.

Boiling that down in terms of the relevant steps; on each runtime resource you need to run the MSI installer, which installs the new browser extension. It removes your current Edge browser extension and replaces that with an MV3 equivalent and installs the necessary components alongside your Blue Prism runtime resource or interactive clients to allow you to leverage that MV3 browser extension. Once the install has been applied, you'll want to regression test your browser automation process. You could run it on the runtime resource that you've uplifted to use the BAA, to check whether you see any functional differences. As we've probably mentioned pretty much all the functional differences you could expect as part of this session. The considerations around insert and invoke JavaScript, the considerations around elements that when clicked in previous versions would've triggered JavaScript, you'll need to potentially introduce workarounds for that. From there you would want to roll that browser automation agent out to more machines across your organization to give them all MV3 compatibility.

If you do need to use the insert/invoke JavaScript capability that the browser automation agent provides, there are some additional configuration steps you need to be aware of. All of this is covered in the documentation, but you would need to download the web driver for your browser. In this example it will be Edge and that needs to be placed in the install directory for Blue Prism. You’ll then need to update the application models in your business objects so that a remote debugging port is declared when your browser application is launched. It's only the application modeler how you launch the application because you must enable that debug port so that it's able to communicate with the JavaScript invoker component. You should consider that there's an added maintenance step there, especially around the fact that as the versions of Edge or Chrome or whatever browser you're using go up, then typically a new Selenium package is released that relates to that specific version. Those things tend to be tightly coupled, so you need to keep an eye on both the version of browser you're running as well as whether you've got the latest, correct version of the Selenium package.

What is the best recommendation or approach to migrate from IE or chrome processes to Edge? Is the more stable approach to use IE mode in Edge or to rebuild entirely? Currently we are using Manifest v2 on v6.10.5 but Edge doesn’t seem to be stable after using the conversion tool. What is the best approach to take? From prior experiences and recommendations, what is the best way to automate using MS Edge? Also are there any insights to have the wait elements from IE in modern browsers (Document load, parent document load)?

Given what we've mentioned earlier, ideally you want to be in a position where you're moving away from the IE compatibility mode purely because we don't know when it's going to Sunset. You should be looking to try and move off those if possible. We understand that obviously it may not be possible for all of the processes. Also, equally, if you're using something like a conversion tool to move from IE to Edge, which I think is available as well, that might be a like for like conversion and you won't necessarily get the benefits of what's available.

In the newer versions of Blue Prism, we introduced a feature, whereby you can use CSS selectors as opposed to XPath. The approach that we would suggest is to go with a tool in the first pass, convert and see what happens. If it works, perhaps dive into the separate areas to try, and figure out if it's leveraging any of the new capability. Then look at whether there’s an opportunity to clean it up and do it in a more modern way. Migration gives an opportunity to lighten the load on the digital worker and remove some of the stuff that's no longer required.

As for any insights into when functions from IE would be available in modern browsers- we introduced enhancements in that area in 6.9. Looking back in the release notes, from 6.9 onwards you should be finding that when you're automating Chrome, Edge, and Firefox, you have things like the parent document loaded and document loaded conditions in your weight stages. So that should be there already for you to leverage.

Can you share any documentation around the upgrade path or approach to migration of MV3 please?

We've got a few courses available on Blue Prism University which cover the decisions that you need to run through around deciding what’s best for you. The process of deploying new solutions like the BAA are documented in the release notes and the install guides. In our Knowledge Base articles, there's information a matrix which says, ‘this is my situation, what do I do?’ It has columns to say, well option one or primary option would be this and secondary option to consider would be that. Those are the sorts of materials that would be useful to leverage in understanding the different approaches for MV3 migration.


#BluePrismNews #AskMeAnything #Product 

#InsideRPA