Posted: 21 Aug 2020 16:12 EDT Last activity: 25 Aug 2020 14:38 EDT
Deploying Pega Robotics into Citrix (XenApp and XenDesktop)
To provide some context to the questions below currently we run an application (referred to as APPX within this blurb) on all desktops as a Citrix Published application because it does not run well as a local installation due to network bandwidth limitations.
Recently it was asked if we could also run the Pega Robotics (RDA solution) as a published application on our XenApp servers. We run about 30 users published application instances of APPX per server right now. After this was proposed we have some additional questions.
Our best case scenario would be to continue running the APPX as a published application that each user launches from their physical desktop and then run Pega Robotics on that physical desktop. So the question would be if we tried to run in this configuration would Pega Robotics perform from the published application of APPX? Are there any concerns with running it this way?
If the above (preferred) solution cannot be made to work and it's required that Pega Robotics be ran as a published application from XenApp servers we have the additional questions below.
Is there is any documentation that covers installation and configuration of Pega Robotics on a Server 2016 / XenApp Published application server so that the application can be used as a Citrix published application?
If documentation is not available, can someone explain how an instance of a Pegabot published application would interact with a instance of a published application of APPX (keep in mind there is potential these might not be running on the same servers)?
Will the Pegabot client be able to run up to 30 instances of the client as a published application from a single installation?
If it can run 30 instances from a single installation how does the resource utilization scale, and / or what server resources (CPU, memory, storage, etc.) would be needed to run this many instances of the client?
1. If you want Pega Robotics to interact with APPX, you would need to run Pega Robotics as the published application and have it start APPX as a local application (since PR will be running from the Citrix server, APPX will be local).
1. https://community.pega.com/knowledgebase/articles/pega-rpa/citrix-support-robotic-automation is a starting point on how Citrix works. If you are running Pega Robotics solely within Citrix (i.e. it is only interacting with application(s) within the same Citrix server), then there isn't much to consider. You'd simply install and configure Runtime on the Citrix environment and set it to be the published application that users launch. Runtime would then start the application(s) that the user currently launches.
2. You cannot interact with applications over Citrix. Runtime must be installed on the Citrix server and will launch the application locally. If you need to interact with applications on a local desktop and applications that run in Citrix, you would need to use what we refer to as Citrix-Mixed-Mode. This involves using a Citrix Context in your project. The way this works is the local Runtime starts and launches a published application version of Runtime in Citrix. The Runtimes communicate back-and-forth with the Citrix one handling the application(s) running within Citrix. In the link above, there's a second link to an article on using Citrix Contexts.
3. I don't understand this question. When you run Pega Robotics on your Citrix server, it will be the published application and will ultimately start the current application (APPX in your example). There will be some overhead with Pega Robotics, so if your capacity is 30 instances per server now, adding Runtime will likely reduce that number as you are now introducing another application into the mix that has not been sized for.
4. Again, I may be misunderstanding here, but the overhead of Runtime varies depending on hat you are doing. CPU-wise, it isn't very intensive usually, but memory-wise, I would say that the worst-case-scenario would be an extra Gig or so of RAM needed. Usually, I have seen the Citrix admins run some sort of profile once your project is finished to determine the sizing needs of the server. It is certainly likely though that the overhead will reduce the capacity on a given Citrix server from what it is currently at without Runtime.
Thanks for your reply that helps us a lot, basically the ask is that we have to provide the best approach for the client whether running the both the target apps in Citrix server or running the Runtime in Citrix mixed mode.
We have developed the automation assuming that the client will use the Citrix desktop app to execute the automations.
we have few technical queries,
1) If we want to run the automation in Citrix mixed mode we need to change the code and add the citrix context and execute the automation. this will add some additional development hours.
2) we can go with running both the target apps and Runtime as citrix published mode
if we go with approach 2,
does the existing code will work for different users who will access the runtime and target apps from Citrix?
if we go with approach 1:
How does the installation and automation needs to be changed?
Do we need to install the Runtime in both Citrix server as well as in user's local desktop?
the client is using the File share approach for code deployments, if this is the deployment approach, how will the runtime will pick the package and how do we update the Runtimeconfig.xml?
I am not sure I can provide a simple answer to all your questions. Whenever possible, I would try to avoid using Citrix-Mixed-Mode as it does indeed add complexity. If everything runs on one "computer", then your code doesn't need to be changed in any meaningful way. For example; if I have written an automation to work against APPX only and now want to move that to Citrix, I could simply change the shortcut that currently launches APPX to launch Runtime and then from a user perspective, they'd get access to your automation that would also startup APPX for them as it presumably does today. If you're using Mixed-Mode, then you'd need to install Runtime on the desktop and also on Citrix. In addition, Mixed-Mode has some limitations, so your code would likely need to change. You'd certainly need to change the structure to move your APPX adapter and automations beneath the Context. You'd also be limited to a single project in your solution, so if your solution is currently using multiple projects, they would need to be consolidated into one (because the context is the only means by which code can be executed inside of Citrix, and because you cannot include projects inside of other projects). In addition, Citrix-Mixed-Mode automations have limitations as well, so there would likely need to be not-insignificant code changes.
In Mixed-Mode, the Runtime on the Citrix Context can only load packages from a share. It does not have the ability to get packages from Robot Manager (Package Server). In the context is where you specify where the package is loaded from in Citrix, not in the Citrix RuntimeConfig.xml.
what if the Target apps and the Runtime are all from citrix server and all are being accessed as Citrix Published apps, in this case also do we also need to add the citrix context and update the code too?
If everything resides on the Citrix server, then only Runtime would be the published app and the apps users currently access as published apps, would be started from the same Citrix session (as local apps) as Runtime. So for example; APPX is currently the published app. Now, you want to automate it. You'd write your automation to start APPX and perform the automations. The user would now launch Runtime as the published app, which would load your project and in-turn, start APPX as a local application (to runtime since it is running on the Citrix server).
The Citrix Context is only for Mixed-Mode (where one of the applications runs inside of Citrix and others run outside of Citrix on the local desktop). MonitorAll should work inside of Citrix, however you really wouldn't want to use that. Remember that from a user perspective, they are now launching Runtime (or whatever you brand your project as) as the published app. They wouldn't then launch the current published app. Runtime would be starting the published app, so the best practice would be to have the StartMethod as Start so your adapter could start it. If your users launched the app manually from the published app, it could load on any one of the Citrix servers in your "farm", which Runtime would not be in control of.