Deploying Jobs for a GeRes2-instance in Blob-Storage

As explained on the landing page for the GeRes2-project, when executing jobs in the JobProcessor, GeRes2 is downloading the binaries and files required for executing a job from blob storage.

Which storage account is used?

As per the documentation page “Configuring Storage for GeRes” in this Wiki, the primary storage Account for GeRes2 must be used for this purpose (as opposed to the diagnostics storage account). This storage account is configured in the Geres.Storage.ConnectionString setting in the GeRes2 service configuration file (*.cscfg).

Where is GeRes2 looking for Job-packages inside of this storage account?

In this blob storage service, GeRes2 looks for a jobprocessorfiles container. This container is supposed to have sub-folders in it for each tenant as a very basic means of isolating job implementation packages from different tenants/customers.

In each of the directories inside of this container, you can have as many ZIP-packages with files required for job-execution as you want. The contents of those ZIP-packages are:

  • A .NET assembly DLL containing your IJobImplementation that does the work. This assembly MUST be in the very root directory of the ZIP-archive.
  • Any additional files, resources and folders required by your job.

Deploying jobs for GeRes2

The best way to learn, how you can deploy jobs for GeRes2 is, to deploy one of the sample jobs we’re shipping as part of the GeRes2 solution. We recommend you use tool such as CloudBerryLabs storage explorer (available for free) if you want to manually deploy jobs. In future releases we’re thinking about a command line tool that helps with this (and some other) operations.

After a full re-build of the GeRes2 solution, you’ll find the files and binaries required for those sample jobs in the deploy sub-directory as shown below.

image

Inside of this directory you find a sub-directory called jobs which contains two subfolders representing two different tenants to be created in blob storage. For example in the .\deploy\jobs\SampleTenant folder, you’ll find a folder called GeresJobSamples which contains an assembly with two sample jobs (FinancialYearEnd and UpdateWaitingPostings, both are in the assembly GeresSimpleJobSamples.dll).

image

The contents of this directory need to be packaged into a ZIP archive.The name of that ZIP-archive needs to match the value of the JobProcessorPackageName when scheduling a job. For example, the GeresJobRequestorSampleConsole application we ship with the GeRes2 solution uses the following code to schedule jobs included in the assembly shown and mentioned above:

// create a new job
var newJob = new Job
{
    JobType = jobType,
    JobName = string.Format("{0} {1}", jobType, i),
    TenantName = tenantId,
    JobProcessorPackageName = "geresjobsamples.zip",
    Parameters = String.Empty
};

try
{
    string jobId = geresServiceClient.Management.SubmitJob(newJob, batchId).Result;
    try
    {
        geresServiceClient.Notifications.SubscribeToJob(jobId);
    }
    catch (Exception ex)
    {
        Console.WriteLine("Failed subscribing to job: {0}!", ex.Message);
    }
    Console.WriteLine("Job {0} : {1} --> Submitted", i, jobId);

}
catch (Exception ex)
{
    Console.ForegroundColor = ConsoleColor.Red;
    Console.WriteLine("Failed submitting job: {0}", ex.Message);
    Console.ForegroundColor = currentConsoleColor;
}


Therefore the ZIP-archive needs to be named geresjobsamples.zip since the JobProcessorPackageName uses this value when submitting a job as highlighted in the code above. The folder you deploy this ZIP-archive to needs to match the TenantName specified when submitting a job (highlighted in orange in the code above). Assuming you use “SampleTenant”, the folder in BLOB-storage where you put the ZIP-package to needs to be named “SampleTenant”, as well.

To deploy using CloudBerry Labs Storage Explorer for Azure as recommended above, simply ZIP the two files shown in explorer above (GeresSimpleJobSamples.dll and GeresSimpleJobSamples.pdb, whereas the *.pdb is optional and only needed for debugging) into a ZIP archive. Make sure that both files are in the root directory of the ZIP archive and not in a sub-directory. Especially be careful if you’re using Windows Explorer for packaging since when packaging the folder instead of the files will result in having the files in a sub-folder instead of the root-folder of the ZIP archive.

Next copy the resulting ZIP archive in a folder called SampleTenant in your local file system. The open CloudBerry Storage explorer. In the left window connect to your GeRes2 primary storage account (the one specified in the Geres.Storage.ConnectionString setting) . In the right window navigate to the folder containing the previously created SampleTenant-folder that contains your ZIP-archive with the job files as shown below.

If it does not exist, yet, create a container in the blob storage account using CloudBerry that is named jobprocessorfiles (as shown below). Open that container. Then drag the files from the right window (local file system) to the left window (blob storage account). The result should look as in the last screen shot below.

image

image

Note that you can pick any folder name or name for the ZIP-package as long as the folder name matches the TenantName-parameter for the job-submission as shown in the code above and the name of the ZIP-package matches the name of the JobProcessorPackageName when submitting the job as shown above.

Deployment for local execution

Deploying jobs for local execution works exactly the same as for cloud-based GeRes2-instances. If you have specified the development storage of the Azure Emulator for local debugging, the only difference is, that you need to deploy the job files as described above to the local development storage of the Azure Emulator. CloudBerry supports that as well.

Last edited May 1, 2014 at 8:01 PM by mszcool, version 2