End user operator not subscribing to a UI notification channel

User Experience
, , , ,
1

Hi There,

I have used ‘On load’ action in a section to subscribe to a notification channel where I have configured “Refresh-CurrentHarness” as a call back action. I’m publishing the notification channel through a declare trigger when the assignee changes and the case is getting committed to data base. I see this publish-notifications method is working perfectly fine when it is in dev studio while it’s not when it comes to the end user. When I tried checking the logs by setting com.pega.pegarules.session.internal.serverpush to debug, I noticed that the subscription is not all happening from the enduser side. In dev studio, my operator is subscribing to the channel and hence when the trigger activity invokes the publish-notifications method, my operator (where the subscription is present) is going properly for the call back action.

Can anyone help me in solving the issue of subscription with the enduser? I tried restarting the environment as well, but it didn’t work.

Notification channel path.png
Notification channel path.png379×389 58 KB
Invoke notification channel.png
Invoke notification channel.png1062×356 20.8 KB

2

@Pavan_kalyan

  • I hope the use case is same with developer & end user operator. But main thumb rule is subscriber should be already present on the screen and then publisher or activity calling notification channel should be triggered next. If it happens reverse then notifications wont be received.

  • For activity rule in security tab if we have any privileges make sure those are present for end user. If not activity wont be called

  • On load of end user portal capture network logs to see the status of web socket . It should be 101 status, if it is not then the messages or notifications wont be send.

Hope this helps !

Thank you.

3

@Priyanka Boga

  • Both the use cases are same for developer and enduser, where the issue is only with the enduser.

  • There are no privileges defined for the activity and the publish-notifications is happening as expected from the enduser. The problem is that the other enduser operator that should subscribe prior to this publish-notifications is not subscibing as expected.

  • I’ve observed the websocket statuses recorded. All are at 101 status but still the subscription is not happening.

Please let me know if there’s anything that I should check to solve my issue?

4

@Pavan_kalyan

-Create a log category and add below logs in debug mode. Off the log category once done with capturing.

com.pega.platform.message
com.pega.pegarules.session.internal.serverpush.atmosphere.AtmospherePushEngine
com.pega.pegarules.session.internal.presence.PresenceLifeCycleEventManager
com.pega.pegarules.session.internal.mgmt.base.NodeRequestorMgt
org.atmosphere.util.SimpleBroadcaster
org.atmosphere.cpr.DefaultBroadcaster
com.pega.pegarules.session.internal.serverpush.AbstractPushEngine
com.pega.pegarules.session.internal.serverpush.atmosphere.AtmospherePegaHandler
com.pega.pegarules.management.internal.PushServerMonitorManagement
com.pega.pegarules.management.internal.NotificationMonitorManagement

  • On screen when subscriber is present enable browser developer tools and go to elements tab. Search for data-subscription-id and capture that value. If there are multiple subscribers on the screen check for other parameters on that element and if call back function matches capture that id

  • In logs search using this subscription id and verify the condition value is proper or not as expected. If the when condition property value is different then it wont trigger call back action

  • I hope the refresh harness call back dont hold the subscriber . If it holds move to different section outside the harness may be portal header.

Thank you.

5

@Priyanka Boga

Thanks for providing the loggers. However, I’m still not able to see a subscription related message getting logged after setting the loggers to debug and doing the action on the case that subscribes to the channel. If the subscription happens the call back will definitely happen as I’ve seen it working from dev studio operator.

Since the subscription itself didn’t happen, I believe I have to check something else. I tried restarting pyProcessNotification queue processor as well assuming it will be a reason to push the subscriptions. That didn’t work too.

6

@Pavan_kalyan - This require more debugging on the use case live. Please raise INC ticket to GCS for further investigation.

Thank you.

7

@Pavan_kalyan please provide the INC id here so we can help track progress on your issue.