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?
Answer by Yuriy L. ·
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.
Answer by Yuriy L. ·
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:
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.