One of the classic questions related on the SharePoint app parts is their capability to connect between each other. This has been classic scenario with web parts since the dawn of the SharePoint, so question is pretty understandable. Since app parts are essentially IFrames in steroids, they don’t natively support similar connectivity models as the classic web parts, but we can solve the requirement using alternative approach.
We have basically two different options for the connectivity with the app parts:
- Client side route
- Server side route
High level architecture for server side model
- Actual app part instances on the pages with the operations to communicate to server side code
- SignalR Hub proxy, which works as the message broaker between client side code and server side code
- Actual hub for routing messages is in the provider hosted app server side code. Each app part registeres to the hub and after that you can do real time communications between them
Server side connectivity with App parts
Following video demonstrates the key areas of the code and how the server side communication works cross app parts.
Actual implementation for SP app
SignalR code part was directly borrowed from the SignalR getting started guidance, which explains how to setup things and how the code actually works. All I did was take the code and created two app parts, which will talk between each other. To be precise, each web part instance could actually also talk between other instances, but this is up to the design.
Here’s how the app parts are shown on the page when we have two web parts, which are communicating between each other.
Here’s the server side implementations for those functions in the Hub implementation. This hub is as simple as it gets. Name and message information sent from client side is simply broadcasted to all connected clients without any filtering or modifications. You could just as well filter or route the messages only to specific clients, which in this case would be then different app parts.
Since communication happens on server side, you can actually make this work cross processes, browsers, computers or end users. This is also important thing to remember during the implementation. Provided example actually shows all the messages for all the browsers which are accessing the page at the same time. This opens up pretty interesting other opportunities, but if you want to use SignalR just for isolated session based communications, you’ll need to filter the traffic between the app parts based on the session. This could be done in the server side hub by using the information we get from the call.
Here’s a picture of a situation where we have two different pages in the site, which are having two different web parts accessed by two separate browser processes. If we want, we can make the communication to work in this kind of scenario as well, but then we are talking slightly different pattern or objective than just having connected app parts.
Few useful links and resources related on this blog post.