cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

How to mass update the scripting framework without publishing the entire TestPartner DB?

kalle_lahtinen
Advisor

Hello,

We have a shared monitoring environment where the "master scripting agent" idea cannot be used, since all the agents monitor different apps and as such have unique TestPartner databases as well. The process for upgrading the scripting framework assumes that the FrameworkUpdates.xml is imported to the master agent, and then published to all other agents. Is there any way to just publish the latest version of FrameworkUpdates.xml to all agents, without publishing the entire TestPartner DB?

Not sure honestly why the framework isn't automatically upgraded for each agent during service pack installation - why have this separate process for it?

Br,

Kalle

5 REPLIES 5

yuriy_look
Inactive

@Kalle
L.


Hi Kalle,

I think it was your customer’s wrong decision to have
different Recorder databases on different agents. I think the proper way of addressing this
situation would be creation of the database that would contain all the
scripting assets. Necessity to develop
different scripting assets on different machines does not preclude from having
a "master scripting database". If the database would be maintained on a specific machine, it could
still be considered a "master scripting agent".

I see the following major aspects of creating such database:


  • Exporting assets from the individual databases
    and importing them into the master database. For text assets (scripts, modules, shared modules) "copy and
    paste" could be an alternative.
  • Merging user modifiable functions and user
    created modules and shared modules.
  • Resolving naming conflicts. This might be pertinent to both the names of
    the assets and to the names used in user modifiable functions and in user
    created modules and shared modules.

It might make sense to use one of the databases as a starting
point. Also, It might make sense addressing
naming conflict in individual databases and making sure the scripts still work
prior to bringing the assets to the master database. And, of course, saving intermediate results –
things might not work right away.

Having one scripting database should be beneficial to your
customer from many points of view: assets sharing, code sharing, and, of course,
that they will need to update only one DB.

I cannot be more specific without seeing what your customer
has. Please feel free to post any
additional questions.

You might also like to post your thoughts in DC RUM Product Ideas forum.

Thank you,

Yuriy

Hi Yuriy,

Thanks for the response! I may have worded the "shared environment" a bit ambiguously, what I meant is that since we're a managed service provider, there are several different customers within one DC RUM environment. So as such, it's not a single customer's decision on how to implement this; agents are located within different customer subnets monitoring only a specific customer's apps, so the idea to have a single master agent is not really possible to accomplish.

I suppose there are two enhancement ideas that come to mind:

1. The ability to publish an xml file that is imported for selected agents. Since the current method only supports copypasting the TestPartner DB to the agent (thus overwriting the old one), this would require some work to also automate the asset importing.

2. The framework could be updated along with the regular agent recorder update - is there some reason why this isn't done automatically?

yuriy_look
Inactive

@Kalle
L.

Hi Kalle,

You probably know this, JIC. Files
that are necessary for the Framework updates are already present on the agent
in, by default, C:\Program Files (x86)\Compuware\Synthetic
Monitoring\Recorder\Framework Updates folder. You can use user data publishing for delivering your own xml files. But, you are right, currently there is no
option to automate importing into the Recorder database. This is why I suggested that you post your
proposed improvements in DC RUM Product Ideas forum. DC RUM Product Ideas forum is being closely monitored by
our product management, whereas this forum discusses using the existing product
features.

Thank you,

Yuriy

Thanks Yuriy, I'll definitely post an RFE regarding this. And good point about the XML file already being there, so you don't need to transfer it per each agent... But you do need to import it manually.

If anyone else would find this useful, please upvote the RFE here:

https://answers.dynatrace.com/spaces/436/dc-rum-rfes-very-new/idea/185745/rfe-ability-to-publish-xml-files-for-agent-recorde.html