SPROXY error: “No connection to ESR”
When calling transaction SPROXY, we receive the following error “error has occurred during communication with ESR” – please look at the screen below.
ESR -> Enterprise Services Repository
SSFS (Secure Storage in FileSystem) configuration for BRTOOLS
To increase the security of database connections, SAP Kernel 7.20 Patch Level 100, introduces a new method for the secure saving of the SAP database user or SAP database password. This method stores data for connection to the database in so-called SSFS (Secure Storage in FileSystem). For more information, see SAP Notes: 1622837, 1639578 and 1764043.
To activate SSFS please use the following steps:
- Create the appropriate folder: /oracle/SID/security/rsecssfs/data and /oracle/SID/security/rsecssfs/key
- Check or create the user brt$adm in the database:
- SQL> create user brt$adm identified by <your password>
- SQL> grant sapdba, sysdba, sysoper to brt$adm;
- The initial password shall be changed to the actual password using brconnect…
- brconnect -u SAPSR3/PASSWORD -c -f chpass -o ‘BRT$ADM’ -p ‘<your password>‘ -s brtools
- Now we can test it:
- brconnect -u // -c -f check
Konfiguracja SSFS (Secure Storage in FileSystem) dla BRTOOLS
Aby zwiększyć bezpieczeństwo połączeń z bazą danych, SAP Kernel 7.20 Patch Level 100 wprowadza nową metodę bezpiecznego przechowywania użytkownika i hasła bazy danych. Metoda ta przechowuje dane dla połączenia z bazą danych w tak zwanym SSFS (Secure Storage in FileSystem). Aby uzyskać więcej informacji, zobacz SAP Noty: 1622837, 1639578 oraz 1764043.
Kroki do wykonania w celu aktywacji SSFS:
- Tworzymy folder: /oracle/SID/security/rsecssfs/data + /oracle/SID/security/rsecssfs/key
- Sprawdzamy/Tworzymy użytkownika brt$adm w bazie danych:
- SQL> create user brt$adm identified by <your password>
- SQL> grant sapdba, sysdba, sysoper to brt$adm;
- Z poziomu brtools raz jeszcze ustawiamy to samo hasło, które wpisaliśmy powyżej – dzięki temu hasło zostanie zapisane w keystore, np.:
- brconnect -u SAPSR3/HASLO -c -f chpass -o ‘BRT$ADM’ -p ‘<your password>‘ -s brtools
- Robimy sprawdzenie czy brtools działają bez hasła – wcześniej musimy sprawdzić czy w lokalizacji jest plik: /oracle/SID/18/dbs/initSID.sap
- brconnect -u // -c -f check
SAP Java – changing instance name after refreshing the system with production data
In the following scenario, we’ll focus on changing the instance name (SID). The data of the SAP Java test instance will be replaced with data from the production system. The database refresh process itself will be the subject of a separate article.
At this moment, we will focus on the steps that should be taken after such a refresh of the database, on the server where we have the JAVA instance running. Let’s assume that:
- test Java instance name is “TST”, host: test01, instance numbers: J47 and SCS46;
- the name of the production JAVA instance is “PRD”, host: prod01, instance numbers J47 and SCS46;
- before refreshing, the TST system was embedded on NetWeaver 7.4, while the production system was already in NetWeaver 7.5;
- the TST instance has been overwritten with data from the PRD system.
SAP Java – zmiana nazwy instancji (SID) po odświeżeniu systemu danymi z produkcji
W poniższym scenariuszu skupimy się na zmienie nazwy instancji (SID). Dane testowej instancji SAP Java zostaną zastąpione danymi z systemu produkcyjnego. Sam proces odświeżenia bazy danych będzie przedmiotem osobnego artykułu.
W tym momencie skupimy się na krokach, które należy wykonać już po takim odświeżeniu bazy danych, na serwerze gdzie mamy uruchomioną instację JAVA. Przyjmijmy, że:
- nazwa testowej instacji Java to “TST“, host: test01, nr instancji: J47 i SCS46;
- nazwa produkcyjnej instancji JAVA to “PRD“, host: prod01, nr instancji J47 i SCS46;
- system TST przed odświeżeniem był osadzony na NetWeaver 7.4, natomiast system produkcyjny był już w wersji NetWeaver 7.5;
- instancja TST, została nadpisana danymi z systemu PRD.