RSS

Archiv der Kategorie: SAP

SAP Netweaver AS Java: Deployment von ear Dateien

SAP Netweaver AS Java: Deployment von ear Dateien

Motivation

Es gibt so viele Dateiformate für das Deployment auf Applikationsservern, insbesondere in der SAP Umgebung, da verliert man mal schnell den Überblick. Ich habe im Artikel Dateiformate für Web-Applikationen (EAR, JAR, WAR etc.) schon einen Einblick in die „üblichen Verdächtigen“ gegeben. Beim SAP Netweaver AS Java wird das Ganze noch einmal etwas komplizierter. Hier darf man sich noch mit sca und sda Dateien herumschlagen.

Die Frage nach dem Warum und Weshalb bleibt dem Schöpfer überlassen.

Doing

Wie macht man aber nun aus einem ear File eine SAP konforme sca-Datei ?

  1. NWPACKTOOL aus Hinweis 1223957 installieren (SUSER erforderlich)
  2. Aus .ear file ein SDA file machen (hat dann weiterhin die Endung .ear)
  3. sda File erstellen:

    createsda –n jndi name –v vendor name –l jndi name –c 2 –type J2EE SourceEarFileLocation TargetSDAFileLocation

    – JNDI name/application name : same as that u have mentioned under ejb-j2ee-engine.xml while developing the module(like „ModuleDeploy“)

    – Vendor name: can be anything like „pi.module“ (but it should be less than 20 characters).

    – SourceEarFileLocation: Give the EAR file location.

    – TargetSDAFileLocation: Mentioned the location where you want to create ur SDA file.

    Beispiel:
    createsda –n ModuleDeploy –v pi.module –l ModuleDeploy –c 2 –type J2EE C:EARTest.ear c:result8SDATest

  4. sca file erstellen:
    packsca –n SCName –v Vendor –l location (z.B. Kunde) –r Release (z.B. 1.0) –sp Service Level (z.B. 1)  –pl Patch Level (z.B. ) –da Quellverzeichnis mit sda Dateien –includingsubdirs Zieldatei (sca)

    Beispiel: 
    A SCA named di_test.sca is created. It contains every SDA located in the directory c:testsda and its subdirectories. Also, every build archive located in the directory c:testbas and its subdirectories is packed into the resulting SCA:

    packsca –n di_test –v test.com – l testfactory –c 12 –r 6.45 –sp 2 –pl 0 –da c:testsda –ba c:testbas –includingsubdirs c:di_test.sca

     

Fazit

 Warum einfach, wenn es auch kompliziert geht? Ist halt SAP, da muss es einfach etwas komplizierter sein 😉

Links

Erstellen von SDA- und SCA-Archiven

Convert EAR file to SDA file

packsca

 

Schlagwörter: , , , ,

SAP NW IdM: Zugriff auf die IdM DataSource mit Java

SAP NW IdM: Zugriff auf die IdM DataSource mit Java

Motivation

Um auf die IdM Datenbank von einem SAP NW AS Java zuzugreifen, kann man sich eine DataSource anlegen. Wenn man sich auf dem AS Java befindet, auf dem die UI für IdM deployed ist, kann man die vorhandene DataSource nutzen. Bei Verwendung der DataSource hat man gegenüber dem „DriverManager“ den Vorteil, dass alle Verbindungsparameter zentral im Applikationsserver definiert werden können, man benötigt also im Code keine Parameter für beispielsweise Username, Passwort etc.

Vorgehensweise

Dazu startet man den Netweaver Administrator (NWA)  und geht auf: Konfiguration > Infrastruktur > Anwendungsressourcen:

Falls vorhanden, sollte man auf dem AS Java für die IdM UI folgende DataSource vorfinden: 

 

Die folgende Einstellungen besitzt:

Um nun eine DataSource anzulegen, geht man wie folgt vor:

Anlegen einer neuen Ressource vom Typ „Neue JDBC-Custom-DataSource“:

Anschließend übernimmt man die o.g. Einstellungen.

Wenn man eine Applikation deployed, die auf diese Ressource bzw. Datenbank zugreifen soll, kann man das relativ einfach, mit folgenden Code erledigen. Im Beispiel wird davon ausgegangen, dass eine DataSource mit Namen „IDM_DataSource“ angelegt wurde bzw. existiert:

import java.sql.*;
import javax.naming.*;
import javax.sql.*;

final class GetConnection {

  /** Uses JNDI and Datasource (preferred style).   */
  static Connection getJNDIConnection(){
    String DATASOURCE_CONTEXT = "jdbc/IDM_DataSource";

    Connection result = null;
    try {
      Context initialContext = new InitialContext();
      if ( initialContext == null){
        log("JNDI problem. Cannot get InitialContext.");
      }
      DataSource datasource = (DataSource)initialContext.lookup(DATASOURCE_CONTEXT);
      if (datasource != null) {
        result = datasource.getConnection();
      }
      else {
        log("Failed to lookup datasource.");
      }
    }
    catch ( NamingException ex ) {
      log("Cannot get connection: " + ex);
    }
    catch(SQLException ex){
      log("Cannot get connection: " + ex);
    }
    return result;
  }
...
}

Als Vergleich: die konventionelle Vorgehensweise über den DriverManager am Beispiel MySQL:

import java.sql.*;
import javax.naming.*;
import javax.sql.*;

final class GetConnection {

  /** Uses DriverManager.  */
  static Connection getSimpleConnection() {
    //See your driver documentation for the proper format of this string :
    String DB_CONN_STRING = "jdbc:mysql://localhost:3306/airplanes";
    //Provided by your driver documentation. In this case, a MySql driver is used : 
    String DRIVER_CLASS_NAME = "org.gjt.mm.mysql.Driver";
    String USER_NAME = "juliex";
    String PASSWORD = "ui893djf";
    
    Connection result = null;
    try {
       Class.forName(DRIVER_CLASS_NAME).newInstance();
    }
    catch (Exception ex){
       log("Check classpath. Cannot load db driver: " + DRIVER_CLASS_NAME);
    }

    try {
      result = DriverManager.getConnection(DB_CONN_STRING, USER_NAME, PASSWORD);
    }
    catch (SQLException e){
       log( "Driver loaded, but cannot connect to db: " + DB_CONN_STRING);
    }
    return result;
  }
...
}

Egal, für welchen Weg man sich entscheidet (DataSource im AS Java oder DriverManager), es wird ein Handle auf die Datenbank vom Typ „Connection“ zurückgegeben. Mit „Connection“ kann man dann alle üblichen Operationen (SQL-Statements etc.) auf der Datenbank ausführen, siehe „Lesson: JDBC Basics„.

Fazit

Im Interesse der Wartbarkeit eines Systems sollte man bei Verwendung eines Applikationsservers (egal ob IBM Websphere, SAP Netweaver, JBoss etc.) immer den Weg der DataSource gegenüber dem „DriverManager“ vorziehen. Man macht seinen Code dadurch flexibler und unabhängig von irgendwelchen systemspezifischen Einstellungen.

motivation

To connect to the IdM (Identity Management) database of SAP NW IdM you can use the ‚old-style‘ ‚DriverManager‘ class or you can use the ‚DataSource“ mechansim provided by SAP NetWeaver AS Java. Wenn man sich auf dem AS Java befindet, auf dem die UI für IdM deployed ist, kann man die vorhandene DataSource nutzen. Bei Verwendung der DataSource hat man gegenüber dem „DriverManager“ den Vorteil, dass alle Verbindungsparameter zentral im Applikationsserver definiert werden können, man benötigt also im Code keine Parameter für beispielsweise Username, Passwort etc.

Vorgehensweise

Dazu startet man den Netweaver Administrator (NWA)  und geht auf: Konfiguration > Infrastruktur > Anwendungsressourcen:

Falls vorhanden, sollte man auf dem AS Java für die IdM UI folgende DataSource vorfinden: 

 

Die folgende Einstellungen besitzt:

Um nun eine DataSource anzulegen, geht man wie folgt vor:

Anlegen einer neuen Ressource vom Typ „Neue JDBC-Custom-DataSource“:

Anschließend übernimmt man die o.g. Einstellungen.

Wenn man eine Applikation deployed, die auf diese Ressource bzw. Datenbank zugreifen soll, kann man das relativ einfach, mit folgenden Code erledigen. Im Beispiel wird davon ausgegangen, dass eine DataSource mit Namen „IDM_DataSource“ angelegt wurde bzw. existiert:

import java.sql.*;
import javax.naming.*;
import javax.sql.*;

final class GetConnection {

  /** Uses JNDI and Datasource (preferred style).   */
  static Connection getJNDIConnection(){
    String DATASOURCE_CONTEXT = "jdbc/IDM_DataSource";

    Connection result = null;
    try {
      Context initialContext = new InitialContext();
      if ( initialContext == null){
        log("JNDI problem. Cannot get InitialContext.");
      }
      DataSource datasource = (DataSource)initialContext.lookup(DATASOURCE_CONTEXT);
      if (datasource != null) {
        result = datasource.getConnection();
      }
      else {
        log("Failed to lookup datasource.");
      }
    }
    catch ( NamingException ex ) {
      log("Cannot get connection: " + ex);
    }
    catch(SQLException ex){
      log("Cannot get connection: " + ex);
    }
    return result;
  }
...
}

Als Vergleich: die konventionelle Vorgehensweise über den DriverManager am Beispiel MySQL:

import java.sql.*;
import javax.naming.*;
import javax.sql.*;

final class GetConnection {

  /** Uses DriverManager.  */
  static Connection getSimpleConnection() {
    //See your driver documentation for the proper format of this string :
    String DB_CONN_STRING = "jdbc:mysql://localhost:3306/airplanes";
    //Provided by your driver documentation. In this case, a MySql driver is used : 
    String DRIVER_CLASS_NAME = "org.gjt.mm.mysql.Driver";
    String USER_NAME = "juliex";
    String PASSWORD = "ui893djf";
    
    Connection result = null;
    try {
       Class.forName(DRIVER_CLASS_NAME).newInstance();
    }
    catch (Exception ex){
       log("Check classpath. Cannot load db driver: " + DRIVER_CLASS_NAME);
    }

    try {
      result = DriverManager.getConnection(DB_CONN_STRING, USER_NAME, PASSWORD);
    }
    catch (SQLException e){
       log( "Driver loaded, but cannot connect to db: " + DB_CONN_STRING);
    }
    return result;
  }
...
}

Egal, für welchen Weg man sich entscheidet (DataSource im AS Java oder DriverManager), es wird ein Handle auf die Datenbank vom Typ „Connection“ zurückgegeben. Mit „Connection“ kann man dann alle üblichen Operationen (SQL-Statements etc.) auf der Datenbank ausführen, siehe „Lesson: JDBC Basics„.

Fazit

Im Interesse der Wartbarkeit eines Systems sollte man bei Verwendung eines Applikationsservers (egal ob IBM Websphere, SAP Netweaver, JBoss etc.) immer den Weg der DataSource gegenüber dem „DriverManager“ vorziehen. Man macht seinen Code dadurch flexibler und unabhängig von irgendwelchen systemspezifischen Einstellungen.

 

Schlagwörter: , , , , , ,

SAP PI: Benutzer für den Nachrichtenaustauch (Kommunikationsuser)

SAP PI: Benutzer für den Nachrichtenaustauch (Kommunikationsuser)

Motivation

Für die Kommunikation externer Applikationen bzw. Systeme mit SAP PI empfiehlt es sich sog. technische Benutzer (Service User) zu verwenden. Sie sind nicht an eine bestimmte Person gebunden, können sich nicht einloggen (wie etwa Dialog User) und laufen nicht ab. Zudem erleichtert die Verwendung verschiedener Kommunikationsuser später das Monitoring und die Fehlersuche.

Benutzertypen

In SAP PI gibt es zwei Benutzertypen:

  • Dialog User:
    Repräsentieren „menschliche“ Benutzer, die Zugriff auf die PI Tools (ESR, ID oder SLD) benötigen
  • Service User:
    Technische Benutzer, die eine Kommunikation zwischen den verschiedenen PI Komponenten ermöglichen. Das gilt sowohl für die interne Kommunikation, als auch für die Kommunikation von externen Applikationen mit dem PI, aka Message Exchange.

Kommunikationsuser für PI

Damit eine Anwendung mit dem PI kommunizieren kann, verbindet sie sich entweder mit der Adapter Engine (J2EE Stack), oder direkt mit der Integration Engine (ABAP-Stack). Bei der Standard-Installation von PI ist es notwendig dem Benutzer die Rolle SAP_XI_APPL_SERV_USER im ABAP Stack zuzuweisen. Für die Verwendung der Advanced Adapter Engine Extended (AEX) bzw. die J2EE Stand-Alone-Installation siehe User Management for AEX.

Die Rolle SAP_XI_APPL_SERV_USER beinhaltet automatisch die Berechtigung zur Ausführung des IDOC-Adapters und des Plain-HTTP-Adapters! Desweiteren ist sie ausreichend zur Kommunikation mit folgenden Komponenten:

  • ABAP Proxy Sender und Empfänger
  • Java Proxy Sender und Empfänger
  • Advanced Adapter Engine (AAE)
  • Integration Server
Während der Installation von SAP PI wird der Benutzer PIAPPLUSER angelegt und die Rolle SAP_XI_APPL_SERV_USER zugewiesen. PIAPPLUSER sollte als Referenzkopie für weitere Kommunikationsuser verwendet werden.
Für die AAE und das PCK (Partner Connectivity Kit) wird die Rolle xi_af_receiver der Komponente sap.com/com.sap.aii.af.ms.app*MessagingSystem für die Verarbeitung eingehender Nachrichten benötigt.

Links:

SAP Help Portal: SAP Netweaver PI

SAP Help Portal : Message Exchange

SAP Help Portal: SAP NetWeaver Process Integration Security Guide (> User Management and Authorization Concepts)

SAP NetWeaver 7.3.1 Process Integration Troubleshooting Guide (7.3, 7.11)

Motivation

It is a good idea to use so called technical users (aka service users) for the message exchange of external application with SAP Netweaver Process Integration (PI). Why? Because they have several advantages compared with a ‚human‘ user (aka dialog user): they are not bound to an individual person, they cannot login to the PI system and their password will not expire. Furthermore, especially in a productive environment, different communication users for different applications or scenarios simplify monitoring and troubleshooting.

Types of users

Pi distinguish mainly between the following user types:

  • Dialog User:Human users that need access to PI tools like (ESR, ID oder SLD)
  • Service User:Technical users that enable the communication between the different PI components. They are used for the internal communication and for the Message Exchange with external applications or systems as well.

Communication user for PI

An external application or system usually wants to connect to the Adapter Engine (running on the J2EE stack) or directly with the Integration Engine (running on the ABAP stack). To enable the communication with the ABAP stack, you have to assign the role  SAP_XI_APPL_SERV_USER to a communication user. For communication with the Advanced Adapter Engine Extended (AEX) which is the J2EE Stand-Alone-Installation of PI, please have a look at User Management for AEX.

The role SAP_XI_APPL_SERV_USER includes the execution of the IDOC and the Plain-HTTP-Adapters! Furthermore it enables the communication with the following PI components:

  • ABAP proxy sender and receiver
  • Java proxy sender and receiver
  • Advanced Adapter Engine (AAE)
  • Integration Server
To create a communication user, you can use the user PIAPPLUSER as a master copy, which is created during the installation of PI – it has already the role SAP_XI_APPL_SERV_USER assigned.
For the AAE and the PCK (Partner Connectivity Kit) you have to assign the role xi_af_receiver of component sap.com/com.sap.aii.af.ms.app*MessagingSystem to enable execution of incoming messages.

Links:

SAP Help Portal: SAP Netweaver PI

SAP Help Portal : Message Exchange

SAP Help Portal: SAP NetWeaver Process Integration Security Guide (> User Management and Authorization Concepts)

SAP NetWeaver 7.3.1 Process Integration Troubleshooting Guide (7.37.11)

 
Hinterlasse einen Kommentar

Verfasst von - September 3, 2012 in Applikationsserver, SAP

 

Schlagwörter: , , ,

SAP PI: Mit dem Condition-Editor Teilstrings abfragen

SAP PI: Mit dem Condition-Editor Teilstrings abfragen

Im Rahmen eines Projektes habe ich ein bisher mir unbekanntes Feature des Condition-Editors von PI entdeckt, nämlich das Überprüfen von Substrings. Das läßt sich beispielsweise in einer Receiver- oder Interface-Determination einsetzen. Man will in einem Feld überprüfen, ob z.B. die ersten 3 Zeichen einer bestimmten Zeichenkette entsprechen und wenn das der Fall ist, wird der Empfänger A, ansonsten aber der Empfänger B ausgewählt.

Beispiel:

Nachricht (Outbound/Eingang PI):

Receiver Determination:

Zu diesem Zweck erstellt man mit dem Condition-Editor eine Bedingung, die das entsprechende Feld in eckige Klammern einschließt (ohne vorangegangenen Slash „/“), ruft die Substring Funktion auf und wählt Startindex und Endindex. Achtung: Der Endindex wird nicht mehr mit dargestellt! Durch einen Gleichheitsoperator werden die booleschen Werte „true“ oder „false“ zurückgegeben:

/p1:idmGetProcessStatus/request[substring(system,1,3)=‘SME‚]

Der Operator „Ex“ überprüft, ob das Feld existiert oder nicht. Es existiert, wenn der boolesche Wert „true“ ist und es existiert nicht, wenn der boolesche Wert „false“ ist.

Im Beispiel (Receiver Determination) wird auf die Zeichenketten „SME“ und „E97“ überprüft. Ist im Feld „system“ der Wert „SMEabc“ oder „SME1234“ etc. eingetragen, beginnt also der Feldinhalt mit der Zeichenkette „SME“, dann wird in das System der oberen Zeile geroutet, beginnt der Feldinhalt mit „E97“ wird in das System der unteren Zeile geroutet. Triff keine der beiden Bedingungen zu, schlägt die Nachricht fehl („No receiver found“).

Links:

SDN: Xpath Condition in Receiver Determination

help.sap.com: Condition Editor

help.sap.com: StandardfunktionenIn a project I discoverd a feature of SAP PI, which I did not realize in the past. It is a feature of the condition editor in combination with the usage of the Java substring function.If you want to use the features of this function in combination with the condition-editor, you can use it. For example, you want to check whether the first 3 characters of a particular string in a XPath-field match. If that’s the case, the receiver A is selected and otherwise the receiver B is selected. This is one approach to implement content based routing.

Example:

Message (Outbound sender/Inbound PI):

Receiver Determination:

In order to let this work, you have to define a conditon like this:

/p1:idmGetProcessStatus/request[substring(system,1,3)=‘SME‚]

The „Ex“ operator is use to check if a field or a condition exists. With our condition the field only exists, if the first three character match, otherwise not!

Links:

SDN: Xpath Condition in Receiver Determination

help.sap.com: Condition Editor

help.sap.com: Standardfunktionen

 
Hinterlasse einen Kommentar

Verfasst von - August 2, 2012 in SAP

 

Schlagwörter: , , ,

SAP ALE: Stammdaten-IDocs verteilen

SAP ALE: Stammdaten-IDocs verteilen

Definition

Stammdaten (engl. Master Data) zeichnen sich dadurch aus, dass sie eine relativ lange Verweildauer im System haben, in dieser Zeit aber eher selten geändert werden.

Arten

Es gibt eine Vielzahl von Stammdaten für unterschiedlichste Bereiche, z.B. Vertrieb, Logistik, Personalverwaltung, etc. Es gibt aber auch Stammsätze die von verschiedenen Bereichen genutzt werden können. Durch die Verwendung von zentralen Stammsätzen entfällt eine redundante Datenhaltung. Ein Beispiel dafür ist der Materialstamm. Der Materialstamm ist ein zentraler Stammsatz, um die Informationen bezüglich Artikel, Teile und Dienstleistungen zu speichern, die ein Unternehmen beschafft, fertigt und lagert. Der Materialstamm stellt das zentrale Informationsobjekt für die Auftragsabwicklung dar. Der Materialstamm wird von sämtlichen Abteilungen wie zum Beispiel Einkauf, Verkauf, Produktion, Buchhaltung und Controlling genutzt.

Sichten

Die Abteilungen müssen nicht alle Informationen des Materialstammes sehen. Es werden deshalb unterschiedliche Sichten definiert, die Felder bzw. Informationen eines Stammdatensatzes definieren und darstellen.

SMD-Werkzeug: Änderungen sammeln und verteilen

Änderungen an Stammdatenobjekten werden über das SMD-Werkzeug (Shared Master Data) verwaltet. Das SMD-Werkzeug dient der Verteilung von Stammdatenänderungen an dezentrale Systeme.

Das SMD-Werkzeug sorgt dafür, dass Änderungen an Stammdatenobjekten zusammengeführt werden.

Das SMD-Werkzeug ist an die Änderungsbelegschnittstelle angeschlossen. Ist ein Stammdatum verteilungsrelevant, schreibt die Anwendung einen Änderungsbeleg. Der Inhalt wird an das SMD-Werkzeug übergeben. Sind die Felder verteilungsrelevant, werden vom SMD-Tool Änderungszeiger (Change Pointer) geschrieben und in den Tabellen BDCP und BDCPS abgelegt – danach wird ein Master-IDoc erzeugt. Das Master-IDoc wird von der ALE-Schicht übernommen und an interessierte Systeme versendet.

Zum Verteilen von geänderten Stammdaten müssen die Änderungszeiger weiterverarbeitet werden. Dabei werden, abhängig vom Nachrichtentyp, Stamm-IDocs erzeugt und zum Versenden an die ALE-Schicht weitergegeben. Dazu dient das Program RBDMIDOC. Üblicherweise wird RBDMIDOC automatisch durch einen Hintergrund-Job ausgeführt, wobei ein Hintergrund-Job pro Nachrichtentyp einzuplanen ist. Abhängig von der Einstellung der Partnervereinbarungen kann es notwendig sein, das Versenden von IDocs durch Ausführen des Programms RSEOUT00 explizit anzustoßen.

Anhang

Generelle Verwaltung unter:
SALE -> Geschäftsprozesse modellieren und implementieren -> Verteilung von Stammdaten -> Replikation von geänderten Daten

Transaktionen:
WE81   Nachrichtentyp anlegen: Änderungszeiger definieren
BD52   Änderungszeiger bzw. Felder für den Änderungszeiger anlegen
BD60   Zusatzdaten des Änderungszeigers ergänzen: Wegen evtl. Umstellung auf BDCP2
BD50   Änderungszeiger aktivieren
BD53   Nachrichtyp reduzieren
BD61   Änderungszeiger generell aktivieren
BD21   Änderungszeiger auswerten

Reports:
RBDMIDOC   IDocs aus Änderungszeigern erzeugen
RSEOUT00    Übergabe der gesammelten IDocs and die Kommunikationsschicht

Links

ALE-Einführung und Administration

Mastering Business Scenarios with SAP Netweaver PI

 
Hinterlasse einen Kommentar

Verfasst von - Juli 21, 2012 in Allgemein, SAP

 

Schlagwörter: , , ,

SAP ABAP: SSL/SAP Cryptolib einrichten

SAP ABAP: SSL/SAP Cryptolib einrichten

Die SAP Cryptolib wird u.a. benötigt, um SSL Verbindungen auf dem ABAP Stack zu verwenden. Sie können die aktuelle Version vom Service Marketplace herunterladen. Vorher sollten Sie überprüfen, ob und welche Version auf Ihrem System installiert ist. Sie können auf einem ABAP Stack durch Eingabe der Transaktion STRUST > Environment > Display SSF Version überprüfen, ob die SAPCRYPTOLIB installiert ist und in welcher Version. Alternativ können Sie auf der Kommandozeile den Befehl sapgenpse ausführen.

Um den SAP ABAP Stack für die Verwendung von SSL zu konfigurieren, ist folgende Vorgehensweise empfehlenswert:

http://help.sap.com/saphelp_em70/helpdata/de/48/f6c6da490ad44987572237dd3ce0e2/content.htm

http://help.sap.com/saphelp_em70/helpdata/de/65/6a563cef658a06e10000000a11405a/frameset.htm

 

  1. Installation der SAP Cryptolib auf Ihrem Betriebssystem, Download vom Service Marketplace
  2. Konfiguration der Profilparameter mit der Transaktion RZ11.
  3. SSL Server PSE anlegen in der Transaktion STRUST
  4. Zertifikatsanforderung für SSL Server PSE
  5. Zertifikatsanforderung signieren lassen von CA
  6. Importieren der Antworten in die SSL Server PSE
  7. Pflegen der Zertifikatsliste der SSL Server PSE
  8. Durchstarten des ICM
    Um den ICM-Monitor durchzustarten, wählen Sie in der Transaktion SMICM > Administration > ICM > Restart > Yes
    Sie können über die Drucktaste Auffrischenüberprüfen, ob der ICM-Monitor wieder hochgefahren ist.Das System zeigt im Trust-Manager die inaktiven PSE-Ordner SSL-Server und SSL-Client (Standard) im linken Bildschirmbereich an. Inaktive Ordner sind mit einem roten Kreuz gekennzeichnet.
  9. Anlegen Client PSE

Installation der SAP Cryptolib überprüfen

1.      Führen Sie den Report SSF02 aus (SA38 > SSF02 > Ausführen > Ausführen)

2.      Setzen Sie das Kennzeichen Version ermitteln.

3.      Wählen Sie Ausführen.

Das System zeigt Ihnen die aktuelle Version der SAP Cryptolib.

 
Hinterlasse einen Kommentar

Verfasst von - März 30, 2012 in SAP

 

Schlagwörter: , , ,

Kurzmitteilung
SAP IdM: Anleitung für Installation 7.2

Um SAP IdM (Identity Mangement) 7.2 zu installieren, habe ich eine interessante Seite auf SCN gefunden: Implementation (Release 7.2)

SAP IdM: Anleitung für Installation 7.2

 
Hinterlasse einen Kommentar

Verfasst von - März 30, 2012 in SAP

 

Schlagwörter:

 
Erstelle eine Website wie diese mit WordPress.com
Jetzt starten