• • SAP Datasphere takes a modern approach by combining warehousing with advanced features such as federation, virtualization, and semantic modeling.

  • Federation allows organizations to access and analyze data where it resides without unnecessary duplication.

  • Virtualization enables seamless views across multiple sources, reducing delays caused by data movement.

  • The biggest differentiator is semantic modeling, which preserves business context from SAP applications. This means key definitions, hierarchies, and relationships are automatically carried over.

  • For example, financial dimensions, cost centers, or product hierarchies remain intact, making data meaningful to both business and technical users.

  • By bridging the gap between IT and business, SAP Datasphere helps organizations achieve trusted, context-rich analytics, unlike traditional warehouses that often provide raw, decontextualized data.

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.

1. Create an API approval process.

1. Create the data to be inserted.

1. Create an Approval Form

Enter a subject by binding the sales order number with subject.

1. Create the Approval form and bind the data.

1. If we use Process started by in the Recipients– users then the person who has started it will get the work item.

1. Now if the order is rejected the create an email to be sent to the person who has created the SO.

1. Finally, the work flow will look like.

1. Now we have to release it.

1. Now Deloy the Workflow Process.

1. Go to à SAP BUILD à Environments à public à trigger à actions à view

• Here you will find all the necessary things your required to configure your workflow in Fiori applications.

Completed.

Think of it as a tool to digitize and automate repetitive, rule-based, or approval-driven processes.

Key Features of SAP BPA

• Workflow Automation
  Design approval flows (e.g., purchase requisition → manager approval → procurement).

• Robotic Process Automation (RPA)
  Software bots that mimic human clicks and data entry in other systems.

• Business Rules
  Define logic/rules to automate decisions (e.g., “if amount > $10,000 → escalate to director”).

• Forms & Document Processing
  Collect input via digital forms, extract data from PDFs or invoices.

• Pre-Built Content
  SAP provides ready-to-use process templates (like employee onboarding, supplier invoice processing).

Why is it Used?

Companies use SAP BPA to:

1. Reduce Manual Work → Bots can handle repetitive SAP GUI tasks (e.g., creating sales orders, updating vendor data).

2. Improve Efficiency → Automates approval flows across SAP S/4HANA, SuccessFactors, Ariba, etc.

3. Ensure Compliance → Rules-based automation reduces human error.

4. Save Costs → Less manual effort, faster processing.

5. Improve User Experience → Employees can focus on value-added work instead of copy-paste tasks.

Example Use Cases

• Automating purchase order approvals.

• Extracting data from supplier invoices and posting to SAP S/4HANA.

• Onboarding new employees (HR form submission → approvals → account creation).

• Running bots at night to collect data and send reports by email.

Name: SMTP_MAIL
Type: SMTP
Description: SMTP Server for Email
Mail Server: smtp.office365.com
Port: 587
Authentication: BasicAuthentication
User: your-email@company.com
Password: <app password or SMTP password>

Additional Properties:

mail.smtp.auth = true
mail.smtp.starttls.enable = true

1. (If your company uses another SMTP, replace accordingly.)

2. Save & Test

   • Save the destination.

   • Use the Check Connection button to ensure it works.

Sending Emails from BTP Apps

Once the destination is created:

• In CAP (Cloud Application Programming) or Node.js/Java apps running on BTP, you can call the destination using the Destination Service API.

• Example: use @sap-cloud-sdk/connectivity (Node.js) or com.sap.cloud.sdk.cloudplatform.connectivity.DestinationAccessor (Java) to fetch SMTP config and send emails via a mail library.

Alternative: SAP BTP Mail Service

Instead of configuring SMTP yourself:

• Some BTP regions provide a Mail Service (Mail API) that can be used directly for outbound mail without handling SMTP configuration.

• Check if your subaccount entitlements include “Mail” service.

Subaccounts → Logical partitions inside a global account. They let you organize environments by project, department, or customer.

Spaces (Cloud Foundry only) → Environments within subaccounts to separate workloads (Dev / Test / Prod).

Think of it like this:
🏢 Global Account (your company’s contract)
→ 📂 Subaccount (HR, Finance, Project A, Project B)
→ 📦 Spaces (Dev, Test, Prod)

Step by Step (Subaccount & Space Creation)

1. Log in to SAP BTP Cockpit.
2. Go to Global Account → Subaccounts → Create Subaccount.
   • Choose Region (important: services are region-specific).
   • Define Subdomain (used in app URLs).
3. Open Subaccount → Cloud Foundry → Enable Cloud Foundry Organization.
4. Inside CF → Create Spaces (Dev, QA, Prod).
5. Assign members & roles per subaccount and space.

Use: Enables resource separation, security, and lifecycle management.

• Without SCC → Your BTP apps can’t reach internal (on-premise) systems.
• With SCC → You can expose only selected resources safely to BTP apps, without opening up the entire network.

Think of it like a firewall-friendly, secure bridge.

Step-by-Step Setup

Step 1: Install SAP Cloud Connector

• Download it from the SAP Development Tools website.
• Install on a server (Windows/Linux) inside your corporate network.

Step 2: Access the SCC UI

• Open a browser and go to:
  https://localhost:8443

• Default login:

  • Username: Administrator

  • Password: manage (you’ll be forced to change it).

Step 3: Connect SCC to Your Subaccount

• In the SCC UI, go to Subaccount → Add Subaccount.

• Enter:

  • Region: Select the SAP BTP region (e.g., eu10, us10).

  • Subaccount ID: Get this from your BTP Cockpit.

  • Login Email & Password: Your SAP BTP user.

• Save → SCC now shows “Connected” if successful.

Step 4: Define On-Premise Systems

• In SCC UI, go to Cloud To On-Premise → Access Control.

• Click Add System Mapping.

• Choose:

• Backend Type: e.g., ABAP System, HTTP, RFC.
• Protocol: e.g., HTTP for OData services, RFC for SAP function calls.
• Internal Host & Port: (e.g., sap.internal.corp:44300).
• Virtual Host & Port: The alias name that BTP apps will use.

• Save.

Step 5: Expose Resources

• Still under Access Control, select your system.
• Choose Resources → Add.
• Define which path/services (e.g., /sap/opu/odata) are exposed.
• Save.

Step 6: Use in SAP BTP Destination

• Now, when creating a Destination in BTP Cockpit:

  • Set Proxy Type = OnPremise.

  • Use the Virtual Host & Port defined in SCC.

• Test connection — if green, your BTP app can reach the on-premise system.

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.

Where it runs:

• On SAP BTP or any external cloud platform
• Communicates with SAP S/4HANA via APIs (ODATA, REST, BAPI, etc.)

 Typical Use Cases:

• Creating new apps without changing the core
• Complex integrations with third-party systems
• Mobile apps or web portals
• Machine learning or advanced analytics scenarios

 Pros:

• Decoupled from core = less impact on upgrades
• Greater flexibility with tools and languages (e.g., Java, Node.js, Python)
• Scalable and cloud-native development
• Ideal for innovation scenarios

 Cons:

• Requires setting up integration (APIs, authentication, etc.)
• Potential latency (depending on use case)
• Higher architectural complexity