Eigene "reportAction" Methode - wie am besten integrieren?

The place for development of / with / for opsi.
Post your API questions here!
pandel
Beiträge: 658
Registriert: 25 Jan 2013, 16:47

Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon pandel » 13 Sep 2018, 12:22

Hi!

Ich denke darüber nach, für unser internes Change Management eine eigene Methode "reportAction" zu kreieren, die mir in eine separate MySQL Datenbank bei durchgeführten Produkaktionen reinschreibt, wer was wann auf welcher Maschine initiiert hat.

In einem ersten Anlauf würde ich gerne jede setProductActionRequest mit Zeitstempel in eine Tabelle hauen.

Rein konzeptionell, wie gehe am einfachsten vor, um die Daten aus der passenden Methode abzugreifen?

Lieber Gruß
Holger

Benutzeravatar
n.wenselowski
Beiträge: 2886
Registriert: 04 Apr 2013, 12:15

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon n.wenselowski » 21 Sep 2018, 15:35

Hi Holger,

vermutlich wird das ganze aufwändiger als gedacht, weil du die Information willst wer die Installation durchgeführt hat.
Ohne diese Information könntest du die gewünschte Methode einfach überschreiben und um den DB-Zugriff ergänzen.

Wenn du das später für weitere Methoden ausbauen willst, würde ich vermtulich ein eigenes BackendAccessControl auf Basis des bereits bestehenden implementieren, welches neben der Zugriffskontrolle auch die gewünschten Informationen über die Aufrufe erhebt.
BackendAccessControl daher, weil dieses auch Informationen über den zugreifenden Benutzer hat - die Backends zur Datenhaltung haben diese nämlich in der Regel nicht.


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.

pandel
Beiträge: 658
Registriert: 25 Jan 2013, 16:47

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon pandel » 21 Sep 2018, 16:00

Hi Niko!

Ayayay... das klingt deutlich aufwändiger, als erwartet. Na gut, dann habe ich zumindest mal eine grobe Richtung in die ich denken kann. Ob und wie das was wird, steht eh noch in den Sternen, ich hab so wenig Zeit. Andererseits steht mir unsere externe Prüfung im Nacken, die das unbedingt will und momentan muss ich das zu Fuß festhalten. Das Tool von unserem RZ kann das kreuz und quer und rechts und links, nur opsi leider nicht, daher hatte ich gehofft, dass halbswegs einfach implementieren zu können... nut gut, wir werden sehen.

Besten Dank und ein schönes Wochenende!

Bis denn,
Holger

Benutzeravatar
n.wenselowski
Beiträge: 2886
Registriert: 04 Apr 2013, 12:15

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon n.wenselowski » 21 Sep 2018, 16:09

Hi Holger,

ich habe Audit-Anforderungen im Hinterkopf für den Webservice-Rebuild mit Python 3. Steht nicht explizit auf der Roadmap, aber ich würde generell gerne eine einfache Möglichkeit haben mich ins Processing zu hängen und Auswertungen machen zu können (u.a. App Performance-Daten).
Aktuell ist es leider nur relativ aufwändig möglich.
Wir könnten sowas für dich im Rahmen vom Support bauen, aber das heißt ja dann auch wieder, dass sich der Bau des neuen Webservice verzögert :roll: :lol:


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.

pandel
Beiträge: 658
Registriert: 25 Jan 2013, 16:47

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon pandel » 21 Sep 2018, 16:11

Dachte ich mir schon... wie das Thema in puncto Support ausgeht, hör ich von meinen Vorgesetzten, die das zu entscheiden haben, jetzt schon :roll: ... da wurde schon in ganz anderen Bereichen abgewunken. Da es ja zu Fuß geht, warum automatisieren :shock: :x pfff!

Nö nö, besser, es geht allgemein voran ;) - da profitieren wenigstens alle davon!

Benutzeravatar
n.wenselowski
Beiträge: 2886
Registriert: 04 Apr 2013, 12:15

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon n.wenselowski » 12 Nov 2018, 10:46

Hi Holger,

da Arbeiten in Richtung neuem Webservice gut voran gehen noch mal die Nachfrage welche Daten du willst:
  • Wer hat
  • wann
  • welche Methode
  • mit welchen Parametern ausgeführt?

Fehlt dabei noch etwas?

Ich würde mir jetzt noch vorstellen, dass gelockt wird ob es ausgeführt wurde und falls nicht evtl. ein Grund warum nicht.


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.

pandel
Beiträge: 658
Registriert: 25 Jan 2013, 16:47

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon pandel » 12 Nov 2018, 11:16

Hi Niko!

Im Grunde hast du fast alle wichtigen Punkte drin. Da ich unsere Prüfer kenne (und die sind, glaube ich, schon recht hardcore drauf), erweitere ich das mal passend:

  • Wer hat
  • wann
  • welche Methode
  • bei welchem Produkt
  • in welcher Version
  • auf welcher Maschine
  • mit welchen Parametern ausgeführt
Es ist nämlich ein beliebtes Spiel zu fragen, ab wann welche Produktversion einer bestimmten Software auf einer Maschine eingesetzt wurde, vor allem dann, wenn es um den Nachweis eines zeitlich korrekten Einsatzes bei Änderung gesetzlicher Rahmenbedingungen geht ;)...

Das mit deinen Zusatzpunkten halte ich ebenso für absolut sinnvoll! Wenn die Daten eh schon da sind, ergibt das eine super Schnellübersicht!

Lieber Gruß
Holger

Benutzeravatar
n.wenselowski
Beiträge: 2886
Registriert: 04 Apr 2013, 12:15

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon n.wenselowski » 12 Nov 2018, 13:48

Hi Holger,

pandel hat geschrieben:
  • Wer hat
  • wann
  • welche Methode
  • bei welchem Produkt
  • in welcher Version
  • auf welcher Maschine
  • mit welchen Parametern ausgeführt
Es ist nämlich ein beliebtes Spiel zu fragen, ab wann welche Produktversion einer bestimmten Software auf einer Maschine eingesetzt wurde, vor allem dann, wenn es um den Nachweis eines zeitlich korrekten Einsatzes bei Änderung gesetzlicher Rahmenbedingungen geht ;)...

Okay, das ist dann recht speziell auf die Produkte zugeschnitten und besonders die Beantwortung der Frage nach der Version würde dann im Nachgang nochmal etwas interaktion mit dem Server erfordern.

Außen vor ist hierbei auch wenn an der Konfiguration (von Server oder spezifischem Client) über die API etwas angepasst wird.
Wenn es sowieso sehr spezielle Anfragen betrifft, dann macht es eventuell Sinn das direkt im Backend zu verankern, anstatt nur den Request im Webservice zu loggen.
Ich hatte anfangs gedacht relativ simpel den Request nicht nur ans Backend zu dispatchen, sondern noch zu anderer Stelle (Audit-Logger) weiterzuleiten. Der Charme dabei ist für mich, dass es weniger Arbeit im Backend selbst produziert und man dabei auch eventuell abgewiesene Anfragen mitbekommt. Wenn jetzt aber eine Methode wie setProductActionRequest aufgerufen wird, macht diese intern ja noch weitere Methoden-Aufrufe.
Für eine zuverlässige Auswertung müsste außerdem sichergestellt werden, dass die Erweiterungs-Methoden einem bestimmten Stand (dem von Software-Paket-Version X.Y) entsprechen. Könnte sowas auch eine Rolle spielen?

Vielleicht wird es dann doch Sinn machen hierzu auf ein dediziertes Backend zu gehen.


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.

pandel
Beiträge: 658
Registriert: 25 Jan 2013, 16:47

Re: Eigene "reportAction" Methode - wie am besten integrieren?

Beitragvon pandel » 12 Nov 2018, 17:03

Ich bin mir nicht sicher, was genau du mit "Erweiterungs-Methoden" genau meinst, daher kann ich das iwie nicht beurteilen, inwieweit das eine Rolle spielt...

Da ich das Backend zu wenig kenne, habe ich nur sehr rudimentäre Ideen, wie das gehen könnte (als class mixin, via message queue, whatever...), aber grundsätzlich würde ich die Daten auch im am ehesten im Backend abgreifen. Wobei, wenn du eben in irgendeiner Art Senden-Empfangen Stil Reportdaten verarbeiten würdest, könnte natürlich auch der Webservice seinen Senf dazu geben.