Adding messages on pulse through activity/utility is not working as expected.
In our application cases are created through an activity.
We have a requirement to add two messages to pulse after case creation. This is configured in two occurrences. One message is added as part of an activity.
The other message is added as part of a flow.
When trying to validate this scenario, it is observed that only one message was added to pulse.
To debug the issue, while tracing the case creation it is observed that whenever the tracer running both the messages are posted on to pulse. When it is not being traced, only one message is being posted.
Ideally, it should be functional irrespective of whether the tracer is on or not because there are no code changes. Please look into these symptoms and if this is a problem with pega engine code, please help us with hotfix on priority.
Thanks in advance
Rahul Reddy Edara
***Edited by Moderator: Pallavi to update platform capability tags***
It still doesn't work even when, suggested pxCreateSystemPost and pxPostMessage are used instead of pzAddFeedPost. It is only working with tracer. When not traced, only one message is being posted on to pulse.
Can you please let us know why that is functioning properly when it is being traced with a tracer and not functioning otherwise.
Like you said if there were configuration issues, I assume tracing it shouldn’t make it functional.
I'd start by suggesting you use other activities than pzAddFeedPost since that was is marked internal, so there's no guarantee that if you can figure out how to get it to work that it won't change out from under you. Out of curiosity, if you change the activity to use your current operator, instead of system do you see the post without tracer? What about if you focus on pyTopCasePage? I know occasionally, tracer will change the behavior if a page is referenced but not loaded into memory, since tracer expands everything to capture the clipboard data. Likewise, if there's a deferred load of a data page, or something, and you aren't waiting, the slow down added by the work tracer does could allow that process to finish before it's needed, where running without it may get a different outcome for any race condition.
Also, looking at they different methods mentioned here ultimately they all end up down in pxPostMessage, so it might be helpful to do a private checkout of that activity and add logging to understand the path you go down when you don't have tracer running/to take a look at the data on the clipboard for various steps. It looks like pzSavePostMessage does a bunch of deferred saves with a commit that isn't always called. I'd be curious to know what path you go down there. Do you end up in the commit step? The roll back step?
Unfortunately, since tracer changes the behavior, I think you're going to need go down a path of instrumenting some form of diagnostics.