orkungedik/SAP-basis-dataset huggingface dataset:
## 4.1.3.4.3.2  Create User-Provided Service Instances Using the Cloud Foundry Command Line Interface
Use the Cloud Foundry Command Line Interface to make a user-provided service instance available to Cloud Foundry applications.
## Prerequisites
- Download and install the cf CLI and log on to Cloud Foundry. For more information, see Download and Install the Cloud Foundry Command Line Interface [page 2533] and Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534].
- Obtain a URL, port, user name, and password for communicating with a service that is not available in the marketplace.
## Context
For more informaton on user-provided service instances, see https:/ /docs.cloudfoundry.org/devguide/ services/user-provided.html .
## Procedure
Open a command line and enter the following string to create a user-provided service instance:
```
cf create-user-provided-service SERVICE_INSTANCE [-p CREDENTIALS]
```
Specify the following parameters:
- SERVICE\_INSTANCE : The new name for your service instance.
- CREDENTIALS : Credentials as JSON
## Next Steps
To bind your application to the user-provided service instance, follow the steps described in Bind Service Instances to Applications Using the Cloud Foundry Command Line Interface [page 258].
## Related Information
Creating Service Instances [page 254]
```
Creating Service Keys [page 259] About Services [page 253]
```
## 4.1.3.4.4 Binding Service Instances to Applications
Use the SAP BTP cockpit or the Cloud Foundry Command Line Interface to bind service instances to applications:
- Bind Service Instances to Applications Using the Cockpit [page 258]
- Bind Service Instances to Applications Using the Cloud Foundry Command Line Interface [page 258]
You can also bind service instances by declaring them as part of your multitarget application (MTA). To learn how to do that, have a look at the service binding parameters.
- Service Binding Parameters [page 680]
## 4.1.3.4.4.1  Bind Service Instances to Applications Using the Cockpit
##  Note
The content of this page has moved to a new location.
To learn how to bind service instances to applications using the cockpit, see Binding Service Instances to Cloud Foundry Applications.
## 4.1.3.4.4.2  Bind Service Instances to Applications Using the Cloud Foundry Command Line Interface
You can bind service instances to applications using the Cloud Foundry Command Line Interface (cf CLI).
## Prerequisites
- Download and install the cf CLI and log on to Cloud Foundry. For more information, see Download and Install the Cloud Foundry Command Line Interface [page 2533] and Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534].
- Deploy an application in the same space in which you plan to create the service instance. For more information, see Deploy Business Applications in the Cloud Foundry Environment [page 742].
- Create a service instance. For more information, see Create Service Instances Using the Cloud Foundry Command Line Interface [page 255].
## Procedure
Open a command line and enter the following string:
cf bind-service APP-NAME SERVICE\_INSTANCE [-c PARAMETERS\_AS\_JSON]
Specify the following parameters:
- APP\_NAME : Name of the application.
- SERVICE\_INSTANCE : Name of the service instance.
- -c : (Optional) Provide service-specific configuration parameters either in a valid JSON object in-line or in a parameters file. This file reference can be an absolute or relative path to a file.
## Related Information
```
Creating Service Instances [page 254] Creating Service Keys [page 259] About Services [page 253]
```
## 4.1.3.4.5 Creating Service Keys
You can use service keys to generate credentials to communicate directly with a service instance. Once you configure them for your service, local clients, apps in other spaces, or entities outside your deployment can access your service with these keys.
You can use the SAP BTP cockpit or the Cloud Foundry Command Line Interface to create service keys:
- Creating Service Keys Using the Cockpit
- Create Service Keys Using the Cloud Foundry Command Line Interface [page 259]
For more information on service keys, see https:/ /docs.cloudfoundry.org/devguide/services/servicekeys.html .
## 4.1.3.4.5.1  Create Service Keys Using the Cockpit
##  Note
The content of this page has moved to a new location.
To learn how to create service keys using the cockpit, see Creating Service Keys in Cloud Foundry.
## 4.1.3.4.5.2  Create Service Keys Using the Cloud Foundry Command Line Interface
Use the Cloud Foundry Command Line Interface to create a service key.
## Prerequisites
- Download and install the cf CLI and log on to Cloud Foundry. For more information, see Download and Install the Cloud Foundry Command Line Interface [page 2533] and Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534].
- Create a service instance. For more information, see Create Service Instances Using the Cloud Foundry Command Line Interface [page 255].
## Procedure
Run the following command to create a service key:
cf create-service-key SERVICE\_INSTANCE SERVICE\_KEY [-c PARAMETERS\_AS\_JSON]
Specify the following parameters:
- SERVICE\_INSTANCE : Name of the service instance.
- SERVICE\_KEY : Name for the service key.
- -c : (Optional) Provide service-specific configuration parameters either in a valid JSON object in-line or in a parameters file. This file reference can be an absolute or relative path to a file.
## Results
Local clients, apps in other spaces, or entities outside your deployment can now access your service instance with this key.
## Related Information
Creating Service Instances [page 254]
Binding Service Instances to Applications [page 257] About Services [page 253]
## 4.1.3.4.6 Deleting Service Instances
Use the SAP BTP cockpit or the Cloud Foundry Command Line Interface to delete service instances:
##  Caution
Be aware that instances will be deleted ultimately. There is no way to revoke this step.
- Delete Service Instances Using the Cockpit [page 261]
- Delete Service Instances Using the Cloud Foundry Command Line Interface [page 261]
You can also delete service instances using the Multitarget Application plug-in for the Cloud Foundry command line interface. This works with the command deploy , bg-deploy , and undeploy with specifying the --deleteservices option. To learn how to do that, have a look at the multitarget application commands.
- Multitarget Application Commands for the Cloud Foundry Environment [page 2554]
## 4.1.3.4.6.1  Delete Service Instances Using the Cockpit
##  Note
The content of this page has moved to a new location.
To learn how to delete service instances using the cockpit, see Deleting Service Instances.
## 4.1.3.4.6.2  Delete Service Instances Using the Cloud Foundry Command Line Interface
You can use the Cloud Foundry Command Line Interface (cf CLI) to delete service instances.
## Prerequisites
- Download and install the cf CLI and log on to Cloud Foundry. For more information, see Download and Install the Cloud Foundry Command Line Interface [page 2533] and Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534].
## Procedure
1. Open a command line and log in.
2. (Optional) List all services and bound apps in your org:
```
cf l -a <API endpoint>
```
cf services
3. Unbind the service from any application.
cf unbind-service APP\_NAME SERVICE\_INSTANCE
4. (Optional) List all service keys for your service instance.
cf service-keys SERVICE\_INSTANCE
5. Delete any service key from the service instance.
6. Run the following command to delete a service instance:
```
cf delete-service-key SERVICE_INSTANCE SERVICE_KEY
```
cf delete-service SERVICE\_INSTANCE
Specify the following parameters:
- SERVICE\_INSTANCE : The name of your service instance.
- APP\_NAME : The name of an application your service instance is connected to.
- SERVICE\_KEY : The name of the service key of your service instance.
## Related Information
About Services [page 253]
Deleting Service Instances [page 260]
## 4.1.3.4.7 Updating Service Instances
Use the Cloud Foundry Command Line Interface to update service instances:
- Update Service Instances Using the SAP BTP Cockpit or Cloud Foundry Command Line Interface [page 262]
You can also update service instances inside a multitarget application if the service broker supports updates. Change the deployment descriptor file or a configuration file for a service instance inside your multitarget application and deploy your application to trigger an update of the respective service instance.
## 4.1.3.4.7.1  Update Service Instances Using the SAP BTP Cockpit or Cloud Foundry Command Line Interface
##  Note
We have redesigned SAP BTP cockpit screens to view and manage service instances.
For more information about the procedure to update service instances using the cockpit, see Updating Service Instances.
To learn how to update service instances using the Cloud Foundry Command Line Interface, continue reading this document.
Use Cloud Foundry Command Line Interface to update service instances:
## Prerequisites
- Download and install the cf CLI and log on to Cloud Foundry.
For more information, see Download and Install the Cloud Foundry Command Line Interface [page 2533] and Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534].
## Context
You are using a service instance, for which you want to change the plan or the service-specific configuration.
## Procedure
1. (Optional) Open a command line and enter the following string to list all services in your space:
2. (Optional) Enter the following string to list the details of your service:
3. Run the following command to update your service instance:
```
cf services
```
```
cf service SERVICE_INSTANCE
```
```
cf update-service SERVICE_INSTANCE [-p NEW_PLAN] [-c PARAMETERS_AS_JSON] [-t TAGS]
```
Specify the following parameters:
- SERVICE\_INSTANCE : The name of your service instance as shown when executing cf services .
## 4.1.3.4.8 Boosters
Boosters are a set of guided interactive steps that enable you to select, configure, and consume services on SAP BTP to achieve a specific technical goal.
You can access them directly from your desired global account in the SAP BTP cockpit, by choosing Boosters in the navigation menu. This leads to a page where you can find an overview of all available boosters, grouped by capability. From this overview page, you can get quick information about a booster, start a booster, or choose a tile to access the booster details.
## Booster Details
The details of boosters are organized in 3 tabs:
## · Overview
Here, you can get information about what the booster does, its key features and how that particular booster can help you.
## · Components
Here, you can see all the components that are required for the booster to run.
## · Additional Resources
Here, you find a list of additional information resources where you can learn more about the concepts and components mentioned in the booster.
Boosters automate processes and always achieve a technical goal, often in the form of an artifact. Artifacts are entities that you develop which may consume technical components (for example, services). Examples of artifacts include applications, content for integration and workflows, or even documents.
When you start a booster, a wizard opens up which guides you through a set of steps. Following these steps enables you to reach the result described in the booster overview.
## Related Information
Create a Subaccount [page 2249] Navigate in the Cockpit [page 2207] Create Spaces [page 2520]
## 4.1.3.5 Development Languages
Learn about the development languages and buildpacks supported in the SAP BTP, Cloud Foundry environment.
The polylglot nature of SAP BTP means that you have the freedom to choose between various development languages. While we do recommend using Java and Node.js for most use cases, you're free to use the language that best suits your development needs.
To find more information on the three main languages supported by SAP, follow the links below:
- Developing Java in the Cloud Foundry Environment [page 265]
- Developing Node.js in the Cloud Foundry Environment [page 365]
- Developing Python in the Cloud Foundry Environment [page 378]
##  Note
Please be informed that the SAP BTP, Cloud Foundry runtime Cloud Service is an open Platform-as-aService targeted at microservice development and orchestration. SAP is a member of the Cloud Foundry Foundation, which provides Cloud Foundry, a model for cloud-native application delivery. SAP allows use of certain, publicly available, system buildpacks that are supported by the Cloud Service. However, SAP is not in possession or control of, and cannot be responsible for the content, operation, or use of system buildpacks that are not part of the Cloud Service (including SAP Business Technology Platform).
SAP may, without notice, remove any system buildpacks at any time and at SAP's own discretion.
## Tutorials
Tutorial Navigator: Build an Application in the Cloud Foundry Runtime
## Guided Answers
Find solutions to some Java, Python and Node.js issues in the troubleshooting section: Troubleshooting [page 383]
## Related Information
Best Practices [page 240]
## 4.1.3.5.1 Developing Java in the Cloud Foundry Environment
Find selected information for Java development on SAP BTP, Cloud Foundry and references to more detailed sources.
## Usage
To use a buildpack, specify its name when deploying a Java application to SAP BTP, Cloud Foundry. For example:
```
cf push -f <PATH_TO_APP_MANIFEST> -b sap_java_buildpack_jakarta cf push -f <PATH_TO_APP_MANIFEST> -b sap_java_buildpack cf push -f <PATH_TO_APP_MANIFEST> -b java_buildpack
```
You can also use the buildpack or buildpacks attribute to specify it in the manifest.yml file:
```
---applications: - name: <APP_NAME> buildpacks: - sap_java_buildpack_jakarta ...
```
or in the mtad.yml file of your archive:
```
... modules: - name: <APP_NAME> type: java.tomcat path: <path_to_archive> properties: ... parameters: ... memory: 512M buildpack: sap_java_buildpack_jakarta ...
```
## What's New
To check the latest news and updates about SAP Java Buildpack, go to its release notes: What's New for SAP Java Buildpack
## Troubleshooting
If you encounter an issue while using SAP Java Buildpack, you can create an incident for your specific problem, using support component BC-CP-CF-BLDP .
## Related Information
Buildpacks [page 266]
```
Customizing the JVM Settings [page 295] Logging and Tracing [page 324] Debugging Java Applications [page 330] Bill of Materials (BOM) [page 364]
```
## 4.1.3.5.1.1  Buildpacks
You can choose to deploy applications by using the following Java buildpacks:
- SAP Java Buildpack 1 [page 267] - an SAP-managed buildpack that supports Java 8, 11, 17, TomEE 7 and Tomcat 9
- SAP Java Buildpack 2 [page 274] - an SAP-managed buildpack that supports Java 17, 21, TomEE 10 and Tomcat 10
- Community Java Buildpack [page 278] - an open-source product maintained by the java-buildpack community
## 4.1.3.5.1.1.3  Community Java Buildpack
Find SAP-managed Cloud Foundry Java components and updates that belong to the community javabuildpack .
## Buildpack Versioning
The SAP BTP, Cloud Foundry environment provides one recent version of java\_buildpack as part of its system buildpacks. To check this version, proceed as follows:
1. Log in to a particular SAP BTP region and subaccount. For example, if your region is eu10 , run:
2. Then run:
```
cf api https://api.cf.eu10.hana.ondemand.com
```
```
cf buildpacks
```
To learn about changes in the Java buildpack's versions and features, regularly check the latest buildpack releases in the GitHub community page.
## Updates
- SapMachine - as of v4.55 of the java-buildpack , SAP provides SapMachine 11 and 17 instead of OpenJDK 11 and 17 in the offline java\_buildpack .
```
See SAP Note: 3261748 SapMachine is replacing OpenJDK 11 & 17 in java_buildpack
```
## 4.1.3.5.1.2  Runtimes and Containers
Find out which application runtimes and containers you can use, depending on the Java buildpack your application is using.
- TomEE 7 [page 279] - use this runtime only with SAP Java Buildpack 1
- TomEE 10 [page 282] - use this runtime only with SAP Java Buildpack 2
- Tomcat 9 [page 286] - use this runtime only with SAP Java Buildpack 1
- Tomcat 10 [page 289] - use this runtime only with SAP Java Buildpack 2
- Java Main [page 293] - use the Java Main container with all Java buildpacks
## Related Information
Buildpacks [page 266]
## 4.1.3.5.1.3  Customizing the Java Virtual Machine (JVM) Settings
- Java Options [page 296]
- Java Memory Assistant [AWS, Azure, or GCP Regions] [page 297]
- Out-Of-Memory Behavior [page 297]
- Using an Agent [page 301]
- SapMachine [page 301]
- Memory Calculator [page 306]
## 4.1.3.5.1.3.1  Java Options
You can configure the Java properties by defining the JBP\_CONFIG\_JAVA\_OPTS environment variable.
Defining the JBP\_CONFIG\_JAVA\_OPTS environment variable in the manifest.yml file of the application.
<!-- image -->
Defining the JBP\_CONFIG\_JAVA\_OPTS environment variable by using the cf set-env command of the Cloud Foundry Command Line Interface (cf CLI).
```
cf set-env myapp JBP_CONFIG_JAVA_OPTS "[java_opts: '-DtestJBPConfig=^%PATH^% -DtestJBPConfig1=\"test test\" -DtestJBPConfig2=\"^%PATH^%\"']"
```
## Escaping Strings
## When defining the JBP\_CONFIG\_JAVA\_OPTS in the manifest.yml file
A single quote ' is used to enclose the JBP\_CONFIG\_JAVA\_OPTS environment variable in the manifest.yml file. Strings containing the following characters must be quoted: : , { , } , [ , ] , , , &amp; , * , # , ? , | , - , &lt; , &gt; , = , ! , % , @ , \ .
When a single quote
'
is used, other single quotes
' in the string must be escaped by doubling it '' .
When defining the JBP\_CONFIG\_JAVA\_OPTS by using the cf set-env command
The string must be enclosed in the double quotes " escape them using the backslash \ .
. If there are other double quotes in the string, you have
When defining java options with values containing spaces
In case you need to specify a option value, which has blank spaces in it, you need to surround it with quotes " . If the value contains special characters like for example $ , you have to escape them using the escape character specific for the operating system shell where the application is pushed. In the example below the $ in the $PATH string is escaped using the \ escape character for Linux. Otherwise, if the $ sign is not escaped, the value of the variable PATH is substituted in the property value.
<!-- image -->
## 4.1.3.5.1.3.2  Java Memory Assistant [AWS, Azure, or GCP Regions]
##  Note
The content in this section is not relevant for China (Shanghai) and Government Cloud (US) regions.
Java Memory Assistant is a Java agent that generates heap dumps based on preconfigured conditions in the memory usage of the application. See: Java Memory Assistant
##  Note
This public repository went out of maintenance on Sept 21, 2023 . Nevertheless, its latest version 0.5.0 is working fine so you can keep using it.
When enabled in the buildpack, the agent generates two files *.hprof (heap dump) and *.addons , when the configured memory limits are met.
The *.addons file contains:
- Command-line parameters
- Implemented interfaces for the classes
- Information (name) about transient fields for the classes
- Class and metaspace statistics
- Stack traces of the last OOM errors
See also: Java Memory Assistant Framework
## 4.1.3.5.1.3.3  Out-Of-Memory Behavior
SAP Java Buildpack prints a histogram of the heap memory to the logs when the JVM encounters a terminal failure.
<!-- image -->
This functionality is activated by default.
If you want to deactivate it, add property -XX:+ExitVMOnOutOfMemoryError through the JBP\_CONFIG\_JAVA\_OPTS property in the application's manifest.yml file, like this:
```
---applications: - name: <APP_NAME> buildpacks: - sap_java_buildpack_jakarta env: JBP_CONFIG_JAVA_OPTS: 'false, java_opts: ''-XX:+ExitVMOnOutOfMemoryError''' ...
```
## Killing a process with jvmkill
SAP Java Buildpack allows you to set jvmkill agent when staging your application. A jvmkill agent is added by default to the properties when starting the Java application process. The following configuration is added:
```
-agentpath:META-INF/.sap_java_buildpack/jvm_kill/jvmkill-<jvmkill_version>.RELEASE-trusty.so=printHeapHistogram=1
```
This is sufficient to print a histogram and kill the process when an out-of-memory (OOM) error occurs.
If you want to disable jvmkill and omit its agent being added to the startup properties, use the SJB\_NO\_JVMKILL environment variable, like this:
```
env: SJB_NO_JVMKILL: true
```
## Generate Heap Dumps with Java Properties
It's a good practice to generate a .hprof heap dump file on the event of OutOfMemoryError to analyze and find the root cause of the issue.
Various distributions including SapMachineJre and SapMachineJdk provide standard mechanism for generating a heap dump in the event of an OOM error. The following properties can be added on startup for this purpose:
```
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<heap_dump_path> -XX:OnOutOfMemoryError='kill -9 %p'
```
- -XX:+HeapDumpOnOutOfMemoryError triggers heap dump generation under a default path.
- -XX:HeapDumpPath specifies where to specify the heap dump file.
- -XX:OnOutOfMemoryError specifies what command or script to be run if OOM occurs. This command usually kills the process.
The heap dump is generated and stored in an application container location. This means, it will be removed once the application instance container is restarted.
##  Note
Killing the process will trigger a restart. Therefore, if you need to investigate further in the heap dump file stored in the application container, the process should not be killed.
## Related Information
ActiveProcessorCount [page 300]
Cloud Foundry: jvmkill
Development
## 4.1.3.5.1.3.4  ActiveProcessorCount
This JVM option overrides the number of CPUs which the virtual machine uses to calculate the size of thread pools for operations (such as garbage collection).
##  Note
Previously, SAP Java Buildpack used to set JVM option "-XX:+UseContainerCpuShares" but it's now replaced by "-XX:ActiveProcessorCount=&lt;value&gt;" .
The ActiveProcessorCount flag prevents out-of-memory (OOM) errors in case a GC algorithm with high internal memory usage has been activated by the JVM in relatively small containers (&lt; 4GB). Larger containers (&gt;4GB) benefit from a higher ActiveProcessorCount value.
SAP Java Buildpack automatically sets the JVM option "-XX:ActiveProcessorCount=&lt;value&gt;" , where &lt;value&gt; is defined as follows:
- For container instances &lt; 4GB, the ActiveProcessorCount is set to 1 .
- For container instances &gt;= 4GB, the ActiveProcessorCount is set to 1 CPU per 1GB of container memory. For example, if a container instance is 7GB, the value will be set to 7 .
If you want to explicitly set the value of ActiveProcessorCount , you can do that through the JBP\_CONFIG\_JAVA\_OPTS property in the application's manifest.yml file.
- For SAP Java Buildpack 1:
- For SAP Java Buildpack 2:
```
---applications: - name: <APP_NAME> buildpacks: - sap_java_buildpack env: JBP_CONFIG_JAVA_OPTS: 'java_opts: ''-XX:ActiveProcessorCount=7''' ...
```
```
---applications: - name: <APP_NAME> buildpacks: - sap_java_buildpack_jakarta env: JBP_CONFIG_JAVA_OPTS: 'java_opts: ''-XX:ActiveProcessorCount=7''' ...
```
## Related Information
Out-Of-Memory Behavior [page 297]
## 4.1.3.5.1.3.5  Using an Agent
SAP Java Buildpack can work with any Java agent as long as it's included in the .jar or .war archive of your application.
The buildpack extracts the agent when the application is deployed. To check if the agent is extracted to the expected location, run:
```
cf ssh
```
To use an agent with SAP Java Buildpack, set the &lt;JBP\_CONFIG\_JAVA\_OPTS&gt; environment variable as follows:
```
env: JBP_CONFIG_JAVA_OPTS: 'java_opts: "-javaagent:<PathToYourAgent>"'
```
The Java agent is platform-agnostic, but must be compatible with the version of the JVM you are using (SAP JVM or SapMachine).
## Native Agents
A native agent is a dynamic library. If you want to use one, it must be compatible with the architecture of the platform. For Cloud Foundry, this is Linux x86\_64. As an application developer, make sure that the correct agent is used, and regularly apply updates whenever they're needed.
To use a native agent, set the &lt;JBP\_CONFIG\_JAVA\_OPTS&gt; environment variable as follows:
```
env: JBP_CONFIG_JAVA_OPTS: 'java_opts: "-agentpath:<PathToYourAgent>"'
```
## 4.1.3.5.1.3.7  Memory Calculator
The memory calculator provides a mechanism to fine-tune the Java Virtual Machine (JVM) memory for an application. Its goal is to ensure that applications perform well while not exceeding a container's memory limit.
Below you can find which memory calculators are used in the relevant Java buildpacks.
## SAP Java Buildpack 1
This buildpack supports two memory calculator versions:
- Memory Calculator V2 [page 307] - activated by default.
- Memory Calculator V1 (SAP JVM Memory Calculator) [page 312] - this is an optional memory calculator. You can activate it by adding the following environment variable:
```
---applications: - name: <app-name> ... env: MEMORY_CALCULATOR_V1: true ...
```
## SAP Java Buildpack 2
This buildpack supports only Memory Calculator V2 [page 307], which is the same as the one provided by the community Java Buildpack. See: (GitHub) Java Buildpack Memory Calculator
<!-- image -->
##  Restriction
Memory Calculator V1 is only available for SAP Java Buildpack 1 [page 267].
If you try to activate it for SAP Java Buildpack 2 [page 274], an error will be thrown.
## Community Java Buildpack
This buildpack uses its default and only memory calculator: (GitHub) Java Buildpack Memory Calculator
## Related Information
Buildpacks [page 266]
## 4.1.3.5.1.4  Overriding Resources in Droplet
Applications can override resources in the droplet by placing directory files that have the same relative path as the droplet root.
The following example shows how an application can override the default Tomcat's server.xml file in directory META-INF/sap\_java\_buildpack/resources/ .
## Example
1. You have the following file structure in your Java application:
META-INF/
```
- sap_java_buildpack/ - resources/ - tomcat/ - conf/ - server.xml/ WEB-INF/
```
2. After the application is built and deployed, this will result in the following file structure in the droplet:
3. When the Tomcat container is started, the content of the server.xml file will come from the application.
```
META-INF/ - tomcat - conf/ - server.xml
```
```
- .sap_java_buildpack/ WEB-INF/
```
This mechanism also allows adding new resources inside the droplet in their respective places, based on where the files are located under META-INF/sap\_java\_buildpack/resources/ .

Tip
The overriding principle is applicable for both sap\_java\_buildpack and sap\_java\_buildpack\_jakarta .
## Related Information
Resource Configuration [page 318]
```
Cloud Foundry component glossary
```
## 4.1.3.5.1.5  Resource Configuration
You can configure your application container [page 278] by using text configuration files.
For example:
- conf/tomee7.xml
- conf/tomee.xml
- conf/server.xml
- conf/logging.properties
Resource configuration feature of SAP Java Buildpack provides means for changing parameterized values in all text files (part of the application container or part of the application files) during staging.
Files can contain multiple key-value pairs containing placeholders, marked as ${propname} . T o prevent undesired modifications, all files that can be changed must be explicitly listed by the application in a corresponding resource\_configuration.yml file, along with the default values for all placeholders.
## Template for resource\_configuration.yml
```
---filepath1: key1: value1 key2: value2 filepath2: key1: value1
```
Depending on the SAP Java Buidlpack version (1 or 2), the filepath1 must start with either tomcat , tomee , or tomee7 to match the used application container, and should contain a subpath to a resource.
- When changing parameterized values inside application files, the file path should look like this: &lt;application\_container&gt;/webapps/ROOT/&lt;path\_to\_file\_relative\_to\_application\_root&gt;
- When changing parameterized values in the configuration of an application container, the file path should look like this:
&lt;application\_container&gt;/conf/&lt;path\_to\_config\_file&gt;
## Example 1
You can create a resource\_configuration.yml with the following content:
```
tomcat/webapps/ROOT/WEB-INF/mytextfile.txt: placeholder: "defaultValue" tomcat/conf/server.xml: connector.maxThreads: 800
```
## Example 2
1. You have a given application with the following application files:
2. The content of mytextfile.txt is:
3. The resource\_configuration.yml looks like this:
```
src/ main/ java/ resources/ webapp/ META-INF/ sap_java_buildpack/ config/ resource_configuration.yml WEB-INF/ mytextfile.txt
```
```
My hometown is ${hometown}.
```
```
---tomcat/webapps/ROOT/WEB-INF/mytextfile.txt: hometown: "London"
```
4. After the application is staged, the content of mytextfile.txt will be:
```
My hometown is London.
```
## Example 3
The following example demonstrates how to provide values for placeholders during staging.
1. Use the data from Example 2 (steps 1-3).
2. Then, in the manifest.yml file of the application, add the following environment variable:
```
env: JBP_CONFIG_RESOURCE_CONFIGURATION: "['tomcat/webapps/ROOT/WEB-INF/ mytextfile.txt': {'hometown':"Paris"}]"
```
This gives the possibility to provide values for placeholders that differ from the default ones provided in the example above.
3. After staging of the application, the content of mytextfile.txt will be modified to:
```
My hometown is Paris.
```
## Related Information
Overriding Resources in Droplet [page 317]
Apache Tomcat 9: Configuration Reference
Apache Tomcat 10: Configuration Reference
Apache TomEE: Server Configuration
## 4.1.3.5.1.6  Context Root Redirect
SAP Java Buildpack provides a context root redirect functionality.
When you call a Web application without adding its runtime [page 278] context path to the URL, it's automatically appended.
## Example
If you configure /my\_context\_path as a context path, and the Web application is available on /my\_app , then:
When you call:
&lt;HOST&gt;:&lt;PORT&gt;/my\_app
You'll be redirected to:
&lt;HOST&gt;:&lt;PORT&gt;/my\_context\_path/my\_app
The default context path value for Tomcat and TomEE is "" (empty string).
For more information on how to change the default value, see:
- Tomcat 9 [page 286]
- Tomcat 10 [page 289]
- TomEE 7 [page 279]
- TomEE 10 [page 282]
## 2. Define the application class as tenantProvider . For example:
```
<?xml version='1.0' encoding='utf-8'?> <Context> <Resource name="jdbc/DatasourceOne" auth="Container" type="javax.sql.DataSource" factory="com.sap.xs.jdbc.datasource.tomcat.TomcatDataSourceFactory" service="jpa-db-managed" personalize="true"/> tenantProvider="com.sap.test.custom.provider.UserDefinedTenantProvider"/> </Context>
```
## Related Information
Providing Multitenant Applications to Consumers in the Cloud Foundry Environment [page 405]
## 4.1.3.5.1.8  Multiple Buildpack Framework
The Multiple Buildpack Framework enables SAP Java Buildpack to act as the final buildpack in a multiple buildpack deployment. It reads the contributions of other, earlier buildpacks and incorporates them into its standard staging.
##  Note
If you try to use SAP Java Buildpack as a non-final buildpack, an error will be thrown.
When SAP Java Buildpack acts as the final buildpack in a multiple buildpack deployment, it honors the following core contract integration points with non-final buildpacks:
| Integration Point   | Buildpack Usage                                                                                                                                |
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
| /bin                | An existing /bin directory contributed by a non-final build- pack will be added to the <$PATH> of the application as it executes.              |
| /lib                | An existing /lib directory contributed by a non-final build- pack will be added to the <$LD_LIBRARY_PATH> of the ap- plication as it executes. |
## 4.1.3.5.1.9.2  Configure the Access Logs of an Application
SAP Java Buildpack uses the logback-access module to provide HTTP-access log functionality.
## Prerequisites
- Download and Install the Cloud Foundry Command Line Interface [page 2533]
- Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534]
## Context
The access logs differ slightly from the other logs and traces. There are many standard tools available that read access logs from any server, display them, calculate statistics and so on. That's why the format of the access log produced by Tomcat and TomEE is not SAP-specific. The default pattern defined in the configuration file is "%date "%r" %s %b" .
To find the access log files of your application, you have to connect via SSH to the SAP BTP , Cloud Foundry container and go to the logs directory.
To change the default access log settings, follow the steps below.
## Procedure
1. Modify the default configuration.
2. SAP Java Buildpack uses LogbackValve to configure access logs in Tomcat and TomEE. The following
environment variables are used in the configuration file and can be overwritten:
- &lt;ACCESS\_LOG\_FILE&gt;
- &lt;ACCESS\_LOG\_FILE\_COUNT&gt;
- &lt;ACCESS\_LOG\_FILE\_MAX\_SIZE&gt;
- &lt;logback.access.log.xs.pattern&gt;
2. (Optional) Change the name of the access log files.
- By default, access logs are placed in the application container in the logs/access.log file. Y ou can configure the directory containing this file, as well as the name of the files by using environment variable ACCESS\_LOG\_FILE . T o do that, define the full path to the desired directory and the file name. For example: env:
```
ACCESS_LOG_FILE: "/home/vcap/logs/access-log/access.log"
```
3. (Optional) Change the number of access log files. You can change the number of stored files with the environment variable ACCESS\_LOG\_FILE\_COUNT . The default value is 3 . For example:
```
env: ACCESS_LOG_FILE_COUNT: 5
```
4. (Optional) Change the size of the access log files.
You can modify the size of every access log file with the environment variable ACCESS\_LOG\_FILE\_MAX\_SIZE . The default value is 8 MB. For example:
```
env: ACCESS_LOG_FILE_MAX_SIZE: 10
```
5. (Optional) Change the format of the HTTP access log
You can change the default format and have your access logs written differently. SAP Java Buildpack uses the resource configuration functionality to allow this. Changing the pattern attribute in the configuration file of Tomcat and TomEE is supported. The application has to provide the new value via the JBP\_CONFIG\_RESOURCE\_CONFIGURATION mechanism.
- For SAP Java Buildpack 1:
- For SAP Java Buildpack 2:
```
env: JBP_CONFIG_RESOURCE_CONFIGURATION: "['tomcat/conf/logback-access-
```
```
localhost.xml':{'logback.access.log.xs.pattern' : 'combined'}]"
```
```
env: JBP_CONFIG_RESOURCE_CONFIGURATION: "['tomcat/conf/logback-accesslocalhost.xml':{'logback.access.log.pattern' : 'combined'}]"
```
NOTE: If you use an Apache TomEE container, the configuration is the same - just replace tomcat with tomee or tomee7 .
## 4.1.3.5.1.10  Debugging Java Applications
Debugging an application helps you detect and diagnose errors in your code.
You can control the execution of your program by setting breakpoints, suspending threads, stepping through the code, and examining the contents of the variables. See:
- Debug an Application Running on SAP JVM [page 331]
- Debug an Application Running on SapMachine [page 332]
- Debug a Community Java Buildpack Application [page 333]
## 4.1.3.5.1.10.1  Debug an Application Running on SAP JVM
You can debug an application running on a Cloud Foundry container that uses SAP JVM.
## Prerequisites
- Download and Install the Cloud Foundry Command Line Interface [page 2533]
- Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534]
- Deploy your application using SAP Java Buildpack 1. To do that, open cf CLI and run:
- Ensure that SSH is enabled for the application. See Accessing Apps with SSH
```
cf push <app name> -p <war file> -b sap_java_buildpack
```
##  Note
SAP JVM is included in SAP Java Buildpack 1. With SAP JVM, you can enable debugging on-demand without the need to set any debugging parameters, hence without having to restart the application or SAP JVM.
## Context
After enabling the debugging port, you need to open an SSH tunnel that connects to this port.
## Procedure
1. To enable debugging or to check the debugging state of your JVM, run jvmmon in your Cloud Foundry container by executing:
2. From the jvmmon command line window, run:
3. (Optional) To confirm that debugging is enabled and see which port is open, run:
```
cf ssh <app name> -c "app/META-INF/.sap_java_buildpack/sapjvm/bin/jvmmon"
```
```
start debugging
```
```
print debugging information
```
The following is an example of the information displayed by jvmmon :
```
State: Debugging back is waiting for debugger to connect Port: 8000 Client: Globally accessible
```
The default port is 8000 .
4. To exit jvmmon , run: q
5. To open the SSH tunnel, run:
```
cf ssh <app name> -N -T -L 8000:127.0.0.1:8000
```
Your local port 8000 is connected to the debugging port 8000 of SAP JVM running in the Cloud Foundry container.
##  Note
The connection is active until you close the SSH tunnel. When you finish debugging, close the SSH tunnel by pressing Ctrl  +  C .
6. Connect a Java debugger to your application. For example, use the standard Java debugger provided by Eclipse IDE and connect to localhost:8000
## 4.1.3.5.1.10.2  Debug an Application Running on SapMachine
Debug a Java web application running on a Cloud Foundry container that uses SapMachine.
## Prerequisites
- Download and Install the Cloud Foundry Command Line Interface [page 2533]
- Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534]
## Context
To debug an application using SapMachine , you need to open a debugging port on your Cloud Foundry container, and then open an SSH tunnel to connect to that port.
## Procedure
1. To open the debugging port, you need to configure the JAVA\_OPTS parameter in your JVM. By default, the agentlib (which enables the debugging) is pre-configured. It could be turned off by setting the following property in the environment:
```
env ... JBP_CONFIG_SAP_MACHINE_JDK: "[default_debug_agent_active: false]"
```
You could also disable the default configuration by specifying it manually. Set the following option in the application manifest.yml file:
```
JBP_CONFIG_JAVA_OPTS: "[java_opts: '-
```
```
agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n]"
```
You can change the default port 8000 in the command.
2. To enable SSH tunneling in your application, run:
3. To open the SSH tunnel, run:
```
cf enable-ssh <app_name>
```
```
cf ssh <app name> -N -T -L 8000:127.0.0.1:8000
```
Your local port 8000 is connected to the debugging port 8000 of the JVM, which is running in the Cloud Foundry container.
 Note
The connection is active until you close the SSH tunnel. When you finish debugging, close the SSH tunnel by pressing Ctrl  +  C .
4. Connect a Java debugger to your application. For example, use the standard Java debugger provided by Eclipse IDE and connect to localhost:8000 .
## 4.1.3.5.1.10.3  Debug a Community Java Buildpack Application
You can debug an application running on a Cloud Foundry container that uses the community Java buildpack.
## Prerequisites
- Download and Install the Cloud Foundry Command Line Interface [page 2533]
- Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534]
## Context
To debug an application using the community Java buildpack , you need to open a debugging port on your Cloud Foundry container and open an SSH tunnel that will connect to that port.
## Procedure
1. To open the debugging port, you need to configure the JAVA\_OPTS parameter in your JVM. From the cf CLI, run:
2. To enable SSH tunneling for your application, run:
3. To activate the previous changes, restart the application by running:
4. To open the SSH tunnel, run:
```
cf set-env <app name> JAVA_OPTS '-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000'
```
```
cf enable-ssh <app name>
```
```
cf restart <app name>
```
```
cf ssh <app name> -N -T -L 8000:127.0.0.1:8000
```
Your local port 8000 is connected to the debugging port 8000 of the JVM running in the Cloud Foundry container. Also, 8000 is the default port.
##  Note
The connection is active until you close the SSH tunnel. When you finish debugging, close the SSH tunnel by pressing Ctrl  +  C .
5. Connect a Java debugger to your application. For example, use the standard Java debugger provided by Eclipse IDE and connect to localhost:8000 .
## 4.1.3.5.1.11  Profiling Java Applications
Application profiling helps you analyze the resource consumption of your Java applications running on virtual machine - SAP JVM or SapMachine.
## Related Information
Profile an Application Running on SAP JVM [page 335]
Profile an Application Running on SapMachine with JFR/JMC [page 337]
## 4.1.3.5.1.11.1  Profile an Application Running on SAP JVM
The SAP JVM Profiler is a tool that helps you analyze the resource consumption of a Java application running on SAP Java Virtual Machine (JVM). You can use it to profile simple standalone Java programs or complex enterprise applications.
## Prerequisites
- Install the SAP JVM Tools for Eclipse. For more information, see Install the SAP JVM Tools in Eclipse [page 336].
- Open a debugging connection using an SSH tunnel. For more information, see Debug an Application Running on SAP JVM [page 331]
## Context
To measure resource consumption, the SAP JVM Profiler enables you to run different profiling analyses. Each profiling analysis creates profiling events that focus on different aspects of resource consumption. For more information about the available analyses, see the SAP JVM Profiler documentation in Eclipse. Go to Help Help Contents SAP JVM Profiler .
## Procedure
1. In Eclipse, open the Profiling perspective.
2. From the VM Explorer view, choose ( Connect Host Via Debugging Port ).
3. Enter your host name and port number, and choose Next .
##  Note
Your port number is your local SSH tunnel endpoint.
4. Choose the analysis you want to run and specify your profiling parameters.
##  Note
To use the thread annotation filters, complete the fields under the Analysis Options section. By default, all filters are set to * , which means that all annotations pass the filter.
## 4.1.3.5.1.11.1.1  Install the SAP JVM Tools in Eclipse
SAP JVM Profiler is included in the SAP JVM Tools.
## Prerequisites
You have downloaded and installed Eclipse IDE for Java Developers . See: Eclipse Packages
## Procedure
1. Open the Eclipse IDE and navigate to Help Install New Software .
2. In the Work with combo box, enter https:/ /tools.hana.ondemand.com/oxygen and choose Add .
3. Select SAP BTP Tools SAP JVM Tools and choose Next .
4. Select SAP JVM Tools , accept the terms and conditions, and choose Finish .
5. Restart the Eclipse IDE to apply the new changes.
## Results
After the restart, a new SAP JVM Profiler section is displayed in the Overview page.
## 4.1.3.5.1.11.1.2  (Optional) Add your SAP JVM to the VM Explorer
You can add your SAP JVM to the VM Explorer view of the SAP JVM Profiler .
## Prerequisites
- Install the SAP JVM Tools in Eclipse [page 336].
- Download and Install the Cloud Foundry Command Line Interface [page 2533]
- Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534]
## Context
From the VM Explorer, you can debug, monitor or profile your SAP JVM. For more information about the VM Explorer , see the SAP JVM Profiler documentation in the Eclipse Help.
##  Note
You need to use the jvmmond tool, which is included in the SAP Java Buildpack.
## Procedure
1. From the cf CLI, execute:
```
cf ssh app name -c "app/META-INF/.sap_java_buildpack/sapjvm/bin/ jvmmond -port 50003 -J-Dcom.sap.jvm.tools.portRange=50004-50005 -JDjava.rmi.server.hostname=127.0.0.1"
```
This starts the jvmmond service on your Cloud Foundry container. It is listening to port 50003 . This command also specifies a port range of 50004-50005 in case additional ports need to be opened.
2. To enable an SSH tunnel for these ports, execute:
3. In your Eclipse IDE, open the Profiling perspective, and from the VM Explorer view choose Manage Hosts .
4. Choose Add and enter the following host name and port number: localhost:50003
```
cf ssh <app name> -N -T -L 50003:127.0.0.1:50003 -L 50004:127.0.0.1:50004 -L 50005:127.0.0.1:50005
```
## Results
Your application is added to the VM Explorer.
## 4.1.3.5.1.11.3  Profile an Application Running on SapMachine with async-profiler
You can use the async-profiler tool to profile your Java application on SapMachine.
## Prerequisites
- You have installed the Cloud Foundry command line interface. See: Download and Install the cf CLI
- You are logged on to a SAP BTP, Cloud Foundry space. See: Log On to the Cloud Foundry Environment Using cf CLI
- The version of your buildpack is at least 1.110.0 (for SAP Java Buildpack 1) or 2.24.0 (for SAP Java Buildpack 2).
- The version of your SapMachine is at least 17.0.14 or 21.0.6 .
- You have a Java application that is up and running on SAP BTP, Cloud Foundry.
- You have enabled SSH for your application. See: Configuring SSH access at the app level
## Context
To profile Java applications with the async-profiler tool, you can use the cf CLI Java plugin [page 2551], which provides convenience commands for profiling.
##  Note
In the steps below, we use myapp as an exemplary application name. Replace it with your actual application name.
## Procedure
1. Start the CPU profiling. Run:
cf java asprof-start-cpu myapp
Result: Profiling started
2. (Optional) You can check the status of the profiling. Run:
cf java asprof-status myapp
Result:
Profiling is running for xx seconds
3. Stop profiling and download the profiling data to the given local directory. Run:
cf java asprof-stop myapp
## Result:
```
--- Execution profile --Total samples       : 15 ... Successfully created JFR recording in application container at: /tmp/myapp<GUID>.jfr Jfr recording file saved to: ./myapp-asprof-<GUID>.jfr Jfr recording file deleted in app container
```
4. Check the additional convenience commands. Run:
5. To profile other events, you can start the async-profiler by running the start-asprof command with arguments:
```
cf java
```
```
cf java asprof-start --args "-e nativemem" myapp
```
## Related Information
Profiling Modes
```
Profiler Options Cloud Foundry Command Line Java plugin
```
## 4.1.3.5.1.12  Configuring a Database Connection
You can configure your application to use a database connection so that the application can persist its data. This configuration is applicable for the Tomcat 9 [page 286], TomEE 7 [page 279], and Tomcat 10 [page 289] application containers. See:
- Configure a Database Connection for the Tomcat Application Container [page 349]
- Configure a Database Connection for the TomEE Application Container [page 347]
- Database Connection Configuration Details [page 342]
- SAP HANA HDI Data Source Usage [page 350]