Pega Platform’unda Declare Index, Report Definition Rule, Index Tablosu ve PZPVSTREAM Kolonu Hakkında

Pega platformunda örneğin bir Work Class’ı altında yeni bir Property Rule oluşturduğumuzda Work Class’ının ilişkilendirildiği tabloda veritabanı seviyesinde yeni bir kolon oluşturma zorunluluğu bulunmuyor.

Pega platformunun pc_work veya pr_other gibi OOTB tablolarında PZPVSTREAM adında binary large object tipinde bir kolon bulunuyor. Uygulamanın ihtiyacına göre yeni case type lar tanımlandıktan sonra oluşan class ların ilişkilendirildiği tabloda da aynı şekilde PZPVSTREAM adında binary large object tipinde bir kolon otomatik olarak oluşuyor.

Uygulama seviyesinde ilgili property’de tutulan bir bilgi spesifik bir kolon mapping’i olmasa bile ilgili Work tablosundan okunabiliyor veya bu tabloya yazılabiliyor. Çünkü, Pega uygulaması veritabanına bir commit işlemi gerçekleştirdiğinde property i serialize işleminden geçirip otomatik olarak PZPVSTREAM kolonuna yazıyor. Aynı şekilde select sorgusu çalıştırdığında da PZPVSTREAM içerisindeki veriyi Deserialize edip Pega uygulamasındaki obje lere dönüştürüyor. Diyelim yeni açtığınız N adet property niz var ve bu N adet property’de tutulan bilgilerin hepsi property tipinden bağımsız tekil veya liste olacak şekilde PZPVSTREAM  kolonunda topluca saklanabiliyor. Veritabanı seviyesinde PZPVSTREAM kolonundan bilgi okuyabilmek için ise aşağıdaki OOTB function kullanılabilir.

 

Pega platformunun sağladığı bu esneklik uygulama geliştirme süresini kısaltsa da diğer taraftan PZPVSTREAM kolonundan bilgileri okuyabilmek için uygulanan ekstra işlemden dolayı uygulama performansına olumsuz etki edebilir. Tek bir Case Instance’ını açarken (read: obj-open-by-handle) PZPVSTREAM kolonundan bilgileri okuma işleminin performansa olumsuz etkisi hissedilmesede rapor çekme gibi toplu yapılacak işlemlerde bu olumsuz etki hissedilecektir. Uygulamaya gelecek  değişiklik taleplerinde özellikle rapor taleplerinde yavaşlık doğrudan hissedileceğinden dolayı Pega platformu Report Definition rule içerisinde expose edilmemiş bir property kullanımı algıladığında Guardrail warnings kısmında size aşağıdaki şekilde uyarı gösterecektir.

 

Report Definition rule çalıştırıldığında ise yine aşağıdaki şekilde uyarı gösterilecektir.

 

Bu duruma önlem alınmalı çünkü örneğin Pending durumlu yüzlerce veya binlerce case’i kullanıcıya göstermek istiyorsunuz ve rapor içerisinde expose edilmemiş property ler var. Bu durumda her bir satır için PZPVSTREAM kolonundan bilgi okuma işlemi yapılacağından dolayı büyük performans sorunları yaşama ihtimali vardır. Bu durumda hem hatasız bir rapor çıktısı elde etmek, hem de major performans sorunları yaşanmaması için ilgili property için harici bir kolonun oluşturulması gerekecektir.

Pega platformunda property rule’unun actions kısmında “Optimize for reporting” adında bir özellik var. Bu işlem temel olarak ilgili property için ilgili tabloda spesifik bir kolon açmaya yarıyor yani bu işlem gerçekleştiğinde platform veritabanı seviyesinde ilgili tablo veya tablolar için ALTER TABLE .. ADD .. script’ini çalıştırıp tekil bilgi saklayan property için kolonu Work class ının ilişkilendirildiği tabloda oluşturuyor. Alan uzunluğunun değerini default olarak platforma bırakmak istemiyorsanız ilgili property rule unda max length alanına bilgi ihtiyaca göre girilmelidir. İlgili kolon oluştuktan sonra artık platform Report Definition rule unun üreteceği select sorgusunda bu yeni kolondan bilgiyi okuyacak ve Work object ine bir commit işlemi gerçekleştiğinde PZPVSTREAM’e yazmasının yanı sıra bu kolona da artık bilgiyi yazacaktır.

Normal şartlar altında Pega platformundan expose işlemi gerçekleştirildiğinde veritabanında property ismiyle aynı şekilde kolon oluşur ve ekstra bir işlem yapmaya gerek kalmaz. Ancak eğer bir sebepten property nin maplendiği kolon manuel oluşturulduysa ve ismi property isminden tamamen farklıysa bu durumda Work Class rule’unun external mapping kısmında property ile ilgili kolonun map lenmesi gerekecektir. Aksi takdirde platform örneğin activity rule undaki obj-browse methodu (ilgili property için select value only işaretlense bile) ile veya report definition rule undan bilgiyi PZPVSTREAM alanından okumaya devam edecektir.

Bu noktaya kadar  text, integer, decimal vb. tipte tekil bilgi tutan property rule ları varsayarak açıklamalar yapmıştık. Pega platformundaki veri yapılarında tekil bilgi saklayan property tiplerinin yanı sıra single page ve page list tipinde property lerde var. Temel olarak single page’e içerisinde birden fazla property barındırabilen tek object, page list’e de içerisinde birden fazla page barındıran array’e benzer bir veri yapısı diyebiliriz. Peki bu tipteki property leri ilgili Work tablosunun PZPVSTREAM kolonundan harici nasıl okuyacağız veya bir diğer deyişle nerede açığa çıkaracağız? Bu konuya çözüm olarak Index tablosu ve Declare Index adlı rule u kullanacağız. Temel olarak Declare Index kullanımı single page veya page list tipindeki property lerdeki bilgileri ana case tablosuyla primary key – foreign key ilişkisi olacak şekilde farklı bir tablo ile ilişkilendirmeye yarıyor diyebiliriz. İlgili case’in work object ine bir commit işlemi gerçekleştiğinde eğer declare index kullanılıyorsa örneğin page list içerisindeki bilgiler farklı bir tabloya yazılacaktır. Yazının devamında Order – Items veri modeli üzerinden pega platformundan declare index kullanımına örnek verelim.

 

Declare Index rule u oluşturmadan önce ilk etapta aşağıdaki Review Harness’da görüldüğü gibi  bir Order Case’i oluşturup Pega platformunun Order case’i altında bulunan Items Page List’ini nereye yazdığını aşağıda paylaşılan sorgu vasıtasıyla görelim.

QUERY

SELECT

pyID,

pr_read_from_stream(‘.Items(1).Code’,pzInsKey,pzpvstream) AS FirstItemCode,

pr_read_from_stream(‘.Items(1).Cost’,pzInsKey,pzpvstream) AS  FirstItemCost,

pr_read_from_stream(‘.Items(1).Quantity’,pzInsKey,pzpvstream) AS FirstItemQuantity,

pr_read_from_stream(‘.Items(1).Total’,pzInsKey,pzpvstream) AS FirstItemTotal,

pr_read_from_stream(‘.Items(2).Code’,pzInsKey,pzpvstream) AS SecondItemCode,

pr_read_from_stream(‘.Items(2).Cost’,pzInsKey,pzpvstream) AS  SecondItemCost,

pr_read_from_stream(‘.Items(2).Quantity’,pzInsKey,pzpvstream) AS SecondItemQuantity,

pr_read_from_stream(‘.Items(2).Total’,pzInsKey,pzpvstream) AS SecondItemTotal,

pr_read_from_stream(‘.Items(3).Code’,pzInsKey,pzpvstream) AS ThirdItemCode,

pr_read_from_stream(‘.Items(3).Cost’,pzInsKey,pzpvstream) AS  ThirdItemCost,

pr_read_from_stream(‘.Items(3).Quantity’,pzInsKey,pzpvstream) AS ThirdItemQuantity,

pr_read_from_stream(‘.Items(3).Total’,pzInsKey,pzpvstream) AS ThirdItemTotal,

pr_read_from_stream(‘.Items(4).Code’,pzInsKey,pzpvstream) AS FourthItemCode,

pr_read_from_stream(‘.Items(4).Cost’,pzInsKey,pzpvstream) AS  FourthItemCost,

pr_read_from_stream(‘.Items(4).Quantity’,pzInsKey,pzpvstream) AS FourthItemQuantity,

pr_read_from_stream(‘.Items(4).Total’,pzInsKey,pzpvstream) AS FourthItemTotal,

pr_read_from_stream(‘.Total’,pzInsKey,pzpvstream) AS TotalCost

FROM

pc_work_dms

WHERE

pzInsKey = ‘DMORG-DMSAMPLE-WORK ORDER-36’

QUERY RESULT

pyID Order-36
FirstItemCode 82H8034TTX
FirstItemCost 9.999
FirstItemQuantity 1
FirstItemTotal 9.999
SecondItemCode BX8069510940X
SecondItemCost 22.906
SecondItemQuantity 3
SecondItemCost 68.718
ThirdItemCode MHDC3TU/A
ThirdItemCost 15.999
ThirdItemQuantity 2
ThirdItemTotal 31.998
FourthItemCode PS719407775
FourthItemCost 8.999
FourthItemQuantity 1
FourthItemTotal 8.999
TotalCost 119.714

 

Görüldüğü üzere Items PageList’inin her bir elemanı Work class’ının ilişkilendirildiği tablonun PZPVSTREAM kolonuna yukarıdaki gibi yazılmış.  Yukarıdaki sorguyla tek tek her bir elemanın içerisindeki bilgiler sorgu sonucunda getirildi. Ancak bu kullanım mevcut yapının nasıl işlediğini bir örnekle göstermek içindi. Rapor’da sipariş ve bu siparişin kalemlerini dinamik olarak göstermemiz gerekecektir ve bunu gerçekleştirebilmemiz için Items Page List’inin farklı bir tabloda açık olarak tutulması gerekecektir. Bunun için önce Index-Items isminde Index- Abstract Class’ından türetilen bir Concrete Class oluşturacağız ve ardından Declare Index Rule vasıtasıyla Pega platformunun Items bilgisini Index-Items Class’ının ilişkilendirildiği tabloya yazmasını sağlayacağız.

Keys kısmında belirtilen pxInsIndexedKey alanına Work tablosundaki pzInsKey değeri yazılacaktır yani bu alan için foreign key bilgisini tutuyor diyebiliriz. pxIndexCount alanı index sayısını ve pxIndexPurpose da Declare Index rule un ismini tutuyor diyebiliriz.

Pega platformu pr_Index_Items tablosunu oluşturduğunda sadece OOTB kolonları oluşturacaktır. Bundan dolayı Items Page List Class’ında bulunan ve açığa çıkartmak istediğimiz tüm property ler de Index-Items Class’ı altında oluşturulmalı ve property rule içerisinde bulunan actions tuşu altında bulunan “Optimize for reporting” fonksiyonu kullanılarak açığa çıkartılmalıdır (tabloda yeni bir kolon oluşturulması). Bu arada Pega platformu concrete bir work class’ı veya data class ı oluşturduğunda bu class ların ilişkilendirildiği tabloda PZPVSTREAM kolonunu oluştururken Index tabloları için bu kolonun kullanımına gerek olmayacağından oluşturmayacaktır.

 

Son olarak aşağıdaki gibi Declare Index Rule’u oluşturup ardından yeni bir Order case’i üretelim ve Items Page List’indeki verilerin yazıldığı Index tablosunu kontrol edelim. Daha sonrasında Report Definition rule’u çalıştırarak ilgili Order ve Item larını getiren raporu Pega platformu üzerinde üretelim.

 

 

 

Order Work Class’ı altına bir Report Definition Rule oluşturalım. Report Definition Rule altında bir başka tabloyla Join leyebilmek için Class Joins, Declarative Index Joins, Associations veya Sub Reports özellikleri kullanılabilir. Index tablosuyla Join lemek için gereksiz efor harcamamak için doğrudan Declarative Index Joins özelliğini kullanmak yerinde olacaktır. Diğer taraftan Item’ın ismini Item bilgilerinin tutulduğu Master tablodan getirebilmek için Class Join kullanmamız uygun olur.

Rapor çıktısı

Vakit ayırdığınız için teşekkür ederim.

Mert Çaldağ