Configuring an Application with the Deployment Manifest

The DeploymentManifest.xml file is included as part of an Apprenda Application archive, and allows the Platform to discover and pre-configure some basic application setup required for deployment to the Platform. All configuration is done when an archive is uploaded and the application version is in the Definition stage. In most cases, you can use the Deployment Manifest instead of configuring an application through the Developer Portal’s UI after its uploaded to the Platform.

The Platform will use the information in the Deployment Manifest to automatically populate the corresponding portions of your application’s definition in the Developer Portal. Note that when patching, the Platform will not delete any existing definitions or synchronize new items with existing items. The Platform will only add new items that it finds in the configuration file to your application’s definition.

Deployment Manifest Requirements and Schema Location

All Deployment Manifests require the following:

  • utf-8 encoding
      <?xml version="1.0" encoding="utf-8"?>
    
  • The appManifest element defines the Deployment Manifest schema to parse the XML. All configuration settings for your application must be placed inside this element. Update the schema location in the example below to reference the schema for your Platform version
      <appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd"
                   cloud="CloudNameHere">
      </appManifest>
    

Schema Locations

The following schemas define the available configuration options in a Deployment Manifest.

Use the schema that matches your Platform version as the xsi:schemaLocation in the appManifest element for all Deployment Manifests.

Cloud Affinity

For installations with multiple clouds, Cloud affinity controls which Cloud the Platform will deploy the application to.

Set Cloud affinity by adding the cloud attribute to the appManifest element with the name of the cloud where you want the application to be deployed. If the specified Cloud does not exist, the archive upload will succeed with a warning and Cloud affinity will not be set.

<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd"
             cloud="CloudNameHere">

Application Settings

Application Settings refer to controls that affect the entire application. You can only configure some of these settings while the first version of an application is in the Definition stage. Any application settings included in the Deployment Manifest for a subsequent patched version are ignored. 

Application Services (User Access Model)

Application Service level (also called the “User Access Model” in the Developer Portal) determines how users can access your application. The selected service level for an application will limit the choices available for other Application Settings.

Including the service level is required for applicationServices if its included in a Deployment Manifest.

<applicationServices level="None" />

Valid values for level are None, Authentication, Authorization, and Multitenancy.

If the pipeline mode, presentation strategy, or database strategy are also set in the manifest and are incompatible with the Application Service level (User Access Model) set in level, the archive upload will succeed but the Platform will reconfigure these values to ones that are available for the selected Application Service level. Additionally, if the Application Service level specified violates any Platform-wide service limitations set by your Platform Administrator, the Platform will not accept the archive and the archive upload will fail.

Within the applicationServices element, you can specify several other features of your application as attributes.

Enforce SSL

Determines if your application is accessed strictly through an SSL/TLS connection or if it allows standard HTTP connections. When set to true, the Platform will automatically redirect standard HTTP traffic to your application to HTTPS. If set to false (default), the application can be accessed both ways (HTTP and HTTPS).

<applicationServices level="None" enforceSSL="true" />

Session Replication

When enabled (default), the session object is replicated by the Platform’s distributed cache and is made available to all of your application instances. This is useful to allow more than one instance of your application to service a request and still utilize session data. It will also ensure that if your instances are recycled, the session data is not lost.

<applicationServices level="None" sessionReplication="true" />

You cannot have session replication enabled and run more than one instance of a .NET UI application component on the same server. If session replication is enabled, .NET UI workloads from the same application must be deployed to different servers.

Sticky Sessions

Determines if sticky sessions is enabled for an application. When enabled, the Platform will guarantee that all user requests for a particular UI session are serviced by the same application instance. If disabled, the Platform will round robin requests to the different instances. The default for this option is true.

<applicationServices level="None" stickySessions="True" />

Load Balancer URL Configuration

Controls the behavior of the Platform front load balancer for accessing your application when you are using a custom domain name. If you are not using a custom domain name or have a custom vanity URL set, this setting will have no affect on your application.

<applicationServices level="None" loadBalanceUrlConfiguration="Preserve" />

Valid options are Preserve (default) and Redirect. Preserve means the custom hostname is maintained for the entire session. Redirect tells the load balancer to redirect requests for your application made using the custom URL to the Platform’s native URL instead. This might be useful if you want to ‘pin’ a client against a particular location like when using a Geo load balancer.

Presentation (User Interface) deployment strategy 

You can set application-level presentation-related information under the presentation element. Inside this element you can define the pipeline mode, presentation strategy, a custom style sheet for the application’s authentication page, and a custom application vanity URL and encryption certificate for the URL.

Configuration options in the presentation element must be compatible with the Application Service level (also called the “User Access Model”) set in the applicationServices element. If not, the Platform will automatically change these configuration settings to the defaults that align with the service level.

<presentation pipelineMode="Integrated"
              strategy="CommingledAppRoot"
              customAuthenticationStylesheetUrl="http://myauth.com"
              customApplicationUrl="http://mycustomapp.com/"
              customApplicationUrlCertificate="certificateFileName.pfx"/>

Pipeline mode

Controls IIS’s Managed Pipeline Mode for your application’s ASP.net presentation layer.

<presentation pipelineMode="Integrated" />

Valid options are Integrated and Classic and they map one to one to the application pool options in IIS. Classic will mimic the behavior of IIS6 and below and might be helpful for older applications. Integrated (default) uses behavior starting with IIS7.

Presentation Strategy

Controls the deployment strategy for your application’s presentation layer as well as the URL pattern that the Platform will use to access your application.

<presentation strategy="CommingledAppRoot"/>

Valid values are CommingledRootApp and CommingledAppRoot.

CommingledRootApp indicates that you want all your tenants to share the presentation layer as well as have the URL pattern of http://apps.rooturl/appalias/.

CommingledAppRoot indicates that you want all of your tenants to share the presentation layer and have the URL pattern of http://appalias.rooturl/.

Both options are an efficient or dense deployment option. The difference between CommingledAppRoot and CommingledRootApp is that CommingledAppRoot’s URL pattern offers access to your application through a personalized subdomain instead of a personalized path, which you can use with CommingledRootApp.

Custom (Vanity) Application Vanity URL and Certificate

If your application requires a custom domain name, you can specify a vanity URL to use. Your applicaiton is accessible through the URL you set and Platform provided native URL. When using this setting you need to coordinate with your IT administrator to make sure that the DNS for the URL resolves to the Platform’s load balancer. NOTE: This setting is only valid when the presentation strategy is set to CommingledAppRoot.

You can also specify an Application Vanity URL certificate. If the certificate file is specified, you must also set the customApplicationUrl and place the certificate in the application archive. Only Developers that have been granted the proper securable can upload a certificate file.

Custom Login Page Stylesheet

Custom Invoice Stylesheet

Sample DeploymentManifest.xml for Application Settings

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd"
             cloud="CloudNameHere">
             <!--Valid values for cloud: the name of a cloud that is part of your Apprenda installation; used to set cloud affinity on installs with multiple clouds-->

  <applicationServices level="Multitenancy" enforceSsl="True" sessionReplication="False" stickySessions="False" loadBalancerURLConfiguration="Preserve" />


<!--Valid values for presentation pipelineMode: "Classic", "Integrated"-->
<!--Valid values for presentation strategy: "CommingledAppRoot", "CommingledRootApp",-->
  <presentation pipelineMode="Integrated"
                strategy="CommingledAppRoot"
                customAuthenticationStylesheetUrl="http://myauth.com"
                customApplicationUrl="http://mycustomapp.com/"
                customApplicationUrlCertificate="certificateFileName.pfx"/>
</appManifest>

Java Components

System Properties and a default JRE for Java Web Application components in WAR (Web application Archive) format can be configured as indicated below. All configuration settings in this section should be placed inside the wars element of your application’s Deployment Manifest. For every war in your application, define a new war element inside of wars and add any of the configuration options below.

<wars>
    <war name="WarName">
        <!--Configuration settings -->
    </war>
</wars>

Default JRE

Set the default version of Java to use for the application. If this is not set, the application will use the default Java version determined my Platform Operators. This can be set for each war element in the Manifest.

The name provided must match the name of a native version provided by the Platform, or a custom Java version added by your Platform Operator. For more information about the available Java versions, contact your Platform Operators.

<war name="Apprenda.First.War" javaVersion="Default JRE 1.6"></war>
<war name="Apprenda.Second.War" javaVersion="Default JRE 1.8"></war>

System Properties

<systemProperties>
    <property name="warProp1" value="the first war value" />
    <property name="warProp2" value="the second war value" />
</systemProperties>

Command line arguments (runtime options)

List of command line arguments (runtime options), the Platform will add to CATALINA_OPTS on workload startup.

<commandLineArguments>
    <argument name="-Xms1024m" />
    <argument name="-Xmx2048m" />
    <argument name="-XX:PermSize=64m" />
</commandLineArguments>

Container Type 

You can specify a container type for Java Web Application components. While most Platform installations will support Tomcat 6 & Tomcat 7, your Platform Operator may configure support for JBoss or other Tomcat versions. The container type listed must exactly match the name of a container type that is supported on your Platform.

If you have another application with Java Web components, you can view a list of supported container names on the Components>General>Deployment Container section of the Configuration tab in the Developer Portal. Your Platform Operator can also obtain a list for you from the Java Hosting page in the System Operations Center.

<war name="jboss-numberguess.War" containerType="JBoss EAP 6" />

JMX Monitoring 

JMX Monitoring can be initially enabled/disabled for Java Web Applications components through the “enableJMX” attribute if the Developer uploading the Application Archive has the Monitoring JMX Resources securable. Through the use of Monitoring Subscriptions, objects being monitored through JMX can be configured for each application component and at a specific refresh rate (in seconds).

<war name="Apprenda.Taskr.War" enableJMX="True" >
    <monitoringSubscriptions>
        <monitoringSubscription updateInterval="10">
            <properties>
                <property name="jmx[&quot;com.apprenda.test:type=State&quot;, &quot;CountA&quot;]"/>
                <property name="jmx[&quot;com.apprenda.test:type=State&quot;, &quot;CountB&quot;]"/>
            </properties>
        </monitoringSubscription>
        <monitoringSubscription updateInterval="25">
            <properties>
                <property name="jmx[&quot;com.apprenda.test:type=State&quot;, &quot;ValueC&quot;]"/>
            </properties>
        </monitoringSubscriptions>
    </monitoringSubscriptions>
</war>

Custom Log4j format

The Platform supports custom Log4j formatting for Java Web Application components. The conversion characters with their respective data types can be found at here. While the conversion characters are able to pull in specific fields, you are not limited to only conversion characters. You can make your own messages including or excluding conversion characters as you see fit.

If no custom format is specified, the default value is %-6r [%15.15t] %-5p %c - %m%n. 

<war name="Apprenda.Taskr.War" logMessageFormat="Your Custom Pattern Here --- [%p] - %m" ></war>

Sample DeploymentManifest.xml for Java Components

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">
    <wars>
        <war name="Apprenda.Taskr.War" javaVersion="Default JRE 1.6" logMessageFormat="Your Custom Pattern Here --- [%p] - %m" enableJMX="True">
            <systemProperties>
                <property name="warProp1" value="the first war value"/>
                <property name="warProp2" value="the second war value"/>
            </systemProperties>
            <commandLineArguments>
                <argument name="-Xms1024m" />
                <argument name="-Xmx2048m" />
                <argument name="-XX:PermSize=64m" />
            </commandLineArguments>
            <monitoringSubscriptions>
                <monitoringSubscription updateInterval="10">
                    <properties>
                        <property name="jmx[&quot;com.apprenda.test:type=State&quot;, &quot;CountA&quot;]"/>
                        <property name="jmx[&quot;com.apprenda.test:type=State&quot;, &quot;CountB&quot;]"/>
                    </properties>
                </monitoringSubscription>
                <monitoringSubscription updateInterval="25">
                    <properties>
                        <property name="jmx[&quot;com.apprenda.test:type=State&quot;, &quot;ValueC&quot;]"/>
                    </properties>
                </monitoringSubscriptions>
            </monitoringSubscriptions>
        </war>  
    </wars>

</appManifest>

Linux Services

If you are creating a Linux Service application, you must include a Deployment Manifest that references the named artifact-specific sub-folder in the name attribute of the service element. Find more information about configuring a manifest for a Linux Service application, see the Linux Services page. The example manifest below include some of the available configuration options for this type of application.

Sample DeploymentManifest.xml for Linux Services

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >

  <applicationServices level="None"/>
  <linuxServices>
      <service name="SimpleService">
        <environmentVariables>
          <variable name="test" value="Test Environment Variable" />
          <variable name="foo" value="$#APPLICATIONALIAS#$" />
        </environmentVariables>
        <commandLineArguments>
          <argument name="firstArg" />
          <argument name="secondArg" />
          <argument name="appAlias=$#APPLICATIONALIAS#$" />
        </commandLineArguments>
        <ports>
          <dynamicPort portName="HTTP" httpMapped="true" />
          <dynamicPort portName="OTHER" />
        </ports>
        <tokenReplacements>
          <tokenReplacement>
            <includePatterns>
              <include>**/*.strange</include>
            </includePatterns>
            <excludePatterns>
              <exclude>**/exclude*</exclude>
            </excludePatterns>
            <replacements>
              <replacement token="$#CUSTOMTOKEN#$" value="Replaced Token" />
            </replacements>
          </tokenReplacement>
        </tokenReplacements>  
      </service>
   </linuxServices>

</appManifest>

Kubernetes Components

When creating an Apprenda Archive for an application that contains a Kubernetes component you can optionally choose to include a Deployment Manifest that will define some configuration options. Note that the name attribute of the pod element must reference the named sub-folder in the pods directory of the archive. See more about including a Kubernetes component in an archive.

To define a pod component in a Deployment Manifest, include the pods element. You can only define a single pod inside of the pods element.

<pods>
    <pod>
        <!--Configuration Settings-->
    </pod>
</pods>

A pod element can define, custom properties, a resource policies, instance count, and they type of scaling to apply to the Pod. The example below highlights more about how to define a Pod.

Sample DeploymentManifest.xml for Pods

<?xml version="1.0"?>
<appManifest xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" xmlns="http://schemas.apprenda.com/DeploymentManifest">
  <linuxServices />
  <pods>
    <pod name="k8scomp" throttlingPolicy="TestPolicy" instanceCount="3" scalingType="Manual">
      <customProperties>
        <customProperty name="PodProperty">
          <values>
            <propertyValue value="Value1" />
          </values>
        </customProperty>
      </customProperties>
    </pod>
  </pods>
</appManifest>

Custom Service Hosts for WCF Services

The Platform allows you to manually specify a custom service host type to use for each WCF service. Set the customServiceHostFullName attribute equal to the full name (full namespace plus class name) of the service host type you wish to use for that service. The custom service host implementation must reside in the same assembly as the service itself.

Manually specifying the custom service host to use allows you to have multiple service host implementations in the same assembly without trouble. If a custom service host is specified in the Deployment Manifest but a corresponding service host class is not found in your assembly, then there will be an error when promoting your application.

Sample DeploymentManifest.xml for Custom Service Host Specification

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <services>
      <service name="TimeCard.Service" customServiceHostFullName="TimeCard.Service.TimeCardServiceHost" />
  </services>

</appManifest>

Windows Services

Any archive that includes one or more Windows Services must include a Deployment Manifest with information about the Windows Services. Define a Windows Service by including the windowsServices element.

  <windowsServices>
    <service name="MyAwesomeApp.WindowsService" nameOfExecutable="MyAwesomeApp.WindowsService.exe"/>
      <ports>
        <staticPort num="5555" />
        <staticPort num="5556" />
      </ports>
  </windowsServices>

Then use a service If a Windows Service requires specific ports, you can specify them using the ports mapping configuration options.

The name of each Windows service defined in the Deployment Manifest must match the name of its individual Windows service folder within the application archive you plan to upload. The name of the executable must also match that specified in the Deployment Manifest.

Sample DeploymentManifest.xml for Windows Services

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">
<!--Required: service name, nameOfExecutable-->
  <windowsServices>
    <service name="MyAwesomeApp.WindowsService" nameOfExecutable="MyAwesomeApp.WindowsService.exe"/>
      <ports>
        <staticPort num="5555" />
        <staticPort num="5556" />
      </ports>
  </windowsServices>


</appManifest>

Require 32-bit for .NET Services and UIs

The Platform allows you to indicate that your WCF/Windows service needs to run as a 32 bit process, and whether or not your .NET UI requires the IIS application pool be configured for running as a 32 bit process. This is false by default and only needs to be included if you need the 32-bit configuration.

To set 32-bit a requirement, add require32Bit = true to the presentation element and the service elements for the WCF/Windows services that need it.

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <!--Configure a .NET UI-->
  <presentation requires32Bit="true" />

  <!--Configure a Windows Service-->
  <windowsServices>
    <service name="MyAwesomeApp.WindowsService" requires32Bit="true" nameOfExecutable="MyAwesomeApp.WindowsService.exe" ports="55555,55556" />
  </windowsServices>

  <!--Configure WCF services-->
  <services>
    <service name="MyAwesomeApp.Service" requires32Bit="true" />
    <service name="MyOtherAwesomeApp.Service" requires32Bit="true" />
  </services>

</appManifest>

Data storage

You can specify the data deployment model and storage provider (MS SQL or Oracle) for your application using the configuration settings described in this section. 

Place data storage configurations inside the persistence element of the Deployment Manifest. In addition to the other configuration options in this section, you can define custom properties for your database component in the persistence element.

<persistence strategy="IsolatedDB">
    <!--Configuration settings-->
</persistence>

The strategy attribute is required. It determines how the Platform will deploy your data. Valid values for persistence strategy are “IsolatedDB”, “Commingled” (“Commingled” applies to mssql only).

Deployment host (MS SQL or Oracle)

Use the dbms attribute to set the database Platform should to deploy your data in. If this is not set, the Platform will attempt to determine the deployment host from the provided provisioning scripts. The default is mssql, and it will be used of the Platform can not determine the deployment host from the archive.

<persistence strategy="Commingled" dbms="myssql"></persistence>

Provisioning script specification

As of Platform versions 8.2.0, you can use any ORM software, like Entity Framework Code First Migrations, to implement your data tier by using a Data Tier plugins instead of application provisioning scripts.

This allows you to define the provisioning scripts in the archive. If you plan to use the Platform data provisioning mechanisms, it is strongly recommended that you define your application data in the Deployment Manifest. Platform will attempt to autodetect SQL scripts when MS SQL is specified and PLS scripts when Oracle is specified, if you do not specify the scripts in the manifest.

If any other file format is used for the Application Provisioning or Tenant Provisioning scripts, you must include the full file names with file extension.

<persistence strategy="IsolatedDB" dbms="mssql"  providerContextEnabled="false" >
  <provisioning>
    <application scriptPath="ApplicationProvisioning_Script.sql" />
    <tenant scriptPath="TenantProvisioning_Script.sql" />
  </provisioning>
</persistence>

Use the <application scriptPath="Path/to/script"/> element inside the provisioning element to define the Application Provisioning Script.

Use the <tenant scriptPath="Path/to/script"/> element inside the provisioning element to define the Tenant Provisioning Script.

Provider Context settings

Provider Context utilization for guest applications is disabled by default (please see here for more information on Contexts).  To enable or disable Provider Context utilization for a specific guest app, set the providerContextEnabled setting in the Deployment Manifest to “true” or “false.”

<persistence strategy="IsolatedDB" dbms="oracle"  providerContextEnabled="false" ></persistence>

Sample DeploymentManifest.xml for data storage

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">


<!--Valid values for persistence dbms: "mssql", "oracle11g", "oracle12c", "oracle" (equivalent to "oracle11g")-->
<!--Valid values for persistence providerContextEnabled (mssql only): "true", "false" -->
<!--The values for "application scriptPath" and "tenant scriptPath" must be relative to the Scripts folder in your archive.-->
  <persistence strategy="IsolatedDB" dbms="oracle"  providerContextEnabled="false" >
    <provisioning>
      <application scriptPath="ApplicationProvisioning_Script.sql" />
      <tenant scriptPath="TenantProvisioning_Script.sql" />
    </provisioning>
  </persistence>

</appManifest>

Shared Tables and Default Schema (for MS SQL Server only)

You must define shared database tables in the Deployment Manifest if they are required for your application. A default schema can also be designated as per the example below. 

Sample DeploymentManifest.xml for Shared Tables and Default Schema

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <applicationServices level="Multitenancy" />
  <presentation strategy="IsolatedAppTenantRoot" />

  <persistence strategy="IsolatedDB" defaultSchema="dbo">
    <tableOptions>
    <tableOption name="Tag" schema="dbo" option="AllTenants" />
    </tableOptions>
  </persistence>

</appManifest>

Token Replacement

You can use the Deployment Manifest to define files the Platform should token switch for your application components. If this is not provided in the Deployment Manifest, token switching may still take place in the matching file patterns defined in the Platform Registry.

To use token replacements for a component to specify additional files that should be token switched, include the tokenReplacements element inside the component definition in the Deployment Manifest.

Inside tokenReplacements you can include one or more tokenReplacement elements that define what patterns to look for, which patterns to exclude, and what to replace any matching patterns.

<tokenReplacements replaceDefaultFileSearchPatterns="True">  
  <tokenReplacement >
    <includePatterns>
      <include>**\*Copy.xml</include>
      <include>**\*.conf</include>
    </includePatterns>
    <excludePatterns>
      <exclude>**\FileToExclude*.xml</exclude>
    </excludePatterns>
    <replacements>
      <replacement token="$#StaticReplace#$" value="replaced static" />
      <replacement pattern="\$\#Pattern.*\#\$" value="replaced pattern" />
    </replacements>
  </tokenReplacement>
</tokenReplacements>

Replace Default Patterns

If replaceDefaultFileSearchPatterns is set to true, the Platform will only look at the includedPatterns when performing replacements. If replaceDefaultFileSearchPatterns is set to false (default), the Platform will look at both the includedPatterns and the file extension patterns defined in the Hosting.Linux.TokenFilePatterns to token switch.

Included Patterns

Included patterns define files that the Platform should proform token switching in for a component. File search patterns for includedPatterns may include the following special characters:

  • ? - matches any single character
  • * - matches 0 or more characters
  • ** - matches 0 or more subdirectories (ie **\bin*.xml would match \test\bin\test.xml, \bin\test.xml and \test1\test2\bin\test.xml but not \test1\test2\test.xml)

Excluded Patterns

Patterns listed here define files that will not be token switched. ExcludePatterns will always override DefaultFileSearchPatterns and includePatterns.

Replacements

The Platform will always replace tokens for the patterns explicitly defined in tokenReplacement in the files that match the includedPatterns. Platform tokens replacements for the DefaultFileSearchPatterns are replaced before specified replacements in a Deployment Manifest. The replacement nodes specified will only apply to the includedPatterns specified in the same tokenReplacement. They will not apply to file patterns specified in the registry.

For replacements, you can specify a specific string to replace, or define a regular expression to replace.

<replacements>
    <replacement token="$#StaticReplace#$" value="replaced static" /> <!-- token defines an exact token to replace -->
    <replacement pattern="\$\#Pattern.*\#\$" value="replaced pattern" /> <!-- pattern defines a regular expression to replace -->
</replacements>

Sample DeploymentManifest.xml for Token Replacements that Replaces Platform Defaults set through the Hosting.Linux.TokenFilePatterns setting

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">
 <wars>
  <war name="Apprenda.Taskr.War" javaVersion="Default JRE 1.6">
    <tokenReplacements replaceDefaultFileSearchPatterns="True">  
      <tokenReplacement >
        <includePatterns>
          <include>**\*Copy.xml</include>
          <include>**\*.conf</include>
        </includePatterns>
        <excludePatterns>
          <exclude>**\FileToExclude*.xml</exclude>
        </excludePatterns>
        <replacements>
          <replacement token="$#StaticReplace#$" value="replaced static" />
          <replacement pattern="\$\#Pattern.*\#\$" value="replaced pattern" />
        </replacements>
      </tokenReplacement>
    </tokenReplacements>
  </war>
 </wars>

</appManifest>

Sample DeploymentManifest.xml for Token Replacements that Supplements Platform Defaults set through the Hosting.Windows.TokenFilePatterns setting

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

 <presentation>
  <tokenReplacements replaceDefaultFileSearchPatterns="False">  
     <tokenReplacement>
       <includePatterns>
         <include>**\*.xml</include>
         <include>*\web.config</include>
       </includePatterns>
       <excludePatterns>
         <exclude>**\Apprenda.mock.xml</exclude>
       </excludePatterns>
       <replacements>
         <replacement token="@APP_NAME@" value="GuestBook" />
       </replacements>
     </tokenReplacement>
   </tokenReplacements>
  </presentation>

</appManifest>

Environment Variables

Configure environment variables for WCF services, Linux Services, and Java Web Application components in WAR (Web application Archive) format inside the war element defined in the Deployment Manifest. The environmentVariables can define as many variables as you need. Each variable you must include a name and value attribute.

Sample DeploymentManifest.xml for Environment Variables

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

    <wars>
        <war name="Apprenda.Taskr.War" javaVersion="Default JRE 1.6">
            <environmentVariables>
                <variable name="warVar1" value="war value 1"/>
                <variable name="warVar2" value="war value 2"/>
            </environmentVariables>
        </war>  
    </wars>

</appManifest>

Features

Features represent pieces of functionality that are intended to be “governed” through the use of entitlements. Based on the subscription or entitlement that a given user or tenant has, they are able or are not able to perform certain actions on your application. These actions are bound by the features available in their particular entitlement.

Features can defined in the initial version of an application through the features element. Only applications with a User Access Model of Authorization of higher can have Features defined. Feature types are toggle, limiter, block, or boundry. For each type of feature, the name attribute is required.

<features>
  <toggle name="Priority Management" />
  <limiter name="Number of Tasks" />
  <block name="E-mail Support" />   
  <boundary name="Attachment Size" />
</features>

When patching, use the same notation to add Features though the a Deployment Manifest. Note that these changes are only constructive, meaning Features not included with a patch Deployment Manifest will not be automatically removed.

Sample DeploymentManifest.xml for Features

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <features>
    <toggle name="Priority Management" />
    <limiter name="Number of Tasks" />
    <block name="E-mail Support" />   
    <boundary name="Attachment Size" />
  </features>


</appManifest>

Securables

Securables control access to your application. Only users that have been granted your defined securables will be able to use or access the parts of your application that are protected by securables. Only applications with a User Access Model of Multi-tenancy or higher can use securables.

To define securables for your application, use the executionSecurables element to list all needed securables. Include the name and description attributes for each securable defined.

<executionSecurables>
  <securable name="Modify Tags" description="Grants permission to update and delete tags" />
  <securable name="Change Priority" description="Grants permission to change priority on tasks" />
  <securable name="Delete Tasks" description = "Grants permission to delete tasks" />
</executionSecurables>

When patching, use the same notation to add securables though the a Deployment Manifest, but note that these changes will be purely constructive. This means that securables not included with a patch will not be automatically removed in the patched version.

Sample DeploymentManifest.xml for Securables

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <executionSecurables>
    <securable name="Modify Tags" description="Grants permission to update and delete tags" />
    <securable name="Change Priority" description="Grants permission to change priority on tasks" />
    <securable name="Delete Tasks" description = "Grants permission to delete tasks" />
  </executionSecurables>

</appManifest>

Entitlement Definitions

Entitlement Definitions are required for applications with Authorization or Multi-tenancy as a User Access Model. Note that Entitlement Definitions are also referred to as active offerings.

For patched versions of an application, you can only make limited constructive changes through a Deployment Manifest. You are only able to adding new Components or plans, or update refreshment intervals or Component quantities in patched versions. If you wish to removing Components or update the names of plans and Components you must use the Additional Controls section of the Developer Portal.

Sample DeploymentManifest.xml for Entitlement Definitions

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <applicationServices level="Multitenancy" />
  <presentation strategy="CommingledAppRoot" />
  <persistence strategy="IsolatedDB" />

  <features>
    <toggle name="Priority Management" />
    <limiter name="Number of Tasks" />
    <block name="E-mail Support" />
  </features>

  <entitlementDefinitions>
    <entitlementDefinition name="Standard" description="" isPublished="true" publicName="Name displayed to potential subscribers" publicDescription= "Description displayed to potential subscribers" >
      <userBasedEntitlements>
        <plans>
          <plan name="Basic User" planType="Periodic" description="A description" restrictionOnNumberOfSubscriptions="10" >
            <planModels>
              <planModel refreshInterval="every 7 days" />
            </planModels>
          </plan>
          <plan name="Deluxe User" planType="Periodic" description="A description" >
            <planModels>
              <planModel refreshInterval="every 1 year" />
            </planModels>
          </plan>
          <plan name="No Refreshment Plan" planType="Perpetual" description="A description" >
            <planModels>
              <planModel type="Perpetual" />
            </planModels>
          </plan>          
        </plans>
        <sections>
          <section>
            <components>
              <component displayName="Included Tasks" feature="Number of Tasks" description="The number of tasks that you can create.">
                <planItems>
                  <planItem plan="Basic User" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 7 days" quantity="5" />
                    </planItemDefinitions>
                  </planItem>
                  <planItem plan="Deluxe User" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 1 year" quantity="10" />
                    </planItemDefinitions>
                  </planItem>
                  <planItem plan="No Refreshment Plan" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelType="Perpetual" quantity="10" />
                    </planItemDefinitions>
                  </planItem>                  
                </planItems>
              </component>   
              <component displayName="Manage Priority" feature="Priority Management" isNew="true">
                <planItems>
                  <planItem plan="Deluxe User" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 1 year" />
                    </planItemDefinitions>
                  </planItem>
                </planItems>
              </component>
              <component displayName="E-mail Support" feature="E-mail Support" isHidden="false">
                <planItems>
                  <planItem plan="Basic User" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 7 days" blockLabel="E-mails" quantity="10" />
                    </planItemDefinitions>
                  </planItem>
                  <planItem plan="Deluxe User" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 1 year" blockLabel="E-mails" quantity="999" />
                    </planItemDefinitions>
                  </planItem>
                  <planItem plan="No Refreshment Plan" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelType="Perpetual" blockLabel="E-mails" quantity="20" />
                    </planItemDefinitions>
                  </planItem>                    
                </planItems>
              </component>
              <component displayName="Forum Access" isHidden="false">
                <planItems>
                  <planItem plan="Basic User" inclusionStatus="Included" footnote="*">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 7 days" />
                    </planItemDefinitions>
                  </planItem>
                  <planItem plan="Deluxe User" inclusionStatus="Included" footnote="*">
                    <planItemDefinitions>
                      <planItemDefinition planModelRefreshInterval="every 1 year" />
                    </planItemDefinitions>
                  </planItem>
                  <planItem plan="No Refreshment Plan" inclusionStatus="Included">
                    <planItemDefinitions>
                      <planItemDefinition planModelType="Perpetual"  />
                    </planItemDefinitions>
                  </planItem>                    
                </planItems>
              </component>
            </components>
          </section>
        </sections>
        <footnotes>
          <footnote indicator="*" description="Available in North America Only." />
        </footnotes>
      </userBasedEntitlements>
    </entitlementDefinition>
  </entitlementDefinitions>

</appManifest>

Custom Properties

Custom Properties define Platform behavior towards your application. You can assign them to an application as a whole, or to individual application components. 

The valid values for a Custom Property or whether an application or application component can be assigned values, depends upon the Custom Property settings defined by the Platform Operator. To correctly use Customer Properties, you need to know how it can be applied and the values the property allows. Contact your Platform Operators if you have any questions about the available Custom Properties on your Platform.

To add a Custom Property to your application, add the customProperties element to your Deployment Manifest. Add customProperties inside a component definition to add one or more properties to the component, or add the element outside all component definitions to add the properties at the application level.

<customProperties>
    <!--Configuration Settings-->
  </customProperties>

Inside the customProperties element, define a Custom Property as a customProperty element.

<customProperties>
    <customProperty name="CustomPropOne">
      <values>
        <propertyValue value="ValueA"/>
        <propertyValue value="ValueB"/>
        <!--If the property allows multiple values, you can add as many propertyValues elements as you need-->
      </values>
    </customProperty>
    <!--Add one or more customProperty elements to define more properties-->
  </customProperties>

customProperty elements should always include the name attribute that matches the name of an available Custom Property on your Platform. To define values, add the values element inside a customProperty element, using propertyValue elements to set values for the property. Add more than one propertyValue elements if the Custom Property allows multiple values.

Sample DeploymentManifest.xml for Custom Property Value Assignment

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >

  <!--application level-->
  <customProperties>
    <customProperty name="CustomPropOne">
      <values>
        <propertyValue value="ValueA"/>
        <propertyValue value="ValueB"/>
      </values>
    </customProperty>
  </customProperties>
 
  <!--service level-->  
  <services>
    <service name="Taskr.Admin.Service">
      <customProperties>
        <customProperty name="CustomPropOne">
          <values>
        <propertyValue value="ValueA"/>
        <propertyValue value="ValueB"/>
          </values>
        </customProperty>
      </customProperties>
    </service>
  </services>
 
 <!--Windows Service level-->
  <windowsServices>
    <service name="Apprenda.Testing.WinService" nameOfExecutable="Apprenda.Test.WindowsService.exe">
      <customProperties>
        <customProperty name="CustomPropOne">
          <values>
        <propertyValue value="ValueA"/>
        <propertyValue value="ValueB"/>
          </values>
        </customProperty>
      </customProperties>
    </service>
  </windowsServices>
 
  <!--user interface level-->
  <presentation>
    <customProperties>
      <customProperty name="CustomPropOne">
        <values>
        <propertyValue value="ValueA"/>
        <propertyValue value="ValueB"/>
        </values>
      </customProperty>
    </customProperties>
  </presentation>
 
  <!--database level-->
  <persistence>
    <customProperties>
      <customProperty name="CustomPropOne">
        <values>
        <propertyValue value="ValueA"/>
        <propertyValue value="ValueB"/>
        </values>
      </customProperty>
    </customProperties>
  </persistence>
 
</appManifest>

Port Mapping

For Linux and Windows Services, you are able to specify a list of the ports that are needed by your application to send or to receive communications. The values allowed for the specified ports, as well as the maximum number of ports you can specify for each component, are configured by your Platform Operator. Port values that exceed these limits will result in a failed archive upload.

The Platform will reserve any specified ports for your application to ensure that no other application can use them.

Note: You are also able to include port specifications in applications you plan to deploy with Docker. See how to configure ports for Docker workloads.

To specify ports, include the ports element. You can specify one or more static or dynamic port for each service.

<ports>
  <dynamicPort portName="HTTP"  />
  <staticPort num="5555" />
</ports>

Static Ports

If you declare a static port, the Platform will reserve that exact port listed in the num attribute. Note that once the port is allocated to one instance of the service, other instances of the service must be deployed to another server where the port is available.

<ports>
  <staticPort num="5555" />
</ports>

Dynamic Ports

Specifying a dynamic port lets the Platform know the workload requires a port that the Platform then assigns at deploy time.

For every dynamic port, you must include the portName attribute that declares a name for the port. On Platform, portName is used to define the port as an environment variable and token to be token-switched in the same way other tokens are switched by the Platform.

<ports>
  <dynamicPort portName="HTTP"  />
</ports>

For Linux Services, an example of the naming convention for tokens and environment variables is if a port named “FOO” is specified in the manifest, the Platform creates an environment variable “$PORT_FOO” and an Apprenda Token “$#PORT_FOO#$”.

For Windows Services, an example of the naming convention for tokens and environment variables is if a port named “FOO” is specified in the manifest, the Platform creates an environment variable “$PORT-FOO” and an Apprenda Token “$#PORT-FOO#$”.

HTTP Mapped Port

When a static or dynamic port is marked httpMapped="true", the Platform will use that port to route HTTP traffic to the application. You can only specify one port (static or dynamic) as httpMapped for an application.

<ports>
  <dynamicPort portName="HTTP" httpMapped="true" />
</ports>

Instance Scaling Settings

There are three types of instance scaling that you can assign to your application. Note that depending on how your Platform is configured, you might not be able to use all three scaling types.

You can assign scaling types to individual application components (WCF services, Windows Services, Java Web Applications, and .NET user interfaces).  The scaling methods are Manual, Automatic, and Scheduled. If not explicitly set, Manual scaling is set by default with a value of instanceCount=”1” for all component types except Windows Services (where instanceCount=”0”).

Set the scaling method for a component by setting the scalingType in a component definition in the Deployment Manifest. Depending on the type of scaling you assign, you can add additional elements and attributes to define more information about the component’s scaling needs. The available scaling types are Manual, Automatic, and Scheduled.

<services>
    <service name="Taskr.Admin.Service" scalingType="Manual" />
 </services>

Manual Scaling

If Manual scaling is set, the Platform will maintain the exact specified number of instances set for that component. To define the number of instances you require, set the instanceCount attribute. If it is not included, the default instance count of 1 will be applied (except for Windows Services where the default is 0).

<services>
    <service name="Taskr.Admin.Service" scalingType="Manual" instanceCount="3" />
</services>

Automatic Scaling

If Automatic scaling is set, you must define the minimumInstanceCount and maximumInstanceCount attributes to set the minimumn and maximum instance counts for the caomponent.

<windowsServices>
    <service name="Apprenda.Testing.WinService" nameOfExecutable="Apprenda.Test.WindowsService.exe" scalingType="Automatic" minimumInstanceCount="1" maximumInstanceCount="4" />
</windowsServices>

Scheduled Scaling

If Scheduled scaling is set, a weekly scaling schedule can also be included for that component by including a scalingSchedule element inside the presentation element for that component. All time values included in scalingschedule, use UTC format.

 <presentation strategy="CommingledAppRoot" scalingType="Scheduled" >
    <scalingSchedule>
      <scheduleEvent day="Monday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Monday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Tuesday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Tuesday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Wednesday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Wednesday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Thursday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Thursday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Friday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Friday" time="21:00:00Z" instanceCount="1" />
    </scalingSchedule>
  </presentation>

Sample DeploymentManifest.xml for Instance Scaling Settings

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >

  <!--Manual scaling set-->
  <services>
    <service name="Taskr.Admin.Service" scalingType="Manual" instanceCount="3" />
  </services>
 
  <!--Automatic scaling set with minimum and maximum instance counts-->
  <windowsServices>
    <service name="Apprenda.Testing.WinService" nameOfExecutable="Apprenda.Test.WindowsService.exe" scalingType="Automatic" minimumInstanceCount="1" maximumInstanceCount="4" />
  </windowsServices>
 
  <!--Scheduled scaling-->
  <presentation strategy="CommingledAppRoot" scalingType="Scheduled" >
    <scalingSchedule>
      <scheduleEvent day="Monday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Monday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Tuesday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Tuesday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Wednesday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Wednesday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Thursday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Thursday" time="21:00:00Z" instanceCount="2" />
      <scheduleEvent day="Friday" time="12:00:00Z" instanceCount="5" />
      <scheduleEvent day="Friday" time="21:00:00Z" instanceCount="1" />
    </scalingSchedule>
  </presentation>

</appManifest>

Resource Policy Assignment

If Resource Throttling is enabled on your Platform, you can assign specific Resource Policies or Storage Quotas to your application’s components in the Deployment manifest. The policies available for a given application component are created and managed by your Platform Operator. To find out more about the available Resource Policies, contact your Platform Operators.

If no Resource Policy or Storage Quota is defined in the Deployment manifest for any application component and automatic-assignment is enabled, the Platform will assign that component the Platform Operator chosen default policy for that component type.

To assign a policy, include the throttlingPolicy attribute in the component type definition.

<services>
  <service name="Taskr.Admin.Service" throttlingPolicy="Test Compute Policy" />
  <service name="Taskr.Core.Service"  throttlingPolicy="Test Compute Policy" />
</services>

For database components, you are also able to set a Storage Quota by setting the storageQuotaName and storageQuatoaBlockSize in addition to throttlingPolicy to assign a Resource Policy.

<persistence defaultSchema="dbo" strategy="IsolatedDB" throttlingPolicy="Test Compute Policy" storageQuotaName="Test Storage Policy" storageQuotaBlockSize="2" />

Note that if an application is patched with an archive containing a Deployment Manifest that does not specify Resource Policy/Storage Quota assignments, the patched version’s Policy/Quota assignments will be reset to the Platform defaults (if automatic policy assignment is enabled) or null (if auto-assignment is not enabled).

Sample DeploymentManifest.xml for Resource Policy Assignment

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd">

  <presentation throttlingPolicy="Test Compute Policy" strategy="CommingledAppRoot"  />

  <persistence defaultSchema="dbo" strategy="IsolatedDB" throttlingPolicy="Test Compute Policy" storageQuotaName="Test Storage Policy" storageQuotaBlockSize="2" />

  <services>
    <service name="Taskr.Admin.Service" throttlingPolicy="Test Compute Policy" />
    <service name="Taskr.Core.Service"  throttlingPolicy="Test Compute Policy" />
  </services>

  <windowsServices>
    <service name="MyWindowsService.WindowsService" requires32Bit="false" nameOfExecutable="MyWindowsService.WindowsService.exe" ports="55555,55556" throttlingPolicy="Test Compute Policy" />
  </windowsServices>

</appManifest>

User Account Specification for Application Components

User credentials under which deployed instances of your application’s components will run can be assigned through a Deployment Manifest to individual application components (.NET services, Windows Services, Java Web Applications, and user interfaces). 

Sample DeploymentManifest.xml for Credential Assignment for .NET service, Windows Service, and user interface components

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >


  <services>
    <service name="Taskr.Admin.Service" domain="APPRENDA" userAccount="WCF Service User" password="password" />
  </services>
 
  <windowsServices>
    <service name="Apprenda.Testing.WinService" nameOfExecutable="Apprenda.Test.WindowsService.exe" domain="APPRENDA" userAccount="Windows Service User" password="password" />
  </windowsServices>
 
  <presentation domain="APPRENDA" userAccount="UI User" password="password" />

</appManifest>

Sample DeploymentManifest.xml for Credential Assignment for a Java Web Application component

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >

    <wars>
        <war name="Apprenda.Taskr.War" userAccount="notroot" userToken="mytoken" />
    </wars>
 
</appManifest>

Event Log Overrides

In the course of your application’s lifecycle on the Platform, logs will be generated to alert you about errors or events occurring in your application. In general, Platform logs are controlled by the Global Platform Log Level that is set by your Platform Operator. Only logs that match the global level’s severity or have a worse severity level are logged to the Platform. To help with debugging and to manage logs, you are able to create Log Overrides for any application, that will supersede the global log level and collect log matching your criteria.

To create an override, include the logOverrides element in your Manifest. Inside that element, you can add one or more logOverride elements that defines the type of override to create and the severity level the override should collect logs for. The available values for the log level are Info, Debug, Warn, and Error.

If you want to receive emails when a matching log is created, include a recipients element with a list of recipient and their email.

Note that you can only configure Tenant and User based overrides in the Developer Portal and can not be configured using the Deployment manifest.

Sample DeploymentManifest.xml for Event Log Override Configuration

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >

  <logOverrides>
    <logOverride type="Version" level="Warn">
      <recipients>
        <recipient email="test@apprenda.com" />
      </recipients>
    </logOverride>
    <logOverride type="Source" level="Debug" text="hello*">
      <recipients>
        <recipient email="test1@apprenda.com" />
      </recipients>
    </logOverride>
    <logOverride type="Version" level="Info" text="not valid"/>
  </logOverrides>

</appManifest>

Patching with a Deployment Manifest

For patched versions of an application, you can use the Deployment Manifest to make constructive changes to the following:

  • Features (new Features can be added)
  • Securables (new Securables can be added)
  • Entitlement Definitions (additions and limited changes can be made; a definition copied from a previous version can be published)
  • Custom Properties (new Custom Properties can be added)
  • The inclusion of patching scripts  (for changes to MS SQL databases or Oracle schemas) with an archive used to patch an application 

Database Patching

Include database patching scripts in the Scripts folder within the Persistence folder in an application archive. To take effect, you must list the patching scripts in the Deployment Manifest with the proper path and script type information.

If more than one patching script is included, you must list them in the order the Platform should execute them. When patching an application that leverages Oracle 12c, include rollback scripts in the archive and specify them in the Deployment Manifest as described in the Working with Datasection.

Sample DeploymentManifest.xml for DB Patching and Entitlement Definition Publication

<?xml version="1.0" encoding="utf-8"?>
<appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd" >

<!--Valid values for persistencPatch type: "SchemaScript", "DataScript", "SharedSchemaScript" (mssql only), "SharedDataScript" (mssql only), "Binary" -->
  <persistencePatches>
    <persistencePatch path="\Persistence\Scripts\Schema\SchemaPatch.sql" type="SchemaScript"/>
    <persistencePatch path="\Persistence\Scripts\Data\DataPatch.sql" type="DataScript"/>
  </persistencePatches>

  <entitlementDefinitions>
    <entitlementDefinition name="Standard" isPublished="true" />
  </entitlementDefinitions>   

</appManifest>