This topic assumes that you are familiar with the general Apprenda concepts and serves as an introduction to understanding how to configure your local environment for working with .NET applications.
It is important to understand that Apprenda is not virtualization technology that simply deploys different instances of your application for each new subscriber that signs up for your service, nor does Apprenda require you to put your code through a manual process of ‘wrapping’ in a special cloud- or multi-tenancy-enabling way. Apprenda does require that your applications are written in a way that defines a clear and modular separation of business logic, presentation and persistence where all the business logic is captured in .NET services. Since Apprenda is modeled as a Platform as a Service (PaaS) offering, a written application gets uploaded and published via a web browser to an Apprenda instance. This poses a bit of a problem since it would be cumbersome to have to test code in a live environment by writing code, publishing that code to an Apprenda instance, testing, and then repeating. Instead, the Apprenda SDK allows you to create mock data that will be used to emulate Apprenda on your local development box. The focal point of local development is the Apprenda Mock file. Using this file makes it simple to mock an Apprenda instance.
note: utf-8 encoding is required for all persistence scripts, application and add-on manifests, CLI installer input files, and apprenda mock files.
The Apprenda SDK provides a local environment that allows you to mimic Apprenda data and runtime mechanics while testing your code on your local development machine. You can establish different Tenant access scenarios, application organization, and security components without having to deploy your applications into a live environment. You establish these scenarios by using Apprenda configuration files. Apprenda configuration files are XML definitions that instruct your local environment how to setup the local execution context under which your application will run.
Apprenda mock files are defined by two main sections, a tenants section and an execution context section. The tenants section represents a list of all of the mock Tenants you wish to define, as well as their data. The execution context section represents how the runtime should represent itself to your application. You first need to define your list of customers (by creating Tenants in the tenants section) before you can specify the executing customer in the execution context section. Take a look at the diagram below for details on the XML structure and the data that is available through the API.
Once you’ve defined the Tenants you want to have available in your local instance, you can select one of them as the current executing Tenant by specifying the tenantId attribute in the execution context section as well as the executing User by specifying the userId attribute in the same section. At runtime, the Apprenda local mock will run your code as that Tenant/User pair. Further, by specifying different execution meters and execution securables, you can see how the application behaves when the User encounters a particular Feature or secured functionality based on the subscription they will procure when the application is deployed in a live Apprenda instance.
One of the most common problems when working on your local environment is data not displaying correctly after making changes to an Apprenda mock file. In order to provide a consistent definition between your user interfaces and your services in your local environment, Apprenda statically loads your XML definition the first time it is used, and then it uses a WCF behavior to flow the data back and forth from the UI to the services. Visual Studio uses a small web server to test your asp.NET applications but doesn’t close the web server after you close a debug session. If you make changes to an Apprenda mock file, make sure that you close the web server between debug sessions or else your data WON’T be loaded.