The following diagram illustrates the components of a VLA execution environment and the relationships between components:
Figure 1. VLA Execution Environment

The key components in this diagram are:
  • SAP Systems (managed SAP systems) – Each of these systems consist of software running on one or more machines that perform some business function, such as order processing, accounts payable, general ledger, inventory management, etc. Each SAP System consists of one or more components like a database service, SAP instance or SAP Host Agent service. When all of the components are up and running, the SAP System is running. When all of the components are stopped, the SAP system is stopped. If some systems are running and some are not, the SAP system is in an intermediate state.
  • The SAP LaMa — The SAP LaMa application runs on ABAP or Java stack in a Linux based guest OS. It provides a web-based user interface for SAP Basis administrators to create / destroy / configure / and otherwise operate on and provision SAP systems and their underlying machinery (bare metal or virtualized).

    SAP LaMa has an extensible architecture that allows SAP and third-party vendors (e.g., VMware) to create plugins to extend certain features.

    The VMware Adapter for SAP Landscape Management uses the Key Storage service of SAP NetWeaver to store trusted certificates. During installation, VMware Adapter for SAP Landscape Management creates an unsecure custom keystore view VMware-VASL. If some error with the mentioned view occurs during installation, the public view DEFAULT is used.

  • The VMware Adapter for SAP Landscape Management — This is a plugin to SAP LaMa that extends how SAP LaMa integrates with the underlying systems virtualized with VMware vSphere (see next bullet). This includes, optimizing and extending the functionality for certain operations, such as activating (powering on) and deactivating (powering off), copying and cloning systems, as well as automation of these copying and cloning operations.
    Note: Automation of copying and cloning SAP Systems involves the concept of a LaMa Provisioning Template (LPT), which is different from a VMware vSphere Template (see next bullet).
  • ESXi and vCenter Server (collectively called vSphere) — ESXi is VMware’s premier hypervisor product. VI administrators typically install it on server-class computers, with VMs running guest operating systems (OSes) with SAP Systems as applications within the guests. vCenter Server is VMware’s premier product for managing environments virtualized with ESXi. Collectively called vSphere, these products provide an enterprise-class environment with features for creating clusters, load balancing VMs between host systems (ESXi instances), fault tolerance, virtual networking, virtual storage, and more. In VLA environments, the VLA appliance (next bullet) runs in a VM on this infrastructure.

  • VMware vRealize Orchestrator™ — This VMware product helps VI administrators automate their environments by creating workflows (essentially scripts) that perform VI administrative actions, including complex actions that may take multiple steps, involve loops, conditions, etc. VMware vRealize Orchestrator workflows can handle exceptions automatically or can pause waiting for a VI administrator to mitigate an issue. See the next bullet for how VLA uses VMware vRealize Orchestrator.
  • VMware Landscape Management Appliance (VLA) — This part of the VLA product is a virtual appliance. It maintains connection with one or more vCenters, contains a repository of inventory data and user credentials, and executes operations at VMs, ESX hosts, datastores or networks by utilizing VMware vRealize Orchestrator. Collectively, it consists of one or more web services that accept commands from (previously discussed) LaMa VLA Adapter and/or SA-API clients and take appropriate actions to implement the commands, typically with the help of the (previously discussed) VMware vRealize Orchestrator. For example:
    • When an SAP Basis administrator activates (powers on) a SAP System via LaMa, the VLA Adapter sends commands to the vla-service (discussed later in this topic) to power on the underlying VMs. The vla-service in turn invokes a VLA-specific workflow on the VMware vRealize Orchestrator to turn on the VMs in the underlying vSphere infrastructure. An analogous action occurs when an SAP Basis administrator deactivates (powers off) an SAP System.
    • When an SAP Basis administrator copies a SAP System, the VLA Adapter sends commands to the vla-service. This in turn invokes a VLA-specific VMware vRealize Orchestrator workflow to create vSphere copies of the VMs on which the SAP systems reside, configuring the VMs according to the parameters provided by the SAP Basis administrator in the LaMa web user interface.

    • When a vCloud Director (vCD) script invokes the SA-API to power-on a business-critical application, the sa-api-service (discussed later in this topic) sends commands to VLA-service similar to those discussed in the first example in this list.
    The VLA Appliance contains several components, including:
    • A purpose-configured and hardened operating system (OS)
    • A minimalist set of OS utilities and VLA-specific programs and configuration files required to provide the functionality described here. These include:
      • The vla-service — A web service running in tomcat that receives and processes commands from the VLA Adapter. It also serves out the VLA dashboard web UI. By default, this server listens on port 8443.
      • Tomcat user database — Database with usernames / passwords used to authenticate access to that instance’s services. VI Administrators create an entry in the database for the VLA instance during deployment of the VLA environment using the vla_user command as detailed later in this document.
      • A credentials store to securely store credentials and certificated needed for the communication with infrastructure components in the environment. The credentials store is managed using the vla_credentials command as detailed later in this document.
      • sa_api-server — A web service running in tomcat that serves out the SA-API. This is also known to as the SA-API engine. The purpose of this API is the furtherance of VMware’s Software Defined Data Center (SDDC) strategy by allowing automating the management of business critical applications, such as SAP.