So why am I answering ? Because I know how I would find out if I needed to know. What I would do is trace (with prpc tracer) what happens when a user does it interactively, and I would design my back-end to use some of the same rules. /Eric
NOTE: This example is for Pega72 : which has significantly improved the Pega Pulse Functionality (for the Developer and the End-User).
Just for completeness: here's a working example (it's quite straightforward actually) of how to post a Pulse Message in the context of a CASE.
You just need the 'pzinskey' of the Case you want to post to.
This can be generated by appending the Work Class + space + ID. (I'm not sure there are any caveats to that 'formula': to find out for sure open the 'pyWorkPage' for the CASE/Work Item you want to post to and look up the pzinskey).
So for example the CASE with the ID of 'T-2' in my Work Class of "GCS-SCRATCH-WORK" the pzinksey is:
So you can the OOTB (baseclass) Activity 'pxCreatePost' like this:
I have just defined two PARAMs on my 'wrapper' activity to pass in the message and pzinskey.
Note:When testing from the Designer Studio : I found it necessary to introduce an explicit COMMIT: this is one of the few times where you find need to do this.
Normally: you should avoid every calling COMMIT explicitly - and allow PRPC to issue COMMITs automatically.
So here's an example of it working:
And then back in a User Portal (after hitting the Pulse 'Refresh' icon), you can see the post:
See the HELP tab for the Activity "pxCreatePost" for more variations:
Context param Values that need to be passed for different contexts:
Posting to a case: pzInsKey of the case
Posting to a user: Useridentifer of the user to whom it is posted
Posting to a rule: pzInsKey of the rule
Replying to a post: Parent post id.
There are other Pulse-Related Activities available also.