Offline Tasks with WebJobs

Part 5: Offline Tasks with WebJobs

Update API to enqueue notifications

1. Open the TodosController in the API project.

2. Remove the comments from the AddChangeNotification helper method.

private void AddChangeNotification()
{
  var queue = new EventQueue();
  queue.AddNotification();
}

HACK: Local Storage Workaround

The current version of the WebJobs SDK does not support the Local Storage Emulator, the tool that simulates Azure storage on local development environments. The WebJobs SDK is using features that are not yet available in the local emulator. As a workaround, a Storage Account needs to be created within Azure, and local machines configured to use the remote location.

This requirement should go away with a future release of the storage emulator. This is a known issue and hopefully will be addressed soon.

1. Create a storage Account in the Azure Management Portal for local development use.

1. Click Manage Access Keys.

1. Note the Storage Account Name and copy the Primary Access Key to the clipboard using the Copy icon. You will use these values to build your connection string.

1. Update connection strings from Emulator connection string to live connection string.

1. Update the web.config in the API project

<add name="storage"
     connectionString="DefaultEndpointsProtocol=https; AccountName=[accountName]; AccountKey=[accessKey]"/>
```

1. Update the app.config in the Processor project.

<add name="AzureJobsRuntime"
     connectionString="DefaultEndpointsProtocol=https; AccountName=[accountname]; AccountKey=[accesskey]"/>
<add name="AzureJobsData"
     connectionString="DefaultEndpointsProtocol=https; AccountName=[accountname]; AccountKey=[accesskey]"/>
```

We recommend that this Storage account be different than the Production storage account. The connection strings will be overridden in the Portal in a later step much like they were with the database connection string earlier in this workshop.

Important:
Be mindful of your Git commits and code pushes to GitHub, as committing these changes may expose sensitive information through your public GitHub repository.

Testing locally

1. Set API as the startup project.

2. Start without debugging using ctrl-F5.

3. Set Processor as the startup project.

4. Start debugging with F5.

You may only attach the debugger in Visual Studio to a single process. In this case we are choosing to attach to the Processor because it is the project we have not run yet. You could also start up the Processor from the command line as it is simply a console application. The choice is yours.

1. Start up the gulp server proxied to IIS Express.

gulp run --proxy --proxyPort 31008

1. Validate that new task items are being created and, using the console window, that jobs being picked up from the queue.

2. Shut down the proxy and stop debugging in Visual Studio. You may also want to kill off the instance of IIS Express that was running the API.

Including WebJob in the deployment script

1. Set the current working directory to the repository root.

2. Create a scaffolding script for the WebJobs project.

azure site deploymentscript --dotNetConsole .\src\processor\Processor.csproj -s .\src\TodoList.sln -o .\webjobscript

1. Open webjobscript\deploy.cmd.

2. Inspect the Deployment section.

NuGet Restore
The NuGet Restore command is the same as what we have already included in our deploy.cmd. Because Package restore is done at the solution level, automatically restoring packages for all projects, we do not need to run this a second time.

MSBuild Differences
In addition to building the Processor project instead of our existing API project, the output path is different than our current MSBuild process. This one builds to a sub-folder, \app_data\jobs\continuous\deployedJob. This indicates that this MSBuild Task needs to occur after our existing API compile.

WEB_JOB_DEPLOY_CMD
At first glance, the presence of a new property, WEB_JOB_DEPLOY_CMD, indicates that this may be something required for the primary deploy.cmd. However, this commands purpose is to copy an HTML file into the website when a WebJob is the only item being deployed. The deployed file is similar to the presence of hostingstart.html when the Azure Website was first created, except that this HTML page will notify the visitor that the WebSite is running a WebJob. Because we have other items being deployed, this command is not needed.

KuduSync This KuduSync is identical to the final KuduSync for our current deployment script, synchronizing %DEPLOYMENT_TEMP% to %DEPLOYMENT_TARGET%. Including it in our primary script would be redundant.

The only step we need to copy is the MSBuild step.

Shiny. There is not a lot to do this time.

1. Copy the WebJob's MSBuild step to the clipboard (lines 76-78).

:: 2. Build to the temporary path
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\src\processor\Processor.csproj" /nologo /verbosity:m /t:Build /p:Configuration=Release;OutputPath="%DEPLOYMENT_TEMP%\app_data\jobs\continuous\deployedJob" /p:SolutionDir="%DEPLOYMENT_SOURCE%\src\\" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error

1. Open the primary deploy.cmd in the repository root.

2. Paste this MSBuild step after our API MSBuild step, and before our select node version step.

3. Change the comments to echo and renumber for diagnostics.

If you like, feel free to use echo 2a. rather than renumbering the entire script.

  call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\src\api\API.csproj" /nologo /verbosity:m /t:Build /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\src\\" %SCM_BUILD_ARGS%
)

IF !ERRORLEVEL! NEQ 0 goto error

echo 2a. Build WebJob to the temporary path
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\src\processor\Processor.csproj" /nologo /verbosity:m /t:Build /p:Configuration=Release;OutputPath="%DEPLOYMENT_TEMP%\app_data\jobs\continuous\deployedJob" /p:SolutionDir="%DEPLOYMENT_SOURCE%\src\\" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error

echo Handling node.js deployment.

1. Perform a local deployment.

deploy.cmd

There should now be a wwwroot\app_data folder under your artifact directory. That is the new WebJob.

1. Commit your changes.

Creating a Production Storage Account

1. Create a Storage Account in the Azure Management Portal for production use.

Be sure to create your Storage Account in the same location / Data Center as your Website and SQL Azure Database.

For this Workshop, a locally redundant account is recommended.

1. Go to Manage Access Keys. Note the Storage Account Name and copy the Primary Access Key to the clipboard using the Copy icon. Use these values to build your connection string.

DefaultEndpointsProtocol=https; AccountName=[accountName]; AccountKey=[accessKey]

1. Go to your Azure Website within the Management Portal.

2. Navigate to the CONFIGURE tab.

3. Add a connection string entries for AzureJobsRuntime, AzureJobsData, and storage, setting each to the connection string created above. Save.

4. Push to Azure to deploy the site with the WebJob.

 git push azure master

1. Visit the WebJobs tab under your Website on the portal. Verify that it is there and executing.

2. Sit back and think about how cool this really is.