Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Issue with subscribing to a single node via server-server API

Avatar

Level 3

Hi there,

I'm using your server<-->server API to subscribe to a collection node.  I only want updates for a particular node, so I'm including that in the subscribeCollection call.  However, I'm unexpectedly receiving updates for all the other nodes in the collection node as well.

My call looks like this (in Ruby):

am.subscribeCollection('room', 'UserManager', 'UserList')

Within the LCCS server-server code, this translates to a URL that includes something like the following in the query string:

...&collection=UserManager&node=UserList...

My questions are:

1) Just to double check, is 'node' the correct parameter on the query string? (just wanted to make sure it's not something like 'nodeNames' instead since that's what's used in the ActionScript API).

2) Is there anything else I need to do to receive only UserList updates and not receive the many updates for all the other nodes within the UserManager?

Thanks.  Regards,

-Trace

1 Accepted Solution

Avatar

Correct answer by
Employee

Subscribing to a single node is currently not implemented in the back. Some of the language exposes it in the front end, but the value is ignored.

I suggest you extend your "receiver" class to ignore values for nodes you don't care.

View solution in original post

7 Replies

Avatar

Correct answer by
Employee

Subscribing to a single node is currently not implemented in the back. Some of the language exposes it in the front end, but the value is ignored.

I suggest you extend your "receiver" class to ignore values for nodes you don't care.

Avatar

Level 3

Thanks - can have the receiver take no action when those other items are received. 

There's still a fair bit of overhead, however - we'll still be receiving 10x the data we need and the every node is changing all at the exact same time for every single user due to our workflow, so the very large number of ignored http requests could back up our servers.  Is this something that you can add to your feature list going forward?

Avatar

Employee

Can you give us a concrete example of this use case ?

You mentioned UserManager before, but in UserManager only UserList will get updated if, for example, a user enters or exits the room.

Avatar

Level 3

The use case is, we want to execute some server-side code when the user leaves a room.  The way that custom fields are implemented in LCCS, they're all nodes on UserManager that are peers to UserList.  When we get the retractions on the users (which happen all at once when the session ends for us, and there could be a large number of users), we not only get the retraction for the UserList but also for each of the custom fields.  We can get so many exactly simultaneous LCCS notification requests that some of them may be missed even with a lot of available servers.  Being able to listen to just the 1 UserList retraction instead of 10 custom field retractions would be a big deal for us - we'd have a tenth the simulataneous traffic (and might even need 10 times fewer available servers for peak load).

Thanks again,

-Trace

Avatar

Former Community Member

Hi there,

Unfortunately, subscribing at a node level isn't supported because it will

take us quite a bit of work to get done. Thanks for thoughtfully presenting

your use-case to us - this does help us with prioritization. We're adding it

to the backlog, and if we hear more requests we'll bump up its priority, but

I'll be honest that we'll likely not get to this for a few months.

One way you could work around this issue is to implement your own version

of either custom fields or a user tracker. I'll walk you through some easy

steps to build a custom tracker.

1. In the Room Console, create a new CollectionNode in your room. Name it

"customUserTracker".

2. Create a new Node in that collection named : "trackingNode".

3. Configure the node :

a) userDependentItems = true; // all items will auto-retract as the

publisher leaves

b) accessModel = 100; // will keep all publishes private, just your

server will hear them

c) publishModel = 10; // everyone can publish

Next, you'll need a bit of client code so that when a user joins, they

publish an "I'm here" message. Only your server will hear this because the

accessModel is set to 100 (OWNER, which your server is).

protected var customUserTracker:CollectionNode = new CollectionNode();

// run this when users enter the room

protected function someInitFunction():void

{

customUserTracker.sharedID = "customUserTracker";

customUserTracker.subscribe();

customUserTracker.addEventListener(

CollectionNodeEvent.SYNCHRONIZATION_CHANGE, onSyncChange);

}

protected function onSyncChange(p_evt:Event):void

{

// notify the server of arrival

if (customUserTracker.isSynchronized) {

// send an item to our node, use myUserID for the itemID.

var item:MessageItem = new MessageItem("trackingNode","",

ConnectSession.primarySession.userManager.myUserID);

customUserTracker.publishItem(item);

}

}

.. And that's it! Hook up your server to listen to "customUserTracker", and

you'll receive messages whenever a user joins. Because userDependentItems

auto-retract when the publisher exits, you'll get the retractions on exit as

well, without all the custom user field overhead.

hope that helps,

nigel

Avatar

Level 3

Thanks Nigel - fantastic stuff!  This will do the trick to monitor when users enter and leave.

We likely will also need to listen to a select few individual custom user field changes via the server, so if you are able to change it at some point so we can subscribe only to specific nodes, that would be great.

Kind regards,

-Trace

Avatar

Level 2

Hi,

We're adding our vote on this feature, right now we are receiving lots of undesired notifications from UserManager; would be really nice to subscribe to single nodes.

Thanks!

Matetnic