This is documentation for Apprenda 7 and 8.
Documentation for newer version is available at https://new.docs.apprenda.com.

Applications

The Applications page contains a list of the applications currently deployed on your Platform in the Sandbox or Published stage. Applications in the Definition stage will not appear on this page, as they are not deployed on the Platform. From the Applications page can do the following:

The Applications page is accessible from the top navigation in the SOC. The main page shows the following information for each application:

  • Application name and alias
  • Version deployed
  • Stage
  • Development Team that published the application
  • Workload Type(s) that the application has (Frontend, .NET [WCF] Services, Windows Services, Java Web Applications, Databases, Kubernetes)

Manage a Deployed Application Version

Clicking on the Version link of a deployed application on the Applications page takes you into the Application Details page for that particular application version. The left side of the details page shows some basic information about the application:

  • Version information (version name, version alias, and lifecycle stage)
  • Application information (application name and application alias)
  • Development Team that published the application version
  • Platform Services used by this application (Authentication, Authorization, and/or Multi-tenancy)
  • A link to view Custom Properties that are associated with this application version

The Workloads tab (the default tab) shows the currently deployed Workloads for this particular application version, their location, and, in the case of a .NET service or Windows Service, the Process ID. If Resource Throttling is enabled on the Platform, each Workload (except databases) will display the Resource Policy assigned to it, average CPU usage, and average memory usage.

Manage Frontend (User Interface) Workloads

The Version Details page allows for the management of individual Workloads. For Frontend Workloads, there are two actions that can be taken:

  • Undeploy - uninstall an instance of this version's website
  • Move - move the website to a different server. When moving a Frontend Workload, you can let the Platform choose a suitable server for you (based on role and resource allocation, as well as Cloud Affinity and Application Deployment Policy considerations) or choose it yourself. 

Note: Choosing a specific target with the "Let Me Choose a Server" option will cause the Platform to ignore any existing resource allocation, Cloud Affinity, or Application Deployment Policy restrictions to deploy to the target server you choose. In all cases where the Platform selects a deployment target, it will honor any appropriately configured rules and restrictions.

Manage a .NET Service, Windows Service, or Java Web Application Workload

The Version Details page allows for the management of individual Workloads. For .NET Service Workloads, Windows Service Workloads, and Java Web Applications, there are three actions that can be taken:

  • Stop
  • Undeploy - uninstall an instance of this deployed component.
  • Move - move the Workload to a different server. When moving a workload, you can let the Platform choose a suitable server for you (based on role and resource allocations) or choose it yourself.  Selecting a target yourself will cause any applicable deployment restrictions to be ignored
  • For .NET Service Workloads and Windows Service Workloads, you will also see an option to view that Workload's launchpad.

Manage Kubernetes Workloads

The Version Details page allows you to view details about a Kubernetes application and view the deployed instances of it on the container. Since Kubernetes handles host selection when deploying a workload from the Platform to the cluster, you are not able to move workloads that are deployed on the cluster through the SOC. You are only able to Undeploy a current workload the Workloads tab.

Deploy/Configure Application Components

The Components tab allows you to deploy instances of User Interface, .NET Service, Windows Service, Kubernetes and Java Web Application components to the Platform using the Deploy button located next to each application component:

For User Interface and Java Web Application components, you can configure Service Level Options for any new instances that get deployed in the future by clicking on the arrow and selecting the "Edit Service Level Options" item.

In the resulting window, the value set for Ensured Number of Running Instances (or "instance count") for the component indicates the number of instances the Platform will automatically maintain for the component. By default this value is based on settings configured for the component through the Developer Portal. Platform Operators can change this number by deploy or undeploying instances through the Components or Workloads tab respectively.

A desired instance count must be set for each version of an application, as new versions do not inherit values set for parent versions. In addition, an instance count set through the SOC will apply only to the application version while it remains in its current stage, and will not persist, for instance, if the version is promoted from the Sandbox to Published stage. 

Note that the number of attempts the Platform will attempt to deploy a component to recover a set instance count, as well as the timing for the initial and subsequent recover attempts, can be configured through the following settings in the Platform Registry Settings:

  • MinInstance.RecoveryAttempts
  • MinInstance.HostRecoveryDelayInSeconds
  • MinInstance.RecoveryPauseBetweenAttemptsInSeconds

You can choose to run instances of the user interface or Java Web Application component with credentials other than the Default Account Credentials by unchecking the relevant box and entering new credentials. The changes you make to credential settings will persist only until the application moves to another stage in its Lifecycle.

For .NET Service and Windows Service components, you can configure Service Level Options in the same way by clicking on the arrow and selecting the "Edit Service Level Options" item.

From this screen, you are able to view and set several different behaviors relating to service instance deployment:

  • The value set for Ensured Number of Running Instances (or "instance count") for indicates the number of instances the Platform will automatically maintain for the component. By default this value is based on settings configured for the component through the Developer Portal; however, Platform Operators can change this number by deploy or undeploying instances as described in the section above.
  • The Revivability and Location Affinity for the service can be enabled so that any attempts to restart its instances will be carried out on the same server that an instance resided on before it crashed.
  • You can choose to run instances of the service with credentials other than the Default Service Account Credentials by unchecking the box and entering new credentials.  The changes you make to credential settings will persist only until the application moves to another stage in its lifecycle.

Please note that Service Level Options for Windows Services include only Revivability and Location Affinity and Default Service Account options.

Viewing Custom Properties

The Components tab allows you to view, but not change, Custom Properties that are associated with an application component.  Please see the Custom Properties documentation for more information.

Custom Properties for applications and app components are set by the Development Team that owns the application (for more information, see here).  To view these properties, click on the arrow and select View Custom Properties:

Retrieve JMX Connection Information for Java Web Application Workloads

Developers can enable JMX monitoring for Java Web Application Workloads through the Developer Portal.  If JMX has been enabled for any of an application version's workloads, Connection, User, and Password information can be accessed from the Workloads tab by clicking on the Show JMX Info link in the upper right hand corner. 

User, Password, and Connection information will be listed in the columns that appear.  The SOC provides readonly (RO) AND readwrite (RW) information in the form of GUIDs under both the User and Password columns.  It should be noted that, although developers can access readonly credentials through the Developer Portal, they do not have access to readwrite credentials.  

Static JMX Connections

In addition to the JMX connections noted above, you have the ability to enable Static JMX Connection information. If the Platform is configured to host Static JMX Connections and an application has JMX enabled through the Developer Portal, the Static JMX Connection for that application component can be seen by navigating to the Workloads tab and clicking on the Show Static JMX Connections in the upper right corner. The default JMX Connection information described in the previous section will still be available for monitoring a specific application workload after Static JMX Connections are enabled.

The Username, Password and Static Connection details will appear in the Static JMX Connection modal. This connection is RO, and will be the same as the Static JMX Connection information shown to in the Development Portal for Developers with the Monitor JMX Resources securable

Forward-deploy Databases

The Storage tab displays information about an application version's structured storage partitions or internally-deployed databases:

Information displayed includes the storage Partition Name, the Partition Server (the name of the Oracle server on which the partition is currently hosted), the Storage Used by the partition, and the Tenants for which data is stored on the partition.

In Platform versions before 8.0.0, for Oracle 12c storage partitions only, the Update Connection buttons may be used to configure an application version to connect to an Off-Platform Oracle 12c server.

As of Platform version 8.0.0, you can update SQL Server and Oracle 12c storage partitions for an applicaiton to connection to an off-Platform server. This action is called forward-deploying a storage partition. See our storage parition page for more on this feature and utilizing forward-deployment for Platform DBaaS.

Start and Stop Maintenance for Tenants

When an application version is In Maintenance for a tenant, end user access to the application version through that tenant is temporarily suspended and users will be redirected to a Maintenance page when attempting to launch the application. When an application version is Online for a tenant, users may access the application through that tenant.

The Tenants tab enables to you manually place a tenant In Maintenance by clicking on the Start Maintenance button that corresponds to the desired tenant:

Clicking on the Stop Maintenance button will return the tenant to the Online state.

Although the controls above allow Platform Operators to manually start and stop maintenance, it should be noted that an application version for a tenant may enter the In Maintenance state as a result of events such as the following:

  • When a Development Team promotes a patched version of an application (e.g., version 2), the promotion of the patched version fails, and the database for one or more tenant fails to "rollback" to the previous version (e.g., version 1).
  • When a Platform Operator updates the connection information for an Oracle 12c storage partition through the Storage tab.

Create Platform Operator Overrides

In many cases the Platform Operator is able to override certain policy or developer settings by deploying or undeploying guest application workloads. You can undeploy from the Workloads tab and you can deploy from the Components tab of an application's Version Details page.

Platform Operators are able to deploy or undeploy a workload even if a scaling settings configured for the component in the Developer Portal will be violated. The Platform Operator will receive a confirmation message that indicates that a temporary override is created for the setting.

Note that only Developers have the ability to cancel the temporary override that you create. Furthermore, a desired instance count must be set for each version of an application, as new versions do not inherit values set for parent versions. In addition, an instance count set through the SOC will apply only to the application version while it remains in its current stage, and will not persist, if the version is promoted from the Sandbox to Published stage.

When deploying a new workload, Platform Operators also have to option to choose the server to host the new workload. If the Platform Operator chooses a server, the Platform will deploy the workload to the selected server without applying any Application Deployment Polices.