Microsoft 365 Community Community Demos, 10 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Remote Event Receiver Manager solution in SPFx for managing list events

Description

In this 11-minute developer-focused demo, Dan Toft shares a very simple web part that lets users view, add and delete remote event receivers in lists. Review what is a Remote Event Receiver, Strengths and Weaknesses, and when/not to consider using Power Automate to accomplish task. Use the sample to quickly identify Event Receivers in lists across a tenant without having to connect to PowerShell or go to a REST API. This PnP Community demo is taken from the General Microsoft 365 Development Special Interest Group (SIG) - Bi-weekly sync call recorded on June 10, 2021.

Demo Presenter: Dan Toft (Evobis ApS) | @tanddant

Supporting documents:
• Samples - Remote Event Receiver Manager | https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-remote-event-receiver-manager
• Documentation - Use remote event receivers in SharePoint | https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/use-remote-event-receivers-in-sharepoint

Learn more:
• Learn more about the Microsoft 365 Patterns and Practices community at: http://aka.ms/m365pnp
• Visit the Microsoft 365 Patterns and Practices community YouTube channel: https://aka.ms/m365pnp-videos

A

My name is dan: I'm a microsoft, 365 and sharepoint consultant at the evo biz we're a small company in denmark specializing in helping businesses, implement microsoft, 365 and sharepoint.

A

Just a few quick notes on why I made this demo, there's been a change in the pnp powershell, the latest version, where we're now using app, only authentication and when you apply a remote event, receiver using app only content authentication.

A

We experienced that it doesn't actually execute the remote event receiver. It turns out that you need a app-only principle to do that, and sometimes that's just not convenient when you just need to really quickly apply a remote event receiver. So I figured well if we're using user authentication, it actually works. So can we do this through rest? um I couldn't find any documentation on whether the sp rest endpoint supported it.

A

So I figured might as well just try and I went ahead and tried and it worked um so that's the use case for this demo or sample. Then I'm just going to be talking about what is a remote end receiver and when to use one and when to use power automate.

A

So if we just pull in here, the this is the demo of the web part. So it's really simple all it does. Is it lists the list you have on your site?

A

So you can see we have this one here called you can't create items here, which is just just a list um and I've added a remote event. Receiver called pnp sample block, create which really all it does is it's a synchronous, remote event, receiver. That just tells you you can't create the item here.

A

So what we will see is we get a custom error message, so it says pnp is awesome and so are remote event receivers. These messages can actually be customized because remote event receivers, it's just a soap protocol, so you can return really any message you want um and I'll get to. Why? That's really awesome in just a minute.

A

um We can also do them asynchronous so that you can add something and then remotely there's a server doing some work and it can fill out a field. So this one just clones the title into title cloned, but you could potentially be doing other things there.

A

What the sample allows you to do is just get a quick overview of these. uh You can see it's there. You can delete it or you can add a new one, so so it's really just to quickly manage it and so that you can get an overview of what's going on, because there's no ui way to do this, so you'd either have to connect with powershell or go through the rest api.

A

um Going back to the presentation, I'm going to be talking a little bit about what is a remote event, receiver, so essentially what it is in this case, the the whole demo is focused on remote event, receivers on lists. They do exist in other parts of the platform as well they're a way to listen for events or get a trigger when something happens.

A

So, for instance, when an item is created in a sharepoint list, you can trigger a azure function or really whatever you can. You can host it in on any web server.

A

You can then use that to write data back to the to the list, so you could do some kind of advanced, calculated fields or you could potentially do like we just saw before you can do verification, uh so you can actually use, for instance, two fields and generate a unique primary key across two fields to say you can't have these two fields be identical with another list item you can also because we're in a web server and we have code- you can do really whatever you want, so you could send the data to an external service, say you're, doing your own audit log on some other system, or you could go ahead and get data from another service and write that back to the list in case you're doing integrations to perhaps a time tracking system or something.

A

So that's all really cool, but a lot of this can actually be done using power automate. So when would you want to use?

A

When would you want to use that instead, because I mean obviously power automate is always preferred and using power automate. We can easily do this thing where something changes: okay, the power automate script or power automate flow. I think they're called does something um and writes that back to the list, but one of the use cases where I at least often feel that power automate really is not.

A

That awesome is that you have the six identical lists or 20, because you're using provisioning to to roll out these lists, you're, suddenly very limited in what you can do in power automate. um I've recently seen some really cool blog posts of people. Actually writing power, automate scripts that can run across flows that can run across a large amount of list. But you always end up using a lot of. I don't want to say hex, but you end up customizing the power automate to a point where it's no longer a our user tool.

A

It's almost a developer tool um and in that, in that case, I generally would prefer actually using a remote event. Receiver again in this case, I'm just using an azure function. Logo, because it's something hosted in the cloud- and you can do this whole thing where, instead of having one list, you can actually have six or seven lists or 20. If you want so so you're suddenly able to you do the same thing, but across a lot of lists.

A

So so what are some of the the pros and cons of this um I mean a huge pro: is the reusability? You can actually go ahead and use it across many lists. Also, this whole synchronous an asynchronous thing, so so using power automate, we can't actually block a user from creating a list item. We could potentially delete it afterwards if it's not an allowed operation, but this whole having custom error messages um to tell the the user.

A

What you're entering currently is invalid and not allowed and just stopping them from creating that that's a really powerful tool. It's something that's been in the platform for, as far as I know, a very long time, but just you don't really see it used all that often anymore. um I didn't even know it supported modern ui ansel. I tested it out for this demo, but also the whole aspect of them actually running.

A

I say instantly but say you're running the asynchronous one. It happens really fast. It's not not the five minute trigger you have on a flow, and I believe web hooks also have a five minute trigger ish.

A

So this really snappy performance you can actually get also if we get I put in, quotes unlimited power because we're running back encode we're able to use things like see somewhere the pnp framework. So so we can really do two very powerful things. We can do third-party integrations that don't necessarily work that well with flow, and we don't need a premium license to make an http request to some platform which might even not even support rest, and you might have to do other things.

A

So some of the downsides are it uses code, which means we're no longer in the power user suite of things where power automate, you can teach a user how to to build their own and how to maintain it, so that that's kind of a problem that you're really stuck with code. That needs to be compiled and hosted somewhere and that's the other thing you need to host this somewhere and you can host it in asia and that works, but sometimes when you're working with a client, it can be kind of a thing where you're like.

A

Oh, I need an azure subscription, it's not going to cost that much, but we need to host it there and the client will will be like, but I don't want to pay us an extra subscription. I already have power automated. Why can't we use that?

A

So that's sometime a bit bit of a hassle, then they're they're, harder to to see put in quotes again. So so one of the things I've had sometimes is, if you're helping a new client who already has an existing setup that some other developers worked on, there might actually be remote event receivers there, but you don't really have an overview overview of what's going on.

A

This is also where the sample can be used, because you can actually click in you can see which remote avenues you work on which lists, but that also leads into the black box aspect of it. So we have some code running somewhere in the cloud, but we don't know what it does. uh There's no easy way to see the code. You can't actually see it because it can be hosted on any environment.

A

um So we don't know what what does this do? We can I mean we can create a list item. We can see what happens, but does it do other things? That's really hard to tell where, as with the flow, you can open it up, you can look at it.

A

Another thing that we get is the retry logic can handle logging from power automate where we get this really nice overview of. When has this pause mid run? Did it fail? Did it go? Well, we don't really get that with the remote event, receivers, they're kind of fire and forget.

A

So if it fails it fails, you can obviously use application insights to have a look at if your job failed or not, and so so another thing you could do is using cues and you can actually, whenever the remote of energy has triggers, you can write your queue instead of just executing your code and saying, okay, I'm done so there's definitely some pros and cons for both um and generally. I think you should try to prefer power automate because it is more maintainable. It is more of a.

A

I don't know what you say so supported uh feature set if it feels more native to the platform, and you don't need to do custom code, which I mean we're all some of us are developers we love coding, but we also need to to try and use the tools that we get from the from the microsoft team and that's pretty much it for me. Thank you.

B

Cool really really good uh summary done, and there was a question related on deprecation plans on the remote advanced receivers and there's no explicit ones as such. It is an older technology which we introduced many many many years ago before craft even existed, but it does work. um The really the challenge there is that, like then, no doubt is, is the re, the retry logic.

B

So if there would be a native network disconnectivity between sharepoint, online and azure or whatever, then there would not be a failure, handling or an exception handling on that, but really cool summary. Thank you, dan on.

A