Is the Application (A) in Development environment or (B) a downstream environment where the Application has been deployed using a R-A-P?
With (B) you would start with the SystemManagement Service Package. First run the "GET" RestorePoint Service with no id. Find the name of the restore point created when the R-A-P was installed. Next run the "POST" Rollback Service providing the restore point name (id). For attachLog say "true". For action say "SystemRollback".
Attempting (A) would be very complex if wanting to pin-point rules and data in shared tables that apply to one particular application and not others. Data tables created specifically for the application would be simple to truncate.
i am looking for scenario A where we create a new application from wizard , by using refactor class and ruleset i was able to delete most of the rules except following . So for this rules in screen shot we have to open them and delete individually ?
Yes. If you create RAP - 2 after RAP - 1, then rollback to RAP - 1, the rules added by RAP -2 are deleted.
If concerned about loss of data, you have different options.
(1) A VM's directory can be copied. When launching it, say you "copied it" as opposed to "moved it". Switch VMs
(2) Start with a new VM before creating each application. Switch VMs.
(3) Or you could get fancy and backup the database itself after working on an application saving to a unique file name. Later restore the database when you want to come back to it (wiping out what was in the database previously). This takes time to do this however and, of course, is something you should ONLY use when prototyping.
NOTE: the script below also remove the PegaTemp directory. This is something you would do if wanting to get completely back to some "starting point" before any RAPs have been installed.
According to Help, a rollback looks at history records to decide what to remove.
8>< - - - - - - - rollback help - - - - - - - ><8
When you roll back to a restore point, thePega 7 Platformuses history records to return most of the system to the restore point state. Changes to the following items do not generate history records and therefore will not be rolled back using the roll back feature:
Java .jar imports
Some customdata instances: When you configure the data instance in the rule form, you can specify not to generate a history record. If the data instance does not generate a history record, changes to the data instance cannot be rolled back.
If you have direct access to the database, perhaps through Connect-SQL rules, or can provide a script that a DBA can execute (preferred), you can delete every row associated to a ruleset in your application regardless being a data class or a rule class.
Every database would have a way to search for columns by name regardless what table they are in.