Systemänderbarkeit automatisch auf "nicht änderbar"

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
14 Beiträge • Seite 1 von 1
14 Beiträge Seite 1 von 1

Systemänderbarkeit automatisch auf "nicht änderbar"

Beitrag von LostDarkness (ForumUser / 87 / 15 / 6 ) »
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.
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


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

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
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.

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

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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...

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

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

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

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
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.

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

Beitrag von LostDarkness (ForumUser / 87 / 15 / 6 ) »
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
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin

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

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
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?

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

Beitrag von LostDarkness (ForumUser / 87 / 15 / 6 ) »
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..
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin

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

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
war das gute Stück schon produktiv?
Aber auch, wenn es gelöscht wurde, findet sich ja sicherlich noch eine Version in der Versionsdatenbank.

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

Beitrag von LostDarkness (ForumUser / 87 / 15 / 6 ) »
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.
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin

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

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
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

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

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

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

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
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.

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

Beitrag von LostDarkness (ForumUser / 87 / 15 / 6 ) »
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.

*&---------------------------------------------------------------------*
*&       FORM APPEND_LOG                                               *
*&---------------------------------------------------------------------*
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

*&---------------------------------------------------------------------*
*&      Form  DDPRS_LOG
*&---------------------------------------------------------------------*
*       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.
“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin

Seite 1 von 1

Vergleichbare Themen

6
Antw.
5536
Views
Welche Parameter in Systemänderbarkeit für Löschen in SE16?
von Irie » 16.11.2005 17:03 • Verfasst in Basis
4
Antw.
3183
Views
ALV Layout nicht änderbar
von SAP_ENTWICKLER » 20.11.2015 09:16 • Verfasst in ABAP® Core
3
Antw.
5467
Views
Partnergesellschaft nicht änderbar
von BarbaraM » 22.08.2006 15:33 • Verfasst in Financials
0
Antw.
1292
Views
Naturalrabatt manuell änderbar...
von Niekohle » 24.04.2007 11:51 • Verfasst in Sales and Distribution
2
Antw.
4166
Views
SAP-System hat den Status nicht änderbar
von mc12345 » 04.06.2014 14:03 • Verfasst in Web-Dynpro, BSP + BHTML

Über diesen Beitrag


Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141