orkungedik/SAP-basis-dataset huggingface dataset:
## 3. Consider Special Features
## Accessing Parts of the /proc File System
The proc file system provides a lot of critical information about the system and its running processes. To learn more, read Exploring the Linux /proc file system and Important Linux /proc file system files you need to know . By default, container runtimes mask certain parts of the /proc file system from inside a container in order to prevent potential security issues.
##  Caution
You should change settings around the /proc file system only if you are aware of the impact. Changing the configuration may expose your system to security issues.
- Check if you really need to use the /proc file system. For example, if you want to use it for image building purposes, check the latest version of your build tool because many of them no longer need it.
- If you really need to use the /proc file system, only do so for a nested container. Never expose the /proc file system of your host system to a container.
- If your application needs access to parts of the /proc file system, you can set the procMount field in the PodSpec to unmasked to remove the restriction on the visibility of the /proc file system from inside the container.
## Seccomp
Seccomp is a Linux kernel feature that allows filtering system calls made by a process. It is used to restrict the set of system calls that a process can make.
If, in SecurityContext , the seccompProfile is set to RuntimeDefault, the container uses the default seccomp profile provided by the container runtime.
Read more to learn about:
- Allowed system calls in the default profile of containerd.
- The full list of Linux system calls .
- How to work with Seccomp profiles in Kubernetes - Restrict a Container's Syscalls with seccomp .
- How to se tup a Custom Seccomp Profile in Gardener.
## Host Namespaces
Host namespaces (Process ID namespace, Inter-Process Communication namespace, and network namespace) allow you to access shared information. You can also use host namespaces to elevate privileges. By removing namespaces from Pods, you reduce isolation and circumvent the protection models that containers are based on. It allows the processes in the Pod to perform tasks as if they were running natively on the host.
In the Pod spec, the following fields represent the host namespaces:
- hostPID : Process ID namespace
- hostIPC : Inter-Process Communication namespace
- hostNetwork : network namespace
The three fields are by default set to false and should remain so.
Usually, there is no need to remove this isolation and therefore, Pods should not have access to host namespaces.
##  Caution
Removing namespaces from Pods is a very advanced feature. Use it only if you are certain you need it, for example, for low-level observation of other containers.
## 7.6.2.2 Function Security
To eliminate potential security risks when using Functions, bear in mind these facts:
- By default, JSON Web Tokens (JWTs) issued by an OpenID Connect-compliant identity provider do not provide the scope parameter for Functions. This means that if you expose your Function and secure it with a JWT, you can use the token to validate access to all Functions within the cluster as well as other JWT-protected services.
- Kyma provides base images for serverless runtimes. Those default runtimes are maintained with regard to commonly known security advisories. It is possible to use a custom runtime image. For more information, see Override Runtime Image . In such a case, you are responsible for security compliance and assessment of exploitability of any potential vulnerabilities of the custom runtime image.
- Kyma does not run any security scans against Functions and their images. Before you store any sensitive data in Functions, consider the potential risk of data leakage.
- Kyma does not define any authorization policies that would restrict Functions' access to other resources within the namespace. If you deploy a Function in a given namespace, it can freely access all events and APIs of services within this namespace.
- Since Kubernetes is moving from PodSecurityPolicies to PodSecurity Admission Controller , Kyma Functions require running in namespaces with the baseline Pod security level. The restricted level is not currently supported due to the requirements of the Function building process.
- The Kyma Serverless components can run with the PodSecurity Admission Controller support within the restricted Pod security level when using an external registry. When the Internal Docker Registry is enabled, the Internal Registry DaemonSet requires elevated privileges to function correctly, exceeding the limitations of both the restricted and baseline levels.
- All administrators and regular users who have access to a specific namespace in a cluster can also access:
- Source code of all Functions within this namespace
- Internal Docker registry that contains Function images
- Secrets allowing the build Job to pull and push images from and to the Docker registry (in non-system namespaces)
## 7.6.3  Secure Administration and Operations in the Kyma Environment
Secure administration and operations focus on landscape setup, authentication, authorization, and Istio access logs. Learn about the security measures you can take to improve the security of your Kyma environment.
## Landscape Setup
While creating a staged development environment is a good idea in any case, there are some considerations specific to Kyma you might want to take into account. For more information, see Cloud Foundry, Kyma, or Both?.
## Authentication
SAP BTP, Kyma runtime uses OpenID Connect for authentication. Kyma runtime is configured to use a default shared SAP Cloud Identity Services tenant, SAP ID service, as an identity provider. This is a good starting point for development and testing purposes. However, for production scenarios, it is recommended to get your own SAP Cloud Identity Services tenant. For more information, see Authentication in the Kyma Environment [page 3297].
## Authorization
Kyma uses Kubernetes Role-Based Access Control (RBAC) and assures during provisioning that a user who creates and owns a particular runtime is given the cluster-admin role. Users with the cluster-admin role can define any additional cluster roles or use those defined in Kyma and bind them to other users from Kyma dashboard or with the kubectl CLI tool. See Assign Roles in the Kyma Environment [page 3301]. For recommendations on setting up roles and permissions in Kyma, see Role-Based Access Control (RBAC) in Kyma.
##  Note
For more information about user and member management in the SAP BTP cockpit, see User and Member Management [page 121].
## Istio Access Logs
Collecting Istio access logs can help indicate the core concepts of monitoring (latency, traffic, errors, and saturation) and capture critical aspects of system behavior. By Configuring Istio Access Logs [page 1801] you monitor and analyze the traffic in your Kyma cluster. Then, send the logs to a central platform, for example, a Security Information and Event Management (SIEM) system, for threat detection and incident response.
## Related Information
Kyma Security Concepts [page 3284]
Secure Development in the Kyma Environment [page 3290]
Authentication in the Kyma Environment [page 3297]
Configuring a Custom Identity Provider for Kyma [page 3299]
Assign Roles in the Kyma Environment [page 3301]
Auditing and Logging Information in Kyma [page 3304]
Deprecation Trial for Google's Third-Party Cookies [page 3306]
## 7.6.3.1 Authentication in the Kyma Environment
To authenticate in the Kyma environment, you can either use the default identity provider (IdP) or set up a custom identity provider.
## Default vs. Custom Identity Provider
SAP BTP, Kyma runtime uses OpenID Connect for authentication. Kyma runtime is configured with a default IdP: a shared SAP Cloud Identity Services tenant. This is a good starting point for development and testing
purposes. For production scenarios, it's recommended that you set up your own SAP Cloud Identity Services tenant which provides the following features:
- manages users
- manages user groups and binds cluster roles to the user groups instead of individual usernames in your Kyma runtime
- configures your own risk-based security measures, such as two-factor authentication, IP ranges, etc.
- delegates authentication to an upstream corporate IdP to prevent introducing redundant identities and to benefit from SSO, based on identity provided "centrally"
<!-- image -->
Learn how to Get Your Tenant from SAP Cloud Identity Services.
Alternatively, you can choose any other service compliant with OpenID Connect.
Having an SAP Cloud Identity Services tenant, you can configure it as the custom identity provider of your Kyma cluster. See Configuring a Custom Identity Provider for Kyma [page 3299].
## 3. Select Create .
## Results
Your Kyma environment is instantiated with a custom IdP.
## Related Information
```
Authentication in the Kyma Environment [page 3297] Custom OpenID Connect Configuration [page 3170] OpenID Connect (OIDC) [page 3151]
```
## 7.6.3.2 Assign Roles in the Kyma Environment
Kyma uses roles to manage access within the cluster, which give the assigned users the permissions suitable for their purposes.
## Prerequisites
The cluster-admin role is assigned to your account.
##  Note
After creating a Kyma cluster, you become an admin of this instance and the cluster-admin role is assigned to you by default. As the cluster-admin , you can assign roles to other users. Only the administrator who created the current subaccount can use the SAP BTP cockpit to assign the clusteradmin role to other members.
## Context
You can assign roles to a group of users only if you use a custom identity provider. Assigning roles in Kyma is based on the Kubernetes role-based access control (RBAC) . Y ou can see the list of available roles in Kyma dashboard when you create a Role Binding. Once you become the admin, your user name is read from the SAP BTP (RBAC) concept and is passed to the Kyma provisioner to be bound to the cluster-admin role in Kyma.
## Procedure
1. Log in to Kyma dashboard. The URL is in the Overview section of your subaccount.
2. In Kyma dashboard, select or create the namespace in which you want to assign roles.
3. To create a role binding, go to Configuration Role Bindings + Create Role Binding . Fill in the required fields:
- a. As Name , insert the name of your binding.
- b. As Role Type , choose ClusterRole .
- c. As Role , choose the required role from the list.
- d. As Kind , choose User .
- e. As User name , insert the user email address.
4. Select Create .
## Results
The users have the required permissions within the specified namespace. If the users don't have additional Cluster Role Binding to list the namespaces, they can still access the Kyma dashboard overview but must enter the required namespace name manually.
## Next Steps
If the permissions of the default role aren't sufficient, clone the role and add the missing resources.
## Related Information
Role-Based Access Control (RBAC) in Kyma
## 7.6.3.2.1 Overwrite Kyma Administrators
In some cases, you may need to overwrite usernames of the current administrators, for example, if they forget their password or leave the organization and nobody can access your Kyma runtime.
## Prerequisites
- You're the subaccount administrator.
## Context
To overwrite the names for the cluster-admin role, update the Kyma instance and provide a new value for the administrators field.
##  Caution
This procedure overwrites current administrators and shouldn't be used to add new ones. Treat it as an emergency self-service procedure in case of lost access. To provide access to new users, the clusteradmin should create a RoleBinding and/or a ClusterRoleBinding in the runtime. See RoleBinding and ClusterRoleBinding in the official Kubernetes documentation.
## Procedure
1. In the SAP BTP cockpit, go to your Kyma instance and select Update .
2. Provide a new set of administrators' usernames as an array of strings.
3. Click Update .
```
 Remember Use administrators' email addresses as their usernames. In a JSON file, use the following structure: "example_1@mail.com", "example_2@mail.com",
```
```
"administrators": [ "example_3@mail.com" ]
```
## Results
Your Kyma instance is updated with the new administrators' usernames.
## Related Information
Provisioning and Updating Parameters in the Kyma Environment [page 3138]
## 7.6.3.4 Deprecation Trial for Google's Third-Party Cookies
Google has announced its plan to phase out support for third-party cookies by the third quarter of 2024. See The Privacy Sandbox Timeline for the Web and Prepare for Third-Party Cookie Restrictions .
Third-party cookies are cookies that are set by domains other than the one a user is directly visiting. They are commonly used for online advertising and tracking user behavior across multiple websites. They can be set through JavaScript, iframe, embedded images, or media. SAP primarily uses third-party cookies for service management and single sign-on.
Google offers the third-party deprecation trial that allows re-enabling third-party cookies for a page embedded within a cross-site iframe until December 27, 2024. To enable the depreciation trial, all applications' responses must include a deprecation trial token obtained for each affected domain. At SAP, the process of obtaining the tokens is handled centrally.
There are three different ways to add the deprecation trial token - you can either provide it in an HTTP header, use a meta tag, or inject the token with JavaScript. For SAP BTP , Kyma runtime workloads, it is recommended that you use the HTTP header. You must add the token manually for each of the affected workloads.
## Technical Details
In SAP scenarios, the first request to the origin in a session typically requires cross-site cookies. Sending the Critical-Origin-Trial header in the HTTP response with the trial name Tcpd causes the browser to retry the request with third-party cookies enabled.
For SAP BTP, Kyma runtime, it is not possible to identify the initial request, so the Critical-Origin-Trial header is included in every response. This approach has been accepted by Google.
Each HTTP response must also include a valid depreciation trial token for the used domain in the following HTTP header:
```
Origin-Trial: <token-domain>
```
For domains specific to a particular customer, use the token(s) provided by that customer. For the domain ondemand.com managed by SAP, use the following token:
Avu6rn7emV5gK8gvyGHlX8TMqM9uo1FacP2j/RWTq+8j+yKnqcTO0TQh0bXJ/7QntxD4/ JzXv8aXoqxxZQuqXgYAAABdeyJvcmlnaW4iOiJodHRwczovL29uZGVtYW5kLmNvbTo0NDMiLCJmZWF0dX JlIjoiVHBjZCIsImV4cGlyeSI6MTczNTM0Mzk5OSwiaXNTdWJkb21haW4iOnRydWV9
The token consists of the feature name (Tpcd) and its source, along with other attributes. If an application or service can be accessed from multiple domains simultaneously, you can add one token per domain as a comma-separated list.
```
Origin-Trial: <token-domain1>, <token-domain2>, ...>
```
## Related Information
Apply Third-Party Cookie Deprecation Trial Tokens for Kyma Runtime Workloads [page 3308] Preparing and Testing Your Solution for Third-Party Cookie Deprecation
## 7.6.3.5 Verify Image Signatures in the Kyma Environment
Image signing and image signature verification are important countermeasures against security threats. They help you ensure the authenticity and integrity of the application you deploy in the runtime. You can be sure that what you deploy is what you have built in the build pipeline. While image signing happens in the automated Continuous Delivery (CD) workflow, image signature verification takes place at the time the workload is scheduled in the runtime. For this purpose, Kyma uses Warden, a mandatory security feature, which is added to your cluster by default and ensures that the Kyma workloads are authentic.
Warden is automatically enabled in the namespaces managed by Kyma, which can be identified by the operator.kyma-project.io/managed-by: kyma label. Therefore, you can be sure the Kyma-managed workloads are authentic. Use the kubectl get namespace -l operator.kyma-project.io/managedby=kyma command to list the Kyma system namespaces, protected by Warden.
##  Caution
When you enable third-party Kubernetes tools that mutate workloads (for example, Dynatrace that adds init containers), you must exclude the Kyma-managed namespaces, which are protected by Warden, from the tool config. Otherwise, Warden blocks unknown images. Mind that disrupting the Kyma-managed namespaces may lead to an inability to uphold the Service Level Agreement (SLA).
## 8 Getting Support
To get help, use the available support channels provided by SAP for Me.
##  Note
This section is applicable for all multicloud environments. To find which environments are available in your region, see Regions [page 17].
## Prerequisites
Before you report a case, ensure the following:
## Check Platform Status
- Running on the AWS, Azure, or GCP regions: visit SAP Trust Center . Y ou can check:
- availability by service on Cloud Status tab page;
- availability by region on the Data Center tab page.
- Running on the China (Shanghai) region: check https:/ /status.cn40.platform.sapcloud.cn/ .
- Running on the Government Cloud (US) region: planned downtimes and outage communication are sent through e-mail to the initial administrator of your global account.
## Check Tools Versions
Make sure that you have the latest versions of the tools you're using (recommended), or at least the versions you're using are still supported. For more information, see SAP Development Tools.
##  Note
Trial users can ask for support by posting a question in SAP Community . However, they should first check for answers in SAP Community and Guided Answers .
## Try Out Built-In Support Within SAP BTP Cockpit
When using SAP BTP cockpit as an S-user, try Built-In Support to get customer help within the cockpit. See Built-In Support.
## Learn the Best Practices and Offerings
Familiarize with the guidelines how to engage with support. See Support from SAP Best Practices &amp; Offerings .
## Procedure
To report a case in SAP for Me, proceed as follows:
1. Open SAP for Me and log on.
2. Open the Services &amp; Support dashboard.
3. (Optional) You can use the Knowledge Search tab for existing solutions in:
- SAP Notes &amp; KBAs
- SAP Community
- SAP Support Portal
- Product Documentation
- Guided Answers
4. Use the Get Support application within SAP for Me to get assistance via the available support channels. For more information about the specifics of each support channel and to learn how to report technical issues, see Get Support Application .
For any other non-technical assistance, see Customer Interaction Center .
## Creating a Support User
Sometimes you might need to create a support user to troubleshoot issues in your system. For more information about how and when to create a support user, see 3543065 - Best Practices for Creating Support Users in Your BTP System.
## Related Information
Users and Authorizations for SAP One Support Launchpad
Gather Support Information [page 3315]
Platform Updates and Notifications [page 3316]
Cloud Availability Center
Road Map for Cloud Foundry Environment
Road Map for Kyma Runtime
Road Map for ABAP Environment
## 8.2 Gather Support Information
The Eclipse tools come with a wizard for gathering support information in case you need help with a feature or operation (during deploying/debugging applications, logging, configurations, and so on).
## Context
The wizard collects the information in a ZIP file, which can be later sent to the support team. This way, the support developers can get better understanding of your environment and process the issue faster.
## Procedure
1. From the Eclipse IDE, choose Help Collect Support Information .
2. The launched wizard lists the default components to be collected, depending on the tools you've installed. If you need the support team to look at specific resources, expand the Additional Data section and select the relevant items.
<!-- image -->
##  Note
If you select Screenshot , your currently open Eclipse windows and views are snapped as a picture and added to the ZIP file. Make sure you don't reveal sensitive information.
3. In the File Name field, specify the ZIP file name and location.
4. Choose Finish .
## Next Steps
You can create a support ticket, attach the files to it, and send it to the corresponding support team. For more information, see Getting Support [page 3312].
## 8.4 Operating Model
An operating model clearly defines the separation of tasks between SAP and the customer during all phases of an integration project.
The environment and its services have been developed on the assumption that specific processes and tasks are the responsibility of the customer. The operating model contains all processes and tasks involved in operating the platform and the services and specifies how the responsibilities are divided between SAP and the customer for each individual task. It doesn't include the operation of systems and devices residing at operational facilities owned by the customer or any other third party, as these are the customer's responsibility.
Changes to the operating model defined for the services in scope are published using the What's New section of the platform. Customers and other interested parties must review the product documentation on a regular basis. If critical changes are made to the operating model, which require action on the customer side, an explicit notification is sent by e-mail to the affected customers.
It isn't the intent of this document to supplement or modify the contractual agreement between SAP and the customer for the purchase of any of the services in scope. In the event of a conflict, the contractual agreement between SAP and the customer as set out in the Order Form, the General Terms and Conditions, the supplemental terms and conditions, and any resources referenced by those documents always takes precedence over this document.
## Operating Model in the Cloud Foundry Environment [page 3318]
This operating model clearly defines the separation of tasks between SAP and the customer during all phases of a project.
## Operating Model in the Kyma Environment [page 3324]
This operating model clearly defines the separation of tasks between SAP and the customer during all phases of a project.
## Comparison between the Operating Models of Kyma and Cloud Foundry Runtimes [page 3332]
This operating model clearly defines the separation of tasks between SAP and the customer. It's relevant for all phases of a project for both environments.
## 1 SAP HANA Master Guide
This guide is the entry point for planning the installation of your SAP HANA system landscape.
This guide is organized as follows:
- What Is SAP HANA? A high-level definition of SAP HANA.
- SAP HANA Use Cases
A variety of use cases and scenarios that SAP HANA can be used in from an application point of view.
- SAP HANA Architecture Various aspects of the SAP HANA architecture from a technical point of view.
- SAP HANA Deployment Options An overview of the different deployment options for SAP HANA on-premise or in the cloud.
- SAP HANA Implementation and Operation
An overview of the implementation and operation activities during the lifecycle of SAP HANA. The individual steps depend on the chosen use case and the technical deployment.
- Additional Information A collection of additional information. This section includes information about important SAP Notes, the
SAP HANA license key, the software download, and hardware and software requirements for SAP HANA.
## 2 What Is SAP HANA?
SAP HANA is a modern, in-memory database and platform that is deployable on premise or in the cloud.
The SAP HANA platform is a flexible data source-agnostic in-memory data platform that allows you to analyze large volumes of data in real time. Using the database services of the SAP HANA platform, you can store and access data in-memory and column-based. SAP HANA allows online transaction processing (OLTP) and online analytical processing (OLAP) on one system, without the need for redundant data storage or aggregates. Using the application services of the SAP HANA platform, you can develop applications, run your custom applications built on SAP HANA, and manage their lifecycles.
For information about the capabilities available for your license and installation scenario, refer to the Feature Scope Description (FSD) for your specific SAP HANA version on the SAP HANA Platform webpage.
## 3 SAP HANA Use Cases
SAP HANA can be used in a variety of use cases and scenarios.
## 3.1 SAP HANA as Primary Persistence for SAP NetWeaverBased Applications
SAP Business Suite applications (ERP, CRM, SCM, and so on), SAP Business Warehouse (BW), and other SAP enterprise solutions are built on SAP's pervasive platform, SAP NetWeaver.
SAP NetWeaver has two distinct aspects: ABAP and Java. Many applications built on SAP NetWeaver's ABAP or Java application servers are able to run 'on' SAP HANA, where SAP HANA serves as the sole database in the architecture.
While the technical interfaces are available for applications built on SAP NetWeaver AS ABAP and AS Java to run on SAP HANA, specific development enablement is normally required for each application to ensure it runs optimally on SAP HANA. SAP Business Suite applications (ERP, CRM, SCM, and so on), SAP Business Warehouse (BW), and other SAP NetWeaver-based applications have been renovated to run on SAP HANA in a manner that exploits its many advantages. Additionally, various components and complimentary applications that are built on SAP NetWeaver can also run on SAP HANA through the use of the provided SAP NetWeaver DB interfaces.
<!-- image -->
## SAP HANA and SAP NetWeaver AS ABAP/Java on One Server
Deploying SAP HANA and SAP NetWeaver AS ABAP or SAP NetWeaver AS Java on one server is a multicomponent, resource-optimized, and cost-optimized deployment approach.
For more information, see SAP Note 1953429 - SAP HANA and SAP NetWeaver AS ABAP on one Server and SAP Note 2043509 - SAP HANA and SAP NetWeaver Java on a Single Host .
<!-- image -->
## Related Information
SAP Note 1953429 SAP Note 2043509 End-to-End Implementation Roadmap for SAP NetWeaver AS ABAP on SAP HANA End-to-End Implementation Roadmap for SAP NetWeaver AS Java on SAP HANA End-to-End Implementation Roadmap for SAP BW powered by SAP HANA
## 3.2 SAP HANA as Data Mart
A data mart is an industry term for a repository of data gathered from operational data originating in transactional systems (and/or other sources), designed to serve a particular community of information
workers by forming a basis for analytics, reporting, or a specific use in another type of application. The emphasis of a data mart is on meeting the specific needs of a particular group of users in terms of analysis, content, presentation, and ease-of-use.
With SAP HANA, operational data marts offer real-time analytics and reporting on data replicated from a transactional system's database. The raw tables themselves are copied (structure and data) from the transactional system's database into SAP HANA. As new data is added into the relevant tables in the transactional system's database, copies of those records are automatically transferred immediately into SAP HANA using replication technology. These replicated tables become the basis for specialized views that are created for analytics purposes. In some cases, the data modeling effort involved in developing these views may be significant, to convert raw transactional table data into a form that is best suited for analytics. Business Intelligence tools, such as the BI Tool Suite available from SAP BusinessObjects, are used for analysis and reporting.
## Real-time Operational Data Marts with an SAP Business Suite System
<!-- image -->
SAP Business Suite is a source system for operational data marts in SAP HANA. The SAP Landscape Transformation Replication Server (SLT) is an SAP NetWeaver ABAP-based tool that provides real-time data replication. In addition, a log-based SAP Replication Server (SRS) can also be used to provide real-time data replication for an SAP Business Suite system.
## Real-time Operational Data Marts with a non-SAP OLTP System
<!-- image -->
A non-SAP transactional source system is used as a basis for real-time operational data marts in SAP HANA. SAP Replication Server (SRS) refers to the SAP Replication Server application, which is a tool which provides real-time data replication.
## Agile Data Marts
<!-- image -->
Agile data marts are a type of data mart that offer analytics and reporting on data acquired from a transactional system. When deployed in SAP HANA, they may offer advantages of flexibility when compared to taking a more comprehensive approach to organizational information management, such as deploying data marts within the context of an Enterprise Data Warehouse.
## 3.3 SAP HANA-Based Accelerators
SAP HANA-based accelerators are types of applications or scenarios that extend the capabilities of business processes in SAP Business Suite systems by leveraging the performance and scalability advantages that SAP HANA provides. This is implemented by performing operations for certain parts of computing operations of designated business processes or reports.
The typical approach for accelerators involves replicating data for data-intensive operations that are often bottlenecks for the given operation in an SAP HANA table. A type of 'switch' is then set in the SAP Business Suite application to indicate that whenever these specified tables are read, the read operation will take place in SAP HANA using a secondary database connection.
<!-- image -->
## 3.4.1  SAP HANA Extended Application Services, Advanced Model
SAP HANA extended application services, advanced model, (XS advanced) provide a comprehensive platform for the development and execution of native data-intensive applications.
SAP HANA functions as a comprehensive platform for the development and execution of native data-intensive applications that run efficiently in SAP HANA, taking advantage of its in-memory architecture and parallel execution capabilities. Structured accordingly, applications can profit from the increased performance provided by SAP HANA due to the integration with the data source.
XS advanced is a polyglot application platform that supports several programming languages and execution environments, for example, Java and Node.js. The classic XS JavaScript (XSJS) is supported by a framework running in the Node.js run time.
In simple terms, XS advanced is basically the Cloud Foundry open-source Platform-as-a-Service (PaaS) with a number of tweaks and extensions provided by SAP. These SAP enhancements include amongst other things: an integration with the SAP HANA database, OData support, compatibility with XS classic model, and some additional features designed to improve application security. XS advanced also provides support for business applications that are composed of multiple micro-services, which are implemented as separate Cloud Foundry applications, which combined are also known as Multi-Target Applications (MTA). A multi-target application includes multiple so-called 'modules' which are the equivalent of Cloud Foundry applications.
## 3.4.2  SAP Web IDE for SAP HANA
SAP Web IDE for SAP HANA is a browser-based integrated development environment (IDE) for the development of SAP HANA-based applications comprised of web-based or mobile UIs, business logic, and extensive SAP HANA data models.
SAP Web IDE supports developers who use SAP HANA extended application services, advanced model (XS advanced), by providing a variety of tools, such as syntax-aware editors for code and SAP HANA artifacts, graphical editors for CDS data models and calculation views, as well as inspection, testing and debugging tools.
SAP Web IDE works in conjunction with the SAP HANA database explorer, the SAP HANA deployment infrastructure (HDI), the Application Lifecycle Management tools (ALM) and the XS advanced runtime platform.
## 3.5 SAP liveCache on SAP HANA
You can run SAP liveCache on SAP HANA, lowering total cost of ownership and taking advantage of SAP HANA features.
SAP liveCache is an in-memory object store technology that is used to speed up material planning scenarios in SAP Supply Chain Management (SCM). It is available as an add-on for SAP HANA.
As of S/4 HANA 1709 and S/4 HANA Cloud 1805, it can also be used for production planning scenarios in S/4 HANA Production Planning &amp; Detailed Scheduling (PP/DS).
There are a number of advantages to running SAP liveCache as part of SAP HANA:
- Only one database needs to be administered, which reduces setup and maintenance
- Backup and recovery is simplified:
- There is no longer a need for separate backups
- Inconsistencies that could arise from separate backups can be avoided.
- SAP liveCache can take advantage of existing SAP HANA capabilities like performance and high availability.
## Supported Scenarios
For SAP SCM, the SAP HANA database must run on a single host including SAP liveCache.
##  Note
There is no standalone SAP liveCache based on SAP HANA technology. This means that you cannot replace your standalone SAP liveCache based on MaxDB technology with a standalone SAP liveCache based on SAP HANA technology.
## Monitoring SAP liveCache in SAP HANA Studio
You can use both the DBACockpit for SAP HANA and the SAP HANA studio to monitor SAP liveCache. The following system views allow you to monitor run time information in the SAP HANA studio:
- M\_LIVECACHE\_CONTAINER\_STATISTICS
- M\_LIVECACHE\_CONTAINER\_STATISTICS\_RESET
- M\_LIVECACHE\_LOCKS
- M\_LIVECACHE\_LOCK\_STATISTICS
- M\_LIVECACHE\_LOCK\_STATISTICS\_RESET
- M\_LIVECACHE\_OMS\_VERSIONS
- M\_LIVECACHE\_PROCEDURE\_STATISTICS
- M\_LIVECACHE\_PROCEDURE\_STATISTICS\_RESET
- M\_LIVECACHE\_SCHEMA\_STATISTICS
- M\_LIVECACHE\_SCHEMA\_STATISTICS\_RESET
## System Copy
For detailed information on the procedure for copying an SAP Supply Chain Management system with SAP liveCache on SAP HANA see the Administrator's Guide for SAP SCM 7.0, Version for SAP HANA.
## Related Information
DBACockpit for SAP HANA Administrator's Guide for SAP SCM 7.0, Version for SAP HANA
## 4 SAP HANA Architecture
Various aspects are relevant to the SAP HANA architecture.
## 4.1 SAP HANA Platform Software Components
SAP HANA platform is composed of several components.
For information about the capabilities available for your license and installation scenario, refer to the Feature Scope Description (FSD) for your specific SAP HANA version on the SAP HANA Platform webpage.
The SAP HANA platform edition is the technical foundation of the SAP HANA platform and various SAP HANA editions. The SAP HANA platform edition comprises among others:
- SAP HANA Database
- SAP HANA Client
- SAP HANA Studio
- SAP HANA XS advanced runtime
- SAP HANA XS Engine
- SAP HANA Advanced Data Processing
- SAP HANA Spatial
- SAP HANA Graph
##  Note
For information about the feature capability of the SAP HANA server on Intel-based hardware platforms or on IBM Power servers, see SAP HANA Hardware and Software Requirements in the SAP HANA Master Guide .
## Related Information
SAP HANA Hardware and Software Requirements [page 71]
## 4.2 SAP HANA Technical Deployment Options
The technical deployment options determine how SAP HANA systems, hosts used for SAP HANA systems, and applications running on SAP HANA are deployed.
## 4.2.1  SAP HANA Tenant Databases
As of SAP HANA 2.0 Support Package Stack (SPS) 01, the SAP HANA system can only be installed or configured to be a tenant database system. A tenant database system contains one system database and can contain multiple tenant databases. A single-container system will be automatically converted to a tenant database system during the upgrade to SPS 01.
An SAP HANA system is capable of containing more than one tenant database.
A system always has exactly one system database, used for central system administration, and any number of tenant databases (including zero). An SAP HANA system is identified by a single system ID (SID). Databases are identified by a SID and a database name. From the administration perspective, there is a distinction between tasks performed at system level and those performed at database level. Database clients, such as the SAP HANA cockpit, connect to specific databases.
All the databases share the same installation of database system software, the same computing resources, and the same system administration. However, each database is self-contained and fully isolated with its own:
- Set of database users
- Database catalog
- Repository
- Persistence
- Backups
- Traces and logs
Although database objects such as schemas, tables, views, procedures, and so on are local to the database, cross-database SELECT queries are possible. This supports cross-application reporting, for example.
You have one system database and any number of tenant databases. Multiple applications run in different tenant databases. This deployment option can be used to replace existing MCOS on-premise scenarios.
##  Note
For more information, see Creating and Configuring Tenant Databases in the SAP HANA Administration Guide and the SAP HANA Tenant Databases Operations Guide .
## Related Information
SAP Note 2096000
SAP Note 2101244
SAP Note 2423367
## 4.2.2  Single Application on One SAP HANA System (SCOS)
A single application on one SAP HANA system is also known as Single Component on One System (SCOS).
To more readily describe the various other options for technical deployment, it is useful to first illustrate the simple, straightforward approach to deploying an application on an SAP HANA system. This will be useful for comparison purposes.
<!-- image -->
<!-- image -->
In this configuration, a single application runs in a single schema, in a single SAP HANA database as part of an SAP HANA system. This is a simple, straightforward scenario that is supported for all scenarios without restriction.
## 4.2.3  Multiple Applications on One SAP HANA System (MCOD)
Multiple applications on one SAP HANA system is also known as Multiple Components on One Database (MCOD).
The technical deployment type MCOD refers to the scenario where more than one application, scenario, or component runs on one SAP HANA system. This deployment type is available, with restrictions, for production SAP HANA systems.
<!-- image -->
## Related Information
SAP Note 1661202
SAP Note 1826100
SAP HANA Tenant Databases [page 19]
## 4.2.4  Multiple SAP HANA Systems on One Host (MCOS)
Multiple SAP HANA systems on one host are also known as Multiple Components on One System (MCOS).
SAP does support running multiple SAP HANA systems (SIDs) on a single production SAP HANA host. This is restricted to single-host / scale-up scenarios only. Keep in mind that multi-SID requires significant attention to various detailed tasks related to system administration and performance management.
Production support is restricted to SAP HANA SPS 09 or higher due to the availability of some resource management parameters (for example affinity). Be aware that running multi-SID on one SAP HANA host may impact performance of various types of operations, as contention for computing resources may occur (memory, cpu, i/o, ...).
SAP strongly recommends performing requisite testing in any project before going live; in general, stress/ volume testing is recommended in order to provide good indicators of expected performance. When operating a system that features a multi-SID deployment, SAP recommends to actively make use of the resource management features of SAP HANA (e.g. parameters controlling memory limits, and influencing utilization of CPU cores, etc.) in order to optimize performance.
<!-- image -->
## Related Information
<!-- image -->
## 4.2.5  SAP HANA System Types
The number of hosts in a SAP HANA system landscape determines the SAP HANA system type.
The host is the operating environment in which the SAP HANA database runs. The host provides all the resources and services (CPU, memory, network, and operating system) that the SAP HANA database requires. The host provides links to the installation directory, data directory, and log directory or to the storage itself. The storage needed for an installation does not have to be on the host. In particular, shared data storage is required for distributed systems.
An SAP HANA system can be configured as one of the following types:
- Single-host system - One SAP HANA instance on one host.
- Distributed system (multiple-host system) - Multiple SAP HANA instances distributed over multiple hosts, with one instance per host.
For more information about SAP HANA system types, see the SAP HANA Server Installation and Update Guide .
## 4.2.5.1 Single-Host System
If the system consists of only one host, it is called a single-host system.
The following graphic shows the file system for a single-host installation:
<!-- image -->
## 4.2.5.2 Distributed System (Multiple-Host System)
If the system consists of multiple connected hosts, it is called a distributed system.
The following graphic shows the file system for a distributed installation:
<!-- image -->
A distributed system might be necessary in the following cases:
- You can scale SAP HANA either by increasing RAM for a single server, or by adding hosts to the system to deal with larger workloads. This allows you to go beyond the limits of a single physical server.
- Distributed systems can be used for failover scenarios and to implement high availability. Individual hosts in a distributed system have different roles (master, worker, slave, and standby) depending on the task.
For more information about scaling, failover scenarios, and high availability, see the SAP HANA Administration Guide .
## 4.2.6  SAP HANA with Virtualization
The technical deployment type SAP HANA with Virtualization refers to the scenario where one or more SAP HANA database SIDs are deployed on one or more virtual machines running on SAP HANA server hardware.
<!-- image -->
For information about SAP HANA with virtualization, see:
- SAP Note 1788665 - SAP HANA Support for virtualized / partitioned (multi-tenant) environments
- Intel-Based Hardware Platforms - VMware
- SAP Note 2652670 - SAP HANA VM on VMware vSphere
- SAP Note 2024433 - Multiple SAP HANA VMs on VMware vSphere in production
- SAP Note 2157587 - SAP Business Warehouse, powered by SAP HANA on VMware vSphere in scaleout and production
- IBM Power Systems - IBM PowerVM SAP Note 2055470 - SAP HANA on POWER Planning and Installation Specifics - Central Note
For more information, see SAP HANA and Virtualization in SAP HANA Server Installation and Update Guide .
## Related Information
```
SAP and VMware Announce SAP HANA for Production Use on VMware vSphere 5.5 SAP on VMware SAP HANA virtualized - Overview SAP HANA Guidelines for being virtualized with VMware vSphere SAP Note 1788665 SAP Note 2652670 SAP Note 2055470 SAP Note 2024433 SAP Note 2157587
```
## 4.3 The SAP HANA Network
An SAP HANA data center deployment can range from a database running on a single host to a complex distributed system with multiple hosts located at a primary and one or more secondary sites, and supporting a distributed multi-terabyte database with full high availability and disaster recovery.
In terms of network connectivity, SAP HANA supports traditional database client connections and, with SAP HANA Extended Application Services (SAP HANA XS), Web-based clients. SAP HANA can be integrated with transaction-oriented databases using replication services, as well as with high-speed event sources. SAP HANA-based applications can be integrated with external services such as e-mail, Web, and R-code execution.
The setup of an SAP HANA system, and the corresponding data center and network configurations, depends on your company's environment and implementation considerations. Some of these considerations are:
- Support for traditional database clients, Web-based clients, and administrative connections
- The number of hosts used for the SAP HANA system, ranging from a single-host system to a complex distributed system with multiple hosts
- Support for high availability through the use of standby hosts, and support for disaster recovery through the use of multiple data centers
- Security and performance
SAP HANA has different types of network communication channels to support the different SAP HANA scenarios and setups:
- Channels used for external access to SAP HANA functionality by end-user clients, administration clients, application servers, and for data provisioning via SQL or HTTP
- Channels used for SAP HANA internal communication within the database or, in a distributed scenario, for communication between hosts
Before you start configuring the network for SAP HANA, it's important that you understand the different types of connections to, from, and within SAP HANA and which ports to configure for them. In addition, you should be familiar with the mechanisms used for assigning and resolving host names in SAP HANA. For more detailed information about the communication channels used in an SAP HANA landscape, as well as information about host name resolution, see the SAP HANA Administration Guide .
For information about troubleshooting the SAP HANA network, see the SAP HANA Troubleshooting and Performance Analysis Guide .
## Security
SAP HANA supports the isolation of internal communication from outside access. To separate external and internal communication, SAP HANA hosts use a separate network adapter with a separate IP address for each of the different networks. For IBM Power systems, this might be different. In addition, SAP HANA supports encrypted communication for network communication channels. For more information, see the SAP HANA Security Guide .
## Related Information
Network Zones [page 27]
## 4.3.1  Network Zones
Separate network zones, each with its own configuration, allow you to control and limit network access to SAP HANA to only those channels required for your scenarios, while ensuring the required communication between all components in the SAP HANA network.
These network zones can be basically described as follows:
- Client zone
The network in this zone is used by SAP application servers, by clients such as the SAP HANA studio or Web applications running against the SAP HANA XS server, and by other data sources such as SAP Business Warehouse.
- Internal zone
This zone covers the interhost network between hosts in a distributed system as well as the SAP HANA system replication network.
- Storage zone
This zone refers to the network connections for backup storage and enterprise storage. In most cases, the preferred storage solution involves separate, externally attached storage subsystem devices that are capable of providing dynamic mount-points for the different hosts, according to the overall landscape. A storage area network (SAN) can also be used for storage connectivity - for example, when running SAP HANA on IBM Power.
<!-- image -->
## Related Information
SAP HANA - Storage Requirements
FAQ - SAP HANA Tailored Data Center Integration FAQ
## 5 SAP HANA Deployment Options
SAP HANA is a modern, in-memory database and platform that is deployable on-premise or in the cloud.