Question
Pegasystems Inc.
JP
Last activity: 23 Aug 2017 11:46 EDT
Other unknown hotfixes are installed by itself
Hi,
We have been provided a specific hotfix for our project and it contains a single hotfix (just one activity) that does not require any other hotfix (there is no dependencies). However when we install the hotfix, other unknown hotfixes are also installed by itself. Actually this is not the first time but every time we install provided hotfixes some other multiple hotfixes are installed. Why does this happen? As a standard policy, does hotfix include other important or critical hotfixes all together although they are not directly dependent? Where system is already in production, we need to pay a lot of attentions to what is installed and can't let any unknown hotfixes to be installed just because it is critical or not, without testing or knowing the actual codes because we need to reivew and analyze if it impacts our own application first.
Also, our system is in a closed environment with no Internet connections. That means other hotfixes can't be included in the DL-XXXXX.zip file without GCS manually including it, correct? I am asking this question because every time we install hotfixes we notice others are installed, and is this because system automatically checks what we have in our system and detects what is actually needed, and installs whatever is evaluated to be must be installed, or GCS manually mispackaged it to zip file? I don't see any other fixes binary in the zip file and wondering how things work here. I have never uploaded Catalog file since we did clean installation of Pega 7.2 so far.
Thanks,
Hi,
We have been provided a specific hotfix for our project and it contains a single hotfix (just one activity) that does not require any other hotfix (there is no dependencies). However when we install the hotfix, other unknown hotfixes are also installed by itself. Actually this is not the first time but every time we install provided hotfixes some other multiple hotfixes are installed. Why does this happen? As a standard policy, does hotfix include other important or critical hotfixes all together although they are not directly dependent? Where system is already in production, we need to pay a lot of attentions to what is installed and can't let any unknown hotfixes to be installed just because it is critical or not, without testing or knowing the actual codes because we need to reivew and analyze if it impacts our own application first.
Also, our system is in a closed environment with no Internet connections. That means other hotfixes can't be included in the DL-XXXXX.zip file without GCS manually including it, correct? I am asking this question because every time we install hotfixes we notice others are installed, and is this because system automatically checks what we have in our system and detects what is actually needed, and installs whatever is evaluated to be must be installed, or GCS manually mispackaged it to zip file? I don't see any other fixes binary in the zip file and wondering how things work here. I have never uploaded Catalog file since we did clean installation of Pega 7.2 so far.
Thanks,
***Updated by moderator: Lochan to add SR details***
Accepted Solution
Updated: 1 Aug 2017 12:15 EDT
Pegasystems Inc.
IN
Hello!
On reviewing this SR, we see that it is closed with a suggestion to apply HFix-35184 and an explanation that this issue is fixed in Pega 7.3.
Regards,
PEG
GB
There is no facility in the product to automatically download and install hotfixes.
So if you are observing additional hotfixes appearing after installing 1, then there may be other explanations.
1) Does this DL actually contain multiple hotfixes?
When the GCS team build a DL this will either be a single hotfix, or more than one explicitly added hotfixes (we've selected more than one hotfix to include in the DL) or more than one implicitly added hotfixes (the system has recognised a dependency and has automatically included further hotfixes), or a combination of explicitly and implicitly included hot fix.
But for these, I'd expect that you'd see them when you attempt to install the hotfix.
Also, you should be able to see these when you open the DL file directly.
But from the description when you added this post, this sounds unlikely to be the case here.
2) You actually already have the hotfix installed.
During a hotfix installation the system is going to try to identify which hotfixes you already have through a combination of what you have installed (generally contents of the PR4_ tables and PR_ENGINECLASSES) and the information in the system catalog.
Each DL that we provide will automatically include the CATALOG.ZIP so it seems more likely to me that you may already have rules/engineclasses installed which marry up to hotfix versions in the catalog.
There is no facility in the product to automatically download and install hotfixes.
So if you are observing additional hotfixes appearing after installing 1, then there may be other explanations.
1) Does this DL actually contain multiple hotfixes?
When the GCS team build a DL this will either be a single hotfix, or more than one explicitly added hotfixes (we've selected more than one hotfix to include in the DL) or more than one implicitly added hotfixes (the system has recognised a dependency and has automatically included further hotfixes), or a combination of explicitly and implicitly included hot fix.
But for these, I'd expect that you'd see them when you attempt to install the hotfix.
Also, you should be able to see these when you open the DL file directly.
But from the description when you added this post, this sounds unlikely to be the case here.
2) You actually already have the hotfix installed.
During a hotfix installation the system is going to try to identify which hotfixes you already have through a combination of what you have installed (generally contents of the PR4_ tables and PR_ENGINECLASSES) and the information in the system catalog.
Each DL that we provide will automatically include the CATALOG.ZIP so it seems more likely to me that you may already have rules/engineclasses installed which marry up to hotfix versions in the catalog.
If this is the case, then you haven't actually installed anything new, other than the ones noted during the hotfix installation.
Pegasystems Inc.
JP
Thanks for the info. Yes, scenario 1 seems not be the case for us this time. I am trying to understand scenario 2, but according to your explanation, we haven't actually installed anything new but it just started to appear on Hotfix Manager gadget because of the updated Catalog.zip which is contained in the provided DL file. Is that right? If so, okay, maybe. Then when was it that these additional hidden hotfixes "actually" installed, and how?
In general, although some hotfixes are important in any sense, we can't just install it without knowing what they are because it may gives impact on current application in production. We want to apply only what we want (plus only dependencies). How can we get to know what exactly would be installed beforehand?
Thanks,
PEG
GB
I don't currently have access to a 7.2 system that doesn't contain any hotfixes, so it is difficult to verify at the moment.
But again, if you are seeing hotfixes installed that you weren't aware of installing, then it could be the case that the code/rules associated with the hotfix is already in your system. So in terms of change control and post hotfix installation testing, this seems unlikely to feature as a concern.
As for what is being installed, you should be able to open the DL then open the HFix jar file. This will contain a README file which shows the rules code changed for that hotfix.
One more thing that is worth mentioning; When we try to determine whether a hotfix is installed we either use the class module version (if it is a engine class) or the date of the rule (for rules) to determine whether you already have that hotfix.
However, some hotfixes can include one or more jar files, which so far as I'm aware don't have any version information associated with them. If this is the case then those hotfixes may show up as Partially Installed, as we're unable to verify whether the hotfix is installed or not.
Other Partially Installed hotfixes may just mean up have a component of that hotfix (a code/rule change) that was brought in due to the same code/rule being included in a hotfix that you are installing.
You may wish to verify what's been installed by taking a look at the contents of the pr_sys_hotfix_events table.
Updated: 22 Jun 2017 3:55 EDT
Pegasystems Inc.
JP
Hi,
I got a response from GCS team and they said this is a defect around Hotfix Scanner. We verified that these unknown fixes don't exist on PR_ENGINECLASSES table and Hotscan Manager gadget is wrongly displaying something that don't exit or are not installed. I am communicating with GCS to see if they can provide a fix for this..
Thanks,
***Updated by moderator: Lochan to remove internal mesh link***
Accepted Solution
Updated: 1 Aug 2017 12:15 EDT
Pegasystems Inc.
IN
Hello!
On reviewing this SR, we see that it is closed with a suggestion to apply HFix-35184 and an explanation that this issue is fixed in Pega 7.3.
Regards,