Setting up a GeRes2 Development Environment for local debugging

Setting up a development and production environment is very similar. We start with the easier one which is setting up GeRes2 for development on your local Machine. Please check our requirements-page for details on pre-requisites you need to get started for
development.

Some of the steps described above are described at a greater level of detail in separate wiki-pages. These are listed at the end of this article.

Create a Service Bus Namespace in the Microsoft Azure Management Portal.
Since for local debugging we can use the storage emulator shipping with the Microsoft Azure SDK for storage services you don’t need to create storage accounts just for local development/debugging. Nevertheless, you need to create a Service Bus Namespace
in the Azure Management Portal.

Note: the SDK library versions we used for GeRes2 development currently do not work with Service Bus 1.1. for Windows Server. Therefore running Service Bus in the public Cloud Microsoft Azure is also required for local debugging.

We will investigate with future releases to update GeRes2 so that it is also compatible with the Windows Azure Pack for Windows Server and thus Service Bus for Windows Server what would enable GeRes2 to run in private clouds, as well.

Configure Microsoft Azure Active Directory in the Azure Management Portal.
GeRes2 leverages Azure Active Directory to prevent unauthorized callers from making use of the GeRes2 WebAPIs. It makes use of the most simple way of authentication and authorization through service credentials, by default. That means you need to perform the
steps below.Note:further details for those including screenshots can be found in the wiki-page “Configuring Azure Active Directory for GeRes2”.

Create am Azure AD if you don’t have one, yet. Since every Azure subscription gets one directory, by default, you can make use of this one if appropriate for you instead of creating a new one.

Register the GeRes2 JobHub as an application of type WebAPI in your Azure Active Directory.

Take a note of the “APP ID URI” setting you have selected as you need to update the GeRes2 configuration based on it later in the process.

Register a service-application that consumes the GeRes2 JobHub. Note that when writing this documentation, you need to register service applications as “Web API” in Azure AD, as well. This UI might be updated in the future to reflect a better
wording for service applications, in general, in the future.

After created, navigate to the Configuration-page of this newly created service application.

Take a note of the ClientID since you need it later for configuring GeRes2 clients such as the included sample console.

Generate a new secret key and take immediate note of it since you need it later for configuring GeRes2 clients such as the included sample console.

Finally add a permission to Azure AD that enables the service-application created in step 3 above to call the web API in step 2 above. At the time of writing this documentation, this was only possible through
http://graphexplorer.cloudapp.net or by using the graph API of Azure Active Directory, directly.

Open Visual Studio as an administrator and then open the solution
GeRes2.sln in Visual Studio.

Before building, right-click the top-level solution in the Visual Studio solution explorer and select “Manage NuGet Packages for Solution”.

In the NuGet package manager dialog, select “Restore” at the very top of the window. This will restore all NuGet packages required for successfully compiling GeRes2. Do this before you do your first build since we use portable libraries that
are partially dependent on build-tasks downloaded with those NuGet packages. If you don’t do this upfront, your first build will fail and you’ll need to do a second build that will then succeed.

After you’ve downloaded the NuGet-packages you can completely re-build the solution – it should immediately succeed with those actions being taken assuming you have all pre-requisites installed on you machine

Update the Service Bus connection strings.
To get a working version of GeRes2 you now need to update the Azure service configuration file in the
Geres2_Cloud Microsoft Azure deployment project. Open the file
ServiceConfiguration.Local.cscfg in the project
GeRes2_Cloud and update the following configuration settings with the ServiceBus connection string copied from the Azure management portal.

The configuration setting you need to update is called “Geres.Messaging.ServiceBusConnectionString”.

You need to update this specific setting to match your Service Bus connection string copied from the management portal for for all three roles, Geres.Azure.PaaS.JobProcessor, Geres.Azure.PaaS.JobHub and Geres.Azure.PaaS.AutoScaler.

Update the configuration settings related to Azure Active Directory in the GeRes2 backend.
Open the file ServiceConfiguration.Local.cscfg in the project
GeRes2_Cloud and update the following configuration settings depending on the information you’ve written down from step 2 above:

Geres.Security.AzureAdTenant = <yourazureadname>.onmicrosoft.com

Geres.Security.AzureAdAudienceUri = <your APP ID URI> you have configured as part of step 2.2 above.

(optional) Deploy the sample jobs to test your configuration.
GeRes2 ships with a set of sample jobs which you can deploy to get started quickly and test your configuration. In the case of local debugging, you need to perform the following steps below to deploy the sample jobs.

Re-build the complete solution.

Navigate to the directory in your GeRes2 local git repository: .\geres2\jobs\SampleTenant\GeresJobSamples

Create a ZIP archive with the contents of this folder (directly in the root of the ZIP) called
geresjobsamples.zip.

Upload that folder “SampleTenant” with the ZIP-package in the
jobprocessorfiles container so that the resulting BLOB-name of the geresjobsamples.zip file relative to the root of the storage emulator blob storage service URL is
/jobprocessorfiles/SampleTenant/geresjobsamples.zip.

Note: the names are case-sensitive, especially “SampleTenant” in the URL above.

Update the setting “WindowsAzureAdGeresWebApiId” with the APP ID URI as configured and written down in step 2.2 earlier.

Update the setting “ClientId” with the ClientID as taken note from in step 2.3.2 earlier.

Update the setting “ClientSecret” with the secret key as created and written down in step 2.3.3 earlier.

Set Geres2_Cloud as startup project and run the solution in Visual Studio.

In the running instance of Visual Studio, right-click the project GeresJobRequestorSampleConsole in the solution and select “Debug – Start new Instance” from the context menu.

After the console app started, enter the following data to schedule jobs on input request from the console app:

Enter “s” for submitting jobs.

Enter “SampleTenant” as TenantId – this needs to match the folder in the jobprocessorfiles-container that contains the ZIP-file with the job-binaries as done in step 7 earlier.

Select either “f” for the simpler FinancialYearEnd job or “u” for the more complex UpdateWaitPostings job. More details are available in the section “Implementing Jobs and Job-Samples for GeRes2”.

Select “s” for single operations (this is simpler for getting started).

Enter the number of jobs you want to execute.

Select “y” for running against the local emulator.

After that you should see the steps executed in the sample console application. It starts by authenticating against Azure AD, then submits jobs against the GeRes2 Web API and subscribes to SignalR notification channels.

With that you should have a working demo-deployment of GeRes2 running locally against the emulator. There are several wiki-pages outlining some of the topics mentioned above at a greater level of detail. These are: