Advertisements

Creating Runbooks in Azure and Calling Them from SharePoint Using Webhooks and Flow

AzureFlowSharePointAutomationRunbooks are a feature of Azure Automation that allow you to execute workflows from within Azure or remotely to automate processes.

To give an example, lets say you have a script that monitors an Azure service every 5 minutes to see if it is running or not. The script, will test and see the status of an Azure App Service. If it tests the site, and does not get the HTTP 200/OK message, then it triggers an alert, creates a ticket, and now someone has to go recycle the Azure App Service. If this can happen frequently, then it is something you would look to automate.

In comes the Azure Automation Runbook. You create a PowerShell script that is hosted in Azure (a Runbook), and when your script detects that the service is not responding, it makes a call out to a URL, and the URL runs the Runbook, which restarts the Azure App Service. The monitoring script then runs again, sees that the service is back up, and the appropriate steps are taken.

This might seem like a lot of extra work, but, if you are, say, connecting in through a VPN to manage an Azure environment, it can be quite time consuming just to restart a service.

However, we are not using that as our working example in this article. That was just to give you an idea of the kinds of things that can be done using Runbooks. In this article, we will be showing you how to create a Runbook, and call it from SharePoint, using Microsoft Flow. It will not be a real exciting example either, but, it will show you how to do all this, so you can do more on your own!

Prerequisites

This article assumes the following:

  • You have an Azure subscription. If you do not, you can get one here for free to play around
  • You have SharePoint Online

Creating an Azure Automation Account

Before we can create our Runbook, we need to create an Azure Automation Account. Login into the Azure Portal, click on New > Monitoring + Management > Automation

image

Configure the following settings for your Automation Account:

  • Name: What are you going to call it?
  • Subscription: Select the subscription to use
  • Resource Group: Either create a new one, or, use an existing.
  • Location: Which Azure region should this run in? I am using East US 2… since I’m in the East US.
  • Create Azure Run As account: This is not needed for our test, but, if you’re doing anything in Azure with your runbooks, you will want to configure this. For more information, visit: https://docs.microsoft.com/en-us/azure/automation/automation-offering-get-started#authentication-planning

image

Then press Create.

It’ll take a moment while this deploys…

image

Once done… access it either by the Automation Accounts blade on the left side, or, via the Notifications link Go to resource once its done deploying.

image

And you will be brought to the landing page for your Automation Account, AutomationTest

image

Creating an Azure Automation Runbook

Now that we have our Automation Account, we need to create our runbook. From within the Automation Account, click on Runbooks under Process Automation on the left hand side.

image

Then click Add a runbook at the top of the runbooks dashboard

image

Click on Quick Create / Create a new runbook

image

Fill in the details

  • Name: Check-Website
    Give your runbook a name
  • Type: PowerShell
    You can also choose Python 2, Graphical, PowerShell Workflow, and Graphical PowerShell Workflow
  • Description: Check the status of a website
    Enter in a description for the runbook

Then click on Create

image

And viola! Your runbook has been created!

image

It doesn’t do anything yet, so, we will need to add code. Click on Edit at the top of the dashboard.

Here is where we will type out, or paste in our PowerShell code for the runbook.

image

NOTE: Do not use Write-Host, there is no “host” per-say to write to. Instead, ensure all output is written using Write-Output

Let’s add the following code to test if Google is up and running…

Function OutputStatus($type,$status) {
    Write-Output "$type | $status";
}

Function Get-HTTPSStatus($url,$type) {
    $HTTPSStatus = Invoke-WebRequest $url -Method Get –UseBasicParsing
    if ($HTTPSStatus.StatusCode -eq "200") {
        return OutputStatus -type $type -status "Success"
    } else {
        return OutputStatus -type $type -status "Error"
    }
}

Get-HTTPSStatus "http://www.google.com" "Google Website"

image

Click on Save

image

Now lets test it…click on Test pane

image

Click on Start

image

You will see a message that it is being submitted

image

You can then see that it gets queued

image

And finally, we see the status and the output displayed

image

Pretty neat!

Now, lets say we want to add some parameters to our script, so we can specify the input… and not have it statically set as just “http://www.google.com” as the site, and “Google Website” as the description. Let’s update the code with some parameters…

To get back to your code, click on Edit PowerShell Runbook in the breadcrumb navigation at the top

image

Update our code with the parameters $Site and $Description, and then Save, and then go back on over to the Test pane

image

You can now see we have two fields for Site and Description under Parameters. Fill those out…

image

And run the script again…

image

Looks good! Now… we can do this all day from within Azure… but remember way back to the start of this article, I mentioned calling this from Microsoft Flow from within SharePoint? To do that… we’re going to need to make a change to our script, as well as create a webhook.

First, lets change our script. You know how we just added parameters? Well, when calling a webhook, we’re going to be making a REST call to a URL. We cannot pass in parameters like we just did to the script. That is good for running within Azure itself… in order to pass parameters to our runbook via a webhook… we need to change the parameters. We will be passing in an object called WebhookData (or whatever else you want to call it). Which will be the JSON data sent along with the REST call. So, let’s update our code to this:

image

We will then parse out the Site and Description name/value pairs from that and pass it into our script from the $WebhookData object.

The code for the above is here:

Param (
    [object]$WebhookData
)

Function OutputStatus($type,$status) {
    Write-Output "$type | $status";
}

function Get-HTTPStatus($url,$type) {
    $HTTPStatus = Invoke-WebRequest $url -Method Get –UseBasicParsing
    if ($HTTPStatus.StatusCode -eq "200") {
        return OutputStatus -type $type -status "Success"
    } else {
        return OutputStatus -type $type -status "Error"
    }
}

if ($WebhookData -ne $null) {
    Get-HTTPStatus $WebhookData.RequestHeader.Site $WebhookData.RequestHeader.Description
} else {
    Write-Error "No data received in webhook call."
}

We need to Publish it first before creating the webhook. Go back to the code view, and click on Publish

image

It will prompt you to confirm, click Yes, and it’ll be published.

image

Now that we’ve got that straightened out… let’s move on to creating our webhook.

Creating a Runbook Webhook

From our runbook Dashboard, click on Webhook at the top of the dashboard

image

Click on Webhook – Create a new webhook

image

Then give it a name, and an expiration date, and if it should be enabled or not…

image

Now… notice the big warning sign at the top of this screen…

image

See? Now… copy and paste that URL at the bottom, and save it somewhere. There is no way to get this URL once the webhook has been created.

image

Once you have done that, click OK

Then click on Parameters and run settings and then click OK there

image

Then click Create at the bottom of the form. Until you do that, you can still get the webhook URL…

Ok… now what? Let’s call it from PowerShell, since we need to do a POST to access it.

image

We can see in the Content section of the output, we are given a JobId of 4164eb1f-57ba-41c3-a7cb-2f556652e9ad

In our runbook, if we go to Jobs under Resources

image

We can see that a job successfully ran

image

Click on it, and we can see the status, and you will see the JobId matches what we got from the call from Invoke-WebRequest

image

You will see there were errors… because we didn’t actually send any data along with it. We just called it directly. But now that we have it… we can move on to SharePoint and Flow.

Creating a Flow to Call our Webhook from SharePoint

Now that we’ve gone through the meat an potatoes of this project… let’s look at linking at all together with SharePoint and Flow.

Log into your SharePoint Online tenant… and lets create a new list.

I’ve got a basic custom list called Flowtest

image

Now… once created, in the Modern interface… click on Flow > Create a flow

image

Click on See your flows at the bottom, because we’re going to create a brandy-new one…

image

Click on + Create from blank at the top of the page

image

Click on Search at the bottom of the next screen, and search for SharePoint created… we want to add a trigger for when a new item is created in our list.

image

Select SharePoint – When an item is created

Select your SharePoint Online site from the list, or, enter in the URL, then select the list… in this case, we’re using Flowtest

image

Then click + New step > Add an action

image

Click on HTTP under Connectors

image

Choose HTTP – HTTP

image

Then fill out the details…

  • Method: POST
  • Uri: The URL we copied when we created our webhook
  • Headers
    Site:
    http://www.google.com
    Description: Google’s Website (FROM SHAREPOINT!)

image

And then click on Save Flow

Also… don’t forget to give your flow a name Smile

image

You should now see your Flow

image

Now… open a new window, and go back to your list, and create a new item…

image

And if you check back on your flows…

image

You will see one succeeded!

Clicking on it will give you the breakdown of the flow run (which is one of the more awesome features of Flow… over IFTTT IMHO FWIW YK?)

image

Now… let’s go check Azure…

If we look at the jobs for our Runbook… we’ll see a new one in there…

image

Click on it, and then click on the output

image

image

It worked!

Now… let’s make this a bit more functional. Go back to your list settings in SharePoint

image

I’ve changed the Title field to URL, and added a field called Description as a single line of text.

image

Now, let’s go back to our Flow…

And edit the HTTP step

image

Edit the values for Site and Description, and then select the corresponding Site and Description values from the Dynamic Content list that pops up to the right. See what we’re doing here?

image

Let’s run our Flow… create a new list item, passing in a URL and Description…

image

and check the status…

image

It worked! It’s a day of miracles people! While this is not a really exciting example, it shows how to use Azure Runbooks and Webhooks, and how they can be accessed remotely to do a specific task.

What sort of cool things are you doing or have you done with Flow and Runbooks, if anything?

Resources and References

Advertisements

Options for Deploying Reusable Workflows in SharePoint 2010

With SharePoint 2010, we have two new workflow types we can create, a Reusable Workflow, and a Site Workflow. Today we’ll concentrate on reusable workflows. And if you’ve been living under a rock for the past few months, let me first explain…

In WSS v3, we could create “reusable” workflows in Visual Studio, and through some third party applications, however, in v3, lots of workflows were generated in SharePoint Designer. And a lot of times, people found out the hard way, that you couldn’t just copy and paste them, or suck them into Visual Studio to re-deploy elsewhere. Those workflows are list-based workflows, which are bound just to a single list, in a single site. You could re-create the workflow on other lists, but, that is time consuming… and not that efficient at all.

There were options however – you could copy the workflow files over to a new list, and edit the workflow files manually, to point to the GUID of the list you wanted to deploy it against, or, use some Visual Studio Voodoo, to write some code to accomplish the same thing. Again, not entirely efficient, and, not out of the box.

With SharePoint 2010 and SharePoint Designer 2010, we finally have some options, out of the box.

image

  1. List Workflow – This is the same list-based workflow you know and love from 2007.
  2. Reusable Workflow – This workflow is tied to a content type, hence why it can be reusable, and the focus of this here article today.
  3. Site Workflow – The site workflow is a different beast altogether, and is a topic for another day. These are, as they sound, bound to sites. Not content types or lists, but, to the site itself. Site workflows are not initiated from list-level actions – they need to either be manually called, or called through code. But I digress – we’ll save this topic for another day…

Now, on to the meat and potatoes of this post. The reusable workflow, and, options for deployment. First, lettuce (you should always have some greens with your meat and potatoes… just ask your mother, she’ll tell you the same thing…) create a simple workflow, that will send an email to a single email address when the workflow is run.

I already have a list called Clients on my site, so we’ll use that. Open SharePoint Designer 2010, and connect up to the site, and click on the Workflows navigation node on the left hand of the screen. When you do, you’ll see the Workflows tab in the ribbon as shown above.

image

 

Create a New Reusable Workflow in SharePoint Designer

Now, you may be able to see the future, and to test this, if you think I am going to say “Click on the Reusable Workflow option in the Workflows ribbon tab”, then you are clairvoyant. Congrats on that! So cool… anyways, click there, just as you knew I was going to say.

image

Go ahead and give it a name, such as Notify Client Engagement Manager, and a description, with whatever you please… then select a content type. Now, something I forgot to mention, is that I had already created a Client content type prior to this, so, you may want to go ahead and do that, in case that’s what you’d like to do, if you’re following along at home. Go ahead – this post will still be here when you get back… I’ll wait.

Ok, done? Now, select your Client content type (as shown below), and click OK. You also may note, that you can associate this reusable content type to ALL content types. While I have not peered beneath the sheets on that one yet (SharePoint 2010 has not even officially launched as of the penning of this article…), I am guessing that it uses the System 0x or Item 0x1 content type to associate to, similar as I did in a previous article on binding custom actions to all list types.

image

Anyhow, back on track again! So, now that we have done. We get our next screen. Do as the man says, and start typing away…

image

A phrase like “email” is helpful – it’ll find the action you are looking for

image

Then press enter, and click on these users in the link that appears

image

And then create your email definition, something like as follows, and click OK.

image

And then click Save back up in the ribbon to save any changes, and when you’re ready, click Publish, that’ll, as you may have thought, publish the workflow.

image

Your workflow has now been created. Now, you’ll need to make sure your list is configured to use it, if, indeed, you’d like to use it. As it works just like the other reusable workflows in SharePoint (Approval, Three-State, etc.), it needs to be configured.

So, check your list, and be sure that it is managing content types,

image

And then, go into Workflow Settings on the list settings page

image

Select the content type…

image

And then configure the workflow…

image

And we’ll see that it is assigned to the content type now

image

Let’s test it, just to make sure… go to New Item > Client from the list page

image

And your workflow should fire. Great! Ok! Now what?

Now Bob, in HR, wants to do the same thing – what can we do? Good thing we created a reusable workflow! We have options, which is the real basis for this article.

Save As Template in SharePoint Designer

In SharePoint Designer 2010, we have the option now to save our Reusable Workflow as a Template. To do so, on the Ribbon UI when you are working with your workflow, select Save as Template.

image

This will automagically save the WSP file of the workflow out to the “Site Assets” library, and it will tell you it did so, as shown below.

image

If you click on the Site Assets link on the left-hand navigation in SharePoint Designer, you will see there should be a new WSP file, corresponding with the name of the workflow you had saved as a template.

image

Next, let’s download the file. Just click on it to save it.

image

 

Packaging and Deploying the Reusable Workflow in Visual Studio 2010

Now, here comes the good stuff. Fire up Visual Studio 2010, and go to File > New > Project from the menu.

image

If you have not seen it before in Visual Studio – under Visual C# > SharePoint > 2010, there is a new project template called Import Reusable Workflow. Select that, give your project a name, etc., and click OK.

image

You will then see the SharePoint Customization Wizard window pop up, select the URL you would like to use for deployment/debugging, and you cannot deploy workflows as sandboxed solutions, so Deploy as a farm solution is your only option. Hit Next >

image 

The next window in the SharePoint Customization Wizard is to specify the project source. Select the WSP package containing your workflow which you had exported earlier.

image

Then, select the items to import – you should only have your workflow listed.

image

Click Finish, and Visual Studio will import your workflow from your solution.

image

And when it’s done, and if it completed successfully, it will tell you so.

image

Now, look at the solution in the Solution Explorer on the right. We are not going to make any changes at the moment, but, if you wanted to, add more code, change the forms, etc., you could do that all here.

image

Right click on the project and select Package

image

Once that is complete, if you look in the project folder (created when you selected the project in Visual Studio), you should see your WSP file for your project.

image

Now, you can deploy this out to the debugging/deployment site you specified in the SharePoint Configuration Wizard portion of the import of the workflow, by right-clicking on the project, and selecting Deploy.

image

Checking the Output window will show you the steps taken for deployment.

image

Now how do you check to make sure it was deployed? Well, in Visual Studio, double-click on Feature1.feature in the solution explorer, and in the Title field of the designer view for the feature, you will see your workflow there with it’s defaulted name of Converted Workflows.

image

In your site collection features, you should see a feature by the same name…

image

Activate it, if necessary, and now your cooking with gas, or really, you can use any other sort of medium for generating intense heat that you desire, I am not going to “hold your feet to the fire” on this. Hah. Sometimes – I just crack myself up.

 

Publishing a Reusable Workflow Globally through SharePoint Designer

The first word in the title of this article is “Options”. So, here is another option – using SharePoint Designer to publish the workflow globally. Now, that sounds bigger than it is, however, you also may note, if you are an astronomy buff, that it did not say “Publish Solarsytemmy”, or “Publish Galaxyally”, or even “Publish Universally”. Maybe because I just made some of those words up? Or, maybe, because you are working within the context of a site collection here – a “world” in SharePoint. I really have no idea – I don’t know who came up with the copy for that specific button, or, rather, any buttons anywhere in SharePoint Designer.

So, start by creating a new workflow, or, you can just use the one we did earlier if you’d like.

image

Give it a step, or else its not much of a workflow…

image

Ok, lets save the workflow…

image

and you’ll see in the Ribbon, that mysterious button Publish Globally. Go ahead – click it.

image

You will then be prompted by SharePoint Designer – telling you the intentions and ramifications, with not even a one word salutation, that publishing this workflow globally will publish it to all sites within the site collection. COOL! Do it!

image

Now, to see this in action, go back into your site, and create a new site.

image

Let’s go with a team site – simple, easy, and comes pre-populated with some lists.

image

Now, lets go into our document library, and check out the workflow settings to see if it is there…

image

Oh, wait – no workflows associated with this list. Let’s add one, to see if we can add ours…

image

And there it is!

image

 

Fun stuff, huh? Yeah, I know many of you who have already started toying with 2010 may have already seen, or even done, some or all of this. The truth of the matter is, I’ve had this sitting in my drafts folder since May 10th, and as you can also see, I am finally getting around to posting it.

Hope this helps – and if not, leave me a comment on where I can provide any clarification 🙂

 

Parachute deployment image borrowed from: http://www.cirruspilots.org/Content/CAPSHistory.aspx

%d bloggers like this: