Systemänderbarkeit automatisch auf "nicht änderbar"


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon LostDarkness » 25.01.2019, 10:43

Guten Morgen ABAP-Menschen,

auch wenn ich selbst nicht sehr begeistert von der einer automatischen Anpassung der Systemänderbarkeit bin habe ich trotz Protest meinerseits
die Aufgabe bekommen einen Report zu schreiben welcher als Job eingeplant werden soll, in welchem kontrolliert wird ob die Systemänderbarkeit ( SCC4 + SE06 ) auf "nicht änderbar" gesetzt sind.
Falls das betroffene System auf "änderbar" gesetzt ist soll der Report die Änderbarkeit automatisch auf "nicht änderbar" setzen.

Ich verzweifel schon bei der Suche nach Funktionsbausteinen welche mir direkte Datenbankzugriffe auf die TADIR, DLV_SYSTC, TRNSPACE und die T000 abnehmen würden,
da ich bevorzugt direkte Änderungen auf den Tabellen vermeiden wollen würde.

Die Protokollierung der SCC4 ist durch das Änderungskennzeichen der T000 gewährleistet, für die Protokollierung der SE06-Spezifischen Anpassungen werde ich auch auf den
FuBa "tr_write_log" zurückgreifen müssen, wenn ich das nun richtig recherchiert habe.

Ich bitte um etwas Unterstützung,
vielen Dank und liebe Grüße
Gerrit.
LostDarkness
ForumUser
 
Beiträge: 32
Registriert: 07.06.2018, 10:21
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon zzcpak » 25.01.2019, 15:17

naja SCC4 ist ja auch nur SM30 für Tabelle T000.
Soweit ich das sehe, gibt es auch für Updates auf Namensräume und Softwarekomponenten keine Bausteine. Läuft scheinbar alles über direkte Updates (siehe Report RSWBO004)

Nebenbei halte ich das automatische Verrammeln von Systemen u.U. für kontraproduktiv. Wenn z.B. der SAP-Support gerade ein offenes System benötigt, um die Welt zu retten, zieht man den Kollegen somit gleich den Teppich unter den Füßen weg.

Eine Warnung mit z.B. Mail-Benachrichtigung ist ja gut und sinnvoll, aber gleich wieder ohne Rückfrage schließen ....?
Offene Systeme lassen sich übrigens auch mit dem Solution-Manager überwachen.
zzcpak
Expert
 
Beiträge: 632
Registriert: 29.07.2003, 15:10
Dank erhalten: 53 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon ewx » 25.01.2019, 16:35

zzcpak hat geschrieben:Nebenbei halte ich das automatische Verrammeln von Systemen u.U. für kontraproduktiv. Wenn z.B. der SAP-Support gerade ein offenes System benötigt, um die Welt zu retten, zieht man den Kollegen somit gleich den Teppich unter den Füßen weg.


Ich kann die Anforderung verstehen. Es gab bereits Systeme, die aufgrund dringender Änderungen aufgemacht wurden und dann vergessen wurde, sie wieder zu schließen.
Wahrscheinlich soll der Report auch nicht alle 5 Minuten laufen, sondern eher einmal nachts oder am Wochenende...
ewx
Top Expert
 
Beiträge: 3870
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 334 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon DeathAndPain » 25.01.2019, 16:41

Trotzdem würde auch ich da eine automatisch erzeugte böse Email an einen passenden Administratoren-Emailverteiler (mit der Geschäftsführung in CC) besser finden als einen Code, der selber in die SCC4 eingreift und bei Bugs möglicherweise Unvorhergesehenes anrichtet.
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon zzcpak » 28.01.2019, 08:18

Soweit würde ich gar nicht gehen. Man muss nicht immer gleich alles rumpetzen.

Kommt halt eben auch darauf an, wie System-Öffnungen generell geregelt sind. Unter 46B hatte ich dazu auch mal einen Report geschrieben, der glaube ich stündlich eingeplant war. Mail an das Basis-Team, die das System dann wieder schließen. Da sowieso nur das Basis-Team zu dieser Aktion berechtigt war (auf Anforderung durch Business), war das dann mehr Selbstkontrolle. Mittlerweile wird das über einen Solman-Alert gelöst.

Diese Art des Monitoring hat dann auch den Auditoren gereicht.
zzcpak
Expert
 
Beiträge: 632
Registriert: 29.07.2003, 15:10
Dank erhalten: 53 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon LostDarkness » 28.01.2019, 09:17

zzcpak hat geschrieben:naja SCC4 ist ja auch nur SM30 für Tabelle T000.
Soweit ich das sehe, gibt es auch für Updates auf Namensräume und Softwarekomponenten keine Bausteine. Läuft scheinbar alles über direkte Updates (siehe Report RSWBO004)

SCC4 ist auch eher weniger das Problem, die SE06 bereitet mir etwas mehr trouble. Insbesondere die Protokollierung. Ich hatte quasi schon ein lauffähiges Programm,
welches alle nötigen Instanzen gesperrt hat + das dazugehörige Protokoll via 'tr_write_log' erstellt hat. Danach gab es aber Probleme dabei, das System wieder zu öffnen, aufgrund
dessen das scheinbar die Öffnung Daten mit den gleichen Schlüsselfeldern protokollieren wollte, als zuvor durch meinen Baustein angelegt wurden,
diese mussten wir dann manuell wieder entfernen um das System wieder freigeben zu können...

Nebenbei halte ich das automatische Verrammeln von Systemen u.U. für kontraproduktiv. Wenn z.B. der SAP-Support gerade ein offenes System benötigt, um die Welt zu retten, zieht man den Kollegen somit gleich den Teppich unter den Füßen weg.

Eine Warnung mit z.B. Mail-Benachrichtigung ist ja gut und sinnvoll, aber gleich wieder ohne Rückfrage schließen ....?
Offene Systeme lassen sich übrigens auch mit dem Solution-Manager überwachen.


Ich selbst bin wie erwähnt auch kein Fan dieser Lösung, die Anforderung selbst kommt aber von der Basis.
Es soll auch auf einem Selektionsbild definierbar sein bis wann das System geöffnet bleiben soll, um so eine Schließung zu verhindern wenn das System grad im offenen Zustand benötigt wird, aber das ist
ja mit nicht problematisch.
Programm soll nächtlich als Job eingeplant werden und per Mail über den folglichen Systemstatus informieren.

Danke schon einmal für euren Input, wirklich weiter bin ich aber leider noch nicht :D
Liebe Grüße
Gerrit
LostDarkness
ForumUser
 
Beiträge: 32
Registriert: 07.06.2018, 10:21
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon zzcpak » 28.01.2019, 09:33

LostDarkness hat geschrieben:SCC4 ist auch eher weniger das Problem, die SE06 bereitet mir etwas mehr trouble. Insbesondere die Protokollierung. Ich hatte quasi schon ein lauffähiges Programm,
welches alle nötigen Instanzen gesperrt hat + das dazugehörige Protokoll via 'tr_write_log' erstellt hat. Danach gab es aber Probleme dabei, das System wieder zu öffnen, aufgrund
dessen das scheinbar die Öffnung Daten mit den gleichen Schlüsselfeldern protokollieren wollte, als zuvor durch meinen Baustein angelegt wurden,
diese mussten wir dann manuell wieder entfernen um das System wieder freigeben zu können...


Ah, die Herren von der Basis sind bequem und wollen das automatisieren. Chice Aufgabe :)

Hattest du dich bei Namensräumen/Softwarekomponenten an die Vorgehensweise der FORM Routine UPDATE in Report RSWBO004 gehalten?
zzcpak
Expert
 
Beiträge: 632
Registriert: 29.07.2003, 15:10
Dank erhalten: 53 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon LostDarkness » 28.01.2019, 09:40

zzcpak hat geschrieben:
LostDarkness hat geschrieben:SCC4 ist auch eher weniger das Problem, die SE06 bereitet mir etwas mehr trouble. Insbesondere die Protokollierung. Ich hatte quasi schon ein lauffähiges Programm,
welches alle nötigen Instanzen gesperrt hat + das dazugehörige Protokoll via 'tr_write_log' erstellt hat. Danach gab es aber Probleme dabei, das System wieder zu öffnen, aufgrund
dessen das scheinbar die Öffnung Daten mit den gleichen Schlüsselfeldern protokollieren wollte, als zuvor durch meinen Baustein angelegt wurden,
diese mussten wir dann manuell wieder entfernen um das System wieder freigeben zu können...


Ah, die Herren von der Basis sind bequem und wollen das automatisieren. Chice Aufgabe :)

Hattest du dich bei Namensräumen/Softwarekomponenten an die Vorgehensweise der FORM Routine UPDATE in Report RSWBO004 gehalten?


Ich habe mich grundsätzlich soweit möglich an der RSWBO004 orientiert, auch bezüglich des Updates.
Würde gerne Beispielcode liefern, aber aufgrund dessen, das meine alte Version zu zuvor genanntem Protokoll-Problem geführt hat, wurde ich wenns man nett ausdrücken möchte, drum gebeten
es zu löschen und nochmal neu zu beginnen..
LostDarkness
ForumUser
 
Beiträge: 32
Registriert: 07.06.2018, 10:21
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon zzcpak » 28.01.2019, 10:16

war das gute Stück schon produktiv?
Aber auch, wenn es gelöscht wurde, findet sich ja sicherlich noch eine Version in der Versionsdatenbank.
zzcpak
Expert
 
Beiträge: 632
Registriert: 29.07.2003, 15:10
Dank erhalten: 53 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon LostDarkness » 28.01.2019, 10:27

zzcpak hat geschrieben:war das gute Stück schon produktiv?
Aber auch, wenn es gelöscht wurde, findet sich ja sicherlich noch eine Version in der Versionsdatenbank.


Produktiv nicht, war zu Testzwecken in einem Q-System, aber das Resultat war aufgrund des erwähnten Fehlers leider nicht wie gewünscht.
Ich mache mir die ganze Zeit schon Gedanken wie ich das anders aufbauen könnte als zuvor, komme aber nicht von meinem alten Weg ab.

Ich schaue bei Zeiten mal ob ich noch das alte Coding irgendwo finde, aber weder im Entwicklungs- noch im Testsystem habe ichs auf die schnelle ausfindig machen können.
LostDarkness
ForumUser
 
Beiträge: 32
Registriert: 07.06.2018, 10:21
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon zzcpak » 28.01.2019, 10:47

auch gelöschte Programme sollten zumindest im Entwicklungssystem noch in der Versionsdatenbank liegen.

SE38
Programmname eingeben
Hilfsmittel - Versionen - Versionsverwaltung

dort kannst du dir das Coding dann ansehen und ggfs. auch zurückholen
zzcpak
Expert
 
Beiträge: 632
Registriert: 29.07.2003, 15:10
Dank erhalten: 53 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon DeathAndPain » 28.01.2019, 11:46

zzcpak hat geschrieben:Soweit würde ich gar nicht gehen. Man muss nicht immer gleich alles rumpetzen.

Kommt halt eben auch darauf an, wie System-Öffnungen generell geregelt sind. Unter 46B hatte ich dazu auch mal einen Report geschrieben, der glaube ich stündlich eingeplant war. Mail an das Basis-Team, die das System dann wieder schließen.

Ja, ich hatte meinen drastischen Vorschlag in dieser Form auch nicht ganz ernst gemeint. Hätte vielleicht einen :wink: dazupacken sollen. Wir hatten das hier vor Jahren auch schon mal, dass die Auditoren (oder war es die höhere Führungsetage) einen täglich laufenden Job haben wollten, der ihnen eine Infomail schickt, wenn bestimmte, entscheidende Systemparameter nicth richtig stehen. Systemöffnung könnte dazugehört haben.

Das haben wir dann auch so implementiert, dass jeweils eine Stunde eher der Report ein zweites Mal mit uns als Adressaten gelaufen ist, so dass wir bei derlei Pannen ein Zeitfenster von einer Stunde hatten, das Problem zu beseitigen, bevor es für die wichtigen Leute geprüft wird.
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon zzcpak » 28.01.2019, 12:59

DeathAndPain hat geschrieben:Das haben wir dann auch so implementiert, dass jeweils eine Stunde eher der Report ein zweites Mal mit uns als Adressaten gelaufen ist, so dass wir bei derlei Pannen ein Zeitfenster von einer Stunde hatten, das Problem zu beseitigen, bevor es für die wichtigen Leute geprüft wird.


hehe, das war dann weise Voraussicht.

Mittlerweile lassen sich ja auch viele Sachen mit dem Solution-Manager überwachen, auch Profilparameter mit diesen Root Cause Analysis. Aber ein Tool zum automatisierten Öffnen/Schließen von Systemen ist mir auch noch nicht über den Weg gelaufen. Scheint auch nicht so ganz trivial zu sein.

Aber ohne Coding ist es auch schwer, hier Hilfestellung zu leisten.
zzcpak
Expert
 
Beiträge: 632
Registriert: 29.07.2003, 15:10
Dank erhalten: 53 mal

Re: Systemänderbarkeit automatisch auf "nicht änderbar"

Beitragvon LostDarkness » 28.01.2019, 15:02

zzcpak hat geschrieben:auch gelöschte Programme sollten zumindest im Entwicklungssystem noch in der Versionsdatenbank liegen.

SE38
Programmname eingeben
Hilfsmittel - Versionen - Versionsverwaltung

dort kannst du dir das Coding dann ansehen und ggfs. auch zurückholen


Ich danke dir, habs in der Versionsverwaltung finden können.
Berechtigungsprüfung und E-Mailversand hab ich erst einmal ausgelassen.

Code: Alles auswählen
REPORT zca_syslock.

TYPES: tt_log     LIKE sprot_u    OCCURS 0,
       ts_log     LIKE sprot_u.

DATA: it_t000     TYPE TABLE OF t000,
      it_tadir    TYPE TABLE OF tadir,
      it_trnspace TYPE TABLE OF trnspace,
      it_trnnew   TYPE TABLE OF trnspace,
      it_dlvsystc TYPE TABLE OF dlv_systc,
      it_dlvnew   TYPE TABLE OF dlv_systc,

      wa_t000     LIKE LINE OF it_t000,
      wa_trnspace LIKE LINE OF it_trnspace,
      wa_trnnew   LIKE LINE OF it_trnnew,
      wa_dlvsystc LIKE LINE OF it_dlvsystc,
      wa_dlvnew   LIKE LINE OF it_dlvnew,

      lv_newsection TYPE c,

      pt_msgs     TYPE tt_log,
      ls_log      TYPE ts_log.

FIELD-SYMBOLS: <wa_t000> TYPE t000,
               <wa_trnspace> TYPE trnspace,
               <wa_dlvsystc> TYPE dlv_systc,
               <wa_tadir> TYPE tadir.

SELECTION-SCREEN BEGIN OF BLOCK a1.
SELECT-OPTIONS: so_users FOR sy-uname.
PARAMETER:      p_close TYPE c.
SELECTION-SCREEN END OF BLOCK a1.


IF p_close = 'X'.


  SELECT * FROM tadir INTO CORRESPONDING FIELDS OF TABLE it_tadir
                             WHERE pgmid = 'HEAD'
                              AND object = 'SYST'
                              AND obj_name = ' '.
  IF sy-subrc = 0.
    LOOP AT it_tadir ASSIGNING <wa_tadir>.
      IF <wa_tadir>-edtflag = 'X'.
        <wa_tadir>-edtflag = ''.

        IF pt_msgs IS INITIAL.
          lv_newsection = 'X'.
        ELSE.
          lv_newsection = ''.
        ENDIF.
        PERFORM append_log USING  pt_msgs
                        '2' '' 'TO' '170' text-c01 text-c03 '' '' lv_newsection.

*      MODIFY tadir FROM <wa_tadir>.

      ENDIF.
    ENDLOOP.
  ENDIF.

  SELECT  * FROM t000 INTO CORRESPONDING FIELDS OF TABLE it_t000
                             WHERE mandt = sy-mandt.
  IF sy-subrc = 0.
    LOOP AT it_t000 ASSIGNING <wa_t000>.
      IF <wa_t000>-ccnocliind = ' '.
        <wa_t000>-ccnocliind = '3'.
        IF <wa_t000>-cccoractiv <> '2'.
          <wa_t000>-cccoractiv = '2'.
*        MODIFY t000 FROM <wa_t000>.
        ENDIF.
      ENDIF.
    ENDLOOP.
  ELSE.
    MESSAGE 'Fehler beim Lesen der t000.' TYPE 'I' .
  ENDIF.

  SELECT * FROM trnspace INTO CORRESPONDING FIELDS OF TABLE it_trnspace
                         WHERE editflag = 'X'.
  IF sy-subrc = 0.
    LOOP AT it_trnspace ASSIGNING <wa_trnspace>.

      <wa_trnspace>-editflag = ' '.

      IF pt_msgs IS INITIAL.
        lv_newsection = 'X'.
      ELSE.
        lv_newsection = ''.
      ENDIF.
      PERFORM append_log USING pt_msgs
                        '2' ' ' 'TO' '171' <wa_trnspace>-namespace text-c01 text-c02 '' lv_newsection.

      APPEND <wa_trnspace> TO it_trnnew.
    ENDLOOP.
*    MODIFY trnspace FROM TABLE it_trnnew.
  ELSE.
    MESSAGE 'Fehler beim Lesen der trnspace.' TYPE 'I'.
  ENDIF.

  SELECT * FROM dlv_systc INTO CORRESPONDING FIELDS OF TABLE it_dlvsystc
                          WHERE changeable <> 'N'.
  IF sy-subrc = 0.
    LOOP AT it_dlvsystc ASSIGNING <wa_dlvsystc>.

      IF pt_msgs IS INITIAL.
        lv_newsection = 'X'.
      ELSE.
        lv_newsection = ''.
      ENDIF.
      CASE <wa_dlvsystc>-changeable.
        WHEN 'F'.
          PERFORM append_log USING pt_msgs
                      '2' ' ' 'TO' '171' <wa_dlvsystc>-dlvunit text-c01 text-c02 '' lv_newsection.
        WHEN 'R'.
          PERFORM append_log USING pt_msgs
                      '2' ' ' 'TO' '171' <wa_dlvsystc>-dlvunit text-c04 text-c02 '' lv_newsection.
        WHEN 'E'.
          PERFORM append_log USING pt_msgs
                      '2' ' ' 'TO' '171' <wa_dlvsystc>-dlvunit text-c05 text-c02 '' lv_newsection.
        WHEN OTHERS.
      ENDCASE.

      <wa_dlvsystc>-changeable = 'N'.

      APPEND <wa_dlvsystc> TO it_dlvnew.
    ENDLOOP.
*    MODIFY dlv_systc FROM TABLE it_dlvnew.
  ENDIF.

*  PERFORM ddprs_log.


ENDIF.

*&amp;---------------------------------------------------------------------*
*&amp;       FORM APPEND_LOG                                               *
*&amp;---------------------------------------------------------------------*
FORM append_log  USING  pt_log        TYPE tt_log
                        pv_level      LIKE sprot_u-level
                        pv_severity   LIKE sprot_u-severity
                        pv_msgid      LIKE sprot_u-ag
                        pv_msgnr      LIKE sprot_u-msgnr
                        pv_var1        "like sprot_u-var1
                        pv_var2        "like sprot_u-var2
                        pv_var3        "like sprot_u-var3
                        pv_var4       LIKE sprot_u-var4
                        pv_newsection LIKE sprot_u-newobj.

  DATA: ls_log TYPE ts_log.

  ls_log-level    =  pv_level.
  ls_log-severity =  pv_severity.
  ls_log-langu    =  sy-langu.
  ls_log-ag       =  pv_msgid.
  ls_log-msgnr    =  pv_msgnr.
  ls_log-newobj   =  pv_newsection.
  ls_log-var1     =  pv_var1.
  ls_log-var2     =  pv_var2.
  ls_log-var3     =  pv_var3.
  ls_log-var4     =  pv_var4.
  APPEND ls_log TO pt_log.
ENDFORM.                    "append_log

*&amp;---------------------------------------------------------------------*
*&amp;      Form  DDPRS_LOG
*&amp;---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*  -->  p1        text
*  <--  p2        text
*----------------------------------------------------------------------*
FORM ddprs_log .

  PERFORM append_log USING pt_msgs
                    '4' ' ' 'TO' '174' sy-datum sy-uzeit sy-uname '' ''.

  CALL FUNCTION 'TR_WRITE_LOG'
    EXPORTING
      iv_log_type   = 'DB'
      iv_logname_db = 'TRLOGSYSTEM'
    TABLES
      it_msgs       = pt_msgs
    EXCEPTIONS
      OTHERS        = 1.

ENDFORM.                    " DDPRS_LOG



PS: Ich habe die Modifys auskommentiert, da so ein Modify im Entwicklungssystem durchaus kritisch sein könnte, für den funktionalen Einsatz müssen diese natürlich wieder inkludiert werden.
LostDarkness
ForumUser
 
Beiträge: 32
Registriert: 07.06.2018, 10:21
Dank erhalten: 0 mal
Ich bin: Entwickler/in


Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Adobe Forms - Download - Keine Seiten
vor 11 Stunden von shimsham 2 Antw.
UTF-8 mit Funktionsbaustein
vor 13 Stunden von a-dead-trousers 4 Antw.
gelöst Fehler SAVE NOT ALLOWED bei F4IF_START_VALUE_REQUEST
vor 10 Stunden von AdrianSchm 1 Antw.
SAP Logon bei Aufruf WebGUI
Gestern von msfox 0 Antw.
Formatierung Textdatei aus Query und ABAP
vor 13 Stunden von wreichelt 5 Antw.

  Ähnliche Beiträge beta
SAP-System hat den Status "nicht änderbar"
13.09.2006, 10:45 von Kmattes 4 Antw.
Dynpro "INPUT" konnte nicht interpretiert werden
03.01.2012, 16:01 von a-dead-trousers 6 Antw.
Infotyp-Felder werden nicht in "Überblick" angezeigt
30.01.2017, 10:22 von Dyrdek 0 Antw.
GUI-Status "Neue Einträge", "Ändern" ...
08.04.2008, 19:52 von SAPAlex 4 Antw.
"Ranges Tabelle" anstatt "for all entries"?
25.03.2015, 20:02 von a-dead-trousers 4 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder