Hello, We are currently running Pega 8.8 on DB2, PegaDATA, and our product data database is DB2 as well.
We are upgrading to Pega 24.1 which means Pega will be stored on MSSQL, but our product data will remain in DB2.
The issue is that we have 1,313 Connect-SQL rules that are on classes that do not have database mappings. This mapping has always been assumed to be our DB2 instance with Pega running on DB2.
We’ve defined our DB2 product database as AOSOR
We’ve tried going into the Advanced options of PegaDATA and including AOSOR as another “database that should be reachable by views in the database” and that did not work.
We are currently working on Creating new classes to save all of our Connect SQLs to that are mapped to AOSOR, which is quite the effort for our dev team and our QA team.
I am wondering if there may be any other options to map all of our existing Connect SQLs to AOSOR other than by class.
@CaleK902 We are upgrading from Pega 8.8 (on DB2) to Pega 24.1 (on MSSQL). However, our product data will still remain in the DB2 database (AOSOR). The issue is that we have over 1,300 Connect-SQL rules built on classes that don’t have explicit database mappings. Earlier, this worked fine since everything was on DB2. Now, Pega runs on MSSQL, so these rules can’t find the right database. We tried adding AOSOR as a reachable database under PegaDATA’s advanced options, but that didn’t help. Right now, we’re creating new classes mapped to AOSOR and moving the Connect SQLs there, but that’s a lot of work. I just wanted to check are there any other ways to point all these existing Connect SQLs to AOSOR without doing it class by class?
To solve this issue, you can map your existing classes to the AOSOR database without changing each Connect-SQL rule. One option is to create a Database Table rule and point your existing classes to AOSOR by setting the correct database and table name. If your Connect-SQL rules belong to a common class hierarchy, you can set the mapping at a higher-level class so all child classes use AOSOR automatically. Make sure AOSOR is defined correctly under SysAdmin > Database with proper connection details. If adding AOSOR to PegaDATA didn’t work, try defining it as a separate database rule instead. This way, you avoid creating new classes and reduce effort for your dev and QA teams
@Sairohith Thanks, We aren’t fully certain which classes need to be mapped to PegaDATA in our system, which is why we are creating the DB2 versions of all our classes to specifically use DB2 for those. Ideally, we’d have a way to map to both databases, or at least have a way to tell Pega to just use AOSOR when the package name in the Connect SQL was DB2, as we do have that package name on every SQL that needs to point to DB2.
We were able to come up with a mass solution to our problem. We are using the table directive {table: TableName} to point to a table in the correct database. In order to make this a mass solution, we are appending the table directive as a DB2 simple comment (–{table: TableName}) to the end of all of our SQLs that need to point to our DB2 database. Since Pega doesn’t process simple comments, Pega uses the directive to change to the correct database, but then when DB2 runs the SQL, the table inserted by the directive is commented out.