Question
Conduent
US
Last activity: 13 Jan 2016 14:13 EST
we have imported the hotfix jar file and did so much development .now we need to revert the hotfix .could you please suggest the possible approaches to revert the hotfix.
we have imported the hotfix jar file and did so much development .now we need to revert the hotfix .could you please suggest the possible approaches to revert the hotfix.?
Pegasystems Inc.
IN
Hi Ramisetty,
If you have installed the HFIX via update manager then it would have been easier to implement.Now that you are saying that you imported the HFIX ( perhaps a framework specific HFIX ), there is no such direct mechanism to revert the changes.
Before we dig more on this , I would like to understand few things :
1. Why you are trying to revert the changes made via HFIX ? Is it showing any sideeffect ?
2. Are you aware of the HFIX number and the rules that got changed via this HFIX ?
Conduent
US
Hi Santanu Bhattacherjee,
Thank you for your reply, please find the below reply.
1. Why you are trying to revert the changes made via HFIX ? Is it showing any sideeffect ?
Ans:actually hotfix is not working as expected.
2. Are you aware of the HFIX number and the rules that got changed via this HFIX ?
Ans: yes HFix-25192 for SR-A13258 and we are aware what are the rules modified as part of the hotfix.
Thank you,
Ramisetty
Pegasystems Inc.
IN
Hi
I suggest you to reopen the SR-A13258 and involve PEGA GCS for further troubleshooting.
If it happens to be a faulty HFIX then the changes can be revoked only via another HFIX .
Pegasystems
US
Hi,
Before they re-open the hfix, please note that I suggested they ask their question here in the community. Certainly if we all can not help here, then a new sr can be made, but I still think it's good to work the issue here first.
/Eric
Pegasystems
US
Hello,
The HFix-25192 being discussed is a PegaSurvey one, and hence was installed with the import landing page and not with the update manager landing page.
Ramisetty, I am looking in more detail as to exactly what got imported with that hot fix, but while I look, I want to offer the following general ideas and ask the following questions of you, the answers to which will help clarify your situation:
1) The hot fix includes both a rule utility function and some rules that reference the function. It is quite possible that if you really need to revert the hot fix, you only need to revert the rules that call the function, and not actually remove the function, since its existence will not harm anything, and attempting to remove it may be unnecessary and risky.
2) If the number of rules is small, can you do a private-checkout of the involved rules, and set the contents of the checked out rules to their pre-hotfix state ? And when you do that and test, does it show the desired pre-hotfix behavior ? Note that checked out rules will only be seen by requestors logged in as the user who does the checkout. In particular, SLA jobs will not see the checked out rules, and other users logging in will not see the checked out rules. This can be both GOOD and BAD. GOOD because it allows one user to test without breaking something for other users, but BAD if you WANT another user to be able to test.
Hello,
The HFix-25192 being discussed is a PegaSurvey one, and hence was installed with the import landing page and not with the update manager landing page.
Ramisetty, I am looking in more detail as to exactly what got imported with that hot fix, but while I look, I want to offer the following general ideas and ask the following questions of you, the answers to which will help clarify your situation:
1) The hot fix includes both a rule utility function and some rules that reference the function. It is quite possible that if you really need to revert the hot fix, you only need to revert the rules that call the function, and not actually remove the function, since its existence will not harm anything, and attempting to remove it may be unnecessary and risky.
2) If the number of rules is small, can you do a private-checkout of the involved rules, and set the contents of the checked out rules to their pre-hotfix state ? And when you do that and test, does it show the desired pre-hotfix behavior ? Note that checked out rules will only be seen by requestors logged in as the user who does the checkout. In particular, SLA jobs will not see the checked out rules, and other users logging in will not see the checked out rules. This can be both GOOD and BAD. GOOD because it allows one user to test without breaking something for other users, but BAD if you WANT another user to be able to test.
3) The original hot fix was resolved as "verified" which means the customer assessed that the hot fix solved the original issue. Which of these is your current assessment:
a) Yes, we verified it. It solved the original issue, but we now realize our needs are somewhat different so we want to remove the
hot fix. OR . . .
b) Yes, we verified it, but we shouldn't have. It never actually solved the original issue.
/Eric
Conduent
US
Hi Eric,
Thank you for your reply. actually the problem here is hotfix didn't solve the original issue which we raised and business team observed that some clinical safety that the reason we removed the hotfix in the production environment. we had connect on this and restore the DB in prod environment.
As you are suggested make the rules in private checkout state and modified the rules into pre hotfix state, I am thinking it is not possible due to below reasons.
1).pega survey rule set is OOTB
2) imported and existing rule set version is same like PegaSurvey:07-10-14
3) Most of the imported rules are final rules
finally what we are looking here is , delete the existing PegaSurvey:07-10-14 version and reimport the PegaSurvey:07-10-14 version with out HFix-25192 changes.
Please suggest.
Thank you
Ramisetty Sreenivasulu
JPMC
IN
Hi Ramisetty,
As suggested earlier as well, i can suggest following ways:
1) Restore DB backup (which seems not possible for you as you have done lot of Dev work)
2) Delete the rule changes from the DB directly. (the rule changes has been already mentioned)
3) Create a RAP of your application (which will have all your Dev work). Restore the DB backup that you have. Then reimport your application RAP. Thus you donot loose your dev work.
Pegasystems
US
For reference, here is the list of exactly which rules are included in HFix-25192 . I observed this list by starting "designer studio - > application - > distribution - > import" and specifying the hot fix jar file, and clicked the "allow more granular control" checkbox and advanced one screen beyond that:
Pegasystems
US
Ramisetty, I agree with you that testing with private checkout is not the best way, since the number of rules involved in the hot fix is about 30. However, as a point of technicality, private checkout will work even in situations where rules are final, and rulesets are locked. Normal checkout will not work.
NOTE: Before you try any solution to your issue, make sure you have an emergency db backup of your system. Your system currently works, although not exactly the say you want. If any solution you try leaves you with a non-working system, restoring from this emergency backup will be your easiest way to have a working system again.
Expanding on what Ashish said above, once you have an emergency db backup of your system, I suggest the following :
From reading what's been written so far, I assume that on dev, you had made a pre-hotfix db backup, and then you installed the hfix, plus you did development, so that now you are not wanting to restore from that pre-hotfix db backup because although it will properly revert the hot fix, it will also lose the subsequent development you have performed, is that correct ?
If that assumption is correct, I suggest these steps, which I believe is what Ashish was describing :
1) Make a rule-admin-product (often called a RAP) and use the "create product" button at the bottom of that RAP to produce a recent-development zip file of all the development you have performed after you installed the hfix. Are you clear how to make this rap and zip ?
Ramisetty, I agree with you that testing with private checkout is not the best way, since the number of rules involved in the hot fix is about 30. However, as a point of technicality, private checkout will work even in situations where rules are final, and rulesets are locked. Normal checkout will not work.
NOTE: Before you try any solution to your issue, make sure you have an emergency db backup of your system. Your system currently works, although not exactly the say you want. If any solution you try leaves you with a non-working system, restoring from this emergency backup will be your easiest way to have a working system again.
Expanding on what Ashish said above, once you have an emergency db backup of your system, I suggest the following :
From reading what's been written so far, I assume that on dev, you had made a pre-hotfix db backup, and then you installed the hfix, plus you did development, so that now you are not wanting to restore from that pre-hotfix db backup because although it will properly revert the hot fix, it will also lose the subsequent development you have performed, is that correct ?
If that assumption is correct, I suggest these steps, which I believe is what Ashish was describing :
1) Make a rule-admin-product (often called a RAP) and use the "create product" button at the bottom of that RAP to produce a recent-development zip file of all the development you have performed after you installed the hfix. Are you clear how to make this rap and zip ?
2) Restore from the pre-hotfix db backup. Make sure your system exhibits the pre-hotfix behavior.
3) Use the import-landing page to pull in the recent-development zip. Now verify that your system still is without the hot fix, but that your system includes your recent development.
/Eric
Pegasystems Inc.
US
I would second Ashish's #3 suggestion. That will solve your immediate concern. However, I'm not sure you're well served to leave it at that. Does the HFix introduce a new issue that should be corrected or do you just not like the behavior? If it's the former, working with GCS to get the new problem addressed would be your best bet. You may want to set up a sandbox so that that work doesn't impact your dev work. Alternately, if you just don't like the behavior, you should consider how it's not meeting your needs and look into ways to get it to work satisfactory with your application. The reason for this is twofold. The first is to prevent you from running into critical roadblocks if you ever need a HFix that pulls this one in as a dependency. The second is to avoid adding problems when you try and upgrade.
Thanks,
Mike
Conduent
US
Hi Ashsish/Eric/MIke,
Could you please validate the below proposal to revert the hotfix.
1.we will take the existing DB backup
2.Delete the pegasurvey:07-10-14 rule set version from dev environment
3.Re-import the pegasurvey:07-10-14 rule set from other environment (where we didn't import the hotfix 25192)
4.revalidate and save the required functions
Regards,
Ramisetty
Pegasystems Inc.
US
Ramisetty,
That seems like a fairly safe approach. That said, I'd still like to know the answer to my questions of 7 Jan. Otherwise you may be getting a temporary reprieve while setting yourself up for long term (and potentially more critical) failure. The HFix you don't like WILL be pulled in as a dependency for future HFixes and if you find avoid installing the dependencies, you essentially sign up for a broken and unsupportable system, meaning GCS won't be able to help you with any future problems until you get your install to a known good state (i.e. get all dependent HFixes correctly installed). My personal feeling is that it is better to address root causes than symptoms.
Thanks,
Mike
Conduent
US
Hi Mike,
Thank you for your reply. I would like give more context on the issue which we requested for the hotfix.
1.I think you have an idea on pegasurvey frame work
2.Assume that do we have an a simple question of type date control.
3.Assume that if we enter some text like (#^*%&*%&*kjdghfjkdsg)
4.Try to submit the assessment form
6.We are not getting an html exception on the screen
7. for this issue pega GCS team provided fix that, if we enter some text on the date control they are refresh the text and submit as null.
8.Here our Business team treat this as clinical safety issue, that the reason we are planning to revert the hotfix.
9.from the solution point of what we are looking here , we need to validate the date format which we entered in the date control
Please write to me if you want more info,.
Thank you .
Ramisetty
Accenture
IN
Hi all,
We would like to get your endorsement on the following approach. As you are aware of the total issue. i am just bulleting the points which we think would be the ideal and more cleaner approach where there is no data and rules loss.
1. Take a back up of the current database.
2. Restore the DB before the hot-fix was installed in the environments.
3. Export Pega-Survey Rule set from the DB restored and keep it Handy.
4. Restore the current database again.
5. Delete the Pega-Survey ruleset from the current database.
6. Re-import the Peag survey ruleset exported in the earlier step.
if we follow the above steps there would be no data as well as rules loss. Kindly advise if we can go with this approach for the hot-fix reversal
Pegasystems
US
One thing you could do that would gain confidence without harming your current system, is, after you do number 1 to obtain a db image, perform the rest of the steps on a new system. If after the steps on the new system, that system behaves properly, then great, you know the steps work, and you can even say you're done if you're willing to use the new system instead of the original.
Or, you can repeat the steps again on your original system (except for number 1) with your gained confidence.
On the other hand, if for some reason the new system does not work, at least you still have your original system still running.
(This reminds me of a story I heard several years ago, of a shop where rather than merely backing up their main system each week, they immediately did a "restore" of that backup on their alternate system, and then swapped systems so the alternate was now the main system. That allowed for continual confirmation that the backup actually was usable)
/Eric