The CDS view name is the ABAP-level name used within the ABAP environment. It’s the name you use to reference the CDS view in ABAP programs, in other CDS views, or in tools like ADT (Eclipse). It represents the semantic model and is part of the ABAP repository.

On the other hand, @AbapCatalog.sqlViewName defines the technical name of the SQL view that gets created in the underlying database when you activate the CDS view. This SQL view acts as a bridge between the ABAP dictionary and the actual database. The SQL view is stored in the database and can be accessed using standard SQL statements if needed.

In simple terms:

• The CDS view name = used in the ABAP layer (semantic name for CDS).

• The sqlViewName = used in the database layer (technical name for DB view).

For example:

@AbapCatalog.sqlViewName: ‘ZEMP_SQL’
@EndUserText.label: ‘Employee CDS View’
define view ZCDS_Employee as select from zemployee {
key emp_id,
emp_name,
emp_dept
}

Here, ZCDS_Employee is the CDS view name (used in ABAP), while ZEMP_SQL is the SQL view name (created in the database).

Key Differences Summary

1. In ABAP Development Tools (ADT):

   • Go to File → New → ABAP Project.

   • Connect to your system.

   • Create a new ABAP Package (e.g., Z_RAP_BUTTONS).

2. Create the RAP artifacts:

   • Business Object (BO):

     • Right-click the package → New → Other ABAP Repository Object → Business Object → RAP Business Object.

     • Example: ZBO_SALESORDER.

Step 2: Define the Behavior (Behavior Definition)

1. In your Behavior Definition (.behavior):

define behavior for ZI_SALESORDER
persistent table ZI_SALESORDER
lock master
{
create;
update;
delete;

// Add custom action button
action confirm order result [0..1];
}

Step 3: Implement the Behavior Logic

1. In Behavior Implementation (.behavior.abap):

implementation in class zbp_i_salesorder unique;

method confirm_order.
” Your business logic goes here
loop at it_entity into data(ls_entity).
ls_entity-status = ‘CONFIRMED’.
modify table et_entity from ls_entity.
endloop.
endmethod.

endimplementation.

Step 4: Expose Action in Service Definition

1. Open Service Definition (.service):

define service ZC_SALESORDER_SRV {
expose ZI_SALESORDER;
// Optionally expose action explicitly
action confirm order;
}

Step 5: Register & Test Service

1. Go to /IWFND/MAINT_SERVICE → register your RAP service.

2. Test via SAP Gateway Client (/IWFND/GW_CLIENT) to see the metadata:

   • You should see your confirm order action exposed.

Step 6: Fiori/UI Integration

• If you use Fiori Elements (List Report / Object Page):

  1. The action confirm order will automatically appear as a button in the Object Page or List Report.

  2. No extra UI5 code is required if you use standard Fiori Elements.

  3. If you want custom UI5, you can bind a button like this:

<Button
text=”Confirm Order”
press=”.onConfirmOrder”
/>

And in your controller:

onConfirmOrder: function(oEvent) {
var oModel = this.getView().getModel();
var sPath = oEvent.getSource().getBindingContext().getPath();
oModel.callFunction(“/ConfirmOrder”, {
method: “POST”,
urlParameters: {
SalesOrderID: oModel.getProperty(sPath + “/SalesOrderID”)
},
success: function() {
MessageToast.show(“Order Confirmed!”);
},
error: function() {
MessageToast.show(“Error!”);
}
});
}

With SAP BTP, businesses can adopt a side-by-side extension model. Using tools like SAP Build Apps (low-code/no-code development), CAP (Cloud Application Programming), Fiori services, and AI/ML capabilities, companies can build applications that extend S/4HANA functionality without touching the underlying system. Additionally, workflow automation (via SAP BPA) and integration services allow organizations to streamline processes and connect seamlessly with other enterprise systems.

The benefits are substantial. Extensions on BTP ensure that S/4HANA remains clean and upgrade-friendly, reducing long-term technical debt. Companies gain the flexibility to innovate rapidly, scale applications on demand, and leverage advanced cloud services like analytics, IoT, and AI. This approach not only improves business agility but also ensures that organizations remain competitive in a fast-changing digital environment while safeguarding their ERP investments.

SAP BTP addresses this challenge through the SAP Integration Suite, which provides pre-built connectors, APIs, and templates for both SAP and non-SAP systems. It also supports event-driven architecture, ensuring real-time updates across platforms. Additionally, it includes tools for API management, cloud-to-on-premise connectivity, and secure data transfer using industry standards like OAuth and SAML.

For enterprises, this seamless integration is vital. It improves end-to-end process automation, reduces manual effort, enhances data accuracy, and ensures compliance. More importantly, it empowers organizations to create a unified digital ecosystem, where all business applications communicate effectively. This leads to greater agility, better decision-making, and faster innovation, which are essential for success in the digital era.

The transactions SNRO or SNUM are used to display and manage number range object definitions.

For example, when checking the configuration of MATERIALNR, you can view the relevant details under the tabs Intervals, Customizing, and Group (if available).

The number range object configuration contains several important fields:

• Warning (%) – Specifies the threshold percentage of remaining numbers in the range. A warning is triggered when this limit is reached.
• To-year flag – Determines whether the object is year-dependent or not year-dependent. This is evaluated together with the Year field.
• Rolling flag – Indicates whether the object is rolling or non-rolling.
• If the flag is not set (No-rolling), the object behaves as rolling, meaning that once the interval is exhausted, numbering restarts from the beginning of the interval.
• NR Transaction – Provides a shortcut to the interval configuration, typically accessed from the application side.
• Buffering method / Numbers in buffer – Defines the buffering mechanism and specifies how many numbers are preloaded into the buffer for performance optimization.

use the fields that are used in this example you can create an NR object

Key points:

• A Number Range Object is like a container that controls how numbers are assigned to a particular type of document or record (e.g., customer accounts, material masters, purchase orders, invoices).
• It ensures that each document or master data record receives a unique identifier.
• Defined in transaction SNRO (Number Range Objects).
• Each number range object can have multiple intervals (ranges of numbers), which may be assigned to different company codes, plants, fiscal years, or other criteria.
• Numbers can be:
  • Internal → System automatically assigns the next available number in sequence.
  • External → User manually enters a number within a defined range.

Example:

• Number Range Object: DEBITOR (for Customer Accounts)
• Intervals:
  • 100000 – 199999 (for Company Code 1000, internal assignment)
  • 200000 – 299999 (for Company Code 2000, internal assignment)
  • 900000 – 999999 (external assignment, user inputs)

When a new customer is created, the system checks the assigned interval and assigns the next available number (or validates the user-entered number if external).

Usage examples in SAP:

• FI: Document numbers, customer/vendor accounts
• MM: Material numbers, purchase requisitions, purchase orders
• SD: Sales orders, deliveries, billing documents
• HR: Personnel numbers

• It allows you to expose business objects via REST APIs.
• A Business Object (BO) in RAP is defined via CDS Views + Behavior Definition + Behavior Implementation.

Managed vs. Unmanaged Scenarios

Managed Scenario

In this case, RAP framework manages the persistence (DB operations) automatically.

• You define your CDS entity and annotate it.

• RAP auto-generates all CRUD (Create, Read, Update, Delete) operations.

• Developer effort = Minimal, only add custom logic if needed.

• RAP uses the ETag handling, draft handling, transactional behavior automatically.

When to use:

• When your DB tables are new or not yet used elsewhere.
• For greenfield developments (new business objects).

Example (Managed Scenario)

CDS Entity:

define root view entity Z_I_SalesOrder
as select from zsalesorder
{
key salesorder_id,
customer,
order_date,
status
}

Behavior Definition (Z_I_SalesOrder.behavior):

managed implementation in class zbp_salesorder unique;

define behavior for Z_I_SalesOrder alias SalesOrder
persistent table zsalesorder
lock master
draft;

create;
update;
delete;
endbehavior;

RAP automatically knows how to insert/update/delete records in zsalesorder.

Unmanaged Scenario

In this case, developer controls persistence logic (you implement CRUD manually).

• RAP only provides the framework & metadata.
• You must implement the behavior in an ABAP class (behavior handler).
• Useful when business logic is complex or DB table is legacy (used by other apps, needs validations, custom logic, or external system integration).

When to use:

• When you already have existing tables and need custom save logic.
• For brownfield scenarios (extending existing business processes).

Example (Unmanaged Scenario)

CDS Entity

define root view entity Z_I_SalesOrder
as select from zsalesorder_legacy
{
key salesorder_id,
customer,
order_date,
status
}

Behavior Definition (Z_I_SalesOrder.behavior):

unmanaged implementation in class zbp_salesorder unique;

define behavior for Z_I_SalesOrder alias SalesOrder
lock master;

create;
update;
delete;
endbehavior;

Behavior Implementation (ABAP Class):

CLASS zbp_salesorder DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_abap_behavior_handler.
ENDCLASS.

CLASS zbp_salesorder IMPLEMENTATION.
METHOD if_abap_behavior_handler~create.
” Custom logic for inserting into zsalesorder_legacy
ENDMETHOD.

METHOD if_abap_behavior_handler~update.
” Custom logic for updating existing orders
ENDMETHOD.

METHOD if_abap_behavior_handler~delete.
” Custom logic for deletion
ENDMETHOD.
ENDCLASS.

Purpose of Destinations

• They act like a central connection configuration so that applications don’t need to hardcode system URLs, credentials, or authentication methods.
• You define the target system (destination) once, and multiple apps or services can reuse it.

Key Uses

• Connectivity to External Systems
  Example: An SAP BTP app needs to call an SAP S/4HANA system, an SAP SuccessFactors API, or even a third-party REST service.
  Instead of storing the URL and credentials in the app, you define a Destination in BTP.
• Simplifies Authentication & Security
  Destinations support multiple authentication methods (OAuth2, Basic Auth, SAML, Principal Propagation, etc.).
• Centralized Configuration
  If an endpoint changes (like a new S/4HANA system URL), you only update the destination once — no need to redeploy or change code in all connected apps.
• Standardized Access Across Apps
  Multiple apps can consume the same destination, ensuring consistency.

Example

Suppose you have a CAP (Cloud Application Programming) app on BTP that needs data from SAP S/4HANA:

• You create a Destination in the BTP cockpit pointing to your S/4HANA system (with the URL + OAuth2 credentials).
• Your app just calls destination.get(“S4HANA”) instead of hardcoding URLs.
• If the S/4HANA system moves to a new URL, you update the destination in cockpit, not in your app code.

In short: Destinations in SAP BTP are a secure, centralized way to define and reuse external system connections across apps.

Step by Step Process:

Step 1: Log in to SAP BTP Cockpit

• Go to https://cockpit.btp.cloud.sap and log in with your SAP credentials.
• Select your Global Account and then the Subaccount where you want to create the destination.

Step 2: Ensure Entitlements

• In your Subaccount, go to Entitlements → Configure Entitlements.
• Make sure Destination and Connectivity services are added.
  (If not, add them using Add Service Plans.)

Step 3: Create a Destination Service Instance (for runtime use)

• Go to Subaccount → Services → Instances and Subscriptions.
• Click Create → Instance.
• Select Destination as the service.
• Choose a plan (usually lite for trial or standard).
• Complete the wizard and finish.
• Optionally, create a Service Key or bind it to an application.

Step 4: Configure a Destination

1. In your subaccount, navigate to Connectivity → Destinations.
2. Click New Destination.
3. Fill in the required fields:
   • Name → Unique name (used by apps).
   • Type → HTTP (most common).
   • URL → Target system endpoint (e.g., your SAP S/4HANA or API URL).
   • Proxy Type → Internet (for cloud systems) or OnPremise (if using SAP Cloud Connector).
   • Authentication → Choose method (NoAuth, BasicAuth, OAuth2ClientCredentials, SAML, etc.).
   • Provide credentials (username/password, client ID/secret, or token URL depending on method).
4. (Optional) Add Additional Properties, e.g.:
   • WebIDEEnabled = true
   • sap-client = 100
   • HTML5.DynamicDestination = true
5. Click Save.

Step 5: Test the Destination

• Still in Connectivity → Destinations, find your destination.
• Use the Check Connection button.
• If successful, your app can now consume it.

It acts like a staging area for BO changes until you call SAVE.

Where It’s Used

• SAP RAP BO runtime (ABAP RAP framework)
• Inside the RAP behavior pool implementation
• During create, update, delete operations before saving to the database

Why It’s Needed (Uses & Purpose)

1. Consistency
   • Ensures that multiple operations on the same entity (within one LUW) don’t conflict or corrupt each other.
   • Example: You update an entity and then delete it — the buffer tracks both correctly.
2. Performance
   • Changes are cached in memory first, not immediately written to the database.
   • Only when SAVE is triggered, does the buffer commit all changes in one go (batch write).
3. Validation & Checks
   • It allows running validations, determinations, and actions on BOs with the latest in-memory data.
   • Example: Determinations can use updated data before it’s saved to the DB.
4. Transactional Integrity
   • Supports rollback on failure — changes in the buffer are discarded if any error occurs before save

What Is Stored in the Transaction Buffer?

• New instances of BOs (created but not yet saved)
• Updated field values
• Deleted instance markers
• Messages (errors, warnings, info)
• Draft data (for draft-enabled BOs)

• Data management
• Application development
• Integration
• Analytics
• Artificial Intelligence (AI)

It runs on multiple runtime environments (Neo, Cloud Foundry, Kyma) and is available on hyperscaler infrastructures like AWS, Azure, GCP, and Alibaba Cloud.

ore Layers of SAP BTP Architecture

1. Infrastructure Layer

• Supports multi-cloud deployment:
  • AWS, Microsoft Azure, Google Cloud, Alibaba Cloud
• Provides scalability, global availability, and security.

2. Runtime Environments

• Cloud Foundry – container-based app development.
• Kyma/Kubernetes – event-driven microservices using serverless functions.
• ABAP Environment – for extending S/4HANA in ABAP.
• Neo (Legacy) – older SAP-managed environment.

3. Services Layer

Key services grouped into 4 pillars:

• Database & Data Management
  SAP HANA Cloud, Data Lake, Data Intelligence, Data Warehouse Cloud

• Application Development & Automation
  SAP Business Application Studio, SAP CAP, SAP Workflow, SAP AppGyver (no-code/low-code)

• Analytics
  SAP Analytics Cloud, Smart Predict, BI, Planning

• Integration
  SAP Integration Suite, API Management, Event Mesh, Open Connectors

4. Security & Identity

• SAP Identity Authentication & Provisioning
• Role-based access
• Data encryption and compliance (GDPR, etc.)