SAP Cloud Platform Java Entwicklung – Teil 1

SAP Cloud Platform Java Entwicklung – Teil 1

In dieser Blogreihe zeige ich Ihnen wie die Java Entwicklung für die SAP Cloud Plaform auf Basis von Spring Boot durchgeführt wird. Spring Boot ist das defacto Standard Framework wenn es um die Entwicklung von Java Applikationen in der Cloud / bei Software-as-a-Service geht. Zur Entwicklung mit Spring Boot gibt es eine Vielzahl an Resourcen im Internet, jedoch blieben die SAP Cloud Platform Spezifika dabei meist auf der Strecke. SAP bietet im Neo Stack der SAP Cloud Platform ein SDK dass die Verwendung von SAP-eigenen Funktionalitäten in Java ermöglicht. Dieser Blog fokusiert sich auf die allgemeinen Entwickleraufgaben in der Entwicklung von Java Applikationen. Dabei wird der Aufbau der pom.xml gezeigt und ein einfacher RestController implementiert. Folgende Inhalte werde ich in zukünftigen Blogs zeigen:
  • Zugriff auf HANA DB mittels JNDI
  • Zugriff auf Destinations mittels JNDI
  • Zugriff auf Tenant Informationen mittels JNDI
  • Zugriff auf User Informationen

Aufbau der pom.xml

Die pom.xml beinhaltet alle relevanten Informationen die für den Build der Applikation erforderlich sind.

Parent

Nachdem wir auf Spring Boot setzen muss dies als parent definiert werden.
<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.3.1.RELEASE</version>
  <relativePath />
</parent>

Properties

In den properties werden die Java Version sowie die Version des SAP Cloud SDK definiert.
<properties>
  <java.version>1.8</java.version>
  <sap.cloud.sdk.version>3.107.18</sap.cloud.sdk.version>
</properties>

Dependencies

In den dependencies werden die Abhängigkeiten definiert. Dabei wird u.a. auf SpringBoot Starter Web verwiesen und auch auf das SAP Cloud SDK. Beim SAP Cloud SDK ist es wichtig, dass auf die in den properties definierte Version verlinkt wird, und dass der scope auf den Wert provided gesetzt wird. Damit wird diese Abhängigkeit nicht in das WAR file gepackt und auf als dem Server bereitgestellt betrachtet.
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId> 
</dependency>

<dependency> 
  <groupId>com.sap.cloud</groupId>
  <artifactId>neo-java-web-api</artifactId>
  <version>${sap.cloud.sdk.version}</version>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>com.google.code.gson</groupId>
  <artifactId>gson</artifactId>
  <version>2.8.6</version>
</dependency>

Profile

In diesem Beispiel wird für das Deployment auf den Neo Stack ein eigenen Profil angelegt. Darin wird definiert, dass bestimmte Abhängigkeiten vom Server bereitgestellt werden und diese nicht in das WAR file eingebettet werden. Andernfalls würde der Start der Applikation fehlschlagen.
<profile>
  <id>neo</id>
  <activation>
    <activeByDefault>true</activeByDefault>
  </activation>
  <properties>
    <packaging.type>war</packaging.type>
  </properties> 
  <dependencies> 
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <scope>provided</scope>
    </dependency>  
  </dependencies>
</profile>

Build Plugins

Abschließend muss im Build noch das Spring Boot Maven Plugin definiert werden.
<plugins>
  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
  </plugin>
</plugins>

Build der Applikation für die SAP Cloud Platform

Der Build der Applikation kann über die CommandLine mit folgenden Befehl durchgeführt werden mvn clean package -Pneo Damit die Applikation innerhalb vom Tomcat erfolgreich gestartet werden kann, muss die configure Methode aus dem SpringBootServletInitializer redefiniert werden. Dies kann entweder direkt in der Hauptklasse der Applikation erfolgen oder in einer eigenen Klasse. Ich persönlich bevorzuge an dieser Stelle die Verwendung einer eigenen Klasse.
package at.clouddna.demo;

import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

public class ServletInitializer extends SpringBootServletInitializer {
  @Override
  protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
    return application.sources(DocmgmtApplication.class);
  }
}

Implementierung eines einfachen Rest Controllers

Damit ein Funktionstest durchgeführt werden kann, implementiere ich immer eine Ping Methode in einem eigenen Controller.
package at.clouddna.docmgmt.controller; 

import org.slf4j.Logger;
import org.slf4j.LoggerFactory; 
import org.springframework.http.ResponseEntity; 
import org.springframework.web.bind.annotation.GetMapping; 
import org.springframework.web.bind.annotation.RequestMapping; 
import org.springframework.web.bind.annotation.RestController; 

@RestController 
@RequestMapping({ "/ping" }) 
public class PingController { 
  private static final Logger logger = LoggerFactory.getLogger(PingController.class); 

  @GetMapping
  public ResponseEntity<?> ping() { 
    logger.debug("ping called"); 
    return ResponseEntity.ok("Hello World"); 
  }
}
Damit sind wir mit einer einfachen Applikation bereits fertig. Beim Deployment über das SAP Cloud Platform Cockpit ist darauf zu achten, dass die Runtime Java Web Tomcat 8 ausgewählt wird und dass das Profile als JVM Parameter wie folgt übergeben wird.
-Dspring.profiles.active=neo
Der Ping Controller kann direkt aus dem Browser heraus getestet werden, da die entsprechende Methode über einen HTTP GET Request aufgerufen wird.

OData ABAP Backend Exception

State-of-the-Art SAPUI5 / Fiori Apps erfordern ein sauber implementiertes Error Handling. Sind OData Services in einem SAP NetWeaver ABAP Stack implementiert, gibt es zwei ABAP Klassen die für Exceptions verwendet werden:

  • /IWBEP/CX_MGW_BUSI_EXCEPTION für Business / Logische Fehler
  • /IWBEP/CX_MGW_TECH_EXCEPTION für Technische Fehler

Fehler können auf verschieden Arten geworfen werden. Nachfolgend zeigen wir Ihnen unterschiedliche Optionen.

Ein Möglichkeit ist es, über den MessageContainer den Fehlertext direkt zurückzuliefern. Diese Methode hat den Nachteil, dass die Fehlertexte hartkodiert sind und somit eine Übersetzung in unterschiedliche Sprachen nicht möglich ist.

METHOD customerset_get_entity.
  SELECT SINGLE * FROM zcustomer where ...
  IF sy-subrc NE 0.
    mo_context->get_message_container( )->add_message_text_only( 
iv_msg_type = 'E'                                                       
iv_msg_text = |Der angeforderte Datensatz wurde nicht gefunden.| ).
  
    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
      EXPORTING
        message_container = mo_context->get_message_container( ).
  ENDIF.
ENDMETHOD.

Eine weitere Möglichkeit besteht in der Verwendung einer Nachrichtenklasse. Damit können alle bekannten ABAP Tools wie z.B. die SE91 verwendet werden.

METHOD customerset_get_entity.
  SELECT SINGLE * FROM zcustomer where ...
  IF sy-subrc <> 0.
    mo_context->get_message_container( )->add_message( iv_msg_type   = 'E'
                                                       iv_msg_id     = 'SY'
                                                       iv_msg_number = '100'
                                                       iv_msg_text   = |Der angeforderte Datensatz wurde nicht gefunden.| ).
  
    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
      EXPORTING
        message_container = mo_context->get_message_container( ).
  ENDIF.
ENDMETHOD.

Eine weitere Möglichkeit in Kombination mit dem Message Container bietet sich, wenn Fehler in Form eine BABIRET2 Struktur vorliegen.

METHOD xyz_get_entity.
  DATA: lt_return TYPE bapirettab.
   
  CALL FUNCTION 'BAPI_CALL_XYZ'
    ...
    TABLES
      return = lt_return.
   
  IF lt_return IS NOT INITIAL.
    mo_context->get_message_container( )->add_messages_from_bapi( it_bapi_messages = lt_return ).
 
    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
      EXPORTING
        message_container = mo_context->get_message_container( ).
  ENDIF.
ENDMETHOD.

Es gibt in diesem Szenario auch die Option die Leading Message zu bestimmen. In diesem Fall muss das Coding leicht abgeändert werden.

METHOD xyz_get_entity.
  DATA: lt_return TYPE bapirettab.
   
  CALL FUNCTION 'BAPI_CALL_XYZ'
    ...
    TABLES
      return = lt_return.
   
  IF lt_return IS NOT INITIAL.
    mo_context->get_message_container( )->add_messages_from_bapi( it_bapi_messages = lt_return
                                                                  iv_determine_leading_msg = /iwbep/if_message_container=>gcs_leading_msg_search_option-first ).
 
    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
      EXPORTING
        message_container = mo_context->get_message_container( ).
  ENDIF.
ENDMETHOD.

Exceptions können auch direkt ohne Verwendung des Message Containers geworfen werden.

METHOD customerset_get_entity.
  SELECT SINGLE * FROM zcustomer where ...
  IF sy-subrc NE 0.
    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
      EXPORTING
        textid  = /iwbep/cx_mgw_busi_exception=>business_error
        message = |Der angeforderte Datensatz wurde nicht gefunden.|.
  ENDIF.
ENDMETHOD.

Eine weitere Option besteht darin, der Exception eine Struktur vom Typ scx_t100key mitzugeben.

METHOD customerset_get_entity.
  SELECT SINGLE * FROM zcustomer where ...
  IF sy-subrc NE 0.
    DATA(lv_message) = VALUE scx_t100key( msgid = 'SY'
                                          msgno = '001'
                                          attr1 = |Der angeforderte Datensatz wurde nicht gefunden.| ).
 
    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
      EXPORTING
        textid  = lv_message.
  ENDIF.
ENDMETHOD.

Die letzte in diesem Blog dargestellte Option ist es, eine Exception abzufangen, und den Exceptiontext durchzureichen.

METHOD customerset_get_entity.
  TRY.
      ...
    CATCH cx_root INTO DATA(lr_ex).
      RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
        EXPORTING
          textid  = /iwbep/cx_mgw_busi_exception=>business_error
          message = |{ lr_ex->get_text( ) }|.
  ENDTRY.
ENDMETHOD.

Expertenwissen – Der SAP Cloud Connector einfach erklärt

Die Rolle des SAP Cloud Connector

Der SAP Cloud Connector ist ein zentraler Bestandteil hybrider SAP-Systemlandschaften. Er ermöglich Ihnen eine sichere Integration der Services und Subskriptionen in der SAP Business Technology Platform (SAP BTP) in Ihre On-Premise-Landschaft. Die SAP BTP wurde vor 2021 auch SAP Cloud Platform (SAP CP) genannt. Ein gutes Verständnis der Grundlagen des SAP Cloud Connector ist für einen schnellen, effizienten und sicheren Start unerlässlich. Die Grundlagen erfahren Sie in diesem Artikel.

In unseren Expert Talk Videos erklären wir Ihnen auf unserem legendären Lightboard alles zum SAP Cloud Connector. Das Lightboard ist ein handgefertigtes Unikat das fantastische Erklärungen möglich macht – lassen Sie sich überraschen.

Inhalt

  • Funtionsweise
  • Voraussetzungen
  • Installationsoptionen
  • Einsatzszenarien
  • Konnektivität
    • Verbindung mit der SAP BTP
    • Verbindung mit den Backends
  • Sicherheit
    • Benutzerauthentifizierung
    • SSL-Zertifikat
  • Lightboard-Video SAP CC Grundlagen
  • Mehrsystemlandschaften
    • Verwendung der Location ID
    • Empfehlungen
  • Lightboard-Video Mehrsystemlandschaft 

Wie funktioniert der SAP Cloud Connector ?

Der SAP Cloud Connector ist eine Softwarekomponente die Sie in Ihrer On-Premise-Landschaft installieren und einen TLS Tunnel in die SAP BTP herzustellen. Um konkret zu sein wird eine Verbindung zu Ihrem Subaccount hergestellt.

Der SAP Cloud Connector verwendet den Reverse-Invoke-Proxy Ansatz. D.h. er stellt Ihnen auf Ebene des Subaccount Endpunkte bereit die von den SAP Cloud Services wie SAP Cloud Integration, SAP WebIDE, SAP Mobile Services oder SAP Cloud Portal aufgerufen werden. Er nimmt Ihre Aufrufe aus der SAP Cloud entgegen und leitet Sie an die gewünschten On-Premise-Systeme weiter.

SAP Cloud Connector vs. HANA Cloud Connector

Sie werden in vielen Blogs und auf Webseiten noch vom HANA Cloud Connector lesen. Dieser wurde im Jahr 2017 auf den Namen SAP Cloud Connector umgetauft. Sollten Sie noch vom SAP HANA Cloud Connector oder der HANA Cloud Platform lesen, raten wir Ihnen sich aktuellere, zeit- und technologiegemäße Blogs zu suchen. Die Zeitspanne von mehr als drei Jahren seit der Umbenennung sind im Cloud Zeitalter ungefähr so wie wenn Sie noch immer in der Bronzezeit leben und denken würden.

Welche Voraussetzung bestehen für den Cloud Connector ?

Für den Betrieb des SAP CC benötigen Sie lediglich eine JVM. Er steht seit Jänner 2021 in der Version 2.13 für Sie zur Verfügung. Netzwerkkonnektivität ist eine wesentliche Voraussetzung die Sie beachten müssen.

Der SAP CC muss ausgehend unter Verwendung des HTTPS-Protokolls die Hosts der SAP Business Technology Platform ansprechen können. Andererseits müssen Sie auch die gewünschten Backendsysteme technisch erreichbar machen. Mit der Version 2.13 sind einige spannende Neuerung gekommen. Vor allem mit Blick auf Principal Propagation aus der Cloud Foundry Umgebung hat SAP sehr viel getan um Sie bestmöglich zu unterstützen.

Installationsoptionen

Sie können den SAP Cloud Connector auf Windows, MacOS und Linux ausgeführen. Die aktuellste Version 2.13 können Sie über https://tools.hana.ondemand.com/#cloud beziehen. Sie können Sie Installation sowohl standalone als auch hochverfügbar durchführen. Hochverfügbar bedeutet dass Sie einen Master Node und einen Shadow Node installieren. Es spielt keine Rolle ob Sie die Installation auf Ihrem lokalen Rechner, in Ihrem Rechenzentrum, bei Ihrem Hosting-Anbieter oder sogar in der HANA Enterprise Cloud (HEC) durchführen.

Was bedeutet On-Premise ?

Mit dieser Frage werden wir häufig konfrontiert und sie lässt sich einfach beantworten. Unter On-Premise verstehen wir die von Ihnen oder Ihrem Hosting-Anbieter betriebenen Systeme. Diese laufen entweder in Ihrem eigenen Rechnezentrum, bei Ihrem Hosting-Anbieter oder in der SAP HEC.  

CloudDNA GmbH

Wir haben die Cloud in unserer DNA! Unsere Mitarbeiter beschäftigen sich seit 2005 mit SAP Integration und seit 2013(!) mit der SAP Cloud Platform bzw. SAP BTP, SAP HANA und SAPUI5 / Fiori. Wir werden von unseren Kunden als Subject-Matter-Experts bezeichnet. Kontaktieren Sie uns unverbindlich, wenn auch Sie mit den Besten ihres Fachs zusammenarbeiten möchten.

Einsatzszenarien des SAP Cloud Connector

Wie Sie bereits gelesen haben, spielt der SAP Cloud Connector eine zentrale Rolle, wenn Sie eine sichere Verbindung zwischen der SAP Cloud und Ihrer OnPremise Landschaft herstellen möchten. Er ermöglicht Ihnen, sowohl die SAP Neo als auch die SAP Cloud Foundry Umgebung sicher anzubinden. Typischerweise verwenden Sie ihn für die Kommunikation in Cloud-2-OnPremise Szeanrien verwendet. Es ist aber für bestimmte Szenarien auch möglich dass Sie den SAP Cloud Connector für die Kommunikation OnPremise-2-Cloud verwenden.

Wie funktioniert der Cloud Connector Der SAP Cloud Connector (CC) spielt eine zentrale Rolle wenn es um die Integration von der Cloud Landschaft in die On - premise Landschaft geht Österreich Deutschland Schweiz

Verbindung mit der SAP Business Technology Platform

Der SAP Cloud Connector verbindet sich mit der Business Technology Platform auf Ebene des von Ihnen verwalteten Subaccount. Der SAP CC authentifiziert sich mit einem Benutzer der vom Ihrem Platform Identity Provider (Platform IdP) verwaltet wird. Als Platform IdP können Sie entweder den SAP ID Service oder den SAP Identity Authentication Service (SAP IAS) verwenden. Bei der erstmaligen Anmeldung, die Sie währen der Konfiguration durchführen, wird für den Benutzer ein Client Zertifikat erstellt. Das Zertifikat wird in weiterer Folge für die Authentifizierung gegen Ihren Subaccountverwendet wird. Es wird am Dateisystem Ihres Cloud Connectors gespeichert. Daher müssen Sie bei einer Änderung des Kennworts am IdP das Kennwort im Cloud Connector nicht aktualiseren.

Anbindung der Backend-Systeme

Der SAP Cloud Connector stellt Ihre Backend-Systeme im Subaccount unter einem virtuellen Hostnamen und zugehörigem Port bereit. Diesen virtuellen Hostnamen müssen Sie in den Cloud Services auf Ebene der Subaccounts zwingend verwenden. Für die Verbindung kommt im Subaccount der sogenannten Connectivity Service zur Verwendung. Er stellt über den On-Premise-Proxy technisch die Verbindung zum Ihrem Cloud Connector her.

Der Cloud Connector bildet den virtuellen Hostnamen auf den physischen Hostnamen Ihrer OnPremise Systeme ab. D.h. Sie verwenden im Subaccount den virtuellen Host und er führt ein Mapping auf den physischen Host durch. Zusätzlich müssen Sie im Cloud Connector definieren, welche Ressourcen aus dem Backend über den Cloud Connector angesprochen werden können. Dies entspricht im Falle eines SAP-ABAP-Systems den ICF-Knoten. Sie können den Cloud Connector für folgende Protokolle verwenden:

  • HTTP / HTTPS
  • RFC / RFC (SNC)
  • TCP / TCPS
  • Mail (SMTP, POP3, IMAP)
  • LDAP / LDAPS
  • SFTP / FTP / FTPS

Sicherheitsaspekte

Es gibt eine Reihe an sicherheitsrelevanten Aspekten die Sie im Cloud Connector beachten müssen. Die Authentifizierung Ihrer Administratoren und anderen Benutzer gegen einen LDAP Server ist eine essentielle Empfehlung. Sie sollten auch das selbst signierte SSL-Zertifikat mit dem der CC im Standard ausgeliefert wird so schnell wie möglich durch eines mit dem Hostnamen als CN ersetzen.

UI Zugriff via HTTP / SSL Zertifikat

Das Administrations User Interface des SAP Cloud Connector erreichen Sie ausschließlich über https. Sollten Sie sich für eine Standardinstallation entscheiden, wird es an den Port 8443 gebunden. Den Port können Sie jederzeit über das Skript changeport.bat bzw. changeport.sh ändern. Der SAP Cloud Connector wird mit einem selbstsignierten SSL Zertifikat ausgeliefert. Wir empfehlen Ihnen dieses Zertifikat durch ein offizielles Zertifikat zu ersetzen. Im SAP Cloud Connector können Sie dafür direkt einen Certificate Signing Request (CSR) erstellen.

Benutzerauthentifizierung

Im Standard wird der Cloud Connector als Single-User Instanz ausgeführt. Den SAP Cloud Connector müssen ausschließlich Ihre Administratoren erreichen. Der Standard-Benutzername lautet Administrator und das zugehörige Kennwort lautet manage. Das Kennwort müssen Sie beim ersten Start zwingend ändern. Wir empfehlen Ihnen zur Authentifizierung der Administratoren eine Anbindung an einen LDAP Server. Dadurch können unterschiedliche Administratoren Ihres Unternehmens gleichzeitig mit dem SAP Cloud Connector arbeiten. Sie können somit im Audit Log auch festgestellen welcher Benutzer welche Änderungen durchgeführt hat. Bei der Authentifizierung mittels LDAP stehen Ihnen vier Rollen zur Verfügung:

  • Administrator (sccadmin)
  • Display (sccdisplay)
  • Monitor (sccmonitor)
  • Support (sccsupport)

Die Rollennamen im LDAP können Sie übersteuern. Die Anbindung des LDAP können Sie optional auch über das LDAPS durchführen. Zusätzlich haben Sie die Möglichkeit einen alternativen LDAP Server anzubinden und Sie sind somit für den Ausfall des LDAP Servers gerüstet.

Infos zum WDECPS (SAP Standard Training)

Der SAP WDECPS bietet Ihnen eine 5-tägige praxisnahe Einführung in alle Sicherheitsaspekte der SAP Cloud Platform. Es werden sowohl die Neo als auch die Cloud Foundry Umgebung ausführlich behandelt 

Das Architekturvideo zum Expert Talk

Im Video zeigen wir Ihnen Schritt für Schritt wie der SAP Cloud Connector funktioniert. Wir hoffen Ihnen damit weiterhelfen zu können. Kontaktieren Sie und für Fragen und auch Unterstützung in Projekten. Wir sind für Sie da – Online und auch weltweit vor Ort.

Folgen Sie unserem Youtube Channel um keine Neuigkeiten zu verpassen. Wir veröffentlich in regelmäßigen Intervallen Videos zur SAP BTP die Sie interessieren werden.

Ich bin ein absoluter Fan der Trainings und Erklärungen von Martin Koch. Die Videos am Lightboard schaffen es glatt, seine legendären Trainings zu übertreffen. Die Erklärung ist absolut idiotensicher. „LEGENDÄR“

Oliver F.

SAP Architekt

Verschieden Cloud Connector Instanzen mit demselben Subaccount verbinden

Sie können den SAP Cloud Connector (CC) für unterschiedlichste Szenarien verwenden. Unter anderem auch um sich aus einer geografisch verteilten Systemlandschaft mit einem Subaccount der SAP BTP zu verbinden. Damit können Sie unter Verwendung der SAP Cloud Platform Integration (SAP CPI) bzw. der SAP Integration Suite Schnittstellen in die On-Premise-Landschaft sicher umsetzen. Wir zeigen Ihnen wie die SAP Cloud Connector Location Identifier richtig verwendet wird.

Wie können sie den SAP® Cloud Connector mit unterschiedlichen SAP® Accounts verbinden aus verschiedenen Ländern CloudDNA Team Österreich Deutschland Graz Linz Wien Schweiz

SAP Cloud Integration Kommunikation über den SAP Cloud Connector

Gehen wir von folgender Annahme aus. Sie haben eine SAP CPI (Cloud Platform Integration) oder die SAP Integration Suite mit aktiver Cloud Integration Capability. Sie möchten aus der Cloud Integration heraus über den SAP Cloud Connector (CC) eine Verbindung zu einem System in der On-Premise-Landschaft herstellen. Der SAP Cloud Connector öffnet dazu einen TLS Tunnel (=Transport Level Security) zum Subaccount. Über diesen Tunnel läuft der gesamte Traffic aus der Cloud in die On-Premise-Systemlandschaft. Dies funktioniert sowohl bei SAP- als auch bei Non-SAP-Systemen.

Die SAP Cloud Connector LocationID

Wir gehen in unserer Annahme ein Schritt weiter. Sie müssen Gesellschaften in unterschiedlichen Ländern oder in unterschiedlichen geografischen Regionen über die SAP CPI integrieren. Sie können für dieses Szenario in jeder Region in der Sie ein Backendsystem integrieren möchten einen Cloud Connector installieren. Der Subaccount in der SAP BTP bzw. der SAP Cloud Platform könnte nun nicht mehr unterscheiden über welchen Cloud Connector die Nachrichten in die On-Premise-Landschaft gesendet werden. Auch dafür bietet der SAP CC eine Lösung. Es ist lediglich erforderlich, dass jede Cloud Connector Instanz beim Aufbau der Verbindung mit dem Subaccount eine Location-ID (LOC) verwendet.

Funktioniert in der Neo- und Cloud-Foundry-Umgebung

Die SAP Cloud Connector LocationID wird sowohl für die Neo- als auch für die Cloud-Foundry-Umgebung unterstützt. Die Kommunikation aus den Services und Subskriptionen auf Ebene des Subaccount erfolgt immer über den Connectivity Service. Dieser bedient sich der über den Destination Service angelegten Destinationen. Diese beinhalten die technische Konfiguration. In der Destination muss die Location-ID ebenfalls gepflegt werden. Sie haben jedoch auch die Möglichkeit, einen Cloud Connector als Default zu verwenden. Dazu dürfen Sie keine Location-ID anführen.

Unsere Empfehlung

Wir verwenden in unseren Projekten, die wir gerne auch für Sie übernehmen, SAP Cloud Connector Location Identifier die an die IATA 3-Letter-Codes in der Luftfahrt angelehnt sind. Die Begründung dafür ist recht einfach. Ich bin ausgebildeter Linienpilot und Fluglotse. Ich habe erkannt hat dass man die Standardisierung und Normierung in der Luftfahrt absolut gewinnbringend in der IT verwendet werden kann. Wenn Sie die Liste der IATA-Codes prüfen, werden Sie erkenne, dass es kein Duplikate gibt. Folgende Beispiele für Location-IDs können wir Ihnen als Inspiration geben:

  • Wien (VIE)
  • Berlin (BER) – mittlerweile ja fertiggestellt…
  • Frankfurt (FRA)
  • New York (NYC)
  • Sydney (SYD)
  • Dubai (DUB)

Unser Video Expert Talk zum Location Identifier

Im Video bauen wir diese Szenario Schritt für Schritt für Sie auf. Wir hoffen Ihnen damit weiterhelfen zu können und Sie dem Cloud Connector Expert Level einen Schritt näher zu bringen. Für Fragen und auch Unterstützung in Projekten stehen wir Ihnen gerne zur Verfügung.

Folgen Sie unserem Youtube Channel um keine Neuigkeiten zu verpassen. Wir veröffentlich in regelmässigen Intervallen Videos zur SAP Cloud Platform.

Über den Autor

Martin Koch

Martin Koch

Managing Director

Ich bin SAP Cloud Berater, Architekt und Entwickler der ersten Stunde. Neben der SAP Cloud Platform entwickle ich seit dem allerersten Release SAPUI5 und SAP Fiori Apps. Für SAP bin ich erfolgreich als Trainer im Bereich neue Technologien (Cloud, Integration, SAPUI5, Fiori, Mobile, SAP HANA, Security) im Einsatz. Seit 2021 bin ich SAP Press Autor im Bereich der SAP Business Technology Platform.

Verlieren Sie keine Zeit - kontaktieren Sie uns jetzt

Zögern Sie nicht uns zu kontaktieren. Mit Fragen zum SAP Cloud Connector, zur SAP BTP, zur SAP Cloud Platform, zur SAP CPI, zur SAP Integration Suite und anderen innovativen Themen sind Sie bei uns genau an der richtigen Adresse!

Ihre Nachricht an uns