The study of Pega Platform goes on and I find myself again onto something that feels relevant: CPU activity. Pega treats system processing with a different approach, and I think it is worth to take some time to have a closer look into it.
Scripts vs Activities
Data Transforms are rules intended to perform small conversions and assignments. They are implemented as a list of actions that execute in the order defined in the rule.
Activities are meant for more complex operations that are not possible using other tools (like Data Transforms or Calculated Fields). They consist of a sequence of standard methods and actions, and eventually (although strongly discouraged) they can contain calls to Java code.
When and Where?
The difference between IBM scripts and Pega activities does not only affect the implementation itself. There is another important aspect, and it is “how to use them?”. When and where can you use a script or an activity?
And the answer for IBM is anywhere, anytime. You can always include a script item in the flow, either in a process or in a service, and write the code you need. Processes even offer a system lane, where all the system operations (scripts or services) should be placed. Services can include any number of scripts and nested system services. So, as we can see, flexibility is maximum. Besides, every item in a process or service has the possibility to have some pre- and post-script that executes right before or right after the item.
Pega, on the other hand, does not allow to add system operations so easily. They always need to be attached to some other element in the case definition. Data transforms and activities can be added to a connector between user assignments, which requires opening the process flow diagram and editing the configuration of the connector. The other option to locate them is as a pre- or post-processing of another user assignment, via the configuration of the user assignment itself.
Both tools support the execution of scheduled tasks in a very similar way. IBM uses Undercover Agents (UCAs) to define the date, time and frequency to execute a service. Pega provides Job Schedulers, which work in the same way as UCAs, allowing to specify date, time and frequency of execution for the activities.
Even though BPM is oriented to orchestration of tasks performed by different actors within a process, and thus should be focused on facilitating user-related tasks, there is always a big part of CPU time happening. Initializations, calculations, decisions and information exchange are present in almost any scenario, so system activities always have an important role as well.
Here is a quick comparison of the different points we have discussed:
The general impression is that Pega does not give this feature so much importance. There is not a clear room for it, but activities in case types are always “hidden” behind other elements: associated to process flows or executed as pre/post activities of other flow actions. Meanwhile, IBM has a specific place for them in the system lane of the process and allows to have them anywhere inside services.
So to sum up, I have to stick with IBM on this one. I definitely find it better prepared to handle all the system activity. Pega is looking so dark and limited for me! Or maybe it is just a matter of experience… Only time will tell.Overzicht blogs