Database Table Creation of History Classes
Hello Everyone,
I am looking for an answer on the below issue/question...
Whenever a new class is created, Pega will automatically create a History class for that new class and will "link" it with PegaDATA database instance. My question is, if there is any way to have the control on the database instance rule where the History class to be created.
For instance, when we create a new Data Type and source it with CustomerDATA database instance (assume the CustomerDATA database instance is configured to map to a new database schema), Pega will create a database table under the database schema where CustomerDATA database instance is mapped to. But, the database table of the History class will always be created under PegaDATA database instance, hence it will go into a different database schema. So, is it possible to get the control under which database schema the History table to be created?
The same behaviour as above will also occur whenever we create any dedicated class manually.
I am not looking for a solution from the db backend where with some manual actions the above problem can be solved.
Thanks a lot in adavnce!
Ozkan
***Edited by Moderator Marije to add Case INC-B4013 and FDBK-110564 tags***
Accepted Solution
Updated: 19 Feb 2024 5:26 EST
Pegasystems Inc.
GB
@OZKANMECH I can see that your support ticket INC-B401 ( Database Table Creation of History Classes) was investigated and the final conclusion was this:
-----------------------------------------
We discussed the issue with our SMEs - they do not consider it as a bug.
Pega uses two database schemas, one for the rules (nicknamed PegaRULES), the other one for the data (nicknamed PegaDATA).
You are using a feature that we refer to as "External Database". This was originally invented to allow an easy integration of data stored by 3rd party products, then it was extended to allow Pega data to be shared on database level with external products; to simplify that, you can create Pega Classes that are using such an external database for their storage – but still with the focus on integration with 3rd parties. On this background it is a logical design decision to keep the history tables in the main data schema (PegaDATA).
Consequently, this means that the behaviour that you observes (that a history table is created in PegaDATA even for tables created in an external schema) is expected and desired, so not a bug.
The Database Rule is referring to an "External Database" in regards to the *Pega*-only product.
@OZKANMECH I can see that your support ticket INC-B401 ( Database Table Creation of History Classes) was investigated and the final conclusion was this:
-----------------------------------------
We discussed the issue with our SMEs - they do not consider it as a bug.
Pega uses two database schemas, one for the rules (nicknamed PegaRULES), the other one for the data (nicknamed PegaDATA).
You are using a feature that we refer to as "External Database". This was originally invented to allow an easy integration of data stored by 3rd party products, then it was extended to allow Pega data to be shared on database level with external products; to simplify that, you can create Pega Classes that are using such an external database for their storage – but still with the focus on integration with 3rd parties. On this background it is a logical design decision to keep the history tables in the main data schema (PegaDATA).
Consequently, this means that the behaviour that you observes (that a history table is created in PegaDATA even for tables created in an external schema) is expected and desired, so not a bug.
The Database Rule is referring to an "External Database" in regards to the *Pega*-only product.
The reported behaviour is working as designed and intended, however, the affected feature can be used also in a different way and in such a case, the automatic creation of the associated history tables together with the data tables in the external database would be convenient.
This feature not the original intention for the External Database feature and hence the product does not support your idea out-of-the-box.
Nevertheless, we raised an enhancement request with the number FDBK-110564.
You may track it through your Pega CSM or Pega AE.
------------------------------------
Aaseya IT Services Pvt Ltd
SA
While creating the DB table you have an option to choose the pega data . Better you create the table in Pega Data .
Updated: 28 Jan 2024 17:34 EST
ING
BE
To me, PegaDATA should be reserved for OOTB tables, client data should be stored in different database schema, hence separate database instance.
You cannot create a DB table before you create the corresponding class, and as I explained above if you create the class you dont have the control where the History class will go (it always goes to PegaDATA). But, thanks for your response.
Pegasystems Inc.
GB
@OZKANMECH I can see that this is a duplicate question to one you posted in December:
CustomerData DB Instance/Schema
Please can you mark your last reply as Accepted Answer or copy in the full answer from the other post so that we can close this off?
Updated: 19 Feb 2024 5:16 EST
ING
BE
@MarijeSchillern Not sure how you see this as duplicate but I will close it as I also raised an SR for this. I will follow on this issue through the SR INC-B4013.
Thanks a lot for your support.
Ozkan
Pegasystems Inc.
CA
If there is a requirement to store BLOB information, then you have to use pegaData. PegaData is not meant to store ONLY OOTB tables, but it depends on the requirement to store the data (BLOB) in the data table.
https://support.pega.com/discussion/customerdata-non-blob-vs-pegadata-blob
ING
BE
@RameshSangili thanks for your response, but your answer is not relevant to my question.
Ozkan
Accepted Solution
Updated: 19 Feb 2024 5:26 EST
Pegasystems Inc.
GB
@OZKANMECH I can see that your support ticket INC-B401 ( Database Table Creation of History Classes) was investigated and the final conclusion was this:
-----------------------------------------
We discussed the issue with our SMEs - they do not consider it as a bug.
Pega uses two database schemas, one for the rules (nicknamed PegaRULES), the other one for the data (nicknamed PegaDATA).
You are using a feature that we refer to as "External Database". This was originally invented to allow an easy integration of data stored by 3rd party products, then it was extended to allow Pega data to be shared on database level with external products; to simplify that, you can create Pega Classes that are using such an external database for their storage – but still with the focus on integration with 3rd parties. On this background it is a logical design decision to keep the history tables in the main data schema (PegaDATA).
Consequently, this means that the behaviour that you observes (that a history table is created in PegaDATA even for tables created in an external schema) is expected and desired, so not a bug.
The Database Rule is referring to an "External Database" in regards to the *Pega*-only product.
@OZKANMECH I can see that your support ticket INC-B401 ( Database Table Creation of History Classes) was investigated and the final conclusion was this:
-----------------------------------------
We discussed the issue with our SMEs - they do not consider it as a bug.
Pega uses two database schemas, one for the rules (nicknamed PegaRULES), the other one for the data (nicknamed PegaDATA).
You are using a feature that we refer to as "External Database". This was originally invented to allow an easy integration of data stored by 3rd party products, then it was extended to allow Pega data to be shared on database level with external products; to simplify that, you can create Pega Classes that are using such an external database for their storage – but still with the focus on integration with 3rd parties. On this background it is a logical design decision to keep the history tables in the main data schema (PegaDATA).
Consequently, this means that the behaviour that you observes (that a history table is created in PegaDATA even for tables created in an external schema) is expected and desired, so not a bug.
The Database Rule is referring to an "External Database" in regards to the *Pega*-only product.
The reported behaviour is working as designed and intended, however, the affected feature can be used also in a different way and in such a case, the automatic creation of the associated history tables together with the data tables in the external database would be convenient.
This feature not the original intention for the External Database feature and hence the product does not support your idea out-of-the-box.
Nevertheless, we raised an enhancement request with the number FDBK-110564.
You may track it through your Pega CSM or Pega AE.
------------------------------------