Question
IN
Last activity: 14 Aug 2015 15:14 EDT
Pega Migration Rules and OOTB Concepts
Hello Everybody,
I have the following doubts in mind for a long time. Any help on this would be pretty much appreciated.
1) What is OOTB(Out of the Box) in Pega and is this concept physically accessible or it is same as all the services provided by Pega?
2) Can you please let me know the detailed process of Migration( listing all the possible meanings for migration in pega)? In detail meaning a clear explaination of what it is done and how it is achieved?
Thanks in advance!!
Pegasystems
US
Ootb means no rules have been modified. Some examples:
1) You log in as [email protected] . That operator is ootb so its access group and ruleset list have not been changed.
2) You go into the app explorer to workpool PegaSample and run the NewWork flow in class PegaSample-CustomerRequest (my favorite example) . That is an ootb example.
3) You install the CPM framework (the name was recently changed but lots of folks know it as CPM) and then you may log in as CASysAdmin . That operator is ootb because it comes with the CPM installation.
The ootb rulesets for the base Pega product tend to all start with "Pega-". When you over-ride rules so that your app is no longer ootb, you will in general do a save-as from an ootb rule in a Pega- ruleset into one of your private rulesets whose name will start with something other than "Pega-".
/Eric
Pegasystems Inc.
GB
PRPC ships with many default rules which come 'out of the box' (ie, just after you install the product). Many customers may want to build on the top of these OOTB rules with their own customizations..
One of the reasons the question "Are you using OOTB rules?" tends to come out in discussions with GCS , is that one common approach we use in GCS is to try and reproduce a described scenario or issue as a test-case.
And for us to build a test-case we need to know if any customizations are necessary for the test-case, or whether the test-case can be constructed with OOTB rules.
As far as I'm aware (or at least how I would understand it) the term 'migration' means to move data and rules from one system to another.
So you could migrate Rules from a DEVELOPMENT system to a PRE-PRODUCTION system for instance.
PRPC has the concept of a 'RAP' file (it has nothing to do with music :-) ) a "Rule Application Product" file - it's a mechanism built into PRPC that lets you package up Rules (and Data) into a ZIP file, which can be imported into another PRPC system.
Or you could migrate Rules and Data from an older system to a new environment ready to upgrade the PRPC software. This might be done via a combination of native Database Tools and PRPC tools. (and may also include the use of RAP files as well).
Hope this helps ?
IN
Hi John,
This is really a useful information for me. I would very glad if you could expose the process of customizing OOTB rules and also migration process in detail.. like from your experience.I am hoping to hear something similar to real life scenario which can help me best understand the concept. any documentation on how to perform these operation would be of great help.
Thanks in advance
Pegasystems Inc.
US
Prasanna,
Quite often the OOTB functionality doesn't quite meet your business requirements. Say you want to tweak the way bulk processing works for some reason. So you open the bulk processing rule that you want to change and you copy it into your own ruleset and add your customization. You can no longer accurately say that you are using OOTB bulk processing, because you have taken the rules and altered them, although you used the OOTB rules as your starting point. Conceivably, you could also decide that OOTB bulk processing is so far removed from your needs that you want to build your own from scratch. That would be a custom implementation of bulk processing. Some rules are key to the functioning of the product and so they are marked as final, which means you can't create a rule of the same name in your own ruleset. That prevents you from unintentionally breaking core pieces of functionality. You can call those final rules from your custom rules or you can build your own custom implementation using them as a starting point, by copying them to a new name and making changes, but you are most definitely not building something OOTB at that point. As for how to actually perform it, it's as easy as having an unlocked ruleset, opening the rule you want to customize and hitting save as.
Prasanna,
Quite often the OOTB functionality doesn't quite meet your business requirements. Say you want to tweak the way bulk processing works for some reason. So you open the bulk processing rule that you want to change and you copy it into your own ruleset and add your customization. You can no longer accurately say that you are using OOTB bulk processing, because you have taken the rules and altered them, although you used the OOTB rules as your starting point. Conceivably, you could also decide that OOTB bulk processing is so far removed from your needs that you want to build your own from scratch. That would be a custom implementation of bulk processing. Some rules are key to the functioning of the product and so they are marked as final, which means you can't create a rule of the same name in your own ruleset. That prevents you from unintentionally breaking core pieces of functionality. You can call those final rules from your custom rules or you can build your own custom implementation using them as a starting point, by copying them to a new name and making changes, but you are most definitely not building something OOTB at that point. As for how to actually perform it, it's as easy as having an unlocked ruleset, opening the rule you want to customize and hitting save as.
Since you are building all your rules in an unlocked ruleset and these days that should be associated with an application, a RAP is going to be the recommended way to migrate your changes. Those topics are covered in detail in the PDN and Pega Help. I'd suggest you start there and if you have more specific questions, bring them back here since it's easier to answer something more focused.
Cheers,
Mike
Pegasystems Inc.
US
Hi Prasan,
The below PDN links may be helpful to you. Some of the data overlaps with what has already been mentioned in this discussion.
Links related to the term "OOTB":
https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm
https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm
Links related to the Migration:
https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm
https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm
You can click on "Related Information" in each the above articles to see related articles where you might also find useful information.
Hope this helps!
-Kurt