icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close icon-arrow-uturn icon-calendar icon-clock icon-search
Werken bij Rivium
Blog 23/09/2020

From IBM to PEGA: #3 System Tasks

Pega #3

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
The tools offer two completely different solutions: IBM provides “Scripts” to write any Javascript code needed to perform system operations, while Pega provides “Data Transforms” and “Activities”, which are basically lists of input fields to define actions.

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.

Image 1

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.

Image 2

IBM script items can contain any Javascript code, so the developer has all the possibilities provided by the language to perform the operations he needs.

Image 3

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.

Image 4

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.

Scheduled tasks
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.

Image 5
Image 6

Conclusions
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:

Image 7

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.

Besides, IBM supports Javascript code and Java libraries, which provides absolute flexibility to do whatever you need. On the other hand, Pega limits the possibilities to the methods that it provides and bounds their use to those rigid, structured lists of actions. As a result, IBM looks much more powerful and versatile while Pega feels more restricted and unfriendly to use.

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

Benieuwd wat onze consultants voor jouw organisatie kunnen betekenen?