Question
Pega Static Assembler Utility - Implementation plan
We are planning to implement static assembly process across all the application. There are applications which are in Pega 6.x and in 7.x as well.
We ran the utility in the development environment, which took approximately 2 hrs to complete the process. Below is the snapshot of the log entries which summarizing the completion status.
jvm1 STATIC ASSEMBLY SUMMARY
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - ===========================================================================
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Processed : 116156
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Assembled : 114352
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Not Assembled : 400
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Not Eligible : 1404
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - Total Duration taken (in Sec) : 2421
I have below questions which needs to be clarified in order to better plan the production implementation.
In case of multi node clustered environment, is it required to run for each node or cluster? I see there is a property that we set in the prstaticassembly.properties file to specify the no. of JVMs. What is there relevance of that? If the assembled rules gets stored into DB then running it only once should serve the purpose , please confirm if my understanding is correct.
Does static assembly process only update DB or it also update the disk?
PRPC 7.1.X the “Static Assembler” is available for the user to kick off himself at (Pega button) > System > Tools > Static Assembler. Does that mean after new code deployment running this from one of the node is what required to pre-assemble all the rules?
How to verify that all the required assemble is done and the end user is benefited from this.
Is there a way to not to include based on application each time when we do static assembly ?
In the log snapshot there are entries as below, what is the reason of this and do we care about this?
No of Rules Not Assembled : 400
No of Rules Not Eligible : 1404
Thanks
Sarada
In case of multi node clustered environment, is it required to run for each node or cluster? I see there is a property that we set in the prstaticassembly.properties file to specify the no. of JVMs. What is there relevance of that? If the assembled rules gets stored into DB then running it only once should serve the purpose , please confirm if my understanding is correct.
>>> that is correct! since results are stored in the db, dont have to execute for each jvm.
Does static assembly process only update DB or it also update the disk?
>>> its only the db.
PRPC 7.1.X the “Static Assembler” is available for the user to kick off himself at (Pega button) > System > Tools > Static Assembler. Does that mean after new code deployment running this from one of the node is what required to pre-assemble all the rules?
>>> it depends on no of rules being introduced in the release. for incremental releases, most likely you dont need them. probably you may want to validate it in one of the envs like QA/Test to determine the benefit.
How to verify that all the required assemble is done and the end user is benefited from this.
>>> after the static assembler execution, if users start using the application, there should not be any additional updates to 'pr_assembledclasses' table, since rules should be assembled already.
Is there a way to not to include based on application each time when we do static assembly ?
>>> this could be a product enhancement, if you could show the evidence & benefits.
In the log snapshot there are entries as below, what is the reason of this and do we care about this?
No of Rules Not Assembled : 400
No of Rules Not Eligible : 1404
>>> looks like an information only. while verifying assembly results, if you notice additional updates to 'pr_assembledclasses' table, then this numbers needs to be revisited.